[NUT-devel] Codec id - random notes

Luca Barbato lu_zero at gentoo.org
Sat Jun 24 00:20:21 CEST 2006

Michael Niedermayer wrote:
> Hi

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

dalias was suggesting that, iive was proposing to store the informations
about decoding (workaround or hints) in a separate field.

> 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

I see

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

My naive idea was just to put in the field proposed by iive the
workaround_bugs content. On decode init you just have to take it and put
it in the struct.

I can see different issues in this approach (like being quite ffmpeg
centric). Replicating the specific fourcc could be another possibility,
and as you said it would just mean we are wasting 4 byte just for
keeping things clean for not so technical reason.

so far no other proponents contested Michael stance beside me...


PS: I'm trying to force people analyzing others ideas making summary, if
I'm wrong please tell, if you think I'm wasting time please agree in
another way on a tag system.


Luca Barbato

Gentoo/linux Gentoo/PPC

More information about the NUT-devel mailing list