MPEG 4 Part 2 decoding: First (keyframe works, rest fails with "Unsupported format (facility:5 code:7)"

[sander.borsboom]

Hello,

when I try decoding MPEG 4 Part 2 frames, only the first keyframe succeeds but then all following frames fail. My guess is that we aren't providing the frames in the correct format, so I'll explain what it gets currently:

The first frame is started with a full header, an example follows with some comments explaining my interpretation:

// visual_object_sequence_start_code

00 00 01 B0 F5

// visual_object_start_code

00 00 01 B5 0E CF 

// video_object_start_code

00 00 01 00 

// video_object_layer_start_code

00 00 01 20 00 C8 8D 88 1F 45 14 04 3C 14 10 3F 

// group_of_vop_start_code

00 00 01 B3 00 10 27 

// user_data_start_code

00 00 01 B2 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

// Start of an I Frame

00 00 01 B6 10 03 05 8C 15 2D EB 23 7D FB C6 FB FF 17 B7 CF 7C 95 <snip>

Then the second frame that fails to decode:

// Start of a P frame.

00 00 01 B6 51 0B 02 97 DF 7D F1 7B DE 9A B3 68 5A 3B <snip>

What would be the best approach to debug this?

Greetings,

Sander Borsboom

[Svilen Stoilov]

(Again - this was meant to reach you on Friday)

 

Sander, do you use the same code that you have for H264 decoding (based on the PullPush sample app)?

 

If yes then there are few things that are interesting:

- what is the error returned by the Transcoder object?

- do you receive at least one uncompressed frame before this error (at least one call to primo::Stream::write)?

- do you manage to get the proper parameters from MediaInfo before initializing the Transcoder?

 

I will gladly help with debugging if you provide me with the elementary stream (MPEG-4 Visual). It's better if you can give me the packet boundaries as well so that I can simulate the way packets are pushed to the transcoder (and the internal MPEG-4 decoder). I will be able to see whether:

- your input is malformed

- our internal decoder has a possible bug

- the problem is in the code that feeds the data to the transcoder

 

It's best if you can provide me with 2 files:

1. a dump of the MPEG-4 Visual stream (at least a few frames)

2. a file with the frame sizes as you receive them (in binary or text format it doesn't matter as long as you describe it).

Even if give me only the dumped elementary stream I will run it through the MPEG-4 decoder to see if it has any problems and what's the error.

 

You can send the file(s) through http://www.sendspace.com/ or we may give you an ftp account if you prefer.

 

Regards,

Svilen

[sander.borsboom]

Hi Svilen,

don't worry about the late reply, I spent the whole day porting our code to Linux, so I had enough to do ;).

I am now running it on Linux and it seems to survive a bit longer, this time it got to 10 frames, but my guess is that something of input is sometimes malformed when the crash happens. 

I attached two files:

• mpeg4.offsets: for each "frame" a 4 byte size value in Big endian format. So the first frame has a size of 16,035 bytes.
• mpeg4.data: a dump of the MPEG-4 data as we decode it.

So for this stream, the system decodes the first 10 frames correctly: they all show the correct images. Decoding the 11th frame (size: 2933 bytes) then results in a core dump with the following error:

AVBlocksJNITestUtil: MediaData.h:70: virtual bool_t primo::codecs::MediaBufferImpl::setData(int32_t, int32_t): Assertion `false' failed.

Aborted (core dumped)

"AVBlocksJNITestUtil" is my c++ test utility which just load the stream and decodes one frame after the other. "MediaData.h" is not a file of ours.

As far as I know we get the correct data from MediaInfo: the resolution is correct (if not, the images wouldn't display) and the codec is correct.

If it is not a decoder bug, I think I should be able to send you our c++-only code(after some clean-up) which is able to reproduce the crash.

Greetings,

Sander Borsboom

Op maandag 12 augustus 2013 16:27:31 UTC+2 schreef Svilen Stoilov:

[Svilen Stoilov]

Sander,

Thanks for the video. I tried to decode it by modifying the PullPush sample. Instead of "pulling" the samples I read them from the "mpeg4.data" file by using the frame sizes in "mpeg4.offsets". I found that the AVBlocks transcoder stopped on frame #1 (this is the second packet and the first P frame after the headers and the I frame) with an "unsupported format" error.  Actually the frame is decoded but there's some unexpected stuffing (padding) bytes between the frames. I modified the AVBlocks transcoder to ignore them and then I managed to decode your sequence of 11 frames (mpeg4.data).

 

I believe that your input is OK. We should fix AVBlocks to allow for these stuffing bytes between the frames. I'll investigate it a little bit more but so far the problem seems easily fixable and we can provide a hotfix release of AVBlocks quite shortly.

 

The thing that actually puzzles me is that you say you manage to decode 10 frames and you get the error on the 11-th frame. Moreover you error is different than the one I hit.

To recapitulate:

- I can see a problem in AVBlocks decoding your sequence.

- I can fix it and decode the full sequence (11 frames). Without the fix I decode only the first frame. We can wrap it in a hotfix release of AVBlocks this week so that you can test with it.

- I cannot replicate your behavior. And this is really the strangest thing so if you have more information on this it would really help us.

 

Regards,

Svilen

[Sander Borsboom]

Hi Svilen,

thank you for fixing it, I look forward to the hotfix version to test it. 

About reproducing the problem: I see exactly what you are reporting in Windows, but when I try it in Linux, I get the scenario which I reported earlier. 

I am readying a copy of our testcode for you so you can more easily see what we are doing and possibly reproduce it with our code. My hope is to finish this today, but I thought it would be important to give you the Linux detail since it might let you find the problem before even getting our code.

Greetings,

Sander

2013/8/13 Svilen Stoilov via AVBlocks Support <avblocks-support+noreply-APn2wQe...@googlegroups.com>

--
You received this message because you are subscribed to the Google Groups "AVBlocks Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to avblocks-suppo...@googlegroups.com.
To post to this group, send email to avblocks...@googlegroups.com.
Visit this group at http://groups.google.com/group/avblocks-support.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Met vriendelijke groet / Kind regards,

Sander Borsboom
Technical manager video analytics

Cameramanager.com     Office:       +31(0)88-006.84.50 / +31(0)88-006.84.58 (direct)
Hogehilweg 19               Tech:        sup...@cameramanager.com
1101 CB Amsterdam      Email:       sander....@cameramanager.com
The Netherlands            Site:          www.cameramanager.com

[Svilen Stoilov]

I see. I'll test on Linux today and I'll report back (may be tomorrow).

 

Regards

Svilen

On Wednesday, August 14, 2013 3:46:36 PM UTC+3, sander.borsboom wrote:

Hi Svilen,

thank you for fixing it, I look forward to the hotfix version to test it. 

About reproducing the problem: I see exactly what you are reporting in Windows, but when I try it in Linux, I get the scenario which I reported earlier. 

I am readying a copy of our testcode for you so you can more easily see what we are doing and possibly reproduce it with our code. My hope is to finish this today, but I thought it would be important to give you the Linux detail since it might let you find the problem before even getting our code.

Greetings,

Sander

[Svilen Stoilov]

Hi Sander,

 

I tested on Linux (Ubuntu 32-bit) and I observed the same situation as on Windows:

 

- Before the fix for the MPEG-4 decoding: I get only the first frame decoded. The second frame produces an error "Unsupported Format"

- After the fix I manage to decode the full sequence of 11 frames. I tested with YUV420 and RGB24 output. They both look OK.

 

In my tests the decoded outputs on Windows and Linux are binary equivalent.

 

So, it's likely that you use the AVBlocks Transcoder differently on Linux - compare the socket configuration and the way you feed data.

 

If you can give me a sample project that reproduces the error on Linux (the assertion in AVBlocks) I'll definitely look at it because the assertion should not happen even if the AVBlocks Transcoder is misconfigured.

 

I can publish my tests if you want (basically a modified variant of the PullPushDecoder sample that gets the data from your mpeg4 data and offset files) .

 

Regards,

Svilen

 

On Wednesday, August 14, 2013 3:46:36 PM UTC+3, sander.borsboom wrote:

Hi Svilen,

thank you for fixing it, I look forward to the hotfix version to test it. 

About reproducing the problem: I see exactly what you are reporting in Windows, but when I try it in Linux, I get the scenario which I reported earlier. 

I am readying a copy of our testcode for you so you can more easily see what we are doing and possibly reproduce it with our code. My hope is to finish this today, but I thought it would be important to give you the Linux detail since it might let you find the problem before even getting our code.

Greetings,

Sander

[Sander Borsboom]

Hi Svilen,

it seems you are right: I looked at it again under Linux and it does fail to decode after the first frame, but it kept writing to the output stream which I think confused me.

So I think the next step is for us to test the new version with our code with some more streams, when do you think it will be available? I do not have your e-mail address, so If you send me a mail at sander....@cameramanager.com, I can send you our code.

Greetings,

Sander

2013/8/15 Svilen Stoilov via AVBlocks Support <avblocks-support+noreply-APn2wQe...@googlegroups.com>

[Svilen Stoilov]

Hi Sander,

 

We've built AVBlocks 1.5.0 with the fix for MPEG-4 decoding. You can get the demo binaries from the AVBlocks-Samples repo:

https://bitbucket.org/primosoftware/avblocks-samples/downloads

 

Regards,

Svilen

On Thursday, August 15, 2013 2:22:05 PM UTC+3, sander.borsboom wrote:

Hi Svilen,

it seems you are right: I looked at it again under Linux and it does fail to decode after the first frame, but it kept writing to the output stream which I think confused me.

So I think the next step is for us to test the new version with our code with some more streams, when do you think it will be available? I do not have your e-mail address, so If you send me a mail at sander....@cameramanager.com, I can send you our code.

Greetings,

Sander