[FFmpeg-devel] [patch] 6 channelrawaudioinputresultsininvalid PCM packet error
Fri Nov 14 23:28:50 CET 2008
Michael Niedermayer wrote:
> On Fri, Nov 14, 2008 at 10:52:37AM -0800, Baptiste Coudurier wrote:
>> 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
>> Huh ? If there is a problem with mov I'll fix it right now.
> I dont know if there is, i just added mov because phil said:
> "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."
> ive not confirmed this or investigated at all ...
What about this patch ? Regression tests pass.
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1220 bytes
Desc: not available
More information about the ffmpeg-devel