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

[Steve Lhomme]

On Wed, Jul 13, 2016 at 9:54 AM, Steve Lhomme <robux4 at gmail.com> wrote:
> On Wed, Jul 13, 2016 at 9:14 AM, Jean-Baptiste Kempf <jb at videolan.org> wrote:
>> On 12 Jul, Steve Lhomme wrote :
>>> 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.
>>
>> I'm not at ease with this solution.
>>
>> I don't know exactly why, but this feels like a hack, since opaque
>> should be opaque, and the vout should then infer the format from the
>> picture reference given. I understand that there is a chicken-and-egg
>> issue here, though...
>
> Yes.
> - the decoder tries to use hardware decoding if possible, trying a few
> opaque formats, each corresponding to a kind of decoder.
> - for that opaque format it creates a vout.
> - the vout tries to match the decoder to avoid needing filters and
> memory copying, but all it knows is that an opaque is requested.
> - once the vout is created, the decoder gets pictures from the decoder
> pool created by the vout. If it is opaque then the internal format
> picked by the vout has to match exactly what the decoder would have
> picked. Otherwise we need converting filters, that cannot exist
> because all they would know about the input/output is that it's some
> opaque flavor. Or these filters need to be internal to the decoder
> and/or vout.
>
> In short, doing hardware decoding and zero copy at the same time
> involve the decoder and vout sharing more information than an dumb
> OPAQUE pixel format. The choice in vdpau is to have one opaque format
> per possible decoder configuration. Adding 10/12 bit supports will
> multiply its current opaque pixel formats by 2/3. I don't think that's
> a viable solution.
>
> IMO we need some hints between the hardware decoder and the vout. I
> tried that in the past by passing extra data to the vout creation but
> then there's the problem of releasing that data when the vout can be
> reused between files/decoder instances. We already added colourspace
> data in video_format_t so we might add a few more data like the chroma
> subsampling flavor. The bits per pixel is already there but set to 0
> for opaque formats. I'll see if it's possible to override this value
> safely.

Maybe "const vlc_chroma_description_t *" would be a good candidate.
The pointers exist in the core and will not need freed. Plus it
contains exactly all the missing information in video_format_t to pick
the best output.

>> Can we change the format of the swapchain, for example, after opening?
>
> There are cases where a vout is recreated if the format changes. But I
> think it's when the INPUT changes. In this case opaque doesn't change
> to another opaque.
>
>> --
>> Jean-Baptiste Kempf
>> http://www.jbkempf.com/ - +33 672 704 734
>> Sent from my Electronic Device
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel