On 21/12/15 16:32, Anton Khirnov wrote: > One specific point on which I could use some opinions is the specific > API for accessing the data. Conceptually, I can think of the following > possible operations: > 1 copy from hw to ram (conceivably also from hw to hw, but I doubt it > ever really makes sense?) > 2 copy from ram to hw > 3 map hw to ram > 4 map ram to hw > 5 map one hw pixfmt to another (e.g. VDPAU to CUDA) > For each of those, there should also be a query function that tells the > caller which target formats are acceptable for a given input. > > In theory, we could have a single function pair for all of those, since > they have one input and one output frame. But that does not strike me as > the right way, since they are conceptually quite different (1-2 do a > copy, the rest don't). OTOH 1-2 and 3-5 are rather similar, so we could > have one pair of functions for each of those.
> > Opinions? > I'd rather have two functions, one with move semantics and the other with copy semantics since, even if you could have both at the same and make it work flipping the frame writable bit on/off as needed, it would be a bit confusing otherwise. A function to duplicate hw buffers might be useful as well. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
