[vlc-devel] [PATCH 1/6] decoder: add code to send 3d metadata to the output modules to be handled

Rémi Denis-Courmont remi at remlab.net
Thu Aug 16 18:49:55 CEST 2018

Le torstaina 16. elokuuta 2018, 10.20.29 EEST Steve Lhomme a écrit :
> On 14/08/2018 17:05, Rémi Denis-Courmont wrote:
> > Also testing the other way around I found out that changing the vout
> > 
> >> dynamically like that fails the hardware decoder. In D3D the context is
> >> created by the vout and shared with the VA, if the vout disappears and
> >> the VA remains unchanged the new vout will have a different context and
> >> it won't work (black screen).
> > 
> > If you change the video output behind the back of the decoder, then it
> > won't work.
> > 
> > But as far as I understand this patch, this is about the case of the
> > decoder proactively changing its output format. In that case, the decoder
> > is responsible for using picture buffers from the picture pool of the new
> > video output. Nothing else can fix or work around it for the decoder.
> Actually it's not a change from the decoder but "side data" that changed
> in the stream. See DecodeSidedata() in avcodec/video.c.

That *is* a change from the decoder for the sake of the interface between the 
decoder and the video output.

> More generally I think we should differentiate the actual picture format
> (as in pixels needed to decode, the get_format from lavc) from
> 'metadata' changes including the offset/visible area, sar, orientation,
> HDR, stereo source, etc. In the first case if the chroma or pixels
> change we need a new vout. In all the other cases it depends on the vout
> capability and since it's not requested by the decoder and will require
> a decoder restart we should do our best not to recreate the vout.

As ALREADY MENTIONED, those are already distinguishable and sometimes 
distinguished (e.g. SAR or crop changes). The current vout architecture has 
supported that from its very beginning internally, regardless of how the 
decoder thread works.

But stereoscopy change cannot realistically be treated as such a "harmless" 
property change if it leaves only D3D11 supporting direct rendering. So it 
needs to change the video output, at least for now.


More information about the vlc-devel mailing list