[FFmpeg-devel] [PATCH] adpcm-ima-wav header and codec
Timofei V. Bondarenko
tim
Wed Oct 17 15:24:02 CEST 2007
Michael Niedermayer wrote:
> On Mon, Oct 15, 2007 at 07:55:29PM +0400, Timofei wrote:
>> Hi.
>>
>> I found a few bugs in the adpcm-ima codec.
>> This format is used in smv video by sigmatel-based mp3 players.
>>
>> 1) The field 'bytes-per-second' in WAV header is set incorrectly.
>> This breaks seeking on hardware player.
>> I found the bitrate value used in calculations comes from commandline and
>> does not reflect reality.
>> The adpcm-bitrate.patch puts correct bitrate in avctx.
>> This fixes wav header, but the ffmpeg program still prints wrong bitrate
>> during encoding.
[...]
>> --- ffmpeg-svn/libavcodec/adpcm.c 2007-10-12 12:21:16.000000000 +0400
>> +++ ffmpeg/libavcodec/adpcm.c 2007-10-12 19:01:53.000000000 +0400
>> @@ -166,6 +166,7 @@
>> /* and we have 4 bytes per channel overhead */
>> avctx->block_align = BLKSIZE;
>> /* seems frame_size isn't taken into account... have to buffer the samples :-( */
>> + avctx->bit_rate = avctx->sample_rate * avctx->block_align * 8 / avctx->frame_size;
>
> tabs are forbidden in ffmpeg svn
> and
> /**
> * the average bitrate
> * - encoding: Set by user; unused for constant quantizer encoding.
> * - decoding: Set by libavcodec. 0 or some bitrate if this info is available in the stream.
> */
> int bit_rate;
>
> that is its set by the user not by libavcodec acording to API
Well. How to fix the header then?
Is it better to put one more nail into avformat/riff.c (see attachment).
And one more for printing correct bitrate.
>> --- ffmpeg-svn/libavcodec/adpcm.c 2007-10-12 12:21:16.000000000 +0400
>> +++ ffmpeg/libavcodec/adpcm.c 2007-10-12 19:01:53.000000000 +0400
>> @@ -448,19 +449,17 @@
>> break;
>> case CODEC_ID_ADPCM_IMA_WAV:
>> n = avctx->frame_size / 8;
>> - c->status[0].prev_sample = (signed short)samples[0]; /* XXX */
>> + c->status[0].prev_sample = *samples++;
>> /* c->status[0].step_index = 0; *//* XXX: not sure how to init the state machine */
>> bytestream_put_le16(&dst, c->status[0].prev_sample);
>> *dst++ = (unsigned char)c->status[0].step_index;
>> *dst++ = 0; /* unknown */
>> - samples++;
>
> this change is purely cosmetic and belongs in a seperate patch
Agree. See adpcm-codec2.patch
>
>
> [...]
>
>> --- ffmpeg-svn/libavcodec/adpcm.c 2007-10-12 12:21:16.000000000 +0400
>> +++ ffmpeg/libavcodec/adpcm.c 2007-10-12 19:01:53.000000000 +0400
>> @@ -483,17 +483,17 @@
>
> looks ok
BTW these changes break regression tests. It is intentional. Should i do
something about?
>
>
>> --- ffmpeg-svn/libavcodec/adpcm.c 2007-10-12 12:21:16.000000000 +0400
>> +++ ffmpeg/libavcodec/adpcm.c 2007-10-12 19:01:53.000000000 +0400
>> @@ -220,6 +220,16 @@ static inline unsigned char adpcm_ima_co
>> return nibble;
>> }
>>
>> +static void inline adpcm_ima_init_step_index(ADPCMChannelStatus *c, short next_sample)
>
> i dont think that this should be inline, or what is the speed gain from that?
>
Right. Look at another try.
Regards.
Tim.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: adpcm-bitrate2.patch
Type: text/x-patch
Size: 545 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071017/b99daf65/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: adpcm-codec2.patch
Type: text/x-patch
Size: 1164 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071017/b99daf65/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: adpcm-bitrate-print.patch
Type: text/x-patch
Size: 736 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071017/b99daf65/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: adpcm-index_step2.patch
Type: text/x-patch
Size: 1717 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071017/b99daf65/attachment-0003.bin>
More information about the ffmpeg-devel
mailing list