[Ffmpeg-devel] 4XM audio codec_tag

[Michael Niedermayer]

Hi

On Mon, Nov 06, 2006 at 03:16:32PM +0100, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> > Hi
> > 
> > On Mon, Nov 06, 2006 at 02:29:17PM +0100, Baptiste Coudurier wrote:
> >> Michael Niedermayer wrote:
> >>> Hi
> >>>
> >>> On Mon, Nov 06, 2006 at 12:17:20PM +0100, Baptiste Coudurier wrote: 
> >>> [...]
> >>>>>>>>>>> I would tend towards: better clutter the table a bit
> >>>>>>>>>>> and support more formats however rare than having a
> >>>>>>>>>>> cleaner table.
> >>>>>>>>>> Again you've drifted from the question of sharing the
> >>>>>>>>>> codec ID table between unrelated formats, and treating
> >>>>>>>>>> the RIFF table as some kind of absolute reference.
> >>>>>>>>>>
> >>>>>>>>>> Just face the facts: formats use different tags to
> >>>>>>>>>> identify codecs, no matter how much you pretend that
> >>>>>>>>>> all of them use the RIFF values.  The only way to
> >>>>>>>>>> properly handle this is by using one codec tag table
> >>>>>>>>>> per format.  End of story.
> >>>>>>>>> i have no problem with one table per format, what i have
> >>>>>>>>> a problem with is that libav* would fail decoding a file
> >>>>>>>>> if no match is found and that it would leave the codec
> >>>>>>>>> tag decission to the end user and not suggest a default
> >>>>>>>>> one if theres none in the one table for the target format
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> if OTOH there is one table per format and a default
> >>>>>>>>> fallback table then thats something different with which
> >>>>>>>>> iam fine
> >>>>>>>> A "fallback table" doesn't make any sense at all.  None.
> >>>>>>>> Zero.  Nil. Either a format supports some particular codec,
> >>>>>>>> in which case its ID table will have an entry for that
> >>>>>>>> codec, or the codec is not supported, in which case failure
> >>>>>>>> is the only sensible option. "Suggesting" to use a tag from
> >>>>>>>> some other random format instead is utterly senseless.
> >>>>>>>> Such behavior is what created the AVI mess in the first
> >>>>>>>> place.
> >>>>>>> avi is a generic container its supposed to be possible to
> >>>>>>> store anything in it (with a few exceptions) the same is the
> >>>>>>> case for mov, matroska and nut there is nothing messy with
> >>>>>>> that
> >>>>>> There is nothing messy about a container that can potentially
> >>>>>> be used with any codec.  The mess comes when people INSIST ON
> >>>>>> INVENTING THEIR OWN CODEC TAGS.  How the f*ck are others
> >>>>>> supposed to know what those tags mean if they are not included
> >>>>>> in some kind of official list?
> >>>>> uhm, look in the lists for avi and mov? and just read the tag,
> >>>>> ohh well is it so hard to guess that mpg1 is mpeg-1 video?
> >>>>>
> >>>> Now look at 'mp4s', we have to deal with avi fourcc cause someone
> >>>> stupid thought that putting avi fourcc was ok to do...
> >>> is that is the worst you can find? mp4s is microsofts official fourcc
> >>> for iso mpeg4 version 1 IIRC so i would suspect that this is besides
> >>> m4s2 the most official fourcc for mpeg4 in avi really not a good
> >>> example for bad user invented tags in avi ...
> >>>
> >> No, one day, someone put avi fourcc in mov, now we want to decode files
> >> using avi fourcc, then we have to check against avi fourcc in mov, and
> >> then collision appear.
> >>
> >> Now same guy thinks, yes, mov is generic container so I can put whatever
> >> fourcc I want, let's put mp4s... and we are in deep shit, He might not
> >> want it all in fact, he just stream copied, and since we honor codec_tag
> >> first, and after all we just cannot refuse him to do that, since mov is
> >> generic container.
> > 
> > ok, change stream copy to not set codec_tag by default but instead add a
> > command line parameter which changes that (sets codec_tag to input codec_tag)
> > 
> > furthermore
> > 1. if a codec_tag is set and it exists in the muxers table with a
> >    correct matching codec_id it should be used
> 
> yes
> 
> > 2. if a codec_tag is set and it exists in the muxers table with a
> >    wrong mismatching codec_id or it does not exist in the table then 
> >    it should be used if strict_std_compliance is set to 
> >    <=FF_COMPLIANCE_EXPERIMENTAL or cause a fatal error if not
> 
> I would not accept mismatching codec_id. If it does not exists, yes.
> 
> > 3. if a codec_tag is not set then set it depending on the table
> 
> yes
> 
> > 4. if there is no entry in the table then use a common table if
> >    strict_std_compliance is set to <=FF_COMPLIANCE_EXPERIMENTAL
> >    or cause a fatal error if not
> 
> yes
> 
> > do you agree with that?
> > 
> 
> mostly, yes.

then implement it if you have too much energy instead of wasteing it
for flaming :)

[...]

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