[FFmpeg-devel] [patch] 6 channelrawaudioinputresultsininvalid PCM packet error
Thu Apr 2 06:48:17 CEST 2009
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
>>> 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
More information about the ffmpeg-devel