[FFmpeg-devel] [PATCH] Fix interlaced MPEG2 decoder crash (issue2367)

[Anatoly Nenashev]

On 24.12.2010 22:04, Anatoly Nenashev wrote:
> On 23.12.2010 23:32, Michael Niedermayer wrote:
>> On Thu, Dec 23, 2010 at 07:41:11PM +0300, Anatoly Nenashev wrote:
>>> On 23.12.2010 18:33, Michael Niedermayer wrote:
>>>> On Thu, Dec 23, 2010 at 11:19:55AM +0300, Anatoly Nenashev wrote:
>>>>
>>>>> On 23.12.2010 03:36, Michael Niedermayer wrote:
>>>>>
>>>>>> On Thu, Dec 23, 2010 at 02:16:21AM +0300, Anatoly Nenashev wrote:
>>>>>>
>>>>>>
>>>>>>> Hi!
>>>>>>> Full problem description available on 
>>>>>>> https://roundup.ffmpeg.org/issue2367.
>>>>>>> After some research I've found that sample file(exploit.bin) 
>>>>>>> conflicts
>>>>>>> with specification in the following lines:
>>>>>>>
>>>>>>>
>>>>>> is anything capable of playing this file?
>>>>>>
>>>>>> or is it a damaged file?
>>>>>>
>>>>>> how has this file been created exactly?
>>>>>>
>>>>>>
>>>>>>
>>>>> Sample file is truncated version of the original file which has been
>>>>> grabbed from Optelecom Siqura C-60.
>>>>> I've left only two first pictures to minimize the problem. Original
>>>>> sample uploaded to
>>>>> ftp://upload.ffmpeg.org/MPlayer/incoming/interlaced_mpeg2/interlaced_mpeg2.bin 
>>>>>
>>>>> It can be successfully decoded by libmpeg2 tools. By the way, 
>>>>> libmpeg2
>>>>> reports errors for exploit.bin and returns no frame but don't crash.
>>>>>
>>>> If something can play this file then the patch is 100% wrong
>>>> if nothing can play this file then the patch is still wrong because 
>>>> you drop
>>>> the previous I field that has been decoded correctly.
>>>>
>>> Yes, first field can be successfully decoded, but second can not. Who
>>> will need this half decoded frame?
>> You are the first person ive seen who asks, who needs part of a 
>> video. Well
>> I guess the user who wants to watch it
>
> Ok. I hope the new version is better.
> I've spent some time to be sure that encoding of second P-field 
> conflicts with specification. And now I'm sure that this is true.
> Each slice in second P-field contains following series of bytes: (32 
> or 0A) 5E 02 02 8B C0. This data can be "translated" that slice 
> contains one MB in the beginning and one in the end which are 
> predicted from the field of the same parity (first collision). Other 
> MB's in the slice are skipped (second collision).
> Last slice also contains additional 4 bytes at the end. I don't know 
> for what they are intended.
>
Sorry, forgot to remove some test lines.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: interlaced_mpeg_v2.patch
Type: text/x-patch
Size: 669 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101224/e1b90654/attachment.bin>