[Ffmpeg-devel] Shorten audio FourCC

Måns Rullgård mru
Tue Oct 10 03:18:01 CEST 2006


Diego Biurrun said:
> On Tue, Oct 10, 2006 at 12:34:12AM +0100, M?ns Rullg?rd wrote:
>>
>> Diego Biurrun said:
>> > On Tue, Oct 10, 2006 at 12:22:54AM +0100, M?ns Rullg?rd wrote:
>> >>
>> >> Roberto Togni said:
>> >> > On Mon, 9 Oct 2006 20:04:42 +0100 (BST)
>> >> > M?ns Rullg?rd <mru at inprovide.com> wrote:
>> >> >
>> >> >>
>> >> >> Diego Biurrun said:
>> >> >> > Shorten audio is not yet supported by MPlayer since it lacks a FourCC in
>> >> >> > libavformat/riff.c.  Now adding one would be easy, but the question is
>> >> >> > which one to choose.  The obvious choice would be 'shn', but that's just
>> >> >> > three characters.  So maybe 'shor' or 'shn '.
>> >> >> >
>> >> >> > Then again, in libavcodec/shorten.c is the following code snippet:
>> >> >> >
>> >> >> >   /* shorten signature */
>> >> >> >   if (get_bits_long(&s->gb, 32) != bswap_32(ff_get_fourcc("ajkg"))) {
>> >> >> >   av_log(s->avctx, AV_LOG_ERROR, "missing shorten magic 'ajkg'\n");
>> >> >> >
>> >> >> > Does 'ajkg' have any further relationship with Shorten?  Should it be
>> >> >> > used as the FourCC?
>> >> >>
>> >> >> RIFF files use 16-bit IDs for audio.  Adding a bogus 32-bit ID there to
>> >> >> work around design limitations in mplayer is unacceptable IMO.
>> >> >>
>> >> >
>> >> > MPlayer can happily work also with 16-bit identifiers. But FOURCCs are
>> >> > used by most formats, and look "better" than a random 16-bit IDs.
>> >>
>> >> You're missing the point.  The file riff.c contains mappings between ffmpeg
>> >> CODEC_ID_* values and IDs used in RIFF-type files (AVI and WAV mainly).
>> >> This
>> >> should not be abused as a place for mappings between ffmpeg CODEC_ID_* and
>> >> mplayer internal numbers.  This becomes even more an abuse when the numbers
>> >> chosen are impossible to use in RIFF files.
>> >
>> > I count 5 32-bit IDs already.
>>
>> That's 5 errors, and they are no excuse for adding yet another.
>
> As it's not going to make fixing the issue significantly harder, I
> really don't think it's a big deal.

So why not fix it now?

>> > I'm not opposed to switching them all.
>>
>> Which codecs are they?  Do these have any more or less official proper
>> 16-bit IDs?  If so, we should switch them.
>
>     { CODEC_ID_FLAC, MKTAG('f', 'L', 'a', 'C') },

Why is that there?  It can't be used to store flac audio in wav or avi files.
If some other format uses that tag for flac audio, it should be in a different
list.

>     { CODEC_ID_TTA, MKTAG('T', 'T', 'A', '1') },
>     { CODEC_ID_WAVPACK, MKTAG('W', 'V', 'P', 'K') },
>
>     // for NuppelVideo (nuv.c)
>     { CODEC_ID_PCM_S16LE, MKTAG('R', 'A', 'W', 'A') },

This is nuv.c hijacking the table.  Nuppelvideo is not a RIFF based format, and
thus has no business using those tables.  16-bit PCM LE audio in RIFF formats
uses an ID of 1 as we all know.

>     { CODEC_ID_MP3, MKTAG('L', 'A', 'M', 'E') },

Same again.  MP3 in RIFF formats uses ID 0x55, official or not.

> None of them seem to have official 16-bit IDs AFAIK ..

Do any of them have unofficial 16-bit IDs?

>> > In the meantime one more won't hurt.  We want to release MPlayer 1.0RC1
>> > with Shorten support on the weekend ..
>>
>> That's no excuse.  Good software is released when it's ready, not declared
>> ready when you want to release.  You're starting to sound like my managers
>> at work...
>
> I don't believe that release management is that easy ..

I never said it was.  That's why we don't have formal ffmpeg releases.  Pushing
a dirty hack because you want to release before some random date is typical
commercial development practise.  We don't have any hard deadlines imposed by
managers, customers, or anyone else.  If the code isn't in a state good enough
for an official release, then we shouldn't be labeling it as such.

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




More information about the ffmpeg-devel mailing list