『漫游』酷论坛>『影音数码技术学习交流』>太较真就让人纠结了~

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