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

[Michael Niedermayer]

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

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

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130812/5f3d2514/attachment.asc>