[FFmpeg-cvslog] r25931 - trunk/libavformat/asfdec.c
Sat Dec 18 14:20:41 CET 2010
On Fri, Dec 17, 2010 at 11:54:01PM +0100, Michael Niedermayer wrote:
> On Thu, Dec 16, 2010 at 08:21:25AM +0100, Reimar D?ffinger wrote:
> > On Thu, Dec 16, 2010 at 01:00:29AM +0100, Michael Niedermayer wrote:
> > > The way the scrambling works IIRC (at least in some audio codecs) is that you
> > > have several small more or less independantly decodeable subpackets these
> > > are then scrambled around so that a burst error or loss of several in series
> > > is spread over time and easier to conceal.
> > > it really makes no sense to drop the whole packet if some subpackets are lost
> > > IMHO
> > To be honest I only considered the case of EOF, do we actually have any
> > other case where a read does not finish but we can still continue?
> > I don't think so, and I think we would end up getting out of sync.
> > Anyway what happens in an error case already with the current code
> > is that an error will be returned and then it will try to read/fill
> > the same fragment again I think (not really sure I admit).
> > As said this might/is likely to mean things get out of sync, but
> > so might filling with 0, as long as we have no real-world protocol
> > that we can test this against I'd consider that unimplementable.
> > Anyway, fixed a bug in the last patch (setting
> > ret = asf->packet_frag_size for the scrambling case), but that
> > changes nothing for WMA and I am not at all sure if it makes
> > things better or worse really.
> > If get_buffer fills half a fragment should we 0-fill the rest of
> > the fragment or try to read the rest at a later point (and doing
> > the "fill-up" only at EOF)?
> > Index: asfdec.c
> > ===================================================================
> > --- asfdec.c (revision 25943)
> > +++ asfdec.c (working copy)
> lgtm if it doesnt break anything
Not as far as I could tell, make fate passes (though one wmv test returns
an additional frame - though it looks quite bad, error concealment for
incomplete frames seems bad with WMV at least).
More information about the ffmpeg-cvslog