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

[Reimar Döffinger]

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

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

Only up to the packet level.

> > 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.
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?
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.