[FFmpeg-devel] [patch] 6 channelrawaudioinputresultsininvalid PCM packet error

[Baptiste Coudurier]

Michael Niedermayer wrote:
> On Wed, Nov 12, 2008 at 04:30:12PM -0800, Phil Rutschman wrote:
>>> your original logic generates packets that are not a multiple of 512
>> or
>>> 1024 thus not a multiple of disk sectors, this seems not ideal
>> It generates these packets only in cases which currently fail entirely.
>> While this may not be ideal (at least, if there is neither OS nor C
>> library caching going on), it has the virtue of solving the problem at
>> hand without changing current behavior.
>>
>>> in principle updating the regression test checksums would be fine, but
>>> why does g726 change? this looks like there is something wrong in g726
>>> which has to be found and fixed ...
>> It is worth observing that the size of the mov and mkv files change, not
>> just their checksum. When I extract the raw audio data from
>> tests/data/a-pcm_s16be.mov and strip the header, the file matches the
>> original asynth1.sw file except that it is not quite as long. Reducing
>> RAW_PACKET_SIZE increases the size of the resulting mov file, and
>> conversely increasing it results in a smaller mov.
>>
>> Something odd overall is clearly happening related to RAW_PACKET_SIZE,
>> which may or may not be related to the g726 issue, but I don't currently
>> have the time to investigate the specifics of either.
> 
> so the summary is we need some volunteer to fix
> 1. g726
> 2. mov/mkv loosing some samples depending on RAW_PACKET_SIZE
> 
> after that pcm can be fixed and regression checksums updated.
> 

I investigated, problem is that regression tests are run with -t so it
stops the encoding after 1 sec, during this time, and depending on
RAW_PACKET_SIZE a different number of samples is read, therefore
explaining the difference.

The way to fix this is to read a fixed number of samples in raw.c like
you suggested, I will try to cook something.

I don't know about g726, I didn't check.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org