On 08/02/2017 09:33 AM, Hendrik Leppkes wrote:
On Tue, Aug 1, 2017 at 2:54 PM, Jorge Ramirez-Ortiz
<jorge.ramirez-or...@linaro.org> wrote:
From: Alexis Ballier <aball...@gentoo.org>
This patchset enhances Alexis Ballier's original patch and validates
it using Qualcomm's Venus hardware (driver recently landed upstream
[1]).
This has been tested on Qualcomm's DragonBoard 410c and 820c
Tested decoders:
- h264
- mpeg4
- vp8
- vp9
- hevc
Tested encoders:
-h264
-h263
-mpeg4
Tested transcoding (concurrent encoding/decoding)
Some of the changes introduced:
- v4l2: code cleanup.
- v4l2: follow the decode api.
- v4l2: fix display size for NV12 output pool.
- v4l2: handle EOS.
- v4l2: vp8 and mpeg4 decoding.
- v4l2: hevc and vp9 support.
- v4l2: generate EOF on dequeue errors.
- v4l2: h264_mp4toannexb filtering.
- v4l2: import compat/v4l2 header files.
[1] https://lwn.net/Articles/697956/
Reviewed-by: Jorge Ramirez <jorge.ramirez-or...@linaro.org>
Reviewed-by: Alexis Ballier <aball...@gentoo.org>
Tested-by: Jorge Ramirez <jorge.ramirez-or...@linaro.org>
---
Changelog | 3 +-
compat/v4l2/v4l2-common.h | 107 ++
compat/v4l2/v4l2-controls.h | 987 +++++++++++++++++
compat/v4l2/videodev2.h | 2402 +++++++++++++++++++++++++++++++++++++++++
As commented on IRC before, I'm not a fan of importing Linux kernel
headers for the only reason because its convenient to always have
recent headers available.
Hi Hendrik,
but what is wrong with convenience? as a matter of fact, this will not
add any 'major' maintenance task.
Only when the ffmpeg v4l2 support is modified to add a more recent call
(or some new fourcc) these headers will have to be updated accordingly
(ie do a copy paste for files that are easily avaialable)
IMO, this seems much easier, less error prone - and consistent - than
modifying configure every time looking for what needs to be checked
before building.
On a system with a recent enough kernel to run this, you would also
have matching headers, so IMHO this should behave like any external
library dependency and just check that the headers are recent enough
to build our code, and just skip building the module otherwise.
but what if the user is running of vendor trees with some hacked
versions of these files in the rootfs? this way at least he'll know
exactly what he is building. And if wishes some custom behavior, we are
enforcing that he changes the UAPI v4l2 in the ffmpeg _tree_
Seems coherent to me.
also notice, that having a recent enough kernel does allows the user to
build, will not guarantee that we will be able to run these
encoders/decoders (the user will need actual hardware support for that
and the v4l2 driver in the kernel)
- Hendrik
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
