On Tue, 3 Apr 2018 17:06:03 +0100 Derek Buitenhuis <derek.buitenh...@gmail.com> wrote:
> On 4/3/2018 4:15 AM, wm4 wrote: > > So I think all what you've been writing can be reduced to: should this > > really be side data, or would it be better to just make it a new > > AVStream field. > > I don't really have an opinion on this one way or another. > > Do others? Uh no idea. One angle: The idea with AVStream side data is that it can be attached as AVPacket side data. So if an API user is fine with treating all kinds of side data per AVPacket, it can call av_format_inject_global_side_data() and ignore AVStream side data. Basically, you could ask the question whether this kind of side data makes sense as per-AVPacket, and if not, then it should be AVStream side data. Maybe. Another angle is that the API better because side data would not add yet another AVStream field. It makes the API more discoverable: the API user can easily detect an unsupported side data type and handle it as soon as he has a sample, instead of having to go over every AVStream field during the initial implementation, and wondering what the hell it does (and things going wrong when not handling explicitly). I probably didn't word that too well, but I hope you get what I mean. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
