Log in

View Full Version : What is it with mencoder and AV sync?


Tom Servo
11th December 2007, 20:21
Trying to convert my first video for my iPod Touch, I've encountered grave AV sync issues.

I didn't initially have a clue why that'd happen, but after unsuccessfully trying to unmux a AVC stream out of a MP4 file (which are pretty broken, because it made mpeg4ip and MP4Box cry) with it, I've found out about -noskip and the harddup filter.

Retrying to encode the video with these options, I've faced yet again AV sync issues.

Because on my platform, namely Solaris, libfaac doesn't compile, I have to perform the audio encoding with Nero AAC in a Linux zone. As such, I have to split audio and video encoding into seperate steps.

Now I've read about -mc 0, but why do I need to specify even flags, even though I'm already telling it to not skip frames or reduplicate removed duplicates. The manual says that -mc takes care about AV sync, but I'm using the -nosound flag and don't even see a point in it.

It's becoming mildly aggravating, any hints are appreciated.

Thanks.

--edit: Mencoder 1.0.rc2 with x264 r702, outputting into a H264-ES stream.

nm
12th December 2007, 13:23
What are the full command lines you use for the encoding process (demuxing, encoding, muxing)?

Can you upload a problematic source sample somewhere?

micmac
13th December 2007, 12:23
Using "-nosound" is a bad idea when encoding with mencoder. Use "-oac copy" instead. How is it to know the AV delay when one tells it to forget about the audio track altogether?

nm
13th December 2007, 14:39
I think that in this case A/V delay information is lost anyway because video is output as an elementary stream and all frames are encoded without duplication or dropping. If some special delays have been set in the original source, they would need to be read and reconstructed when muxing the re-encoded video and audio streams back together, or applied when decoding the audio from the original source. I don't know of any tools to do the former, but the latter should be possible with mplayer -ao pcm. However, it would still be interesting to see what kind of a source brings up these difficulties.

Personally I use the same basic approach (except that I decode audio with mplayer, encode it with Vorbis and mux the resulting streams to Matroska). I haven't had a single sync problem with my PAL MPEG-2 DVB sources and various others.

Tom Servo
13th December 2007, 16:00
I suppose there's extra delay information, because the source file is an Xvid, possibly also encoded with duplicate frame dropping.

I've tried it using -oac copy, but the only container that MP4Box seems to accept for H264 video is MP4, and the MP4 files generated by mencoder seem to be faulty. MP4Box says something about "AvcC field wrong size (8)", then imports the audio track, sets SAR and then core dumps.

Another thing I've tried is force mencoder to mux the external AAC file into the video during encoding, using -oac copy, -audio-demuxer and -audiofile, but a) I suppose the delay info goes missing that way, too, and b) it doesn't recognize the proper bitrate and screws up the file, too.

I'll continue to play around a bit.

nm
13th December 2007, 18:31
How do you demux and decode the audio that you feed to Nero AAC? Have you tried doing that with mplayer -ao pcm -vc dummy -vo null?

evade
5th January 2008, 06:26
I have found mencoder likes to drop frames, if you are encoding audio externally and muxing these options are crucial, particularly harddup:

-mc 0 -noskip
-vf harddup # this should be at the end of your filter chain
-ofps 24000/1001 # change this to match your source, mencoder seems to handle variable framerates and keep sync if it is muxing audio but not otherwise

rernst
11th January 2008, 04:25
If you are muxing back and forth you have to include the -vf harddup option which stops mencode from inserting a repeat frame flag which the muxer doesn't understand. If it plays fine before muxing but is screwed up afterwards, this might be the first thing I would look at.

It is a common problem. It increases file size *slightly*, at least with run-of-the-mill 24 fps motion content.