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

Marton Balint cus at passwd.hu
Tue Oct 22 21:35:52 EEST 2024


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 or creation. 
Also I might want to wrap DNXUC essence to another container, or remux 
it to MXF again. So I am not convinced that the current approach is bad.

Regards,
Marton

>
> That will also have the following important advantages:
> * 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
>
>
>> +static int unpack_y212(AVCodecContext *avctx, AVFrame *frame, const AVPacket *pkt)
>> +{
>> +    uint8_t *data = &pkt->data[0];
>> +    int lw = frame->width;
>> +    int msb_bytes = lw * 2;
>> +    int line_offset = lw * 3;
>> +    int pos_uv = 0, pos_y = 0, pos_in = 0;
>> +    for(int y = 0; y < frame->height; y++){
>> +        for(int x = 0; x < lw/2; x++){
>> +            AV_WL16(&frame->data[1][pos_uv],   get12(data, pos_in++, msb_bytes)); // u
>> +            AV_WL16(&frame->data[0][pos_y],    get12(data, pos_in++, msb_bytes)); // y
>> +            AV_WL16(&frame->data[2][pos_uv],   get12(data, pos_in++, msb_bytes)); // v
>> +            AV_WL16(&frame->data[0][pos_y + 2],get12(data, pos_in++, msb_bytes)); // y
>> +            pos_uv += 2;
>> +            pos_y += 4;
>> +        }
>> +        data += line_offset;
>> +        pos_in = 0;
>> +    }
>> +    return pkt->size;
>> +}
>
> These functions are now MUCH more readable, and it becomes clear that
> you're not accessing frame->linesize, which is immensely suspicious.
> Lines of a frame do not need to be contiguous in memory, there can be
> arbitrary amounts of paddding between them.
>
> -- 
> 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".
>


More information about the ffmpeg-devel mailing list