[NUT-devel] Codec id - random notes

[Michael Niedermayer]

Hi

On Sat, Jun 24, 2006 at 01:41:15AM +0300, Ivan Kalvachev wrote:
> 2006/6/24, Michael Niedermayer <michaelni at gmx.at>:
> >Hi
> >
> >
> >On Fri, Jun 23, 2006 at 10:17:58PM +0200, Luca Barbato wrote:
> >> Michael Niedermayer wrote:
> >> >
> >> > please forget it! send a path to libnut and you will see its not 
> >feasable
> >> >
> >>
> >> Well I believe you even if I'm missing why
> >>
> >> randomcodec_init(int workarounds) won't work
> >>
> >> the call would be something like codecs[tag].init(hints)
> >
> >i have not the faintest clue what you are talking about but storing
> >workarund hints in nut would need you to solve the following
> >1. the muxer has a packet and some codec identifer (fourcc, string or 
> >other)
> >   next the muxer must find the workaround hints, this requires decoding
> >   several frames (the muxer needs at least a mpeg4 decoder and possible 
> >   some
> >   parsers for various headers of other codecs
> >
> >are you suggesting that the nut muxer should decode frames? yes ? no ?
> >if no then from where do you want to find these hints? the muxer has
> >a bunch of "opaque" bytes which are an encoded video frame and a codec
> >id, things like width and height ...
> >
> >
> >2. the demuxer passes the hints to the codec, no codec in existance
> >   can make any sense of such hints, they either can detect the buggy
> >   encoder and deal with it or they cant, if half of the info has been
> >   butchered (fourcc changed from xvid to mp4v) then chances are _slightly_
> >   lower that the detecton will work, most of the time it will, but not
> >   always
> >
> >you can of coarse just store the fourcc either alone or in addition to
> >another identifer, that of coarse will help the decoder but i wouldnt
> >call that "hints"
> 
> XviD stores  bitstream version id. It is just number that is increased
> every time and encoder bug that affects decoding is fixed. If you have
> this number you can set workaround for all bugs even before the first
> decoded frame.

mostly

> (I guess this is not available for the oldest xvid streams, but still...)

yes

the issues here though are that 
1. as you say it fails with very old xvid (do you propose to drop support
   for that?)
2. xvid will store a id of "DivX503b1393" if the "correct" options are set
   it will store a xvid id too so there should be no problem currently but
   still discarding potentially usefull information is a risky practice
   this btw also shows nicely that intentionally wrong information isnt
   fourcc specific but its a issue caused by idiot companies
   who design decoders hw or sw that play only videos from a specific
   encoder, either you set the wrong id or your video doesnt play
3. xvid + some interlaced bug (only detectable through fourcc XVIX)
4. bugs from encoders which arent xvid or divx
   UMP4 comes to mind here, or a common bug with the padding at the end
   of frames detected by analyzing several frame ends

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is