[XviD-devel] packed bitstream

suxen_drol suxen_drol at hotmail.com
Mon Jul 14 21:16:42 CEST 2003


hi,

On Sat, 12 Jul 2003 00:25:38 +0930 Radek Czyz <syskin at ihug.com.au>
wrote:
> I'm trying to create an mpeg4 parser (a small lib that will be able to
> analyze m4v stream or frames and give information about it - matroska
> project needs it).
> I'm trying to figure out the meaning of N-VOPs in packed bitstream..
> and I can't. What do they do? How can I tell if an N-VOP is dummy or
> real? Also, what is exactly written to the 'empty' frame after packed
> PB frame? (or maybe this is the N-VOP.. or maybe not).
> 
> Can anyone tell me please? :)

there is no way to differentiate "packed-n-vops" from real n-vop.
however, packed bitstream can be detected from the divx userdata tag.
the tag takes the form "DivX%dB%d%c", version, build, packed.

i deciphered divx's packed-bframes standard using divx5.01. that was
~18months ago, so maybe they have added some means to distinguish 
packed-n-vops from n-vops.

> Ah, one more thing - imagine that you have a pure m4v stream with 0x7f
> frames (yes I know current encraw doesn't do that - but what if) - is
> there a way to tell if 0x7f byte was added, and remove it? Note that
> I'm not decoding everything, only startcodes and headers - and 0x7f
> looks exactly like what I would expect at the end of real frame, so I
> can't just look at the byte before a startcode... but maybe there is a
> simple way to do that?

0x7f is returned from divx and xvid during the first few frames of
encoding, whilst the encoder is buffering bframes. the encoding
application *should* ignore these, and not write them to the stream.

i can't imagine an easy way to remove these from the bitstream. the only
way is to parse the entire bitstream (decode all the symbols):
1. parse each vop, until the "trailing bits" of the vop are reached.
2. ignore the following byte(s), until the next start_code is found

> If I don't do that and mux such stream to a container with 0x7f
> included (it would stick to the end of previous frame), do you think
> decoders will ignore it, or activate some kind of error correction?

robust decoders should handle 0x7f's fine. mpeg-4 is intended for
streamy/lossy environments. however, a strict mpeg-4 decoder (possibly
the ref software) will dislike 0x7f's in the bitstream.

-- pete




More information about the XviD-devel mailing list