On Tue, 22 Oct 2024, Anton Khirnov wrote:
Quoting Marton Balint (2024-10-22 20:35:52)
On Tue, 22 Oct 2024, Anton Khirnov wrote:
Quoting Martin Schitter (2024-10-21 21:57:18)
+static int pass_through(AVCodecContext *avctx, AVFrame *frame, const AVPacket
*avpkt)
+{
+ /* there is no need to copy as the data already match
+ * a known pixel format */
+
+ frame->buf[0] = av_buffer_ref(avpkt->buf);
I said this twice before already - every single format that uses
pass_through() should instead be exported by the demuxer as
AV_CODEC_ID_RAWVIDEO, because that's what it is.
I don't really want the MXF demuxer/muxer to do DNXUC parsing
What parsing is there to do? You just compare against the codec tag.
As far as I know, the codec tag is embedded somewhere inside the various
boxes of DNXUC (pack box, optional icmp box, optional fill box, sinf box).
So I don't quite see how can you easily get that (or find where the signal
data actually starts) without parsing the box sequence.
Also I might want to wrap DNXUC essence to another container, or remux
it to MXF again.
And where is the problem here?
If demuxing destroys the original DNXUC essence with its box structure,
then you will need something on the muxing side that re-creates this. If a
DNXUC packet contained the whole 'pack' box, this would not be needed.
This is also why I don't quite like that the dnxuc_parser right now skips
some header bytes and points the packet buffer to the signal data. IMHO
the DNXUC packet should really be the 'pack' box itself, and the decoder
should parse that.
So I am not convinced that the current approach is bad.
It is bad because it introduces a completely pointless and arbitrary
distinction between "rawvideo" and "rawvideo, but EXTRACTED FROM MXF".
DNXUC is not only raw data, but the whole box structure with raw or
compressed data inside. The format even allows to store the planes
separately.
Regards,
Marton
And also because of the two points I mentioned:
* decoding these formats won't pointlessly waste resources and add
latency using frame threading, which is useless for them
* your decoder can be marked as AV_CODEC_CAP_DR1
--
Anton Khirnov
_______________________________________________
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".
_______________________________________________
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".
