Le tridi 3 thermidor, an CCXXV, Rostislav Pehlivanov a écrit : > It can be quite big. In some insane cases it can be bigger than the actual > packet or even the uncompressed frame. Its also not strictly necessary to > display something more or less looking okay, but its necessary to display > something correctly. I think its better treated like we currently treat HDR > by defining a side data type and letting the API users cache and use it, > which is what this patch does.
All this could apply to a dedicated field. Using side data only brings a type pruning of the actual type. Except: > Side data is also refcounted so it even > solves the size issue. Indeed. A separate type could be refcounted too, though, but that would require a little more code. Short-term convenience vs. long-term convenience. > > > + * The data contains an ICC profile with an optional name defined > > in the > > > + * metadata entry. > > Not being a specialist of ICC profiles, I have no idea what that means > > in practice. What data structure is it? > There's a 300 page document describing the bitstream and how its used. The > smallest implementation, lcms is still a few tens of thousands of lines. 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? Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
