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.
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.
If you feel strongly about this, please refer this to the TC.
Regards,
Gyan
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
