Non-compliant streams and libavcodec (hacking x264)

[Dark Shikari]

For the hell of it, I figured I would spend an hour or two figuring out how x264 handles multiple reference frames, and, to be silly, try to make it use more than 16 :p

It crashed on anything over 17 even when I fixed the mallocs and such (I could probably find and fix this, but it doesn't matter for the purpose of this test). Maybe there's an off-by-one error somewhere that allows it to handle 17 without serious modifications, I don't know. So I created a stream with 17 reference frames, which as far as I know is completely out-of-spec and should fail miserably on playback.

Now, strangely enough, it worked on libavcodec (FFDShow and VLC), but not surprisingly failed under CoreAVC. How tolerant is libavcodec of these kinds of incompatibilities anyways? If someone made a stream with 100 reference frames, would it break?

Link to H.264 sample encode, test it on your decoder for laughs. (http://www.mediafire.com/?be0npcnyhxn)

[microchip8]

Here on Linux, MPlayer plays it fine but Xine does nothing (strange though as both MPlayer and Xine use FFmpeg/libavcodec as their backends - maybe Xine has an out-date version)

[mitsubishi]

Doesn't appear to work with cyberlink either.

I havn't got the Nero Showtime installed, but after remuxing into mp4 it loaded into Nero Vision, so Nero seems to work.

[akupenguin]

libavcodec will probably crash with >32 refs. Because interlacing can use up to 32 reference fields, so some of the arrays are that big. Still, it won't produce correct results with >16 (where "correct" means would comply with the standard if you remove the clause that says "dpb can't be bigger than 16"), because some of the arrays which don't take different values per field are only 16.

In general: libavcodec supports any extension to the standard that would take more code to detect and reject than to support.

[microchip8]

Ok, I know this is off topic, but I didn't want to start a new thread just to ask it. The previous H.263 standard supported Overlapped Block Motion Compensation (OBMC). Why doesn't H.264/x264 support OBMC? Or does it support it and I'm just not aware of it?

[akupenguin]

Dunno. Maybe the H.264 committee decided that OBMC wasn't worth the extra CPU cost. It requires motion compensating 4 times as many pixels.