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

[Steve Lhomme]

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.

> 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