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

Reply via email to