[Ffmpeg-devel] [PATCH] remove special nuv wav tags

Måns Rullgård mru
Mon Nov 6 01:03:39 CET 2006


Michael Niedermayer <michaelni at gmx.at> writes:

> Hi
>
> On Sun, Nov 05, 2006 at 11:24:15PM +0000, M?ns Rullg?rd wrote:
>> Baptiste Coudurier <baptiste.coudurier at smartjog.com> writes:
>> 
>> > Reimar D?ffinger wrote:
>> >> Hello,
>> >> On Sun, Nov 05, 2006 at 09:13:14PM +0000, M?ns Rullg?rd wrote:
>> >>> Also, setting AVCodecContext.codec_tag in nuv.c seems a little
>> >>> questionable, given that most of the code treats it as RIFF codec tag,
>> >>> which it is not in this case.
>> >> 
>> >> Either codec_tag is supposed to be riff tags then it should be removed
>> >> or it is supposed to avoid information loss when doing stream copy then
>> >> this is the correct use IMO.
>> >
>> > codec_tag is not riff tag, mov sets it too, and seriously I don't see
>> > why demuxer should not set it to what's in the container.
>> 
>> Well, I guess I'm OK with demuxers setting codec_tag to whatever value
>> the format uses, on the odd chance that something has a use for that
>> piece of information.  I still find it a little strange putting
>> format-specific data in AVCodecContext.  Don't we usually try to
>> separate codecs from containers?  Besides, the codec_id field is
>> meaningless without knowing which format it came from.
>> 
>> > Now lavf exports CODEC_ID which is unique and accurate. That means that
>> > applications using lavf should use CODEC_ID, not codec_tag.
>> > codec_tag is NOT accurate NOR unique.
>> 
>> Yes, I've never found codec_id insufficient.
>
> well, some files need the codec_tag for correctly decoding them, RTFS 
> h263dec.c (fourcc XVIX or UMP4 for example)

The one UMP4 sample I can find on mphq decodes perfectly fine without
codec_tag being set.  I can't (easily) find any samples with XVIX.
Can you name one?

> also huffyuv need various random fields from the avi header for being
> correctly decoded, i think you wont like that either but its needed
> dropping huffyuv isnt ok ...

I can only see it using AVCodecContext.bits_per_sample and opaque
extradata.  I don't think this is pretty, but it is an issue
completely independent from mixing codec tags from different formats.

-- 
M?ns Rullg?rd
mru at inprovide.com




More information about the ffmpeg-devel mailing list