x264 初心者質問スレ part4

これからはインタレ保持でエンコしようと思っているので
デインタレの都合でPowerDVDを買ったんですが・・・
Bフレームを使わないのが常識なのかと思い質問したんですが
実際はそうではないようですね。
ソフト自体の問題みないなので今まで通りBフレーム入れてエンコするようにします。

ｂフレは破綻の原因になるから使ってないな

自分の環境だと今まで全然破綻なかったがなぁ

>>938
インタレ保持の場合でＢフレーム使うと破綻するって話をたまに目にするけど
検証結果を載せたようなサイトって知らない？
破綻すると言ってる人って何か自分で試して無さそうなあやふやな情報源を信じているっぽいんだよな。

Bフレームを使うとPowerDVDでブロックノイズがでると言った者ですが、
あれから色々と検証した結果、Bフレームを使用した場合であっても
重み付け予測でPフレームをゼロに指定（weightp 0）するとブロックノイズが出ないようになりました。
他の再生ソフトでもweightpの使用によってブロックノイズが発生する症状がでているらしいので
これは使わない方が良いかもしれません。

---------------
ﾆｺ動の“拡張 x264 出力（GUI）Exの設定項目とその機能について”より抜粋

デコーダーにおいて、weightp 1または2を使うと映像が壊れる(ブロックが発生する)現象が確認されている。
これにはFlashPlayer10.0も含まれており、修正は10.1で行われた。また、smile鯖にweightp 1または2を使った動画を投稿すると、
未対応形式の動画として蹴られることがよく起こり、運よく蹴られずにすんでも「エコノミー症候群」を発症することも何例か確認されてる。
エコノミー回避動画以外ではweightp 0にしたほうがよいだろう。

weightp 1は当初と違うものになってるから今の1ならバグ持ちデコーダでも正常に再生できることもあるよ

>>942
助言有難うございます。
おっしゃるとおりweightp 1を試してみたところ見事にブロックノイズは出なくなりました。
2の方は今後対応されていくと思いますが1と2ではファイルサイズが３％程度しか変わらなかったので
これからインタレ解除してエンコする場合にはweightp 1で行いたいと思います。
有難うございました。


--------
すいません。>>941の抜粋はEx無しverの時の古い記事でした。
ﾆｺ動の“拡張 x264 出力（GUI）Exの設定項目とその機能について”より抜粋

P-Frameに関してはデフォルトはSmart(Weighted refs + Duplicates)になっている。
これはSimple(Weighted refs)[r1802での変更]よりも効果が高い。なお、いくつかのデコーダーにおいて、
weightp 2を使うと映像が壊れる(ブロックが発生する)現象が確認されている。
これにはFlashPlayer10.0も含まれており、修正は10.1で行われた。

再生できないプレーヤーはh.264に対応してない
糞プレーヤーという事なだけじゃないの？

weightp ： Doesn't add support for interlaced encoding with weightp yet.

weightp 1か2でインタレ保持エンコしようとするとwarningログが出るはずだが、エンコ自体はできちゃうけど
だからインタレ保持エンコする時はweightp 0は常識だと思ってた

後、me esaかtesaでもwarningログが出る
だからインタレ保持はumhでやってる

言葉足らずでしたね
インタレ保持の場合は自分もweightp 0でエンコしてます。
実写などでサイズを小さくする場合には、
まだインタレ解除しているので、その設定をする上での質問でした。

test

リサイズをする場合ってインタレ保持ってメリットありますか？
ググってみたんだけどいまいち理解できないっす。

http://x264dev.multimedia.cx/archives/643
この記事（コメント含）はどういう気持ちで書いているのでしょうか？
"（BD陣営に遅く加わった）ワーナー兄弟のプロにx264を使ってもらって嬉しい（＝x264の実力・信頼性がプロに認められるレベルに達した）”
”競合コーデックVC1に勝った”
こんな感じに汲み取ったのですが・・・いかがでしょうか？

>>950
あんまない。60pにするよりは容量圧縮できるけど、インタレにしても容量食うから60pと大差なかったりする。
リサイズ後にフィールド半分捨てるわけだから縦解像度は減っちゃうし、再インタレ化の過程でジャギると思う。

自分も以前ちょっと試してみたけど、やっぱ60iソースをリサイズするなら60pのほうが自然。

金曜のエヴァをエンコしようと思うんだけど、基本は24fpsで
途中何箇所かの横に流れるテロップの所を60fpsにして結合でいいの？

全部24でいい。と言うか勝手にしろ。

今は60iテロも含めてエンコはALL24pでおｋ
再生時にフレーム補間で120fpsになるからそれで無問題
VFRは既に前世代の遺物になってる

テロカクカクにならない？

>>955
豚はどうすんの？

本編24p + テロップ60iはこれで完璧に処理できる。

http://forum.doom9.org/showpost.php?p=1466105&postcount=4

>>958
kwsk

>>959
http://hibari.2ch.net/test/read.cgi/avi/1308308879/196

>>958
一度bob化してるから全編に適用するわけにはいかないし、結局VFRにするのと同じ作業量じゃね？
完璧ってほどヌルヌルでもないし、だったら普通にVFRにした方が。

24fps固定のするメリットは再生時のみだが、モバイルCPUの進歩がとんでもなく速いから
来年くらいにはスマホでも60fpsヌルヌルでいけそうな勢いだ。

>>958
なんだ24fps固定か
どこが完璧だよ

使ってみたのか？

>>961
おいおい
元が24fpsは60fpsヌルヌルにはならないぞ
液晶TVみたいに120fpsじゃないと

>>961
テロップのカクつき解消なのに、ヌルヌルを所望とな。

テロップもヌルヌルしてたほうが達成感あるだろｗ

それはVFRではできないってことはわかってるのか？

MVToolsって隣接するフレームの中間となる画像を補間するんだよね
そしたらテロップの後ろの映像も残像が出る場合がありそうなものだけど

>>964
60でオリジナルのフィールドを全て展開してるんだが。
アニメに補完処理までするのか？

びっくりした
それじゃVFRの利点ってなんだと思ってるの？

>>970
多分あんたに皆がびっくりしてると思う

プルダウンされてる60iソースを
１．逆プルダウンで24fps化
２．Bobで60fps化
これで２がヌルヌルだと思ってるわけ？？？？

つまりこういうこと？
trim(aaa,bbb).QTGMC().SelectEvery(10,x,x)

>>961を誤読したのかもしれんが、>>958の関数にbob処理が含まれているという意味だ。
逆プルダウンだけで処理できるとこまで全部>>958で処理しちゃったら損だしクソ重いし、
となると結局VFRにするのと同じ作業が必要だから意味なくね？という意味。

現状、r2074（r1876以降？）では2009年基準のアスペクト比で出力？するようになってるけど
2005年基準のアスペクト比で出力するにはどうしたらいいの？

>>975
もしr1876(1a321d7)でのsarパッチの事だったら、
x264のgitの1a321d7の部分を戻してビルドするか、それでビルドされたバイナリを探す
それかエンコして出来たのがmp4だったらmp4boxの-parを使う

>>961
iPhone4のA4チップは240fps(SD720x480 多分レベルは3か4だったかな)の動画でもすでに再生可能だった
正確にいうと参照フレームからの色抜けみたいなものがなく、ずっと綺麗に色が再現できてた
うちのiMac上のVLCWINじゃ処理追いつかないときもあるけどA4/インテルQTXMacはAVCに強すぎる
多分SDなら300fpsでもいける

たしかにiPod Touchの一番新しいやつで、60fpsとか含むVFRのファイルも
普通に再生できるな。nurunuruではないけど

PSPでさえ60fpsを再生できる

>>979
解像度1920@1080の60pでも余裕で再生できる？

>>980
できますん

>>981
ありがと、余裕で再生できるなら十分な性能だね

VitaならVRAMが不安だけどいけるんじゃない？

960*544(540で16:9)
VRAM128MBだからなぁ
960*544*(24/8)=1.49414MB/フレーム
128MBで85.688フレーム
1920*1080*(24/8)=5.933MB/フレーム
128MBで22.723フレーム分(フルHDの場合)
フルHDだとHDMI出力したら足らないような気がする。

ほいx264 初心者質問スレ part5
http://hibari.2ch.net/test/read.cgi/avi/1314616372/

スレチですが気になったのでここに投下しておきます。スマフォのAVCデコード処理能力についてです。
■検証環境
▼iPhone 4 (A4) / iOS 4.3.3 / GoodReader(デコードはOSが処理)
▼VLC Player v1.1.10 (Win)/ Intel Core i5 第2世代のなにか

■分かったこと
・A4チップのデコード処理能力は別途詳細記述の動画において約110〜120fps前後ぐらいが限界だった。（詳しい結果は下記参照）
・解像度、BaselineやMainなどのプロファイルやレベル等のデコード処理が優しい動画は別途要検証事項。
・iPad 2は既にiPhone 5に搭載予定のA5チップ搭載済みなので持ってる方はどれくらいパワーアップしているかぜひ検証お願いします。
・他のスマフォ持ってる方もお時間あればぜひ検証をお願いします
・1fpsの動画を見るとフレーム間予測による特殊なデコード（つまり順番通りでない）の模様が開始数秒間見れる？
・VLC playerは最後のコンマ数秒間もしくは数フレームのデコードをサボる
・iOSは決められた時間内に最後まで110fps程度で1フレームずつデコードをしっかりする呑気なヤツ。（ちゃんと処理するけど時間オーバー分はゴソっと再生を諦める派）
・VLCは再生すべきフレーム数と時間はきっちり守る頑固者なのでデコードは適当。（処理できなくてもガンガン突っ走る派）

■結果
※1往復はちょうど300フレーム
▼iPhone 4 (A4) / iOS 4.3.3 / GoodReader(デコードはOSが処理)
○1〜30fpsについては言わずもがななので省略
○60fps.mp4　50秒間で10往復　3000フレーム/50＝60fps
×120fps.mp4 25秒間であと約100フレームで10往復完了というところで力尽きた。　約2900フレーム/25＝約116fps
×150fps.mp4　20秒間で約7往復　約2100フレーム/20＝約105fps
×300fps.mp4　10秒間で約4往復　約1200フレーム/10＝約120fps
×600fps.mp4　5秒間で約2往復　約600フレーム/5＝約120fps

▼VLC Player v1.1.10 (Win)/ Intel Core i5 第2世代のなにか
○1〜150fpsについては言わずもがななので省略
○300fps.mp4　ちゃんと10往復した
×600fps.mp4　完全に画が破綻していた。往復回数計測不能

動画の入ったZipファイルはコチラから落とせます　約5MB　ttp://db.tt/l5x3xWM　

-