[MPlayer-users] Re: lavc-Options for *BEST* quality?

[Ketil Z. Malde]

Michael Niedermayer <michaelni at gmx.at> writes:

> global header packet
>   64bit startcode
>   length in time/video & audio stream count/version/...
>   time resolution (so we dont waste bits for constant fps movies)
>   checksum

Checksum for the whole packet (except the checksum :-) and the sync
word (which I think is a better term for "startcode"), right?

>   should be repeated a few times perhaps

Probably better to use an error correcting code, unless you
specifically want to add resilience against burst errors (as opposed
to random bit errors, i.e. you're using radio transmission).  I'm not
sure it's relevant, I think this should be handled on lower levels in
the transmission (eg. TCP/IP). 

> per stream header packet
>   64bit startcode
>   stream id
>   w/h/fourcc/samplerate
>   depth/fps/bitrate/...

> codec specific header packet
>   64bit startcode
>   codec specific data

What's this for?  A stream of a certain type is a stream of a certain
type, any acceptable codec is an acceptable codec.  (Tautology mode
off) What am I missing?

> per frame header packet
>   64-bit startcode for keyframes
>   timestamp vlc
>   stream id vlc
>   flags vlc
>   frame bitstream
>   optional checksum (depending upon flags)

Do you by 'frame' mean what I think you mean?

> timestamps 
>   for non keyframes should be encoded as VLC difference from the last keyframe
>   for keyframes simply relative to the file start & with the number of
>   bits/resolution specified in the header 

> optional checksum
> 16 or 32bit per frame checksums so files can be checked for damage quickly and 
> the damaged frame redownloaded

Again, you seem to imply error-prone transmission here.  Is that
really an issue?

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants