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

[Michael Niedermayer]

On Fri, Dec 24, 2010 at 10:04:31PM +0300, 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.

Its just adding hacks at random places that will break and slow down things,
if by sheer luck this makes this file play is something i cant say without
testing.
Its certainly unfit for trunk


> 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).

What does the official binary decoder output for the first frame?
You cannot fix this without knowing what is correct _first_.
One could guess from looking at the output what is likely correct if this
field is used by future P fields but its better to know the correct output
first.


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101225/e9dcc8aa/attachment.pgp>