On Sat, Jan 10, 2015 at 01:21:42PM -0500, Ronald S. Bultje wrote: > Hi, > > On Sat, Jan 10, 2015 at 12:15 PM, wm4 <nfx...@googlemail.com> wrote: > > > On Sat, 10 Jan 2015 18:03:48 +0100 > > Hendrik Leppkes <h.lepp...@gmail.com> wrote: > > > > > On Sat, Jan 10, 2015 at 6:00 PM, wm4 <nfx...@googlemail.com> wrote: > > > > > > > With a certain fuzzed file, the parser will always return 0 consumed > > > > bytes, which makes calling code call the parser infinitely. Return the > > > > full packet size on error instead. (Here it would be nice if parsers > > > > could return errors at all.) > > > > > > > > Additionally, _if_ there's some data left, return that too, which might > > > > help with somewhat broken but still somehow playable files. > > > > > > > > Fixes ticket #4242. > > > > --- > > > > There might be a more elegant way to fix this. > > > > Also, not sure if the change *out_size has any worth. > > > > > > > > > > Signaling the out_size would mean it should forward the data to the > > > decoder, if it remains 0 the data is just swallowed. What would make more > > > sense in this case? > > > > I'd argue that it's normal for ffmpeg to play something even if the > > data has been pushed through a blender, so if there's a trivial choice > > between swallowing and returning the data, the latter should be picked. > > But actually, it probably doesn't matter. > > > I think I agree, although it's hard to say it makes any difference at this > point. So patch is probably fine.
patch applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel