[FFmpeg-devel] [PATCH][RFC] QCP demuxer

Michael Niedermayer michaelni
Sat May 16 03:46:38 CEST 2009


On Fri, May 15, 2009 at 06:43:53PM -0700, Kenan Gillet wrote:
>
> On May 15, 2009, at 6:19 PM, Michael Niedermayer wrote:
>
>> On Fri, May 15, 2009 at 06:01:27PM -0700, Kenan Gillet wrote:
>>>
>>> On May 15, 2009, at 4:56 PM, Michael Niedermayer wrote:
>>>
>>>> On Fri, May 15, 2009 at 03:36:36PM -0700, Kenan Gillet wrote:
>>>>> On Fri, May 15, 2009 at 2:16 PM, Michael Niedermayer <michaelni at gmx.at>
>>>>> wrote:
>>>>>> On Fri, May 15, 2009 at 10:46:12PM +0200, Reimar D?ffinger wrote:
>>>>>>> On Fri, May 15, 2009 at 11:21:21AM -0700, Kenan Gillet wrote:
>>>>>>>> Any other solution i missed?
>>>>>>>
>>>>>>> e.g. 8-entry LUT and & 7
>>>>>>
>>>>>> this does not appear particularly robust in light of a damaged file
>>>>>>
>>>>>> [...]
>>>>>
>>>>> A file with its rate-map-table corrupted but using a fixed rate
>>>>> would still be  playable, as one with a corrupted but unused entry.
>>>>> So being permissive would be nice, plus, some invalid data would
>>>>> be detected later if a corrupted entry is used.
>>>>>
>>>>
>>>>> FIY, I have a sample, a trashed file, with a corrupted rate-map-table,
>>>>> which still played correctly with the solution attached which make it
>>>>> round 3.
>>>>
>>>> the probability of a 8 entry table to be corrupted while the rest of the
>>>> file is not is rather small, that is compared to "implementation error"
>>>> in that sense, are you sure your implementation is correct?
>>>
>>> I check the code against the RFC, and i believe it is correct.
>>> The rate-map-table is only used if the  var-rate-flag is non zero.
>>> If zero, the file then contains packets of fixed length and the table
>>> is not used.
>>>
>>> After further investigation, the trashed file was generating an empty
>>> wav file, so the changes were not making any difference in the output.
>>>
>>>
>>
>>>> and what makes you think it is corrupted?
>>>
>>> I used the trasher tools.
>>
>> good point but then id assume that not just that table is off
>>
>>
>>> BTW, is there any rule of thumb for a good count/maxburst/filesize ratio
>>> when using the trasher tool?
>>>
>>>>
>>>> [...]
>>>>
>>>>> +            int ret, mode = get_byte(pb);
>>>>> +            int pkt_size  = c->fixed_packet_size ? 
>>>>> c->fixed_packet_size
>>>>> - 1
>>>>> +                                                 :
>>>>> c->rates_per_mode[mode];
>>>>
>>>> this still has the same problem of crashing almost instantly
>>>> and being very fragile even if not crashing
>>>
>>> what about:
>>>
>>> int pkt_size, ret, mode = get_byte(pb);
>>>
>>> if (c->fixed_packet_size) {
>>>    pkt_size = c->fixed_packet_size - 1;
>>> } else if (mode <= QCP_MAX_MODE) {
>>>    pkt_size = c->rates_per_mode[mode];
>>> } else
>>>    pkt_size = -1
>>
>> thats the first part, the next is that you should try to recover
>> from bad data instead of failing
>
> would trying to seek to the next packet to see if it starts with a valid 
> byte_mode
> be ok? all rates in the rate-map table could be tried?
>
> any other idea or suggestion on where to look at?

the simplest: retry with the next byte

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090516/f04dbd06/attachment.pgp>



More information about the ffmpeg-devel mailing list