アカウント名:
パスワード:
最後の最後で問題になりそうなのが実時間保証だと思うのですが, そのあたりってどうなんでしょう? NTSCのTV録画だと秒あたり30フレームを確実に処理しないといけないわけなので, エンコード自体はハードで行うとしても, ファイルへの書き込みやGUI操作時の優先度など, カーネル内のスケジューラやファイルシステムのバッファリング等の制御で, かなり高度な技術が必
SHARP ガリレオ [sharp.co.jp] の場合はRAW(特定のファイルシステムやパーティションに依存せず直接/dev/hdxをいじる)っぽいです。 完全に中身をハッキングしたわけではないので憶測の域を出ませんが、ハードディスクだけを取り出してLinux PCにマウントしたところ、パーティションテーブルもファイルシステムっぽい箇所も見あたらなかったので、おそらくそうだろうと思います。
間違ってたら指摘おな(ね)がいします。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
ハードウェア的には (スコア:3, 参考になる)
とはいえ、日本製の奴で対応したのがなかなかないですけど(汗)
ATIや懐かしいVoodooのTV機能搭載した奴はいけそうなので、何発か積んで同時録がっていうのも面白いかもしれません。
先にあった日本対応部分ですが、確かチャンネル関係はVideo4Linuxのドライバで対応するような気がするのですが(っていうか、キャプチャカードが適正にその国の情報さえ持って
ソフトウェア的には (スコア:3, 興味深い)
最後の最後で問題になりそうなのが実時間保証だと思うのですが, そのあたりってどうなんでしょう? NTSCのTV録画だと秒あたり30フレームを確実に処理しないといけないわけなので, エンコード自体はハードで行うとしても, ファイルへの書き込みやGUI操作時の優先度など, カーネル内のスケジューラやファイルシステムのバッファリング等の制御で, かなり高度な技術が必
Re:ソフトウェア的には (スコア:1, 興味深い)
事になりますね。TV録画用と割り切ってブロックサイズを
(数十秒分くらいに)大きくすれば軽減可能ですが…どうなってる
のでしょう?
# 既存のファイルシステムに頼らないつーアプローチもアリか。
Re:ソフトウェア的には (スコア:1, 参考になる)
SHARP ガリレオ [sharp.co.jp] の場合はRAW(特定のファイルシステムやパーティションに依存せず直接/dev/hdxをいじる)っぽいです。
完全に中身をハッキングしたわけではないので憶測の域を出ませんが、ハードディスクだけを取り出してLinux PCにマウントしたところ、パーティションテーブルもファイルシステムっぽい箇所も見あたらなかったので、おそらくそうだろうと思います。
間違ってたら指摘おな(ね)がいします。
Re:ソフトウェア的には (スコア:1, 興味深い)
パナのDMR-Eシリーズは高速なHDDでなくRAMなのに追っかけ再生とか出来るのはこのためだそうです。