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

Michael Niedermayer michaelni
Thu Dec 16 01:00:29 CET 2010

On Wed, Dec 15, 2010 at 09:05:27PM +0100, Reimar D?ffinger wrote:
> On Wed, Dec 15, 2010 at 02:46:34PM +0100, Michael Niedermayer wrote:
> > > > > > Did somebody change his mind ?
> > > > > 
> > > > > No. It's just that in this specific case it is a pain to do because the
> > > > > demuxer needs to juggle the data around and that's not something you
> > > > > can do if you have only half of it.
> > > > > And I am too lazy to think about if and when you could still do
> > > > > something reasonable.
> > > > 
> > > > then the end of the packet can be filled with zeros.
> > > > we seem to be loosing significant portions of valid audio with this and i
> > > > dont think this is good
> > > 
> > > I really don't like making up data, also the amount of audio lost is not
> > > sufficient to actually hear the difference (well, for me).
> > > Though I admit I really wouldn't mind a nicer solution, especially since
> > > I think the descrambling code in some cases is a NOP.
> > 
> > if the descrambling is not a NOP random bytes in the middle of a packet are lost
> > some audio codecs are designed to handle this, its annoying if the packet is
> > droped IMHO
> And I think it is annoying if we return bogus data without the slightest hint,
> which AFAICT is the only alternative.
> > > Problem is just it takes extra time to come up with a solution I'd consider
> > > good and I don't have that much time I'd like to spend on this...
> > 
> > thats ok but i think then you should leave the code as it was if you lack time
> > and not commit a hack
> Sorry, but I consider that idiotic. You seriously consider it better to leave 
> code around that returns unintialized data, gives no hint about the file being
> broken and all with a fate test that depends on that unintialized data and thus
> only work by pure chance than a "hack" where the only fault is that it is not optimal
> because it drops a packet where the alternatives are only slightly better anyway?

Thats a hell of a long sentance
First of course returning uninitialized data is unacceptable
But its also unacceptable to drop perfectly valid frames because one or more
frames have been damaged or lost. Even if there are no means to indicate this
you cant drop the valid ones.

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

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- 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/20101216/bc404b4f/attachment.pgp>

More information about the ffmpeg-cvslog mailing list