[vlc-devel] [RFC PATCH 0/9] audio decoder fallback: the packetizer way

[Rémi Denis-Courmont]

Le 2016-07-11 18:02, Thomas Guillem a écrit :
> On Sun, Jul 10, 2016, at 15:54, Rémi Denis-Courmont wrote:
>> On lauantaina 9. heinäkuuta 2016 12.20.08 EEST Thomas Guillem wrote:
>> > This is an other proposal to handle audio decoder fallback, the 
>> goal is to
>> > have passthrough decoder that can fallback to PCM decoders and the 
>> other
>> > way.
>>
>> AFAIK, we already have decoder fallback for audio. We don´t have
> Do we ? Where ?
>
>> glitch-free
>> fallback because it´s essentially impossible.
>>
>> And I don´t see why S/PDIF payloaders and PCM decoders could not use 
>> the
>> same
>> packetizer. In fact, I don´t see why they would use different 
>> packetizers
>> at
>
> S/PDIF and PCM can use the same packetizer.
> My main problem is that some demuxers say that the format is 
> packetized
> when it's not really. In that case, there is no packetizer at all. I
> don't really what to do in that case.

I am not buying any of that.

Each codecs has certain semantics on what the ES format parameters mean 
(notably extra data), how the unpacketized and/or packetized blocks are 
sequenced, what the block timestamps and flags mean. This applies to 
demuxers, muxers, decoders, encoders and packetizers. If there is a 
disagreement, it's clearly a bug in one or both plugins.

> The decoder_RequestPacketizer() function doesn't really need the
> packetizer_name argument. This function could just force the usage of
> any packetizer (that matches the format).
> One other solution could be to create an extra packetizer even if the
> format from the demuxer is packetized.

That makes no sense to me.

-- 
Rémi Denis-Courmont
http://www.remlab.net/