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

[Marton Balint]

On Tue, 22 Oct 2024, Anton Khirnov wrote:

> Quoting Marton Balint (2024-10-22 20:35:52)
>>
>>
>> On Tue, 22 Oct 2024, Anton Khirnov wrote:
>>
>>> Quoting Martin Schitter (2024-10-21 21:57:18)
>>>> +static int pass_through(AVCodecContext *avctx, AVFrame *frame, const AVPacket *avpkt)
>>>> +{
>>>> +    /* there is no need to copy as the data already match
>>>> +     * a known pixel format */
>>>> +
>>>> +    frame->buf[0] = av_buffer_ref(avpkt->buf);
>>>
>>> I said this twice before already - every single format that uses
>>> pass_through() should instead be exported by the demuxer as
>>> AV_CODEC_ID_RAWVIDEO, because that's what it is.
>>
>> 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.

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

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

Regards,
Marton

>
> And also because of the two points I mentioned:
>>> * decoding these formats won't pointlessly waste resources and add
>>>  latency using frame threading, which is useless for them
>>> * your decoder can be marked as AV_CODEC_CAP_DR1
>
> -- 
> Anton Khirnov
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>