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

[Reimar Döffinger]

On Tue, May 31, 2011 at 10:04:11AM +0200, Stefano Sabatini wrote:
> On date Sunday 2011-05-29 20:48:40 +0200, Reimar Döffinger encoded:
> > Well, IMO it's also the typical dead-end option: whether you want to
> > do lossless remuxing, build an application that can do fast seeking
> > in a file with compressed audio etc. I'd guess you'd start with
> > reverting this.
> 
> Lossless remuxing and fast seeking is still possible with this patch,
> the only main inconvenient is that you need to cache and decode the
> data in the muxer, considering that decoding is pretty cheap in this
> case I don't consider a big inconvenient.

You also need to figure out which encoding scheme was used and use
an encoder that is not too stupid to find the same encoding (admittedly
the latter seems easy in that case, the former is however no longer
exported by what I can tell).

> > Now I doubt anyone will ever do that so I'm not going to drag this
> > out endlessly, but to me it doesn't seem like a real improvement.
> > Making the demuxer interleave the (possibly compressed) channel data
> > would be something different, it would solve the issue of huge
> > packets if the file is huge and "fix" the pause issue, but is more
> > complex and won't really allow seeking with ffplay's implementation
> > of it.
> 
> I considered this approach and I really couldn't see much benefits in
> it. Indeed the peculiarities of the SVX8 compression methods are:
> 
> 1) you need the first byte for decoding the whole file, decoding is
>    meant to be sequential so you always need to decode *all* the
>    previous data

With the decoder split out, an application can build and store a custom
seek-table that contains the first byte.
It then only needs to prepend that.
Also since it is delta-compression _with_ clipping you might well get
away with just taking 0 as starting value without distorting the sound
much (or better, choose one that minimizes the amount of clipping when
decoding that packet).

> 2) left and right channel are globally interleaved, so you need to
>    read all the left channel data before you can read the right
>    channel data.

If seeking is possible, no. You can interleave the compressed data
(on whichever level desired).
In principle it would also be possible to only support mono in the
codec and export right and left as separate streams, however
while giving clean code that is very user-unfriendly.