[vlc-devel] [RFC PATCH 0/9] audio decoder fallback: the packetizer way
remi at remlab.net
Tue Jul 12 12:09:41 CEST 2016
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
>> > way.
>> AFAIK, we already have decoder fallback for audio. We don´t have
> Do we ? Where ?
>> fallback because it´s essentially impossible.
>> And I don´t see why S/PDIF payloaders and PCM decoders could not use
>> packetizer. In fact, I don´t see why they would use different
> S/PDIF and PCM can use the same packetizer.
> My main problem is that some demuxers say that the format is
> 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.
More information about the vlc-devel