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

[D Richard Felker III]

On Thu, Feb 13, 2003 at 08:29:12AM +0100, Ketil Z. Malde wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> 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?

I like startcode myself.

> >   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). 

Of course we're talking burst errors. Think of a bad block on a hard
drive (reading will return all 0's) or something. Flipped bits
essentially don't happen because of lower level checks, like you
pointed out.

> > 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?

Huh? I don't understand your question at all.

> > 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?

Depends on what you think he means.

> > 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?

Have you failed to read any of the past discussion whatsoever? This
has already been covered many many times. The story goes like this.

"Somehow", certain files, especially large files containing movies,
cdrom images, and the like, manage to get widely distributed and
"shared" on so-called "peer to peer" networks. :) Then users "somehow"
manage to obtain such files from multiple sources around the world,
using multiple mostly-compatible pieces of software to perform the
transfers. Between bugs in some of the less reputable software, and
occasional hard drive corruption that goes unnoticed, certain blocks
of these files may be damaged, and the effect is magnified when the
file is shared with thousands of people around the world.

If you can check and see that particular frames of your copy are
damaged, you can then "somehow" download them from another source to
repair your "backup". ;)

Credits go to Michael, I believe, for the humorous use of "somehow",
which I just shamelessly immitated. :)

Rich