On Fri, 22 Nov 2024, martin schitter wrote:
On 20.11.24 22:03, Marton Balint wrote:
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.
As long as we only support single component variants there isn't much use of
saving the unmodified `pack` structure, because nearly all contained metadata
is more or less redundant and also available one layer above in the MXF CDCI
and RGBA Picture Essence Descriptors.
That's why I just passed along the `sinf`.packet_type and `sdat` frame
content as the only useful information relevant for further processing.
That's also enough information to recreate a functional equivalent DNxUC
`pack` structure later again, if needed.
Nevertheless, I do not have any serious objections against your proposal. It
simply makes sense for more efficient pass-through.
Actually if you change where the packet starts in the parser, the generic
demuxing code will likely do a memcpy on the packet data... So the most
efficient is to not change that... You also have to think not just the
decoding use case, but re-muxing as well, so the codec having a
well-defined packet format which works for all cases is important.
I will apply this in 1-2 days then.
Thanks,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
