[FFmpeg-devel] [PATCH] Avoid reading beyond end of stream in resync function.

[Reimar Döffinger]

On 12.08.2013, at 23:06, Michael Niedermayer <michaelni at gmx.at> wrote:

> On Mon, Aug 12, 2013 at 09:27:20PM +0200, Reimar Döffinger wrote:
>> On Mon, Aug 12, 2013 at 09:05:01PM +0200, Michael Niedermayer wrote:
>>> On Mon, Aug 12, 2013 at 07:40:32PM +0200, Reimar Döffinger wrote:
>>>> This ends up printing a nonsense warning about
>>>> "marker does not match f_code".
>>>> This happens particularly frequently with VDPAU hwaccel
>>>> since there we fast-forward the stream directly to the end.
>>>> (Note: possibly it is incorrect for us to skip all the way to
>>>> the end for VDPAU, possibly someone should investigate that,
>>>> I am a bit lost in that regard).
>>> 
>>> its a bit guesswork but
>>> decode_slice() should maybe update s->mb_y in the hwaccel case
>>> 
>>> (if no better idea exists setting it to mb_height when the bitstream
>>> end is reached could be tried)
>>> 
>>> when mb_y is updated then ff_h263_resync() wont be run unless its
>>> needed
>>> 
>>> the patch could interfere with error concealment beause even if we
>>> are over the end we could have read over a resync marker and there
>>> still might be an intact slice start previously that wasnt decoded
>> 
>> My understanding is that shouldn't be possible.
>> If there is a resync marker, ff_h263_find_resync_marker should have
>> found it and we would only have fast-forwarded to it, not the end
>> of the frame.
> 
> lets assume there is a single resync marker
> we decode the first slice that starts before the resync marker
> and once we are done with it we find ourselfs at the end of the
> bitstream but without a complete image
> with your patch we end here
> before your patch we search for the resync marker and find it and
> then decode the second slice
> this problem has nothing to do with hwaccel,
> ff_h263_find_resync_marker() is not called outside hwaccel

Ah, I missed that the function "seeks back".
It wasn't my intention to break it like that, only to avoid any of the checks being done on the buffer padding.
I'll have to check if a proper version still fixes the issue.