アカウント名:
パスワード:
最後の最後で問題になりそうなのが実時間保証だと思うのですが, そのあたりってどうなんでしょう? NTSCのTV録画だと秒あたり30フレームを確実に処理しないといけないわけなので, エンコード自体はハードで行うとしても, ファイルへの書き込みやGUI操作時の優先度など, カーネル内のスケジューラやファイルシステムのバッファリング等の制御で, かなり高度な技術が必要になると思います.
このあたりはNECやシャープのやつではMontaVistaのリアルタイムLinuxがベースになっていたはずなので, 比較的楽ができるとは思いますが.
まあ, そこは割り切っちゃって時々こま落ちするのは仕方がないとすれば, 十分以上に実用になるのでしょうが.
SHARP ガリレオ [sharp.co.jp] の場合はRAW(特定のファイルシステムやパーティションに依存せず直接/dev/hdxをいじる)っぽいです。 完全に中身をハッキングしたわけではないので憶測の域を出ませんが、ハードディスクだけを取り出してLinux PCにマウントしたところ、パーティションテーブルもファイルシステムっぽい箇所も見あたらなかったので、おそらくそうだろうと思います。
間違ってたら指摘おな(ね)がいします。
NTSCのTV録画だと秒あたり30フレームを確実に処理しないといけないわけなので, エンコード自体はハードで行うとしても, (以下略)
MPEGがハードエンコードでという前提なら余程ショボいCPUでなければ全然問題無いでしょう。 MPEG-2でかなりの高画質にしても高々10Mbps程度です。 DVDがMa
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
ハードウェア的には (スコア:3, 参考になる)
とはいえ、日本製の奴で対応したのがなかなかないですけど(汗)
ATIや懐かしいVoodooのTV機能搭載した奴はいけそうなので、何発か積んで同時録がっていうのも面白いかもしれません。
先にあった日本対応部分ですが、確かチャンネル関係はVideo4Linuxのドライバで対応するような気がするのですが(っていうか、キャプチャカードが適正にその国の情報さえ持っていれば問題なさそうな気がします)、iEPGなどはConfig関係をいじらなければならないようです。(中までガリガリ書き込む必要はないかな)
日本対応の方はそれほど難しいとは思えませんが、やはりキャプチャカードの方が問題かもしれません。
#とか言いながら、落としてみたので、適当にいじってみようっと
ソフトウェア的には (スコア:3, 興味深い)
最後の最後で問題になりそうなのが実時間保証だと思うのですが, そのあたりってどうなんでしょう? NTSCのTV録画だと秒あたり30フレームを確実に処理しないといけないわけなので, エンコード自体はハードで行うとしても, ファイルへの書き込みやGUI操作時の優先度など, カーネル内のスケジューラやファイルシステムのバッファリング等の制御で, かなり高度な技術が必要になると思います.
このあたりはNECやシャープのやつではMontaVistaのリアルタイムLinuxがベースになっていたはずなので, 比較的楽ができるとは思いますが.
まあ, そこは割り切っちゃって時々こま落ちするのは仕方がないとすれば, 十分以上に実用になるのでしょうが.
Re:ソフトウェア的には (スコア:1)
なくて、スケジューラをいじった程度のものじゃなかったか
な。
Re:ソフトウェア的には (スコア:1, 興味深い)
事になりますね。TV録画用と割り切ってブロックサイズを
(数十秒分くらいに)大きくすれば軽減可能ですが…どうなってる
のでしょう?
# 既存のファイルシステムに頼らないつーアプローチもアリか。
Re:ソフトウェア的には (スコア:1, 参考になる)
SHARP ガリレオ [sharp.co.jp] の場合はRAW(特定のファイルシステムやパーティションに依存せず直接/dev/hdxをいじる)っぽいです。
完全に中身をハッキングしたわけではないので憶測の域を出ませんが、ハードディスクだけを取り出してLinux PCにマウントしたところ、パーティションテーブルもファイルシステムっぽい箇所も見あたらなかったので、おそらくそうだろうと思います。
間違ってたら指摘おな(ね)がいします。
Re:ソフトウェア的には (スコア:1, 興味深い)
パナのDMR-Eシリーズは高速なHDDでなくRAMなのに追っかけ再生とか出来るのはこのためだそうです。
Re:ソフトウェア的には (スコア:0)
MPEGがハードエンコードでという前提なら余程ショボいCPUでなければ全然問題無いでしょう。
MPEG-2でかなりの高画質にしても高々10Mbps程度です。
DVDがMa
Re:ソフトウェア的には (スコア:0)
>800Mbpsですから、バスもHDDもかなり余裕があります。
それは転送速度の上限であって、実際に出せる値ではない。特にメカニカルな動作の伴うHDDにおいては、って話だと思います。
#どのくらい余裕かは調べてないのでAC
Zapping等の場合 (スコア:2, 参考になる)
ただ、日本の音声多重や2ヶ国語放送は特殊仕様ですので、あきらめるしかなさそうです。
この辺に対応したチューナーを搭載しているボードは、Video4Linuxに対応していないものがほとんどです。
v4l対応カード (スコア:2, 参考になる)
> とはいえ、日本製の奴で対応したのがなかなかないですけど(汗)
いや意外とあるもんだよ。
実売価格1万円程度なカードでも十分遊べる。
IO DATA GV-TVBC4 PCIの場合
modprobe tuner type=15
modprobe bttv card=67
PCにECC Registeredメモリの利用を推奨します。
Re:v4l対応カード (スコア:0)
card番号探すのが結構手間だったりするけど
この手のボードはOEMが多いから結構使える。
Re:ハードウェア的には (スコア:2, 参考になる)
ベースになっているのはGerd Knorr氏のSAA7134(Philips製)ドライバ [bytesex.org]なのですが、Monster TV1は音声多重のデコードにMICRONAS社のMSP3445Gを使っているので、MSPドライバの日本向け特化を中心に暇を見てやっています。
# 今売られているMonsterTV 2は単体で日本の音声多重の
# デコードの出来るSAA7133を使ってるのでカード構成が違うかも(汗
現状ではVersion 0.2.7へのパッチを提供していて、自動検知でステレオや多重音声の外部音声出力端子経由(サウンドカードの録音端子経由)での音声デコードが出来ています。未だ詰めが甘いですけど。
# 新しいioctlを作って自動検知を封じる必要がありそうですが…
0.2.8preのSNAPSHOTだと音声周りが安定しているようなんですが、一つ前のSNAPSHOTだとSAA7134ドライバがmodprobe -r出来ないのでパッチを公表していません
…今のSNAPSHOTは問題がない。良く動いている。という投稿がv4l mlにあったので、余裕があるときに試しますが…
私の非力なDuronマシンではvcrとmp1e以外だと音声と画像の同期が取れない上に320x240での録画が事実上限界なので(xawtvは640x480で見れる)、このプロジェクトの成果物が音声と画像の同期が取れてVGAサイズの録画ができるようになると嬉しいですね。