On 23.10.24 15:19, Marton Balint wrote:
On Tue, 22 Oct 2024, Anton Khirnov wrote:
Quoting Marton Balint (2024-10-22 20:35:52)
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.
yes -- it's wrapped in an DNxUC specific container like structure.
Some metadata information regarding the content are already available
outside of this sub-container like structure of nested KLV boxes in
common MXF descriptor fields, but others -- like the FOURCC type code of
the actual payload in particular -- are only available after
decoding/parsing this DNxUC specific wrappers.
From a technical point of view, it's not a very complicated task to
parse this structure, but it's definitely something different, than just
demuxing plain MXF containers.
It's also important to remember, that there was always a much more
simple kind of uncompressed video data transport resp. picture essence
embedding facility available in MXF, which is indeed mapped to
AV_CODEC_ID_RAWVIDEO by the MXF demuxer code, but that's something
completely different!
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.
That's indeed a good point!
I'm sure the parser can be improved in many ways significantly.
It's just a very simple skeleton implementation.
The main reason for this weakness is caused by the fact, that I didn't
understand the real structure when I first wrote this code based on
reverse engineering without access to the specification. Now I would
create it differently.
I first implemented parser and decoder together in just one module to
keep the data more closely connected. That's not a completely
implausible design, because there is anyway only one possible way how
DNxUC can be embedded as payload in a surrounding container, but the
separated solution looks also acceptable, although it would definitely
need better support for stacked planes.
At the latest when component composing support will be added, we will
have to rewrite it. But at least right now resp. for the current state
of feature support it should simply do the job.
But thanks for the reminder resp. your well justified criticism.
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.
That's another very important point, because this composable planes are
not just an unnecessary luxury in case of DNxUC, but the only way to
transport image data and alpha channel information in one stream.
In contrast to the more tradition way of video data exchange DNxUC
doesn't define/allow RGBA or any other similar 4-channel pixel formats.
Transparency support is only available via this multi-layer component
stacking mechanism in DNxUC.
If we want to support this kind of more complex organized data in a
user-friendly manner, we will first have to convert it to more simple
ffmpeg compatible pixel formats by this DNxUC specific decoder.
martin
_______________________________________________
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".
