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

[Reimar Döffinger]

On 29 May 2011, at 15:49, Stefano Sabatini <stefano.sabatini-lala at poste.it> wrote:
> 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.

I thought it obvious that pausing should stop audio and video output, to my knowledge that's what basically ever player does.

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

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