On 19/02/2017 11:09, Anton Khirnov wrote: > - introduce a new pixel format, AV_PIX_FMT_CUVID, which wraps the frame index > and allows transfer to CUDA via av_hwframe_transfer_data(). Then either > * Return those PIX_FMT_CUVID frames to the caller and let them do the copy > manually. This is most flexible, but more work for the caller and might > mean synchronization problems, so we'd need to add locks (perhaps to the > CUVID frames context). > * Handle delay+map+copy somewhere else in lavc. The question is where > would the right place be. Janne suggested at FOSDEM to add a dummy > decoder, > h264_cuvid wrapping h264dec, which would do the delay and copy. That > should > work, but isn't very elegant.
The problem I see with this approach is that it would have to be duplicated for the many other decoders supported by cuvid, so over time we'd have to make it generic. > - we could also add some sort of a "postprocess" stage to AVHWaccel, run > before > returning a frame from decode(), or perhaps invoked separately by the lavc > generic code. Sounds sort of nicer, I'd keep it internal to lavc if it doesn't hurt performance. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
