[FFmpeg-devel] [PATCH v12 5/9] libavcodec/dnxucdec: DNxUncompressed decoder

[martin schitter]

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