On 08/28/2017 11:52 AM, wm4 wrote:
On Sun, 27 Aug 2017 18:26:32 +0200
Jorge Ramirez<jorge.ramirez-or...@linaro.org> wrote:
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...
With hwaccels, the hardware gets only the slice data (and a bunch of
API parameters with information about the bitstream etc.) instead of
the full bitstream. The advantage is that higher level bitstream
parsing, metadata retrieval, reference frame management, frame
reordering, etc. are all done by the already existing native codec
implementation.
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).
Just forget that libavdevice exists, and keep it correct and simple in
libavcodec.
[resending to the ML];
but I do need to use some of the functions supported in libavdevice for
its v4l2 frame grabber support; ignoring that code means I will have to
pretty much duplicate it with a couple of additions that said..
is this what you are suggesting or am I misunderstanding you?
I'll post v7 after this last bit (this dependency seemed to also be a
source of concern for Paul Mahol)
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
