On 4/3/2018 5:26 PM, wm4 wrote: > 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.
It doesn't make sense as per-packet side-data. > 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. I got what you mean. I still don't have an opinion one way or another. It's a trade-off between Yet Another AVStream Field vs a more complex API and implementation as side data. I may be slightly erring towards an AVStream field. I would be interested to hear others' opinions on this if they have a stronger one. - Derek _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
