[vlc-devel] [PATCH 1/2] Adds Intel QuickSync Video Encoder
Felix Paul Kühne
fkuehne.videolan at gmail.com
Thu May 16 17:11:54 CEST 2013
On 16.05.2013, at 17:04, Jean-Baptiste Kempf <jb at videolan.org> wrote:
> On 16 May, Rafaël Carré wrote :
>> Le 16/05/2013 16:57, Jean-Baptiste Kempf a écrit :
>>> On 16 May, Rafaël Carré wrote :
>>>> Le 16/05/2013 16:40, Jean-Baptiste Kempf a écrit :
>>>>> On 16 May, Rafaël Carré wrote :
>>>>>> Le 16/05/2013 16:35, Jean-Baptiste Kempf a écrit :
>>>>>>> On 16 May, Rafaël Carré wrote :
>>>>>>>> Le 16/05/2013 14:06, Julien 'Lta' BALLET a écrit :
>>>>>>>>> This second patch adds a simple i420 -> nv12 chroma filter, as
>>>>>>>>> initally suggested by jb.
>>>>>>>>
>>>>>>>> Is it faster than swscale ?
>>>>>>>
>>>>>>> Now, no, because it is plain C. But it allows us to do SIMD, like we do for
>>>>>>> i420->RGB, YUY2->I422 or NV12->RGB. So this is the first step.
>>>>>>
>>>>>> We should wait until it has a proper fast implementation before
>>>>>> committing something slow IMO.
>>>>>
>>>>> Why? swscale has a higher priority, already.
>>>>
>>>> Because it's useless?
>>>
>>> It won't be useless. And then why don't you remove all modules that have
>>> a lower priority than another one?
>>
>> Because they supposedly have some advantage, that one is just slow.
>
> I would argue that not depending on swscale is an advantage though...
> But ok.
I'd like to second you here. Being less dependent on swscale is a big advantage, since it's unmaintainable.
Additionally, did you do some benchmarks with the C module compiled by a proper, modern C compiler, such as Clang 4.x, etc.? Seeing the minor advantage libav's ARM ASM got nowadays, I wouldn't be terribly surprised if the difference is barely noticeable.
Best regards,
Felix
More information about the vlc-devel
mailing list