太较真就让人纠结了~

发现wav音频转成aac后长度总会发生变化，用megui、neroaac都试过了~难怪每次做完dvdrip总觉得音频有些异样，一直以为是自己太敏感了，今天仔细比对了一下长度才发现有玄机啊。。。。

这种情况兄弟们都怎么办？无视之还是手动填补差距呢。。。。。

啊 挖個墳

我也遇到類似問題了 現在有解嗎?

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就能完美解決這個問題

楼上你的长度值是哪里来的？不要去相信mediainfo显示的信息，一定要再解码成wav才能得到确切的值。

megui输出的mp4就是nero输出的mp4，如果用mp4box封装，不会丢失delay。一旦将其换成mkv,aac或者用ffmpeg系的解码器解码或封装，延迟就会消失，长度就会增加。

引用

最初由 辉耀 发布
感谢总结性发言，之前看的有点迷糊了……

不过这样还是比较纠结啊……
mp4 raw如果要进行音频重压肯定就是要压到比较低的码率了，这时候舍弃HE AAC还是比较可惜啊……
即使是WAV的DVD，用OGG就没法用MP4封，兼容就差些了（PS3认不了MKV&OGG、MKV在PC也没略缩图==）；而且现在解不了OGG的MP4也挺多的……便携看片党也……

那就继续封aac呗，反正10~20毫秒的误差还是能接受的。

不知道mp3有没有这样的问题

引用

最初由 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音频不会延迟。

引用

最初由 52wy 发布
发现就算封成mp4没有延迟只要再重新封进mkv依然会变成有延迟的状态，无语啊。

請問也就是說成品MP4（音視頻都有）→mkv都會產生延遲么…… = =
那麼我們要用什麽格式好呢……
之前又聽說MP4比mkv略遜一籌……囧rz，國外都喜歡用MP4啊……搞不懂了……

啊……原來如此，受教了~

我曾拿一段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的解码数据和这些信息对应，算出正确的第一个采样的偏移来……