[Ffmpeg-devel] Shorten audio FourCC
Måns Rullgård
mru
Tue Oct 10 01:34:12 CEST 2006
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.
> 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.
> 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...
--
M?ns Rullg?rd
mru at inprovide.com
More information about the ffmpeg-devel
mailing list