[Ffmpeg-devel] Shorten audio FourCC

Diego Biurrun diego
Tue Oct 10 01:49:15 CEST 2006


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.

> > 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') },
    { 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') },
    { CODEC_ID_MP3, MKTAG('L', 'A', 'M', 'E') },

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

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

Diego




More information about the ffmpeg-devel mailing list