Guys, if you want you can try the new profile I'm currently testing for MCEBuddy 2.0
[x264-New]
profile-desc="H.264 New"
vf=pullup,softskip,pp=fd,scale=:-10,hqdn3d,harddup
lavdopts=threads=2
ovc=x264=yes
x264encopts=threads=auto:frameref=6:subq=7:qcomp=0.8:me=umh:me_range=24:trellis=2:bframes=0:nocabac=yes:partitions=p8x8,i4x4:level_idc=30:direct_pred=auto:deblock=-1,0:bitrate=1536:vbv_maxrate=1536:vbv_bufsize=1536
oac=faac=yes
faacopts=br=128:raw=yes:mpeg=4:tns=yes:object=2
af=volnorm=2
of=lavf=yes
lavfopts=format=mp4
#FileExtension=mp4
#IPod=yes
No sync issues and it is iTunes, iPod compatible and generally clean and safe from an MP4 perspective. Also handles high motion a lot better. Might be a little heavy on the CPU so let me know how you go if you use it. MP4 is likely to become THE container for H.264 with MCEBuddy 2.0 as it doesn't have the sync issues that AVI/H2.64 has. Working with a lot of other systems and devices is also a bonus.
Jens comments are generally correct. To produce a viable MP4 from a mencoder transcode you need a remux (see Jens ffmpeg example). MCEBuddy has this function, this is what #Ipod=yes does. I'll probably rename it to #mp4remux=yes or something in MCEBuddy 2.0.
Phredeaux
Does this work in 1.0.8, or just in the 2.0 beta?
I am hoping that this will fix the issue that I am having too.
I am using this to convert to iPhone.
Some files work great.
Some files will not xfer to the iphone (not a valid format, or somesuch). I suspect it may be a difference in the original signal (?) as there *may* be a correlation with what channel the signal is from.
Some files are completely munged with bad audio sync, but that seems to be related to a bad/noisy signal with a lot of dropped frames.