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

martin schitter ms+git at mur.at
Wed Nov 20 05:24:09 EET 2024



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.

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.

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

Martin


More information about the ffmpeg-devel mailing list