[vlc-devel] [PATCH 05/14] filter: allow the owner not to provide a buffer callback
Steve Lhomme
robux4 at ycbcr.xyz
Wed Sep 18 14:17:25 CEST 2019
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
>
More information about the vlc-devel
mailing list