[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