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

[Anatoly Nenashev]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: interlaced_mpeg_v2.patch
Type: text/x-patch
Size: 1363 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101224/193e5034/attachment.bin>