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

[Steve Lhomme]

On Wed, Jul 13, 2016 at 10:15 AM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> 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.

Is there a way to tell if a codec should be decoded to 10 bits per
channel ? We surely want to render content as best as we can.

Also the chroma implied from the libavcodec decoder also means that's
what we'll use if hardware decoding is not working. So it's a good
idea to that information.

> --
> Rémi Denis-Courmont
> http://www.remlab.net/
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel