On 6/13/2025 3:34 PM, Tomas Härdin wrote: > Interesting. I didn't think to use side data for it. Putting the edit > lists in AVStream seems wrong. They belong to AVFormatContext. Else we > can't support ganged or alternate packages in MXF (OP1b, OP1c, OP2b, > OP2c, OP3b, OP3c), nor could we support IMF. Yes, I know imfdec.c > exists. It too is cursed.
I don't know what any of that means, but I definitely wasn't aware of any MXF stuff back then, so probably didn't design for it. > Here's what I came up with so far for reference. The idea is to just > stick a pointer to AVEditLists in AVFormatContext. This was written > before I saw the ABI point and the indirection solution to it. My main concern here is that it is extremely complex from API perspective, and approximately zero users will end up using it correctly (or at all), outside of ffmpeg.c. (From what I can tell this complexity solely comes from IMF/MXF.) Probably part of such an RFC needs to contain how it is intended to be used (integration with existing APIs, functions, etc.). If it is just these structs, it's essentially unusably complex as far as I am concerned. (This was an issue with my old RFC too, but this is even more complex, and hindsight is 20/20). Some amount of "just works", or a higher level API needs to exist, I think. - Derek _______________________________________________ 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".
