[vlc-devel] [PATCH 05/14] filter: allow the owner not to provide a buffer callback
Alexandre Janniaux
ajanni at videolabs.io
Wed Sep 18 14:58:05 CEST 2019
Hi,
I agree that OpenGL video context doesn't have much sense, although
EGL could have, as only OpenGL could handle such data, and thus it
wouldn't be convertible easily.
Regards,
--
Alexandre Janniaux
Videolabs
On Wed, Sep 18, 2019 at 02:17:25PM +0200, Steve Lhomme wrote:
> Hi,
>
> On 2019-09-18 13:32, Rémi Denis-Courmont wrote:
> > Hmm well yeah... in other words, it's not easy or at least not obvious in the general case.
> >
> > Also how does should an OpenGL shader-based filter if the decoder device
> > is, say, NVdec, and the video context is X11?
>
> There is no X11 video context. I'm not sure if you're talking about the
> windowing part of the display module. The windowing part doesn't deal with
> any of that. So let's assume you're talking about the XCB display module.
>
> XCB can only handle CPU based chromas. When it's opened it tells which
> chroma it's going to use. This is how it works now. The core will adapt
> whatever video format+video context is last in the decoder+filters pipeline.
> This is the job of the osys->converters chain in the display module.
>
> If the last format+context in the pipeline is NVDEC then a NVDEC GPU>CPU
> filter is used by osys->converters.
>
> If the last filter is an OpenGL filter I'm less sure as what will come out,
> as I haven't looked at the WIP API yet. There's currently no OpenGL decoder
> device or video context. I'm not sure it really make senses. If the input
> video context is NVDEC (it should be since the decoder is NVDEC) it would
> make sense to output that as well. (NVDEC is a bad example though as there's
> no real sharing of memory with the display so it would be inefficient). So
> it works as the case above.
>
> If the OpenGL outputs a CPU based format (NULL video context) then that's
> what the osys->converters has to deal with.
>
> And if that's a different kind of video context, then it's like NVDEC, the
> osys->converters have to deal with it on input and output the CPU chroma XCB
> wants.
>
> So the real deal lies in how the `converters` chain deals with input/output
> with different video contexts. For that I added some opaque chroma to the
> list of interim chromas the "chain" module tries to add intermediate
> filters. Then we are back to what I was describing:
>
> a filter may use a decoder device to create a video context from scratch for
> its output, needed by an opaque chroma.
>
> > It knows neither of them. Sure it'd solvable, but to me it's not obvious at all, and I'd rather sort it out in a workshop than over a mailing list.
> >
> > Le 18 septembre 2019 12:15:30 GMT+03:00, Steve Lhomme <robux4 at ycbcr.xyz> a écrit :
> > > On input of filters it's easy, they get a video context (or NULL for
> > > CPU
> > > based sources).
> > >
> > > The issue is when a filter needs to create a video context on its own.
> > > For CPU to GPU filters it cannot use the input video context. Just like
> > >
> > > a decoder it should use the "decoder device" to create its output video
> > >
> > > context.
> > >
> > > So just like for the decoder, the owner of the filter provides a
> > > "get_decoder_device" callback to get it.
> > >
> > > On 2019-09-18 10:39, Rémi Denis-Courmont wrote:
> > > > Hi,
> > > >
> > > > I am not sure how hardware should be exposed to filters/converters. I
> > > don't recall covering that part of the puzzle at the February workshop.
> > > >
> > > > Le 18 septembre 2019 09:00:41 GMT+03:00, Steve Lhomme
> > > <robux4 at ycbcr.xyz> a écrit :
> > > > > On 2019-09-17 17:32, Rémi Denis-Courmont wrote:
> > > > > > Le tiistaina 17. syyskuuta 2019, 17.22.33 EEST Steve Lhomme a écrit
> > > :
> > > > > > > In this case we just allocate a picture from the filter output
> > > > > format.
> > > > > > > ---
> > > > > > > include/vlc_filter.h | 7 ++++++-
> > > > > > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/include/vlc_filter.h b/include/vlc_filter.h
> > > > > > > index 0c756ce10ec..0bc10e91997 100644
> > > > > > > --- a/include/vlc_filter.h
> > > > > > > +++ b/include/vlc_filter.h
> > > > > > > @@ -26,6 +26,7 @@
> > > > > > > #define VLC_FILTER_H 1
> > > > > > >
> > > > > > > #include <vlc_es.h>
> > > > > > > +#include <vlc_picture.h>
> > > > > > >
> > > > > > > /**
> > > > > > > * \defgroup filter Filters
> > > > > > > @@ -160,7 +161,11 @@ struct filter_t
> > > > > > > */
> > > > > > > static inline picture_t *filter_NewPicture( filter_t *p_filter
> > > )
> > > > > > > {
> > > > > > > - picture_t *pic = p_filter->owner.video->buffer_new( p_filter
> > > );
> > > > > > > + picture_t *pic;
> > > > > > > + if ( p_filter->owner.video != NULL &&
> > > > > p_filter->owner.video->buffer_new
> > > > > > > != NULL)
> > > > > >
> > > > > > Two checks look redundant, though anyway this callback should go
> > > away
> > > > > > altogether eventually.
> > > > >
> > > > > Yes, it will go away.
> > > > >
> > > > > The owner will have the "get_device" callback so it's possible at
> > > some
> > > > > point in the code to have one callback and not the other. But in the
> > > > > end
> > > > > this code won't be there anymore.
> > > > >
> > > > > > > + pic = p_filter->owner.video->buffer_new( p_filter );
> > > > > > > + else
> > > > > > > + pic = picture_NewFromFormat( &p_filter->fmt_out.video );
> > > > > > > if( pic == NULL )
> > > > > > > msg_Warn( p_filter, "can't get output picture" );
> > > > > > > return pic;
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 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
> > > > > >
> > > > > _______________________________________________
> > > > > vlc-devel mailing list
> > > > > To unsubscribe or modify your subscription options:
> > > > > https://mailman.videolan.org/listinfo/vlc-devel
> > > >
> > > > --
> > > > Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez
> > > excuser ma brièveté.
> > > >
> > > >
> > > > _______________________________________________
> > > > vlc-devel mailing list
> > > > To unsubscribe or modify your subscription options:
> > > > https://mailman.videolan.org/listinfo/vlc-devel
> > > >
> > > _______________________________________________
> > > vlc-devel mailing list
> > > To unsubscribe or modify your subscription options:
> > > https://mailman.videolan.org/listinfo/vlc-devel
> >
> > --
> > Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
> >
> >
> > _______________________________________________
> > vlc-devel mailing list
> > To unsubscribe or modify your subscription options:
> > https://mailman.videolan.org/listinfo/vlc-devel
> >
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
More information about the vlc-devel
mailing list