On Wed, 12 Mar 2014 13:54:42 +0100 Vittorio Giovara <[email protected]> wrote:
> On Wed, Mar 12, 2014 at 1:29 PM, Luca Barbato <[email protected]> wrote: > > On 12/03/14 12:49, wm4 wrote: > >>> Another point, (again AFAIU) pixel format/range/space seem to be more a > >>> frame > >>> property, instead of a context one (kinda like interlacing). Would it > >>> make sense > >>> to move everything there? The API I would envision would be an entry in > >>> AVFrame > >>> and an AVFrameSideData for the color range and spaces. > >> > >> They could be direct fields in AVFrame. I think they're important > >> enough - they're crucial for correct processing or display. And there > >> are much less important fields in AVFrame. I would suggest adding the > >> following fields: > >> > >> enum AVColorSpace colorspace; > >> enum AVColorRange color_range; > >> > >> ffmpeg already has these. And I don't think there's a need for > >> gratuitous incompatibility without reasons. > >> > > > > If you are willing to send patches here would be great. I'm not sure why > > a field has an _ and the other does not though... > > > > and IIRC there are 4 fields useful not just those two. > > > > Yes IIRC there is pixel format, color range, color space and color matrix. > Anything else? And color_primaries, color_trc. There's also chroma_sample_location, but it doesn't have to do with colorspace stuff directly. > Also besides compatibility, what other reasons there would be to put > fields in avframe or in side data? In theory you could put all fields into side data, and treat AVFrame as some sort of generic key-value store. Of course that would be insane. So fields that are commonly needed to process the frame data correctly should be direct fields, while obscure/optional stuff should not. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
