『漫游』酷论坛>『影音数码技术学习交流』>太较真就让人纠结了~
roozhou@2010-06-06 00:39
应该和chapter无关。另外mp4和mkv实现延迟的方式不一样，mkv有先天缺陷。
zeas@2010-06-06 15:34
我曾拿一段wav格式的loop素材做了个试验：
源是16位立体声0xB5E（2910）采样的wav文件
然后删去头4个字节（一个采样）再将wav头的长度及data段后的长度减去4另存为一份供对比
参数用neroaacenc -q 0.12 -hev2 -if in.wav -of out.mp4
（Nero AAC codec / 1.5.4.0，因为hev2延迟最明显，故用hev2做测试）
对比两者转出的mp4，忽略头部的修改日期信息和数据段，两者仅在esds、stsz，还有itunsmpb字段的信息出现不同
考虑到AAC数据已完全不同，长度也不一样，故stsz产生的不同可以忽略
关键决定长度和偏移的只有esds和itunsmpb字段了
用neroaactag -list-meta out.mp4 显示itunsmpb字段
原始的wav转的mp4: itunsmpb = 00000000 00000AF8 000001A9 0000000000000B5F （后面都是00了，就不列出来）
减短的wav转的mp4: itunsmpb = 00000000 00000AF8 000001AA 0000000000000B5E
可见itunsmpb的第4项记录了原始长度信息
esds段（有03,04,05号，但不同的只有04）：
原始：04 80 80 80 19 40 15 00 00 DC 00 00 15 78 00 00 4D 08
减少：04 80 80 80 19 40 15 00 00 DC 00 00 15 D8 00 00 4E 60
貌似没有什么明显的规律？
再分别用neroaacdec和faad2(用源代码自带的aacDECdrop例子)解码原始长度的mp4
nero.wav：长度准确，回放无缝loop
faad.wav：总采样数0x2800（而itunsmpb的总和AF8+1A9+B5F=1800 !），而真正无缝的第一个采样是第0xDF0(AF8+1A9=0xCA1 !)个采样
我实在不知道要如何才能将FAAD2的解码数据和这些信息对应，算出正确的第一个采样的偏移来……
52wy@2010-06-16 20:24
发现就算封成mp4没有延迟只要再重新封进mkv依然会变成有延迟的状态，无语啊。
angering@2010-06-17 03:11
引用
最初由 52wy 发布
发现就算封成mp4没有延迟只要再重新封进mkv依然会变成有延迟的状态，无语啊。
請問也就是說成品MP4（音視頻都有）→mkv都會產生延遲么…… = =
那麼我們要用什麽格式好呢……
之前又聽說MP4比mkv略遜一籌……囧rz，國外都喜歡用MP4啊……搞不懂了……
啊……原來如此，受教了~
roozhou@2010-06-17 14:38
只要能正常播放，没什么好不好的。
52wy@2010-06-18 13:01
引用
最初由 angering 发布
請問也就是說成品MP4（音視頻都有）→mkv都會產生延遲么…… = =
那麼我們要用什麽格式好呢……
之前又聽說MP4比mkv略遜一籌……囧rz，國外都喜歡用MP4啊……搞不懂了……
啊……原來如此，受教了~
也不是，如果没有对音频重新编码，那么封成mkv或者mp4是不会产生延迟的。譬如大部分我们用的mp4 raw，只要你没重压音频就不用顾虑。
如果你将音频编码成aac就存在这个问题，比如dvdrip里的音轨是wav，你压成了aac，就会有延迟，压成mp4虽然没有延迟，但是封进mkv后延迟会恢复成和aac一样的状态，封成mp4则延迟略小。而且mmg对aac音频进行延迟处理也不能很精确到毫秒，总有10~20毫秒的误差，所以如果特别纠结音频问题的话还是别用aac了，我试过ogg音频不会延迟。
辉耀@2010-06-18 13:54
感谢总结性发言，之前看的有点迷糊了……
不过这样还是比较纠结啊……
mp4 raw如果要进行音频重压肯定就是要压到比较低的码率了，这时候舍弃HE AAC还是比较可惜啊……
即使是WAV的DVD，用OGG就没法用MP4封，兼容就差些了（PS3认不了MKV&OGG、MKV在PC也没略缩图==）；而且现在解不了OGG的MP4也挺多的……便携看片党也……
roozhou@2010-06-18 14:15
不知道mp3有没有这样的问题
52wy@2010-06-18 14:16
mp3也有哦，我测试了几种，只有ogg比较靠谱。
52wy@2010-06-18 14:17
引用
最初由 辉耀 发布
感谢总结性发言，之前看的有点迷糊了……
不过这样还是比较纠结啊……
mp4 raw如果要进行音频重压肯定就是要压到比较低的码率了，这时候舍弃HE AAC还是比较可惜啊……
即使是WAV的DVD，用OGG就没法用MP4封，兼容就差些了（PS3认不了MKV&OGG、MKV在PC也没略缩图==）；而且现在解不了OGG的MP4也挺多的……便携看片党也……
那就继续封aac呗，反正10~20毫秒的误差还是能接受的。
52wy@2010-06-18 14:29
送上一组测试数据
原始：audio.wav 23:24.821
megui输出的lc-aac：23:24.885 封成mka后：23:24.885
megui输出的he-aac：23:24.928 封成mka后：23:24.928
megui输出的ogg：23:24.821 封成mka后：23:24.834
megui输出的mp3：23:24.864 封成mka后：23:24.887
nero6输出的lc-aac mp4格式：23:24.821 封成mka后：23:24.842
nero6输出的lc-aac aac格式：23:24.843 封成mka后：23:24.843
单看精确度，ogg和nero6输出的mp4和原始wav一模一样，但是用mmg封一次后，只有megui输出的mp4和nero输出的.aac没有rp。ogg、mp3都存在不同程度的rp。
至于这些转换编码带来的长度误差到底会不会造成视频不同步，我没有科学地对比过，因为很多只有几十毫秒的误差，靠肉眼看和耳朵听很难明确判断出差距。但愿有高人能做出权威的测试。
roozhou@2010-06-18 15:15
楼上你的长度值是哪里来的？不要去相信mediainfo显示的信息，一定要再解码成wav才能得到确切的值。
megui输出的mp4就是nero输出的mp4，如果用mp4box封装，不会丢失delay。一旦将其换成mkv,aac或者用ffmpeg系的解码器解码或封装，延迟就会消失，长度就会增加。
52wy@2010-06-18 16:10
引用
最初由 roozhou 发布
楼上你的长度值是哪里来的？不要去相信mediainfo显示的信息，一定要再解码成wav才能得到确切的值。
megui输出的mp4就是nero输出的mp4，如果用mp4box封装，不会丢失delay。一旦将其换成mkv,aac或者用ffmpeg系的解码器解码或封装，延迟就会消失，长度就会增加。
用千千静听看的:cool:
MP4box的delay很多都不认吧~
alusta@2016-01-21 04:24
啊 挖個墳
我也遇到類似問題了 現在有解嗎?
30fps的視頻
原始是fraps+pcm的avi文件
然後視頻流用vs的ffms2源濾鏡引出來x264壓制
音頻流用ffmpeg的copy到wav文件 然後使用neroAacEnc的恒定碼率處理wav文件到aac
然後使用mp4box封裝.h264的視頻流和.aac的音頻流
我使用aegisub3.2.2進行了測試
載入原始的avi文件 --- 沒問題 音頻和視頻都是準確的
載入壓制后的.h264和.aac文件 --- 沒問題 同原始文件相同
載入封裝好的mp4文件 --- 出問題了 音頻方面比視頻晚了55ms左右
嘗試將.h264和.aac重新使用mmg封裝為mkv
然後aegisub載入封裝好的mkv文件 --- 這還是有問題 音頻方面會比視頻快10ms不到的樣子
雖然10ms一般是不影響什麼啦
但是那55ms就有問題了
從aegisub的頻譜上來看 是音頻頭部產生了55ms的空白所導致的
盤.百度.com/s/1jHndTrC
這是測試用的片子 也虧得是這片子 才讓那50ms的差別那麼明顯
aegisub分別載入h264和aac的話是準確的 和原始文件相同
但是一旦將h264和aac封裝進mp4之後 音頻就出現延遲了
解决方案:
不要使用裸流
nero直接輸出mp4封裝好的音頻留
x264的視頻流也封裝進mp4
然後使用lsmash的remuxer混流兩個mp4就能完美解決這個問題
[ 此帖被alusta在2016-01-25 08:56重新编辑 ]
«12»共2页
| TOP