[FFmpeg-devel] [PATCH] GSM-MS decoder and encoder

[Michel Bardiaux]

Michael Niedermayer wrote:
> On Mon, Apr 28, 2008 at 06:56:32PM +0200, Michael Niedermayer wrote:
>> On Mon, Apr 28, 2008 at 05:16:21PM +0200, Michel Bardiaux wrote:
>>> Michael Niedermayer wrote:
>> [...]
>> 
>>>>> its the latter that should fix things if the file is
>>>>> obviously corrupted (which this one is!).
>>>> I see nothing corrupt on the file
>>>>> That is, at the end of get_wav_header (proper patch when
>>>>> there is agreement of the ways and means). Theoretically
>>>>> there is no maintainer for riff.c but since Michael is
>>>>> maintainer for the avi muxdemux I guess he is for riff.c too
>>>>> (should I correct MAINTAINERS?)
>>>> Yes i mainain riff.c, feel free to add me to the list if you
>>>> like ...
>>>>> And whether the demuxer or the codec changes the sample rate,
>>>>> a warning should be issued. OK?
>>>> Print as many warnings as you like :) but please dont reject
>>>> streams at random,
>>> It is *NOT* at random. The spec is very clear: the sample rate
>>> for GSM is 8000. Any other value in the RIFF headers is simply
>>> wrong and hints that the encoder has screwed up.
>>> 
>>>> patch below fixes this file and i suspect others as well, i
>>>> will apply it in 24h unless you object.
>>> The change was submitted for review and you didn't object... But
>>> if you insist on a quick-and-dirty fix for all those malformed
>>> files, patch attached for your consideration. But consider the
>>> consequences:
>> Your patch does not fix the problem just try to play them with
>> ffplay. My patch works, yours does not. That file does have a
>> sample rate of 44100 not 8000.

Which makes it a totally invalid encoding.

>> The easiest solution is simply to remove the code messing with the
>> sample rate. The alternative would be to add a sample_rate field to
>> AVStream so both demuxer and decoder can provide their sample rates
>> to the user app. But this seems really bad design as we know which
>> rate is wrong and which is not.

No we don't. A sample rate not 8000 can mean that the user forgot the
rate conversion *OR* that the user just forgot to store the correct rate
in the header.

>> And 2 sample rate fields will just force the user app to duplicate 
>> the logic, the situation would be different if we didnt knew what
>> was correct but heres its clear, if the demuser says X its X if the
>> demuxer doesnt say anything its 8000.
>> 
>> Most sane would be if(!avctx->sample_rate) avctx->sample_rate=
>> 8000;
>> 
>> IMO
> 
> Heres a proper patch for that:
> 

Rejected. It would accept, without any warning, completely invalid
values for encoding.

Unless, of course, if it's an emergency, in that case do zap all the guards.

But what we need is an agreed-upon policy. You have stated rather 
clearly that ffmpeg/ffplay has to be as permissive as possible on 
decoding; I accept that, but IMNSHO loud warnings are needed.

On encoding, the most sane is to reject non-conforming parameters. If 
codec and muxers disagree, as with MOV wanting to write 13200 in the 
header, it will be the muxer's job to do the change. Tit for tat.

The problem is when you have GSM in *and* out, i.e. inheritance of 
dubious parameters. If an input avi has been encoded (mistakenly) at 
44100, do we want -acodec copy to output that? And if *re*encoding is 
requested (a bad idea with GSM, but that is besides the point) do we 
want ffmpeg to produce a file that players would be justified to reject?

Greetings,

PS: I will be on holiday from Wed May 1st to Sunday.
-- 
Michel Bardiaux
http://www.mediaxim.com/