[FFmpeg-devel] [PATCH] iff/8svx: move decoding/deinterleaving in demuxer

[Stefano Sabatini]

On date Sunday 2011-05-29 12:20:56 +0200, Reimar Döffinger encoded:
> On Sun, May 29, 2011 at 11:25:20AM +0200, Stefano Sabatini wrote:
> > On date Sunday 2011-05-29 10:54:29 +0200, Reimar Döffinger encoded:
> > > 
> > > 
> > > On 28 May 2011, at 13:42, Stefano Sabatini <stefano.sabatini-lala at poste.it> wrote:
> > > 
> > > > This is required for making possible to return audio data in packets
> > > > rather than return a huge packet with all the chunk data, which is
> > > > problematic for applications.
> > > > 
> > > > In particular ffplay cannot pause in the middle of a packet.
> > > 
> > 
> > > Have you tested with other applications? ffplay just has a stupid
> > > implementation, IMO that is not at all a good reason to move stuff
> > > that does not belong there into libavformat.

How would you suggest to implement it in ffplay?

Currently ffmpeg has a read_thread which fetch packets from demuxers
and send them to A/V/S queues, when they're processed by separate
decoding threads.

Pausing operations affects the read_thread, while the other threads go
on, so if there is a huge packet the audio decoding thread keep on
decoding it until it's finished. In this scenario pausing can't work.

> > 
> > But... sending a huge packet is not a good idea in principle,
> > applications expect the data to be split in little packets.
> 
> Huh? I don't really think so. FLAC with silence has a similar problem,
> applications that expect that are broken anyway, this might just be
> the most obvious case.

For huge packet I mean a packet which contains all the file data.

> > Also the huge packet idea is preventing seeking into the file, which
> > is a duty of the demuxer.
> 
> Only up to the packet level.

Do we implement frames-level seeking?

> > > Also, would remuxing still work properly after that change (assuming
> > > we had a muxer for the format)?
> > 
> > We don't have an IFF muxer, it may be trivially implemented adopting
> > the same logic (you cache all the incoming packets, and compress and
> > de-interleave them when closing the file).
> 

> A bit messy with having to chose the compression.

That may be a muxer option.

> Also, would you call e.g. the trellis code from libavcodec from libavformat?
> And the option for setting trellis, that would then be yet another
> format-specific option?

Do we need to implement trellis in the iff muxer? I'm not saying that
moving decoding in the demuxer is always a good idea, for this
particular format it's the simplest option (less code, less bugs).

> After reading about the format I don't think there should be much of an
> issue splitting the packets to some arbitrary size.

> However there's still the issue that for compressed audio there is only
> a single "keyframe", so seeking on a demuxer level just isn't possible.

Indeed.
-- 
FFmpeg = Formidable and Fierce Murdering Pure Elfic Gospel