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

[Marton Balint]

On Wed, 20 Nov 2024, martin schitter wrote:

>
>
> On 19.11.24 22:47, Marton Balint wrote:
>>  The current parser does things which a parser should not, like skipping
>>  parts
>>  of the packet header, but it does not actually able to packetize a raw
>>  DNXUC
>>  bitstream.
>
> You're right! I simply can't reject this judgment about the obvious flaws of 
> the current implementation.
>
> Although I see significant improvements in your rewrite attempt, I'm still 
> unsure, if it really solves the main issue.
>
> Your design makes a lot of sense, if someone wants to copy the DNxUC video 
> stream without any additional de-/encoding by just passing through this kind 
> of unprocessed 'pack'-box data. That's a very efficient kind of handling for 
> some cases.
>
> But I'm still not completely satisfied by this solution, because I'm 
> skeptical, that it builds a suitable solution for multi-component cases (RGB 
> + alpha or multiple FX/rendering layers) as well. And that's IMHO the much 
> more puzzling open problem.

The layering issue is for the decoder to take care of, not the parser. 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.

This patch fixing the parser should not be contriversal, because it only 
changes how the parser behaves, there is no argument about that as far as 
I know.

>
> This kind of layered content should be perhaps split immediately within the 
> MXF demuxer and generate multiple video streams very early. But unfortunately 
> this doesn't quite fit into the current MFX demuxer design. Otherwise, we 
> will have to divide the video stream at a later stage, where such changes are 
> usually not expected anymore.
>
> How do you think about this difficulty?
>
> I personally still don't have any convincing solution for this quest.

Some cases the decoder can support, maybe some cases it can't. Let's focus 
on the ones which it can. E.g. planar formats can be used for multiple 
icmp boxes.

>
>>  Rework the parser logic to work similar to other parsers and be able to
>>  correctly packetize raw DNXUC bitstreams.
>
> In principle, I appreciate your rewrite. It's definitely an improvement, and 
> it's perfectly acceptable to shift all further packet processing into the 
> decoder module.
>
> 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.

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).

Regards,
Marton