http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%83%E3%83%88
後はヨロシク。
互換性の問題（VBR音声等）などもでた('∀`)
ASF マイクロソフトのマイクロソフトによるマイクロソフトの為のコンテナ。強力なDRM等で
普及はしてるがもっとユーザーが使いやすくなるようなソフトだせよヽ(`Д´)ﾉ
でも入手しやすく余計な事をせずにすぐ見れる為｝（Windows環境限定）一般人は好む。
MKV マトリョーシカの名前通りに何でも入れられるがコンセプト（だっけ）タイムコード制御
によるVFR、豊富な対応コーデック、字幕、チャプターの格納、複数トラック等機能豊富。
コレを作成、鑑賞するための日本語での情報は比較的少なく日本ではマイナー海外では
スタンダードになりつつある。マニアは使い続けそう(;´Д`)ﾊｧﾊｧ
MP4 期待の新星。対応コーデックはMKVより少ないが国際標準規格の安心感。フレーム
の表示タイミングをコンテナで制御する真VFR等機能面も充実。
ボックス構造と呼ばれる方式で柔軟な拡張が容易でありチャプター等も付けられる。
様々な場面での活躍が期待されるヾ(oﾟωﾟo)ﾉﾞ ！！！
ASFは一般人はつかわんだろｗ
WMV作って拡張子をAVIにして拡張子連動させて喜んでるレベル。
ASFが人気と言うことだろ。
MKVやOGMの再生には対応していない。
音声のトーン調節が可能で、MKVに対応しているプレイヤーって
どんなのがある？
WinampのDSPも使えるffdshowで何とかしろ。
ちょい難しい内容でスマンが。
過負荷で映像が遅れる、ソースレベルで同期していない等、音声のずれにも
いろいろある。キャプチャ時にRTCの精度が低く、不適切なサンプリング・レートが
設定されているだけなら、fpsを何らかのツールで書き換えるなどすれば正常化する。
fps値にはなるけど。
ありがとうです m(_ _)m
やあさぁ、水晶(RTC)とかの同期ズレだと思われるんだけど、
コンシューマ向けの低価格ムービーカメラのサンプル品で遊んでるんだけど
10時間くらい映像撮影してると 音声と映像で、1秒程度の同期ズレがでて
くるんだよね。(メーカいわく製品誤差だそうだが)
MOV形式だとずれないんだよね。
中でもアニオタは、録画時間の短さと、口パクによる許容範囲の大きさから、
数フレームずれてるくらいじゃ全く問題にされなかった。昔出回ったアナログ
録りの地下動画には、思いっきりずれてるのが山ほどある。
音は聞こえるのですが、画像が出ません。
どうしたらよさそうですか？
S:そうするよ
F:ふっ…
林檎儲はMacの中だけでmov使って自己満足に浸ってれば良いんじゃね。
見るのに苦労する。
私の知る限りではNero ShowTimeくらいでしか日本語字幕がまともに表示できない。
映像・主音声・副音声を格納したaviを最近見かけた。
これってどういうことなんだろうか
これとか。
http://en.wikipedia.org/wiki/DivX#DivX_Media_Format_.28DMF.29
英語が超苦手だが頑張って適当に読んでみたが
divxのコンテナがどうとか書いている気がする。
しかしながら俺が見つけた動画はxivd+mp3+mp3なんだ。
説明不足ですまん。
http://www.the-labs.com/Video/odmlff2-avidef.pdf
とはいえMicrosoftのオリジナルとは別物だし、そういった機能を使いたければMP4やMKVに
入れるべきだと思う。この場合はXvid(MPEG-4)とMP3だしどちらでもいいが。
>>38
.divxは.aviに変えてもいけたはず。
MP4でもいいけど
>>35
MP3ならDual-monoモードがあるから、モノラルなら主音声と副音声を両方
格納できるけどそれとは別？
（ ´∀｀）＜ MKVンテナ
（ ） ＼＿＿＿＿＿＿＿＿＿＿
｜ ｜ |
（_＿）＿）
コーディックはH.264とAACもしくはAC3、これが無難。
まぁストレートな代物なら、MP4の方が無難やもしれんが。
たまにH.264+AACのAVIを見かけるがｗ
一時期流行ったOGMって、エロ動画以外じゃあんま見かけなくなりましたな・・・
QuickTimeにplug-inがあるから入れられるのだろうが、OggやMatroskaにしておいた方が無難。
ライセンスフリーでユーザーサイドで規格の改定が出来るフォーマットがいいよな
家電にとっては、変わらないことがメリットでもあるわけだし
メーカーとしては安心して使えるだろう。
勢い次第ではMSだってそのうち対応してくるだろうし・・・
wmvがあるから当分は無理かなｗ
Vorvisもあまり流行らなかったし、mkvも字幕等の特殊用途以外では難しい
個人的にはこっち押してるんだが、TVのキャプとか音声はAACのまま取り込めばいいしmp4で間に合うんだよな・・・
それぞれエンコード済みの音声と動画の生ファイルからMP4コンテナにぶち込んでくれるソフトってあるんでしょうか？
Doom9のテンプレを読むのが早い。
http://forum.doom9.org/showthread.php?t=62723
ありがとうございます。
一番頭にあったMp4Boxとやらを使ってみます
YAMB使ってみたんですが、
コンテナにつめこむ段階でプログレスバーは進まないは時間は動かないわよくわからん。
MP4BoxのフロントエンドならMp4Boxそのまま使っても同じじゃないかと
書き出せたりしますが、Mac以外にゃあんま需要ねーかｗ
＃movからmp4へのコンテナ換え
IP202.152.108.232で編集している奴最悪だな。どうせダウソ厨の主観で技術的裏づけを取っていないんだろうが。
AVIコンテナとしての制限（FPS指定が一箇所、sampleサイズ指定が1箇所）とMuxerのhack（NULLフレーム水増し、インデックス偽装）
をごっちゃにしている。AVIがCFRだというなら、同じ原理で音声はCBR。Muxerのhackを認めるなら音声はVBR対応だし映像もVFR対応だ。
本来規格を客観的に正しく書くべきwikipediaにおいては、AVIはCFR・CBRを貫くべきだろうな。
Bフレ対応にしてもVfWの1in:1outが話題に出ているが、全くの勘違いなのが痛い。
AVIでBフレを正しく扱えないのは、コンテナとしてデコードの制御しか出来ない規格だからだというのに。
映像の再生は、デコード→コンポジション（→プレゼンテーション）というステップを踏むが、AVIが指示できるのはデコードのみ。
だから、Bフレの様な「表示に必要な情報が未来のフレームにあるので、そのフレームを先にデコードしないと表示できない」データを正しく制御できない。
このフレームのデコードと表示の順序逆転が遅延（ディレイ）として現れるので、拡張AVI出力のようにBフレ対応を謳ったソフトを使っても
必ず最低1フレームのディレイが生まれる。（当然参照Bフレームを利用し参照系が増えれば、その分ディレイも増加する。）
MP4の場合は、デコードとコンポジションを別指定できるため、先にディレイ分一気にデコードし、コンポジションを使って各ピクチャの
表示を制御するというコンテナの規格内で表示上の遅延を抑止出来る。（tc2mp4ModやDTSRepairなど。）
実のところ、MP4はedtsを使えばプレゼンテーションも制御できるんだが、対応したsplitterがないっぽいんだよね、QTぐらいしか。
と思うに任せて書いたけど、ここの住人にとっては周知の事実だったか…
ごめんよぉ...orz
かっとなって書いたけどちょっと反省してる。
ちなみに、hackのやり甲斐があるAVIは好きなので否定派じゃないのよ。
ただね、AVIの唯一の強みだった再編集のやり易さもMP4に追いつかれちゃって、
そろそろ世代交代なのかなぁと思うこの頃です。
MainConceptだから性能悪い
それ書いたの俺です。
できるだけ裏取りながら書いたんですが、不備が結構あると思うんで書き換えちゃってくださいな。
あと、俗にハックと言われてる方法のうち、VBR音声関連は実はハックでもなんでもなくて、
AVIのまともな扱い方の範疇ではないか、という思いもちょっと入ってます。
AVIはCFRにしか対応してなくて、NULLフレームの水増しによる擬似VFRは確かにハックだと思う。それは同意。
だからこそ、本文にはVFR非対応を残してます。これは否定しようがないでしょうし。
で、VBR音声だけど、CFRすなわちCBRというのは成り立たないと思いますよ。
CFRでVBRな音声形式はたくさんあります。MP3もAACもそうです。
ここから先は独自研究になっちゃうんで、Wikipediaには書けなかったんだけど、
AVIスプリッタによるタイムコードの割り当てはビデオも音声も同じ方法で割り当ててるんです。
どちらも同じAVISTREAMHEADER構造体の情報を元に、各パケット（wb00チャンクとかdc01チャンクの
一まとまりのデータ）単位かつ、音声の場合はwfx.nBlockAlign単位を一まとまりとして、
dwRate,dwScaleで指定されるレートでタイムスタンプをつけていきます。
（ちょっとわかりにくい表現かもしれませんが、すみません。）
Nandoのハックを例にすると、MP3の1フレームには必ず1152サンプル(MPEG2/2.5の場合は576サンプル)含まれています。
なので、wfx.nBlockAlignをMP3のフレームサイズより大きい値にして、wb00チャンクに1フレームずつ格納します。
そうすると、必然的にフレームレートはdwRate/dwScale=サンプリング周波数/1152 となります。
こうなっていればビデオストリームと全く同じ方法でタイムスタンプを付けるだけで正しいタイムスタンプがつきます。
結局のところハックでもなんでもなくて、ストリームを正しく扱ってるに過ぎないんですよ。
続きます
dwStartをまともに扱えるソフトが少ないとしても、AVIの規格には存在するのですから、
AVIの記事には含めるべきだと思います。もちろんまともに機能していない現状を補足するのは良いと思います。
それから、Bフレームの表示タイミングとか、デコードの順番ですが、
まるも製作所の茂木さんのアイディアを少々拝借してます。
http://pc11.2ch.net/test/read.cgi/avi/1023209133/270-272
結局のところ各データへのランダムアクセスが可能であれば
フレームの順序なんて関係ないんじゃないですかね。
WikipediaのAVIの記事ってことなんで、VFWとかDirectShowの話を抜きにして
純粋にAVIだけでまとめてしまってもいいんじゃないかって考えもあったので、
現実とやや離れ気味かもしれません。できるだけ離れないようにしたつもりなんですが。
MP4の編集環境が揃ってきたうえ、VCMの足かせは外れそうに無いんで
やっぱり世代交代なんでしょうね。。。
長文すみませんでした。
あと縦読みしても何もでてきませんよ。
ひどい記述を何とかしたいんですが、まとまった時間がとれず・・・
http://msdn.microsoft.com/library/ja/default.asp?url=/library/ja/DirectX9_c/directx/htm/mpeg1waveformat.asp
ここを読んでみるといい。wfx.nBlockAlignを1にすることでVFRオーディオを扱うことが用意されている。
これをAVIコンテナに格納する方法は、先に書いたIndexの細工（というが、実質はストリームに応じた適切な設定）と、
MUSTINDEXUSE（だったかな？）の指定で実現できる。
これもAVIコンテナの規格としては外れていないし、先のAudio StreamをSplitterの実装を逆手にとってVideo Streamと
同様のロジックに落とすことと同じことをやっているわけだけど。
それでも、VBRは対応していてVFRは非対応という結論がなぜ出せるのか？ その基準は？ということになる。
これはVideo Streamにもいえて、NULL水増しとはすなわちDropフレームの増加であって、Dropフレーム自体はAVIコンテナの
規格通り。これも、デコーダがDropフレームを前フレームのコピーとしてレンダラが描画を書き換えないという動作を利用し
ているわけだけど。MP4にしたってVFRといってもTimeScaleを越えた分解能は持っていないわけで、AVIのFPSを大きくするこ
とで分解能を増やす方法（120fps化）となんら変わらない。
結局、AVIに対して行われてきたこれらの工夫はAVIコンテナの規格を利用しているわけで、alexがAVIの規格に正確に対応して
いないソフトを糞splitter(demuxer)/decodeと罵る所以だが、果たして、客観性と中立性を求めるwikipediaに置いて「あるべき」
とする主観論者の意見と「現状」という観察しうる客観性のどちらを記述すべきかということになる。
厳密にAVIコンテナとして実現しうる事を書くなら、VFR・VBR対応と書き、VfWの問題点を併記しながら多くのソフトウェアが
CFR・CBRでなければAVIコンテナを扱えない旨を書く。（規格と事実の併記）
逆にCFR・CBRが標準的な用途であり、VFR・VBRは規格上存在するが運用上互換性にまだ問題がある旨を併記する方法もある。
（事実と規格の併記）
要するに、主義主張で「あるべき論」を書くなということ。
（プレゼンテーション）の指示をデコーダが担っているだけ。
Bフレの遅延はまるも氏も仕組みの解説で示しているわけだが。これもAVIでコンポジションの指示ができない、かつ正規のスト
リーム（packed bitstreamではない）を扱う場合にデコーダがディレイ用のバッファを用意し、（参照系分は遅延が発生するけ
ど）表示上問題がないようにしているだけ。
デコーダで補えているからといって、コンテナが対応しているというのは解釈がおかしい。
それに、dwStartを適切に設定するというのも対処法であって、コンテナがデコードとコンポジションの順序が逆になるストリー
ムをコンテナ内で解決できないことに変わりはない。
このあたりは私情が挟んでいるように見えるのでどうかと思った次第。
なんだって事をアピールしたい気持ちは俺にもあるんで、今の記事が許せないところは
とっても共感するのですよ。
ただね、wikipediaだってAVIコンテナと同じで、コンテンツが期待する記事を書いて
上げないといけないと思う訳です。これは、AVIコンテナを正しく扱ってくれない
ソフトウェアに対する気持ちと同じなんですね。
俺もwikipediaを編集してみるかなぁ…
MP3はMPEGLAYER3WAVEFORMAT使うのが一般的なようで、でもMSDNに無いんですよね。
WAVEFORMATEXの方には、
>ソフトウェアは、データの複数の nBlockAlign バイトを、一度に処理しなければならない。
>デバイスに書き込むデータ、デバイスから読み込むデータは、常にブロックの先頭から開始しなければならない。
>たとえば、PCM データの再生を、サンプルの中間 (つまり、非ブロック アライメントの境界) で開始することは不正である。
とあるんで、WAVEファイルでnBlockAlignを最大フレームサイズにするのは間違いなく不正でしょう。
ただ、AVIファイルの場合、wbチャンクの先頭はサンプルの先頭であることが一応保証されてるわけですし、
非ブロック境界で切らないために大きい値にするのはある意味正しい、
という解釈はやっぱり苦しいですかね。
WAVEファイルはどうあがいてもCBRしか正しく扱えないフォーマットですし、
それと同列に落としてしまうのももったいないかなとは思います。個人的な感情ですが。
VBR対応かつVFR非対応の根拠はビデオストリームがそうだから、じゃ不十分ですかね。
AVI内では、少なくともAVISTREAMHEADERを基本情報とした同等なストリームとして扱ってるわけですし。
他コンテナでも結局Pフレームはデコーダがバッファしてるわけですし。
表示タイミングの問題だったら
http://pc11.2ch.net/test/read.cgi/avi/1023209133/272
でいいんじゃないですかね。
これならフレームデータに付いてるタイムスタンプをそのまま使うわけですし。
問題は実装が伴ってないことですけど。
俺も「あるべき論」だけで書くのは不味いと思いますよ。
少なくとも本文には入れていないつもりです。
もともとき加えはほとんど無いですしｗ
ノート（英語版はdiscussion）は文字通り議論の場なので、
こちらにある程度の個人的な意見が含まれるのは良い、という線引きはしてます。
今回コメントアウトした項目はいずれも、現状回避されている例のあるもの、という基準を頭においていました。
回避された現物が存在するのに、本文で欠点であり不可能と言い切っているのは不味いでしょう。
でも可能と書くにはちょっと躊躇われる点もあるので、
とりあえずノートに移動して議論したほうがいいな、という目論見でした。
事実こうやってよく知った人と話せてるんで成功ですかね。
Wikipediaの性質自体、多人数で編集してなんぼのものなので、編集してみてくださいな。
それは置いておいて。
MakKiさんの提唱するデコード方法に抜けている考え方は、データの読み込みタイミングなんです。
静止画をただ作るだけなら話は別ですが、動画は連続した流れの中でデータを扱うので、AVIのようにデータを
デコーダに渡すのをFPSで制御している以上、バッファ中は何も表示されないって事になってしまいます。
それをparserが汲み取って一気にデータを読み込んでデコーダに送ることも可能でしょうが、一気に読み込むデータ量をどう
やって指示させますか？ AVIにそのような定義はできますか？ ってことです。
（それを実現したのがPacked-bitstreamですが、これはストリームフォーマットを変えちゃったんですよね。）
まぁ、parserでありdecoderでありrendererなFilterを作れば一気に解決できるのでしょうが、結局AVIではそういう制御ができ
ないから他で補うって発想が根底にあるわけです。
他のコンテナでは、デコードとコンポジションのタイミングを操作できるので、Packed-bitstreamのような事がコンテナで出来るんですね。
I0を0ms後に読み込み -> I0を0ms後に出力
P4を1ms後に読み込み -> P4を133.2ms後に出力
B2を2ms後に読み込み -> B2を66.6ms後に出力
b1を33.3ms後に読み込み -> b1を33.3ms後に出力
b3を99.9ms後に読み込み -> b3を99.9ms後に出力
フレームに個別のタイムスタンプを持っているか持っていないか、結局はそれがAVIの限界になるわけです。
こいつは、AVIの規格としてはあまり問題ではない格納方法ですが、あくまでMuxerが内部に納められたストリームを
認識して個別の操作をしてやる必要があるため、互換性が著しく低いという問題があります。
言ってみれば再生専用ですね。
そこをどう書くかなんですが、たとえばwikipediaみてVBRいけるんじゃんってなった人が、AviUtlなんかでVBRな音声のAVIを
作ろうとして上手くいかず、wikipediaの記事は嘘っぱちだと騒いでもらっても困るとおもうのですよ。
となると、正式にはCBRで再生互換を有したVBRなAVIも存在するが、編集は専用ソフトで～みたいな書き方になってしまうのかなぁと。
ま、何はともあれ、スレ的にはAVIコンテナ最強ってことでOKでしょう。
うあなにをするやめくぁwせdrftgyふじこlp
パーサの改修は不要ないです。デコーダ側でタイムスタンプの解釈を変えるだけです。
現状 AVI Splitter からはフレームレートに応じたタイムスタンプが単調増加しながら
付加されて出てくるわけです。
これを、そのフレームデータをデコードした結果に付加すべきタイムタンプと解釈する
のではなく、レンダラーに渡す際に FIFO で利用すべきタイムスタンプとして使うだけ
です。
I0 [st:0.000 sec] -> I0 として [st:0.000 sec で] 出力
P4 [st:0.033 sec] -> デコードだけしてまだ出力しない
B2 [st:0.066 sec] -> デコードだけでまだ出力しない
b1 [st:0.100 sec] -> b1 として [st:0.033 sec で] 出力
b3 [st:0.133 sec] -> ここで B2 を [st:0.066 sec で] 出力
P8 [st:0.166 sec] -> b3 を [st:0.100 sec で] 出力
…途中略…
EoS 通知 -> バッファ分を順次出力
現状の ffdshow では何故か P4/B2 のデコード時にも絵をレンダラーに渡しているので
再生時にズレが発生してしまいますが、上記の処理であれば問題は出ません。
渡すことができないので
I0 [st:0.066 sec] -> I0 として [st:0.066 sec で] 出力
P4 [st:0.200 sec] -> デコードだけしてまだ出力しない
B2 [st:0.133 sec] -> デコードだけでまだ出力しない
b1 [st:0.100 sec] -> b1 として [st:0.100 sec で] 出力
b3 [st:0.166 sec] -> ここで B2 を [st:0.133 sec で] 出力
P8 [st:0.333 sec] -> b3 を [st:0.166 sec で] 出力
…途中略…
EoS 通知 -> バッファ分を順次出力
という処理になっているはずです。
# stts が 1000/30 で単調増加で、ctts で I/P には 2 フレーム分の遅延が、
# 参照 B には 1 フレーム分の遅延が追加、非参照 B (小文字の b) は遅延 0
# という状況を想定
こちらでは、そのフレームに付加されていたタイムスタンプをデコーダが管理して
そのフレームを下流 (レンダラー) に渡す際に正しく付与するという形になります。
# ピクチャタイプをフィルタが意識せずに済み、デコーダライブラリがタイム
# スタンプをサポートしていなくても容易に実現できる
以上は DirectShow での再生時しか考えていないので編集時には問題がでます。
現状 AVI を編集する際には VFW CODEC を使うしかない (VFW を捨てるならば
AVI のメリットの大半がなくなる) のでこれは回避不能ですね。
編集時に正しいフレームを表示できない AVI に意味があるのかと聞かれると、
スプリッターが標準でインストールされてるという利点ぐらいしか残されて
ないんですよね。
I0 -> I0出力
b1 -> バッファ,出力無し
B2 -> バッファ
b3 -> バッファ
P4 -> b1出力、以降順にB2,b3,P4を出力
ですが、この順序での入力は CODEC 側が対応しない (H.264/AVC の規格からは
壊れたストリームとして扱われてしまう) ので無理だと思いますよ。
好きじゃない。
・stbl 関連のグダグダっぷりが醜すぎる
stsc,stsz,stz2,stco,co64,stss あたりを眺めてみると絶望してこない？
・moov, moof で何でまったく別の box 構成になってるんだ
まー moof 使ってるのは 3g2 ぐらいだから普通の人は気にせずに済むけど
・なんで mdat にヘッダ入れちゃいけないんだ
新しく対応フォーマット増やすたびに stsd を拡張して、標準のヘッダを
descriptor に変換したり、CODEC の出力からヘッダを落としてやるコード
書いたりしなきゃいけないじゃないか
好きじゃない理由はこんな感じ。
ttp://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
から
ttp://standards.iso.org/ittf/PubliclyAvailableStandards/c041828_ISO_IEC_14496-12_2005(E).zip
で規格書を無料で読めるので、眺めてみると同意してもらえるんじゃないかと思う。
まるも氏までこられるとは。
私がparserの話を出したのは、MakKi氏のデコード方法がストリームデータを一旦蓄積するデコードモデルだったので、
h264 parser辺りにその仕事を割り振る感覚で出しました。
まるもさんはDirectShow前提のモデルで話しているのかな。
たとえば>>87の処理では、デコーダがレンダラーのFIFOで利用すべきタイムスタンプを設定したときに、その時刻は
現実世界では既に経過してしまっている、という矛盾が発生するのではないですか？
現状、DirectShowのレンダラーはがんばってその時間に近づけようとしてくれるので、この場合は再生直後が早送り
になってしまうはずなんですよね。
>>88 のMP4においては、MP4 Splitterの実装を見てみないと正確に書けないところがありますが、MP4のCTS/DTSの
仕組みを考慮すると、Splitterは指示された「時刻」に該当するCTSのサンプルを見つけ、そのCTS以前に存在する
IDRフレームまで遡り、サンプルの格納順にDTSが「時刻」になるまで取得したサンプルを、CTSの表示時刻をつけ
てデコーダに送っているはずっと… あとは連続した再生用に直近で取得したサンプルの位置を保存して無駄なFetch
を回避している感じかな。
edtsとか無視しているんで、こんなところじゃないですかね。
実際、この動作を狙って作られたのがtc2mp4ModやDTSRepairであり、それで作成されたMP4はまさにそのように動い
ているので。
エンコにかける青春スレも最近の記事は読ませてもらいましたが、そこであがっていた100カウントするMP4がこれで
したね。まだ残っていますので、ご覧になってみては？
もしかして seraphy さんでしょうか？
私も MP4 Splitter のソースを詳細に追ったわけではないのですけど、DirectShow で
パーサフィルタを作る場合は、基本的に垂れ流しモデル (レンダラーでブロック
されることを期待して、パーサ段階でのタイミング調整は行わない) を採用します。
http://www.marumo.ne.jp/db2005_6.htm#23
で書いたような動作ですね。(勿論、パーサでタイミング調整を行う邪悪なフィルタ
セットも世の中には存在していて、そーゆーのに出くわすと絶望してあんな愚痴を
延々 6/10 ～ 6/26 まで書いたりもするのですけど)
垂れ流しモデルを採用している場合であれば、
> デコーダがレンダラーのFIFOで利用すべきタイムスタンプを設定したときに、その時刻は
> 現実世界では既に経過してしまっている、という矛盾が発生するのではないですか？
という現象は、デコード処理に CPU 100% を使い切ってしまい、処理が間に合わなく
なる時にしか発生しません (シーク後の再生直後とかには発生しがちになるかもしれ
ませんが、その対策は I0 の出力を B2 入力時にずらすことで可能になります)
あ、上でピラミッドなサンプルだったので、AVCを意識してIDRフレームって書きましたが、まぁ、RAPということで。
>>91
コンテナ談義であれば、MP4はダメダメだと私も思います。
大体、対応ソフトを書くとしてどこまで実装者に苦労させるんじゃボケってくらい…
結局、全てのboxを考慮して実装できない現状が、互換性の低下につながっているわけですし。
（かくいう私もbox限定なコードしか書いたことないですし。規格書は斜め読みしかしてないので、
ぼちぼち本腰いれていかないとおまんま食えないのですけどね･･･）
それに輪をかけて、ストリームの制限があるので携帯機界隈は混沌としています。
ただ、実装者が苦労すれば、利用者はAVIよりも気軽に使えるようになるんじゃないかなという可能性はありますけどね。
何年後かは置いといて…
AVIはVfWがあるおかげで実装者は楽できますが、反面VfWの制限を受けるので色々と利用時にしがらみが出てくると。
それじゃぁがんばってMuxer作りますかといえば、互換性を下げちゃいますしなんともかんとも…
つまるところ、まるもさんが新コンテナを提唱すればいいとおもうのですよっ！（丸投げ
ってはじまったMKVが現状あれなので、普通に乗り気にならないですよねぇ
（まるもさんの記事はためになるので読ませてもらってます。リレーブログの方は世間的に取り上げられてないのでもっ
たいない～と思うその一です。）
書き込む前にリロードしろよ、俺！ あと書き込んだ後も見ろよorz
>>93
seraphy氏ではないですよ。かといってVFR_maniac氏ともちがいます。（というか畏れ多いです。）
私自身は仕事上でこういうものに触れるだけで、ソフトの公開とかはやっていないです。
とても仕事の傍ら「同じ事で」頭を悩ますのは耐えられないので…
そういうこともあって、同業界でソフト公開・サポートまでされている方々はまさに尊敬しているわけです。
別に噛み付いているわけではないのですよ。←ここ重要
で、Splitterの話に関しては、上で書いている両氏のソースとかから考え方を抽出しただけです。
私はGabest（だったかな？）のSplitterを使っていて、nhmlとかでDTS/CTSをいじくりまわしていたときに上のロジックに
行き着いただけですが、かといってそれほど多くを実験したわけでもないですけど。
まぁ、DTSの刻みを極小にしてみて、再生実験してみればある程度はわかるかもしれません。
（その前にソース嫁と言われそうですが。）
AVI Splitterは、垂れ流しモデルということなんですね。
でも、デコーダ側でFPSを元に1フレームIN：1フレームOUT基準でタイムスタンプをつけてしまうから、初期ディレイが
生まれるというわけですか。ffdshowの方をいじれば、AVIでもピラミッドを利用して遅延を発生させずにすむと。
バッファが遅延分のデータを格納できるまで十分に大きい必要はありますが。
ただ、上のモデルではランダムシークに弱くなってしまうので、GOP（とあえて使いますが）の長いストリームには俄然
不利になりますよね。で、結局各フィルタがタイムスタンプで制御しているんだろうと思っていました。
単にマシンパワーがあがって気にならなくなっただけなんですかね。
編集乙です。なぜかエネルギー使うんですよね。
>>84,90,92
デコーダには先にPを渡さないといけなかったのですね。その辺の仕様を知りませんでした。
H.264の規格くらいはちゃんと勉強しないとだめですね。申し訳ない。
>>85
ストリームの種類を問わない方法として、こんなの考えてみました。
http://mksoft.hp.infoseek.co.jp/doc/vbrinavi.html#3.2
ただ、これは本来AVIで使えないはずのVFRになぜかなってしまっているという・・・
>>87
そのタイムスタンプを調節するデコーダは、正しいタイムスタンプをつけるコンテナには使えないですよね。
やはりAVI専用の処理が必要になってしまうと。
DirectShowの場合GUIDで見分けるだけでしょうけど。
やっぱり問題はVCMで編集すると、再生(DirectShow)で表示が食い違う点ですか。
読み出しタイミングの調整の話ですが、中間のフィルタ(含デコーダ)が費やす時間が不定な以上、
最終的な時間調節はレンダラしか出来ないと思います。
そうするとどのようなモデル(Dshowのようなパーサ駆動Push型,レンダラ駆動のPull型 他)であれ、
パーサは可能な限り先行して読み出しを行なわなければならない、となりませんか？
もしそうなら、読み出し時間の指定ってほとんど不要じゃないかなと。
もちろんヒントがあった方が効率は良いでしょうが。
利点、欠点を語る上で不可避なようですし。
あとBフレームって記述もどうしましょうか。双方向参照フレーム？ですか？
AVIの柔軟性は、勝手にFourCCやFormatTagを定義するだけで、パーサの変更無しに
どんなフォーマットでもとりあえず格納できてしまうことですかね。
昔VorbisACMの吐き出すデータ眺めて妄想したのは、MKVやMP4をコンテナごと格納してしまえばいいじゃん、とか。
やっぱりAVI最強！
>つまるところ、まるもさんが新コンテナを提唱すればいいとおもうのですよっ！（丸投げ
ｿﾚﾀﾞ!
今までの話から、モデルの違いが大きいとためかなと感じています。
クロックジェネレータ方式（という名前があるわけでなく、結構ハードよりな方式なのでこう名づけてみました。）
のようなモデルでは、時間を制御するジェネレータが、16ms間隔などで定期的にparser、decoder、renderを順に呼び出します。
parserは、指定された時間に色をつけてINバッファに必要なデータを読み込みます。
decoderは、INバッファにデータがあればデコードして、必要な分だけOUTバッファに戻します。
renderは、OUTバッファにデータがあれば、指定された時間以前のデータで直近を1枚表示します。
ざっくりとはこんな感じで、各バッファ上限をハードの性能で決めて、溢れれば落とします。
（INバッファは理論上あるだけで実際にバッファという使い方はしませんが。）
パーサ駆動なのですが、先読みは「色」分しかおこないません。先読みしなくても問題ありません。
それは、中間のデコーダが与える処理遅延を一定のαとして、映像全体をα分遅らせてしまえばいいという発想だからですけど。
この方式では、結果的にparserに動画の表示タイミングの制御が委ねられていることになります。
あと、よほどのケースを除いて、αはジェネレータの間隔よりも十分小さい値になります。
> ストリームの種類を問わない方法として、こんなの考えてみました。
おお、なんだか面白そうですね。ちょっとじっくり読んでみます。
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
【スペシャル機能】 SKYLAB 【満足度100%保証】 (166)
【バッファロー】DT-H70/PCIEW7 (114)
【放送業界】もうテープはなくなる？【新記録媒体】 (575)
糞環境乙】TSパケットエラー報告3【とは言わせない (840)
CyberLink PowerProducer Part2 (892)
【DLNA】PMSを活用するスレ part2 (704)
--log9.info------------------
【桜田淳子】 玉ねぎむいたら 【石立鉄男】・・・２ (193)
【カツレツ】天皇の料理番【秋山篤蔵】 (579)
殴る女～round4～居るべき場所 (595)
長渕剛のドラマ、「とんぼ」が観たい (731)
◆ 再放送ドラマ 情報交換所 18 ◆ (370)
伝説の教師 南波次郎の名言で1000まで (305)
NHK連続テレビ小説ヽ（◎）/ゲゲゲの女房115反目 (837)
NHK朝の連続テレビ小説「純情きらり」Part58 (740)
【萩原聖人】若者のすべて Ⅳ【木村拓哉】 (607)
【安田成美】素顔のままで Part2【中森明菜】 (304)
【再放送】バブル (449)
「深夜食堂」再放送ｷﾀｰ (206)
━━━ 花より男子シリーズ総合スレ Part155━━━ (777)
朝ドラヒロインの光と影 40 (149)
【石田純一】想い出にかわるまで【今井美樹】 (815)
少女に何が起ったか part3 (317)
--log55.com------------------
ハゲは素晴らしい！
ふりかけ☆使ってる人いませんか？31本目
玉ねぎと納豆食べたら髪生えてきた。Part3
かつらだと思われる有名人
【安い】ファッションウィッグ【良品】2
これから床屋か美容院逝ってくる人のためのスレ14→
ハゲモンＧＯというのが流行ってるらしい
ハゲaa保管庫
