[FFmpeg-cvslog] r25931 - trunk/libavformat/asfdec.c

Michael Niedermayer michaelni
Fri Dec 17 23:54:01 CET 2010


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
[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20101217/fa3fa91b/attachment-0001.pgp>



More information about the ffmpeg-cvslog mailing list