[FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding

[Andreas Rheinhardt]

Gyan Doshi:
> 
> 
> On 2024-02-15 04:17 pm, Anton Khirnov wrote:
>> Hi,
>> sorry for the delay, I've been busy fixing things for the release
>> Quoting Gyan Doshi via ffmpeg-devel (2024-01-29 05:00:33)
>>> On 2024-01-28 04:24 pm, Anton Khirnov wrote:
>>>>> a) it would mean essentially inlining this decoder in the demuxer.
>>>> Why is that a problem? This decoder seems like it shouldn't be a
>>>> decoder.
>>>>
>>>> I agree with Andreas that this seems like it's a demuxer pretending to
>>>> be a decoder.
>>> This module transforms the entire raw payload data to generate its
>>> output, even if the syntax is simple which
>>> essentially makes it a de-coder. The de-multiplexer aspect of multiple
>>> streams is an academic possibility allowed
>>> by the standard but not seen in any sample which makes me suspect it's
>>> used for carriage between broadcast
>>> facilities rather than something ever sent to an OTT provider, let alone
>>> an end user.
>> If it dynamically generates nested decoders, then it's not a proper
>> codec in our model. It should be either a part of the demuxer, or a
>> bitstream filter (possibly inserted automatically by the demuxer).
> 
> s302m is a hybrid creature and does not slot cleanly into any role. So
> there is no theoretically proper place for this component - any choice
> is a least-out-of-place accommodation.
> 
> But it is much more out of place inside a demuxer. Analyzing packet
> payload and then manipulating that entire payload is much closer to a
> decoding role than data chunk extraction for packetization. And the
> stream extracted from the container is meant to be SMPTE ST 302 not PCM*
> or Dolby-E/AC-3..etc, which will both misrepresent what the container
> carries
> and possibly discard S-ADM metadata, if present, in the packet. With
> passthrough demuxing, a stream can be mapped for both decoding and
> streamcopying.

This is not true: It can not be streamcopied into formats expecting
ordinary PCM or Dolby-e/AC-3. Which is why exporting the data without
the unnecessary packetization is preferable.

> 
> A bsf in principle would work but in practice, can't as Andreas
> clarified that bsfs can't set or alter codec_id after init. And
> resetting the codec id requires packet inspection.
> 
> Nested decoders are used without issue in components like imm5 or ftr
> (upto 64 nested decoders!) among others. There's no breaking of new
> ground here.
>