On 10/09/14 11:10, Gwenole Beauchesne wrote: > Well, the initial use-case I had in mind, in view to supporting some > hwaccel2 interfaces, was a capability bit to indicate it is possible > to implicitly output to raw YUV buffers, possibly user-allocated, > instead of dealing with VASurfaceID, VdpSurface id, or other excessive > download/upload/sync mechanisms, etc.
I like the idea indeed. > Another use-case is that for some hwaccels, it could be interesting to > enable frame-level decoding, while also still allowing slice-level > decoding in specific use cases. e.g. in dxva2/vaapi, that could be a > way to enable "short" mode decoding in H.264 AVC, but keep "long" mode > decoding for H.264 MVC. That would need the next step that is the av_hwaccel_alloc/config/open/close() (think about avresample for a similar api). The problems at hand are - Having an avoption api let us easily add features, but passing pointers through avoption properly would require an overhaul to it (so we pass the pointer - we need to keep the structure exposed to let the users that need to pass otherwise-managed pointers keep doing it. - per-hwaccel allocator might be less confusing than having a function returning a pointer that you have to cast, but having 3+ functions for each hwaccel might be a burden in the long time. > Having said that, I believe a simple comment update is fine as it is. > An explicit deprecation attribute would not. I do agree. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
