Libavcodec decoding B-Frames in ASP *.mp4 is broken

[Elias]

I'm sure you've run into this as well. When importing an XviD file with B-Frames into mp4 with MP4Box, and then playing it with ffdshow, the picture becomes uglier. This is because the B-Frames are somehow not rendered correctly with libavcodec. I tried the XviD decoder, and the picture was just fine. This has happened many times with me; I've been able to reproduce this with both ffdshow and VLC. I've never seen this with DivX encoded B-Frames files, so this could be an XviD issue, although I don't encode with DivX 5/6 at all, so I can't answer that. I believe this happens only if the file was encoded with B-Frames+Packed Bitstream. Might be good if you guys did some encoding tests and imported with MP4Box just so that we can get a proper conclusion of how this bug works.

Here are two screenshots of how it looks:

http://img229.imageshack.us/img229/5734/snapshot200512161355438fc.png

http://img229.imageshack.us/img229/7500/snapshot200512161356309ry.png

The first picture is the XviD in mp4, the second is the XviD in avi. Both are rendered by Libavcodec in MPC. Same ugly picture is shown with VLC. This has never happened with Simple Profile.

[stephanV]

Have you tried turning off packed bitstream in XviD VFW and then importing to mp4box? I believe there were some problems with mpeg4modifier and packed bitstream as well recently. So perhaps something goes wrong when unpacking the lot.

[Elias]

Have you tried turning off packed bitstream in XviD VFW and then importing to mp4box? I believe there were some problems with mpeg4modifier and packed bitstream as well recently. So perhaps something goes wrong when unpacking the lot.I didn't unpack this one, MP4Box does it automatically when importing. Also, I believe if I remember correct that the exact same issue happens when unpacking with MPEG4Modifier and importing to mp4 with MP4Box. The file in question didn't have Packed Bitstream from the beginning if I remember correct (I might have unpacked it with MPEG4Modifier and forgotten about it). However, I believe this is a Libavcodec decoding issue, because it doesn't display the picture improperly with the XviD decoder in mp4.

Also, you should know by now that I never encode with Packed bitstream :D

[Doom9]

Could you try to activate the "XviD and DivX QPel bug " option in the miscellaneous options of ffdshow (please try that even if you're not using QPel, it may have an effect even without QPel).

Also, having just very recently worked closely with screenshots, the two don't have the same AR.. did you notice that? The one in mp4 seems squeezed.

Is there any change if you create your XviD stream without packed bitstream (but still with B-frames) or without any b-frames and make the same comparison, take shots from the same frames?

[Elias]

Could you try to activate the "XviD and DivX QPel bug " option in the miscellaneous options of ffdshow (please try that even if you're not using QPel, it may have an effect even without QPel).

Also, having just very recently worked closely with screenshots, the two don't have the same AR.. did you notice that? The one in mp4 seems squeezed.

Is there any change if you create your XviD stream without packed bitstream (but still with B-frames) or without any b-frames?This doesn't happen with every B-Frame XviD, only random. I don't know what causes it. I've imported ASP files before without this issue. As for the snapshots, I took them with MPC. A quick look in properties in Firefox says that both are 512x384. However, I didn't take the snapshots frame by frame, because I don't know how to do that with mp4 files. But it's second by second, which probably is why you think it looks squeezed, because they're not exactly the same frame. Very observant of you though :)

Activating the "XviD and DivX QPel bug" didn't do any difference when decoding. Why should it though? QPel hasn't even been used in this case.

Edit: this doesn't happen when importing the avi to Matroska... which made me go apeshit and considered switching to Matroska permanently :D

[Doom9]

This doesn't happen with every B-Frame XviD, only random. And you cannot trace it back to a certain setting? Will encoding the same source again using different settings yield different results?

Why should it though? QPel hasn't even been used in this case.Because what is behind this option is a different idct. The problem it's supposed to fix may most easily show when QPel is used, but it's not restricted to the use of QPel.

because I don't know how to do that with mp4 files. You're playing in MPC, so pause, press Ctrl-G and enter the frame number you want to go to. Due to packed bistream, the AVI will require a different framenumber, but that's where you can hop between screenshots taken in a picture viewer until you get the right one (you'll grow to hate it but consider yourself lucky you're not making any codec comparisons).

Can you share a sample of your AVI?

[Elias]

Can you share a sample of your AVI?Sure. Hang on. I'll even share two samples from another completely different source with the same issue. I need a tiny moment to direct stream copy and import etc.

[bond]

the problem in mpeg4modifier was caused only when appending two packed bitstream .avi files while the first part didnt end correctly, iirc

Edit: this doesn't happen when importing the avi to Matroska... which made me go apeshit and considered switching to Matroska permanently :Dremuxing avi to .mkv in vfw mode means the video stream is stored the same way in .mkv as in .avi, obviously this makes no difference

if you want to really test if things work correctly with mkv, try native mkv

The file in question didn't have Packed Bitstream from the beginning if I remember correctso as this problem happens with a file that was not packed in .avi, obviously this problem has nothing to do with unpacking packed bitstream

[Elias]

http://rapidshare.de/files/9275798/Desktop.rar.html

I only made two very short samples. The second source can't be seen that properly, but the bug shows if you gaze carefully at the Oprah Logo. It should be enough to study the files and eventually find what's causing this bug. However, if you need bigger samples, let me know. Also, the second source has packed bitstream.

[Elias]

Just for the record: I did not encode these files originally (yes, I downloaded them, I'm a terrorist pirate. Sue me), so I don't know what exact settings have been used.

[Elias]

A quick look in MPEG4Modifier shows that they're both using Custom Quant Matrix, and the MPEG quant. Could this be what's causing the issue with Libavcodec? I thought that these settings were MPEG-4 standards compliant? Or is it just so that Libavcodec lacks support for them when parsed via mp4?

[bond]

it might be a bug in libavcodec's autodetect idct feature propably leading to an idct mismatch

ffdshow by default is set to "autodetect" idct.
i dunno whats going on in ffdshow, but when i set the idct manually to any other idct the correct image is shown on both samples

videolan shows the same problem (propably it acts the same way as ffdshow).

mplayer doesnt show this problem at all, which might be because mplayer might not have the idct detection set to autodetect? dunno
edit: in the mplayer doc it says mplayer uses autodetect by default too

this is especially strange as the clips dont seem to use qpel

any ideas?

[Elias]

it seems to be a bug in libavcodec's autodetect idct feature propably leading to an idct mismatch

ffdshow by default is set to "autodetect" idct.
i dunno whats going on in ffdshow, but when i set the idct manually to any other idct the correct image is shown on both samples

videolan shows the same problem (propably it acts the same way as ffdshow).

mplayer doesnt show this problem at all, which might be because mplayer might not have the idct detection set to autodetect? dunno

this is especially strange as the clips dont seem to use qpelI can confirm this. When putting the idct on XviD MMS (in ffdshow) instead of auto, the picture decodes clear as it should be.

[Doom9]

I wonder if there's a way to see which iDCT ffdshow chose.. could it be that the autodetection is based on fourCC and since there's no fourCC in MP4, ffdshow picks the default one?
However, even with AVIs, in what limited tests I did so far, I actually like the output of the XviD decoder much better.

[bond]

well i am not sure whats going on, as

- idct mismatch is iirc only possible when qpel is used, which isnt done with these clips
- mplayer also has autodetect idct set by default (the doc claims)
- the only xvid version that used a different idct (simple) was published in 2003 or so and the clips available here werent encoded with these old builds (according to the userdata in the vol), which doesnt mean the producer didnt make some strange own compile

so this is very very strange, but i would say as long as we cant reproduce this or know what exactly was done with that file, i would say the producer of this file did something very strange and is to blame :D

[Elias]

so this is very very strange, but i would say as long as we cant reproduce this or know what exactly was done with that file, i would say the producer of this file did something very strange and is to blameIn case anyone would like to contact him and ask him what the hell he is up to, here's the link:

http://interviewsrus.com/home/ <--- Encoded the Oprah episode