[FFmpeg-devel] [PATCH 2/2] avcodec/dnxuc_parser: rework DNXUC parser

[martin schitter]

On 20.11.24 22:03, Marton Balint wrote:
> The layering issue is for the decoder to take care of, not the parser.

Yes, we could handle it in the decoder just like in case of OpenEXR, 
where we use a special `-layer`  option to specify the component/layer 
to pick out of the input stream.

But I still would prefer a solution, which enables the use of common 
ffmpeg stream selectors to choose/mix/rearrange the available components 
more easily without this kind of format specific workaround.

> The parser's primary job is to packetize a non-packetized stream and 
> maybe get some basic information about the packets which normally the 
> container has.

As long as we only support single component variants there isn't much 
use of saving the unmodified `pack` structure, because nearly all 
contained metadata is more or less redundant and also available one 
layer above in the MXF CDCI and RGBA Picture Essence Descriptors.

That's why I just passed along the `sinf`.packet_type and `sdat` frame 
content as the only useful information relevant for further processing. 
That's also enough information to recreate a functional equivalent DNxUC 
`pack` structure later again, if needed.

Nevertheless, I do not have any serious objections against your 
proposal. It simply makes sense for more efficient pass-through.

I just see the desirable handling of multiple components slightly 
different. The DNxUC pack looks for me more like an embedded container 
which again may contain multiple component streams/tracks nested within 
a more general MXF container structure. From this point of view the 
contained component streams/tracks should be extracted/demuxed earlier.

>> Honestly I'm rather surprised, that someone still wants to improve 
>> this DNxUC related code, because I'm personally more in the mood to 
>> ask for reverting the already merged parts. I simply don't want to 
>> waste my time on useless fights...
> 
> I get it, reaching a consensus is not always possible and the debate can 
> be demoralizing. But that is how it is, if you want to contribute to 
> open source, you have to accept that. Some patches may get rejected 
> today, maybe they will get accepted in a year with no fuss. It happens.

You are right!

Nevertheless, I really have to say, I have hardly seen an open source 
project recently, where contribution is so much time-consuming, slow and 
clumsy...

> Regarding DNXUC and the MXF demuxer the main question is not even about 
> the DNXUC decoder, but the MXF demuxer, if it should output RAWVIDEO 
> codec (where possible) or always DNXUC codec. Deciding on this should 
> not delay the inclusion of the DNXUC decoder the way I see it. And in my 
> opinion the DNXUC decoder should support everything the format supports 
> regardless of what the MXF demuxer does. (A library user might use his 
> own demuxer and only the DNXUC decoder from ffmpeg).

On one hand I share the view of those collegians, which argue, that data 
picked from the `sdat` box is nothing else than RAWVIDEO, because it is 
indeed nothing fancy, not compressed, etc. But on the other hand it 
simply needs format specific further processing (e.g. 10/12bit 
unpacking) in most cases and I'm also especially interested in lossless 
and efficient float handling on the GPU, not the simple traditional bit 
depths. Unmodified float data usage and GPU focused data exchange simply 
isn't supported satisfyingly by the current RAWVIDEO handling in ffmpeg.

That's why I try to avoid this RAWVIDEO processing path.

DNxUC isn't a format, which you'll choose as a super inefficient storage 
solution for consumer content or to play directly on screen, but it's a 
useful kind of exchange standard in professional production workflows. 
One of the few options to transfer data between various different 
high-end tools in a lossless and GPU processing friendly manner.

It could enable the utilization of ffmpeg instead of Nuke or similar 
software for batch processing in some cases, where the current float 
handling resp. processing precision and conversion loss of most open 
source solutions is still a strict no-go.

Martin