Quoting James Almer (2024-03-05 16:07:05) > > > > One possible solution is to rename the option to something like > > side_data_prefer_external (better names welcome), and have it switch > > between user-supplied (i.e. global or per-packet) and in-bitstream side > > data. > > > > This adds an ambiguity for the hypothetical case where some side data > > exists as global and per-packet - then I'd say lavc should default to > > per-packet and leave the other case to the caller (should be very rare, > > possibly could be handled with a bitstream filter). > > If a given side data type at the container level were to be duplicated > in the header (global) and per packet, then IMO the packet must have > priority, given it's the container overriding its own parameters.
I'd be careful with 'must' - in a sane world that's what would be reasonable, but I can definitely imagine a situation where you'd want the reverse. But I do agree that it's not something lavc needs to handle. -- Anton Khirnov _______________________________________________ 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".
