[vlc-devel] [PATCH 1/3] [RFC] vlc_es: add the original chroma

Rémi Denis-Courmont remi at remlab.net
Wed Jul 13 10:15:15 CEST 2016


Le 2016-07-13 08:51, Steve Lhomme a écrit :
> On Tue, Jul 12, 2016 at 8:38 PM, Rémi Denis-Courmont 
> <remi at remlab.net> wrote:
>> Le 2016-07-12 17:14, Steve Lhomme a écrit :
>>>
>>> On Tue, Jul 12, 2016 at 5:03 PM, Rémi Denis-Courmont 
>>> <remi at remlab.net>
>>> wrote:
>>>>
>>>> Le 2016-07-12 16:59, Steve Lhomme a écrit :
>>>>>
>>>>>
>>>>> This is needed when using opaque chroma formats. The vout doesn't 
>>>>> know
>>>>> the
>>>>> pixel format that is intended to be decoded and so we can't 
>>>>> decide for
>>>>> 8/10/12/16 bits rendering. The same goes for YUV vs RGB or for 
>>>>> 4:2:0
>>>>> vs 4:2:2.
>>>>
>>>>
>>>>
>>>> What the hell is an "original chroma"? I understand original 
>>>> codec,
>>>> though
>>>> that seems quite useless in video output, or really for anything 
>>>> other
>>>> than
>>>> informational purpose. In VLC, a chroma is a pixel format, and I 
>>>> fail to
>>>> grasp the concept of an original pixel format.
>>>>
>>>> For hardware, the pixel format is unknown; it's most often a
>>>> vendor-specific
>>>> hardware-specific tiling format that VLC knows nothing and should 
>>>> know
>>>> nothing about.
>>>
>>>
>>> Look at 3/3 for the reason why it's needed. I used the name chroma
>>> because that's the same use as i_chroma next to it.
>>
>>
>> I don't care about whatever patch. This makes no sense that I can 
>> tell and
>> you are not providing any explanation why and how it would make 
>> sense.
>> Because it does not; the hardware texture format is opaque and 
>> irrelevant to
>> software (other than the device drivers), including VLC.
>
> Obviously not.

Yet you failed to explain what the original chroma was and...

>
>> You may be confusing pixel format with chroma (sub)sampling and 
>> sample
>> depth.
>
> No.

Patch 2 sets the "original chroma" from the libavcodec default picture 
format. That is a pixel format and an artifact of the libavcodec 
version. That has no implications on how the video decoding hardware 
represent pictures. That makes no sense.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


More information about the vlc-devel mailing list