Problems decoding Mpeg4

[Bernard Maassen]

Dear Support,

We're running into a problem while decoding mpeg4 frames. The transcoder gives an error with no message, no hint and facility:12 code:1
We have captured one of the video streams, and tried it with the demo VideoConverter, which gave the same error.

Is there anything we can do to find out what the problem is here?

I've attached the video data in 2 formats:
hardcrash1_with_size.dat: size:frame:size:frame:size:frame(sizes are in 4 bytes)
hardcrash1.dat: frame:frame:frame:frame

[Svilen Stoilov]

Hi Bernard,

It turns out that the problem is a mixture of a broken mpeg4-visual stream and a too strict decoder in AVBlocks.

There are errors in frame #9 (1-based counting, an I frame): the last 3 macroblocks are invalid, they cannot be decoded and this stops the transcoding.

This particular error in the stream is not critical and we can make the decoding process more robust.

What we can do:

1. Drop the whole frame where such error occurs. I've tested this and we successfully decode 10 out of the 11 frames from the attached stream (frame #9 is missing). This is easy to do but it's not optimal.

2. Ignore the bad macroblocks and produce a decoded frame with artefacts. I've tested this as well and I have 11 frames decoded with frame #9 having artefacts.

The artefacts are acceptable and I guess this is better than dropping the whole frame. However this solution needs more testing especially with longer streams. We'd like to know if this defect occurs only on I frames, if it can be in the middle of the frame or always at the end and similar things.

3. Of course the best would be to conceal the defect by reusing previous macroblocks but currently I have not worked on this so far.

So please tell us if 1) or/and 2) are good enough for you. For 2) it would be very helpful if you provide us with longer test streams so that we can investigate the defect pattern and test more thoroughly the error recovery.

It's also interesting to know how this defect is produced: is it a camera firmware bug, is it a network problem?

Best Regards,

Svilen

[Bernard Maassen]

Hi Svilen,

I've attached a few more "crash files", but all are relative short. I will try to create a larger one.
For the short term option 2 is good enough for us. For the long term, option 3 sounds nice.
I think its an firmware bug on the camera, as i can only reproduce it for 1 model range.

[Bernard Maassen]

Hi Svilen,

I've mailed a larger file to support

[VK]

This should be fixed in AVBlocks 1.9