[MPlayer-dev-eng] Nut & framecode...

[Michael Niedermayer]

Hi

On Friday 23 April 2004 08:09, D Richard Felker III wrote:
> I think Michael's convinced me that framecode is a good thing, for
> extensibility reasons. For now it can be used like my bitfields, and
> more specialized muxers could choose an optimal framecode table if
> they like. But I'd like to propose some minor changes and suggest a
> sane default framecode table that muxers could use. First, the
> changes:
>
> 1. XOR framecode byte with 'N' or 'N'^0xff.
>
> Right now 'N' is the forbidden framecode, and that makes things
> particularly annoying for muxers that want to use the framecode as a
> sort of bitfield. You might say the muxer could just do the XOR
> itself, but then it has to write the framecode table in the global
> header this way, and Michael's compression tricks for it no longer
> work because it's shuffled out of order.
>
> If XOR is made part of the spec, then 0x00 or 0xff becomes the
> forbidden framecode, and nothing special is needed to exclude it.
> (Just have a table of 255 framecodes instead of 256).
ok

>
> 2. Remove predictive coding for data_size.
>
> It's bad for error recovery and unlikely to help except for CBR which
> wastes 30% or more space anyway.
can u explain why its bad for error recovery? when we loose one header we 
cannot recover before the next type >0 frame and that resets the predictors 
so it just uses the values in the stream header not the size of past packets

>
> 3. Clean up flags table (flags[framecode]). It's very confusing.
ok

>
> 4. Perhaps replace all timestamp_lsb stuff with timestamp_delta.
i would rather combine the lsb and full timestamp
btw, lsb timestamp coding is used in allmost all video standards 
(mpeg1,mpeg2,mpeg4,h263,h264)

>
> 5. Remove the buffer overflow from the main header framecode table. :)
ok :)

>
> All of these except #5 are open to discussion. I'm also pretty
> determined about #2 tho. Maybe #1 is stupid and you could just add/sub
> instead of xor...
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Now, the default framecodes:
>
> data_size_msb is always coded
> data_size_mul is always 16
> usage of the bits in framecode:
> bits 0-1: stream id
>  00,01,10 = the 3 most overhead-critical streams (audio, then video)
>  11       = vlc follows (or stream 4 if only 4 total)
> bits 2-5: low 4 bits of data_size
> bits 6-7: pts code:
>  00=delta1
>  01=delta2
>  10=delta3
>  11=vlc follows
>
> Note that keyframe flag is NOT present. For intra-only streams
> (including most audio) it's pointless. For such streams, all
> framecodes will have their keyframe flag set.
>
> In intra/inter streams (most video), keyframes are rare. Therefore all
> framecodes will have the keyframe flag cleared, except for one
> reserved combination for which all fields are vlc-coded (stream id,
> pts) and data_size_mul=1, data_size_lsb=0.
>
> Some optional variants:
> - use 3 bits for stream id and 3 for data_size_lsb if there are more
>   than 3 audio/video streams and more than 4 total streams.
> - likewise only use 1 bit for stream id if there are just 2 streams,
>   and exclude stream id entirely if there is just one.
> - remove pts code if the stream is fixed_fps (pts is always +1) and
>   use the extra bits for something useful. (but what about b frames?)
> - try to put the reserved frame codes (the one that conflicts with
>   startcode and the one used for keyframes) with a less size-critical
>   stream id. first choice is subtitle, then video.
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> A few notes:
>
> Headers on packets < 2048 bytes should only need 2 bytes. This means
> that you don't have to worry about bad overhead increases from large
> packets. The only trouble case is very small packets, and even then,
> overhead is only 1% for 200-byte packets. Average packet size for
> low-bitrate vorbis could easily be as low as 75 bytes, but that only
> gives 2.66% overhead. It's really not possible to do much better.
> Michael had one-byte-per-packet headers before, but that was with data
> size prediction which only works for CBR. Keep in mind these figures
> don't count frames with startcodes ("type2").
for a single audio stream with packets <200byte single byte headers _are_ 
possible even if the stream is VBR

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en