[FFmpeg-cvslog] r14692 - in trunk: libavcodec/pcm.c tests/regression.sh

[Ramiro Polla]

pross at xvid.org wrote:
> On Tue, Aug 12, 2008 at 09:58:32AM -0300, Ramiro Polla wrote:
>> Ramiro Polla wrote:
>>> Hi,
>>>
>>>> the number of decoded U8 samples is
>>>> calculated using some lazy logic (number of short ints / 2). 
>>>>
>>>> See patch.
>>> Thanks. I saw this problem when implementing 24-bit support for the MLP 
>>> encoder.
>> Oh, this change only dealt with 8-bit samples. I hadn't seen that (I 
>> haven't actually tested it =). But I think the same problem arises with 
>> higher bitrates.
>> Trying ./ffmpeg_g -i input.wav -sample_fmt s32 output.mlp
>> (assuming mlp accepts SAMPLE_FMT_S32) only gives half the samples. So if 
>> avctx->frame_size is 40, I only get 20 samples...
> 
> This looks to be a "1sample = 2bytes" legacy assumption within ffmpeg.
> Try the enclosed patch.

I had to change another 2 to av_get_bits_per_sample_format()/8. I 
attached the 2 patches I had to apply to get 24-bit working on MLP. This 
way it works with:
./ffmpeg_g -i file16bit.wav -sample_fmt s24 file24bit.mlp

But with this I also had to read the 24-bit samples with (int32_t) 
((bytestream_get_le24() >> 8) << 8). I guess what Michael wants is to be 
able to use (int32_t) bytestream_get_le32() directly. I'll leave the mlp 
code with bytestream_get_le32() for now...

Ramiro Polla
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s24_1.diff
Type: text/x-diff
Size: 932 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20080812/2b37b2a7/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s24_2.diff
Type: text/x-diff
Size: 1052 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20080812/2b37b2a7/attachment-0001.diff>