[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