Log in

View Full Version : x264 r1400 and massive audio delay


may24
31st January 2010, 23:16
Hi all,

I'm having a strange problem here. Now, before anyone starts yelling at me that x264 is only a video encoder and has nothing to do with audio, please read the whole story.

onlinetvrecorder is an internet service that records your favorite TV program while your're away. You can download this taped recording afterwards.
These guys record in mpeg-2 (supposedly) and re-code in DivX 5.
So the whole thing is an .avi with DivX + mp3 sound (the filename might be misleading I know ...)

Unfortunately the video is still full of advertisements which I would get rid of. So I load the file via .avs script and trim the parts:

vid=AviSource("The_Ellen_DeGeneres_Show_10.01.29_16-00_uswnbc_60_TVOON_DE.mpg.avi")

v1=vid.Trim(9948,33179).FadeIO(15)
v2=vid.Trim(37678,44853).FadeIO(15)
v3=vid.Trim(50258,63220).FadeIO(15)
v4=vid.Trim(67720,74245).FadeIO(15)
v5=vid.Trim(79195,86612).FadeIO(15)
v6=vid.Trim(92309,102845).FadeIO(15)
v7=vid.Trim(109757,115210).FadeIO(15)


v1++v2++v3++v4++v5++v6++v7


When you playback the .avs there is no offset between video and audio.
I process the sound via MeGUI using Nero's AAC encoder and variable bitrate settings (-q 0.4)

For the re-encoding part I use a simple .bat file:

"C:\Program Files\x264\x264-r1376.exe" --crf 20 --level 4.1 --b-adapt 2 --bframes 3 --ref 3 --partitions all --direct auto --weightb --me umh --merange 16 --subme 9 --mixed-refs --8x8dct --no-fast-pskip --no-dct-decimate --vbv-bufsize 30000 --vbv-maxrate 38000 --trellis 2 --threads auto --output ellen3-20.mp4 ellen.avs


Finally vid + audio is muxed by Yamb into a .mp4

And here is the problem:
When the video is re-encoded with x264 r1376 everything is fine. No offset between video and sound.
But if I use x264 r1400 or above I got offsets up to 2 seconds !
I tried several players. Starting with MPC+CoreAVC, mplayer (win), VLC and Windows Media Player 11. The result is always the same ...

Could this be the prob:

Overhaul the muxers to pass through timestamps instead of assuming CFR.
Also overhaul muxers to correctly use b_annexb and b_repeat_headers to simplify the code.
Remove VFW input support, since it's now pretty much redundant with native AVS support and LAVF support.
Finally, overhaul a large part of the x264cli internals.

I tried "--force-cfr" but it has no effect.
A swift analyze of r1376 and r1400 clips prove that the amount of frames a equal, although the filesize is not. (Quite obvious since r1400 is more optimized ...)
The effect can also been seen when putting the stuff into a .mkv container ...

Guest
1st February 2010, 01:50
Closed for rule 6 violation. We do not help with downloaded files.

I did a little research on the site and cannot find any indication that they have the legal right to do what they are doing. If you can prove it then the thread can be re-opened. Send me a PM about it.