On Wed, Aug 2, 2017 at 11:39 AM, Jorge Ramirez <jorge.ramirez-or...@linaro.org> wrote: > 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. >
(Re-send because I didn't send it to the List by accident) You could bring that argument for every single external library/API we support, and that is just not something we should be doing. We require headers to be available in the system for practically every other external API/library with only very few exceptions which have extraordinary circumstances beyond "I don't want to maintain configure checks". So no, we should not be doing this. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
