On 08/25/2017 05:35 PM, wm4 wrote:
That looks generally OK. Is there any chance a hwaccel approach would
be possible instead? If I've learned anything about hardware decoding,
then that hwaccel is vastly superior to vendor-implemented full stream
decoders.
could you help me understand what would that entitle and what how would
that be beneficial to the users?
I just dont feel I can answer that question properly...
v4l2 provides a generic API which is what the patchset uses to perform
encoding/decoding on any v4l2 supported hardware (it is completely
vendor independent)
From the layer above (libavcodec) all it needs is a way to get the
frame information and after processing to pass it back; so in principle,
if the hwaccel API provides that, I could just move it all to use those
calls if you think that fits better with ffmpeg.
but I dont think I understand the benefit of changing from the ffmpeg
encoding/decoding API to hwaccel API.
I don't think I like the attempt of sharing the v4l helper functions
between libavdevice and libavcodec, but I can't tell how much it helps.
ok. I am of course open to suggestions on this (I didnt see any issues
with what the patchset provides or I would have done it differently).
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
