[FFmpeg-devel] [Ffmpeg-devel] [PATCH] nutdec: fix infinite loop when resyncing

[Michael Niedermayer]

Hi

On Thu, Mar 01, 2007 at 07:12:53PM +0200, Oded Shimon wrote:
> On Wed, Feb 28, 2007 at 10:06:12AM +0100, Michael Niedermayer wrote:
> > Hi
> > 
> > On Wed, Feb 28, 2007 at 09:22:16AM +0100, Clemens Ladisch wrote:
> > > Michael Niedermayer wrote:
> > > > On Tue, Feb 27, 2007 at 06:13:40PM +0100, Clemens Ladisch wrote:
> > > > > When nut_read_packet() tries to resync after an error, it restarts
> > > > > decoding at the next startcode after the last syncpoint.  When there was
> > > > > another packet between that syncpoint and the error position, the error
> > > > > position will eventually be reached again and nut_read_packet() will
> > > > > loop forever.
> > > > > 
> > > > > This can be fixed by syncing only to syncpoints.
> > > > 
> > > > or starting from the last startcode, which may loose less before the 
> > > > next syncpoint starcode
> > > 
> > > This wouldn't make any difference; there must be a syncpoint after other
> > > headers.
> > 
> > unless its damaged though i guess this is a little unlikely, so well
> > i am ok with the patch

i retract my approval, this patch is just not correct (and luckily it hasnt
been applied over the past months ...)


> 
> In that case it wouldn't matter anyway, you would stop right after the 
> headers and look for a syncpoint again (in fact, better off you don't 
> attempt demuxing the obviously invalid data...)

iam not sure what you are talking about but if you have several packets
lets say info packets, index packets or a some future extensions, that is

Sync0 Frame0 ERROR Frame1 Info0 Info1 Sync1

then with the patch you will loose these completely undamaged packets,
while currently they are parsed with no issues

you can argue that such packets are not very important but its certainly
not correct nor ideal behavior, resync should happen on the next packet
and search should start from the previous packet (currently syncpoint)

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071104/d5c4691d/attachment.pgp>