[vlc-devel] [PATCH] vout: opengl: add NV12/NV12 support

[Thomas Guillem]

On Sun, Dec 4, 2016, at 11:40, Rémi Denis-Courmont wrote:
> Le dimanche 4 décembre 2016, 11:13:43 Thomas Guillem a écrit :
> > > I have not had time to read my OpenGL paper book, so I can't comment on
> > > the OpenGL aspects. But I think that the file is getting much too big,
> > > but I don't like meaningless splits with tight dependencies between files
> > > either :/
> > > 
> > > I would though think that chroma conversion belongs in a separate
> > > conversion plugin. It might not be feasible without an opaque OpenGL
> > > texture chroma type however.
> > > 
> > > Also, NV12 specifically is a hardware decoder output format. For sure, it
> > > needs to be supported eventually... But does it really make sense at this
> > > point, that the OpenGL output does not support pass-through, so the NV12
> > > will be copied anyway. If copied, then conversion to I420 can be done on
> > > the fly for free in SIMD. IIRC, Laurent even implemented that for x86
> > > already.
> > 
> > Not really free, there is an extra memcpy when doing NV12 -> I420.
> 
> NV12->NV12 would need a copy in vlc_va_Extract() or equivalent, AFAIR. It 
> wouldn't make sense for a software decoder to output NV12.
> 
> So why would there be an extra memcpy()? The SIMD code should copy and
> convert 
> at the same time. Conversion from NV12 to I420 is really trivial.

That's what I was wondering. Should mediacodec always output I420 and
have SIMD conversion done internally to avoid an extra memcpy.

> 
> IMO, this shader is vain until we have pass-through from hardware decoder
> to 
> OpenGL. And by then, we should have a less monolithic OpenGL code base,
> so to 
> speak.

I'm trying to work on that

> 
> P.S.: also patch title is wrong
Yep
> 
> -- 
> 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