On 7/21/2017 12:55 AM, Rostislav Pehlivanov wrote: >> All this could apply to a dedicated field. Using side data only brings a >> type pruning of the actual type. Except: >> >> > Yes, it could. However I still think having it as a side data is better > since its the easiest way and that's what all API users currently use to > retrieve HDR metadata as well.
+1 on exposing it as side data; it's consistent with previous APIs and doesn't require Yet Another Field for something only a few formats (PNG, JPG, TIFF, MP4) can contain. >> This is not what I am asking. Look at the doxy for >> AV_FRAME_DATA_SPHERICAL. Explaining the semantic of the structure >> requires at least a few pages of documentation, but the doxy still >> explains in a few world the data structure used. >> >> What I am asking is very simple: if I want to exploit this side through >> a library, to what type shall I cast the pointer? >> >> > Nothing, its a bitstream. You give it to a library to decode and the > library is then ready to take e.g. rgb and output color corrected rgb. FWIW, literally every other library exposes ICC data the same way (as a dumb buffer), and it's IMO the most reasonable. It's not reasonable to put an actual description of ICC data in the doxy (see: 300 page spec... it is complictated). Just a reference to the spec is fine. I say this as a downstream user of various libraries having had to use ICC profiles (always with lcms2, of course). - Derek _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
