Problems with ffdShow and VFR AVC in Matroska

[omion]

I encode lots of anime, and most of then have been variable frame rate Xvid in Matroska. My problem is that I'm now switching over to x264, and VFR AVC just doesn't play right in ffdshow.

Actually, it's not just VFR. If I use ANY kind of timecode file when muxing the Matroska file, even if it just says "all frames 25 fps", the output will be jittery.

If I don't use B-frames, or if I don't use a timecode file, then the problem goes away. (I assume it's partially due to the out-of-order B-frames in the AVC stream)

The problem is quite specific to Matroska with timecodes, AVC with B-frames, and ffdshow. If one of those does not exist, there is no problem.

My setup:
x264 v.261
MKVmergeGUI 1.4.2
Media Player Classic 6.4.8.4
Gabest's Matroska splitter 1.0.2.6 (also happens with Haali's 20050612)
ffdShow 20050611

Edit: Made some samples (note that these both are 25fps and from the same source. The only difference is a timecode file was used in one)
Without timecodes (http://people.ucsc.edu/~rswilson/other/NO%20timecodes.mkv)
Timecodes set to 25fps (http://people.ucsc.edu/~rswilson/other/timecodes%2025.mkv)

[bond]

how do you know what frames should get dropped and what not with avc?

did you use b-references/b-pyramid?

did you mux the avc stream to mkv from avi or mp4?
maybe there are problems with the times when muxing from avi and therefore not getting "native avc" in mkv

does the file play fine with the nero decoder?

are you sure its not just a "lack of cpu power" problem?

moved to container forum

[Haali]

Your timecode files need to be in coding order, not in display order. As for mpeg4-asp, this depends on the decoder. I wouldn't create vfr streams in vfw compatibility mode at all, as this is known to cause problems in some cases. If you want to use vfr with mpeg4-asp you should use the latest release of my splitter, and a recent build of mkvmerge (like http://www.bunkus.org/videotools/mkvtoolnix/win32/pre//mkvtoolnix-unicode-1.4.2-build20050616-1.rar), and mux in native mpeg4 mode with --engage native_mpeg4. The timecode files need to be in coding order for mpeg4-asp too.

[omion]

how do you know what frames should get dropped and what not with avc?I do all the frame dropping with MultiDecimate inside the AVS file, so x264 just sees a constant frame rate stream which I then tweak with the timecodes file. It's how I've been doing XviD VFR for the past year, and it seems to work just fine.

did you use b-references/b-pyramid?Yup. I'll make a sample with it off, and see if that changes anything.
[ edit: I made a sample without --b-pyramid, and the file with timecodes was better, but still not as good as the one without timecodes. (The encoding quality on both just stinks, though. MUCH worse than my example with --b-pyramid on. Strange.) ]

did you mux the avc stream to mkv from avi or mp4?
maybe there are problems with the times when muxing from avi and therefore not getting "native avc" in mkvFrom MP4. I try to avoid AVI at all costs :D

does the file play fine with the nero decoder?Yes, which makes me think it's an ffdShow problem, not a Matroska problem. However, Nero doesn't handle the 8x8 transform that I tell x264 to use, so I use ffdShow for my decoding.

are you sure its not just a "lack of cpu power" problem?Positive. I have an Athlon-64 3500+ with 1GB of RAM. MPC uses a constant 25% CPU on both the samples I posted. DVD-quality video generally takes up ~40% CPU.

moved to container forumFair enough. I put it where the ffdShow threads were, because I'm pretty sure that's where the problem lies, but it does span quite a few categories.

[omion]

@Haali:
Thanks for the reply! I'll have to re-arrange my timecodes to be in coding order, but that's not the entire problem...
In the samples that I posted, the timecode file was nothing more than:
# timecode format v1
Assume 25.000
so the order shouldn't matter...

PS. I didn't know about any problems with VFR and VFW compatability mode, do you have any more details? Most of my XviD encoding was done this way, and I don't want it to break somewhere down the line.

[Myrsloik]

A v1 timecode file can never be in coding order for natively stored asp/avc with b-frames as it is now. I've made a program that can rearrange timecodes until mkvmerge is improved that you can get from http://yatta.mellbin.org/misc/avcvfr9.rar though if you still want to use vfr.

The vfw vfr issues usually aren't that easy to notice in my opinion if you don't use something like dedup.

[omion]

:D I think I found the problem. As Myrsloik said, the timecode format I was using can't be in coding order, so mkvmerge was rearranging the AVC frames to be in display order to line up with the timecode file. This explains why the jerkiness was evident even in CFR files with timecodes.

I suppose ffdShow just expects the frames to be in the right order and plays poorly, but Nero knows how to rearrange them. Or something like that.