Packed mpeg4 bitstreams, or why I will cry myself to sleep tonight

[Philip Langdale]

Hi all,

Long time readers will recall when I discovered that the hardware was
spitting out the packed
P-VOP twice in a row, so I had to drop the extra frame to keep things
playing correctly. I did
this by dropping any frame which didn't have a valid timestamp (the
frame would be output
once with the invalid timestamp and then again with the valid one).

Naturally, this was too simple, and today I was pointed to some
samples which are subtly
different and result in the hardware only outputting the P-VOP once
(yay!) and doing so without
a valid timestamp (boo!!!). I currently have no way of distinguishing
the two cases...

I ran the files through MPEG4 Modifier and if I unpack/repack them,
they work as usual (double
output) and the tool reports no differences in the metadata it
understands or in the frame lists.

Of course, perhaps Broadcom could fix the firmware to not output
duplicate frames and then I
wouldn't need to cry so much. :-)

--phil

[Naren (Narendra) Sankar]

Phil

I think it is time that I helped to stop you from crying so much :-)

Sorry that there has been a lack of response on my side.

Can you point me to the stream that shows what you discovered today since we should never have a case where we don't output timestamps if there were valid timestamps in the stream?

So this should be easy to track down and maybe this can help fix your other issues as well.

Thanks

Naren Sankar
+1 (408) 218 6327
Broadcom Corporation

Hi all,

--phil

--
To post to this group, send email to
crystalhd-...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/crystalhd-development?hl=en

[Philip Langdale]

Hi Naren,

Ok, here are three variations of the same file:

http://intr.overt.org/misc/packed.avi
http://intr.overt.org/misc/unpacked.avi
http://intr.overt.org/misc/repacked.avi

packed.avi is the original file sent to me in the bug report.
unpacked.avi is the same file unpacked by MPEG4 Modifier
repacked.avi is unpacked.avi repacked by MPEG4 Modifier

The first thing is I must explain how I handle timestamps. I do not
pass in the real timestamps
to the hardware - the handling of the 100ns units in the library is
scary and it can mangle timestamp
values without much effort - so I pass in fake timestamp values that i
know won't be mangled and
I map them to the real ones after the frame is decoded. And with
mplayer, I dont' even get the
real timestamps - mplayer maintains a separate list of pts that it
maps to decoded frames itself
(don't get me started on how fragile that is)

The unpacked.avi file decodes correctly (unsurprisingly)

The packed.avi file decodes the correct number of frames but the
packed p-frame is returned with
a 0 for the picinfo.timestamp value (so my passed in value is discarded)

The repacked.avi file decodes such that the packed p-frame is returned
twice in a row, once with
the 0 timestamp and once with the value I passed in.

I hope you can discover what's going on!

Thanks,

--phil

[Philip Langdale]

Hi everybody.

I made some progress on this one last week. I ended up taking vbindiff
(Visual binary
diff) to the files and made an interesting (to me) discovery.

The file that doesn't trigger the bug uses "delay frames" in the avi
stream to stand in
for the packed i/p frame. The repacked file uses "drop frames"
instead. I haven't been
able to find a clear description of the intended semantics or whether
drop frames are
considered generally acceptable (the files play fine with the usual
software decoder
suspects, so it can't be that unreasonable).

But the key thing is that these frames do look different and, as such,
I can detect
them and use or not use the bug work-around. I've got a simple
(possibly too simple)
patch in my github tree for this.

Right now I just assume an 8 byte packet is a delay frame and a 7 byte
packet is a drop
frame. I guess it's possible for there to be another kind of 8 byte
frame (1 byte of payload;
always 0x7F for a drop frame) but the drop frame has no payload, so
it's unambiguous.
And if I see one type of frame, I assume the stream is one type or the
other - I'm sure
you can build a valid avi that uses both, but I doubt you'd see a
divx/xvid file with packed
b-frames using them as anything except packed frame stand-ins.

--phil