- x264 初心者質問スレ part2
611 ：名無しさん＠編集中[sage]：2010/01/06(水) 00:20:39 ID:svHAavof - 高さが32の倍数じゃなくても別にインタレエンコができないわけではないよ
圧縮効率が悪くなるだけで。
ただMBAFFのアルゴリズム上マクロブロックの数え方が32で割り切れない分は切り上げになる
だから高さ720は32で割り切れる736だと見なされて
736/16=46になってLevel3.1に収まらないだけのこと
別にLevel4.0でいいんじゃないかと思うけど
|
- TS初心者勉強会スレ 15頁目
664 ：名無しさん＠編集中[sage]：2010/01/06(水) 07:22:35 ID:svHAavof - <チラ裏>
ちょっと気になったからffmpeg-r20714のソースをgrepしてみたら
>>649-650の"invalid PCM packet"
はlibavcodec/pcm.cのpcm_decode_frameに渡された入力データが
1サンプル（16bit5.1chなら2*6=12byte）に足りない時に出るみたい
でも、そもそもTSにPCM入ってる事なんて殆どないだろうに
pcm_dcode_frameが呼ばれてる事自体が謎
なんの役にも立たない俺用メモですまん
</チラ裏>
|
- x264 初心者質問スレ part2
617 ：名無しさん＠編集中[sage]：2010/01/06(水) 08:19:37 ID:svHAavof - >>612
追加される16の面積分が不利というよりも
そこに有効なデータがないことが不利と言った方がいいと思う
要は「プログレで縦横が16の倍数ではないとき」と同じような処理が行われるはずで
JPEGなんかだと8の倍数ではない時に同じような処理が入る
一般的には追加の部分（無効領域）が黒や灰色、緑（YUVでのオールゼロ）なんかの
ベタ塗りと見なされたりする
すると当然、有効領域と無効領域の間にエッジが発生するので
この両者にかかるマクロブロックは歪みやすいし縮みにくい
以前はプログレで16の倍数でない時に圧縮率が悪い旨の警告がされていて
これがr1306で除去されたときにその程度が「極度にわずかな量」と言われているので
実際にはインタレでの圧縮率の低下もそれほど大きくないのかもしれない
|
- x264 初心者質問スレ part2
618 ：名無しさん＠編集中[sage]：2010/01/06(水) 08:35:22 ID:svHAavof - （続き）
ベタ塗り自体は圧縮しやすいのだけど、エッジがあることになってしまうと
DCTで高周波に振れてしまうので、有効領域の面積に対して
マクロブロック全体では不利な傾向になる
規格はデコーダ基準で書かれているので、恐らくこの無効領域に
何があるとみなすべきか（ベタ塗りの色とか）の規定はされていないのだと思う
デコーダからすると無効領域なのでクリッピングして出力するだけだから。
圧縮理論的に言うと有効領域のDC値で無効領域をベタ塗りにするとか
DCT後の係数が小さくなるようにデブロック的なフィルタや鏡像で
無効領域にダミーデータを置くとかすれば劣化しにくいけど
そこまではやってないだろうなぁ
て、スレタイ見たら初心者スレだった、イミフだったら無視してくれ…
|
- TS初心者勉強会スレ 15頁目
666 ：名無しさん＠編集中[sage]：2010/01/06(水) 08:49:11 ID:svHAavof - >>665
AACやmp3をdecodeする関数じゃなくてpcmをdecodeする関数だよ
PCMにも24bitとか浮動小数点とかあまり使われないのが色々あるから
それらの形式をエンコーダが受け取れる形式に変換(decode)するための関数であって
AACやmp3はもともとデコード出力が一般的な16bitPCM(pcm_s16le)なのだから
普通は不要でしょ
livavcodec/pcm.cと書いた時点でそれは理解されるかと思ったんだが…
|
- 【クイックサン】QRS-UT100B【TS抜き】Part13
756 ：名無しさん＠編集中[sage]：2010/01/06(水) 08:55:02 ID:svHAavof - 水晶発振子じゃなくてPLLの問題っぽいってどこかで言ってなかったっけか
付いてる12MHzのクリスタル交換してみたけどダメだったって話だった気がする
まぁそうだとするとクリスタルの劣化以上にたちが悪いって話なんだが…
|
- TS初心者勉強会スレ 15頁目
667 ：名無しさん＠編集中[sage]：2010/01/06(水) 09:21:37 ID:svHAavof - <チラ裏>
あぁ、それともデコードされてきたのがs16leだとしても
エンコーダがs16beしか受け付けないような形式にしようとしてるのかな
だとすれば継手変換として呼ばれてる可能性はあるか
でもffmpeg内蔵のコーデックならビルド時点での切り分けで
バイエンディアン設計（というかエンコーダもデコーダもネイティブバイトオーダで扱う）だろうし
ライブラリ使用だとしてもバイエンディアンでないものはちょっと分からないな…
問題の人たちはエンコード先の形式に何を選んでるんだろ
それともアライン調整で変換不要でも呼ばれるのかな
うーん、これ以上ffmpegの深遠を追うのは面倒だな…
</チラ裏>
|