[vlc-devel] [RFC 1/6] libvlc: add rendering callbacks for D3D11 and D3D9

[Steve Lhomme]

On 5/2/2019 4:29 PM, Rémi Denis-Courmont wrote:
> Le torstaina 2. toukokuuta 2019, 11.04.42 EEST Steve Lhomme a écrit :
>>> I really don't think that a type-unsafe API is a good idea for LibVLC.
>>> It's
>>> already hard enough to get right.
>> It's a balance between simplicity and safety.
> No. Proper type-safe callbacks are simpler to document and implement. This is
> only a balance between making it easier for the one VLC developer vs everybody
> else.

My main concern is that it's easier to not support some of the 
callbacks. And then if something doesn't work the host app may not 
realize because this one call is missing. While with control calls, the 
host app sees of all them and has to consciously ignore some.

If some functions/controls are added API to the API it's less visible 
for the host app to know when it's called. Also depending on the 
language of the app it may be easier to have one callback rather than many.

It's also tricky to decide which callback is mandatory and which is not. 
For example the Select Plane call in this API can be ignored by the host 
app if it never handles rendering to NV12/P010. We can't decide when we 
receive the list of callbacks if it's OK not to have this callback, 
because we don't know what rendering format it will use. If it was a 
particular callback not implemented it will never be told to the host 
that this call was missing. It's harder to debug issues.

>
>> Having to handle a
>> message/control means you need to understand what is in "input" and in
>> "output". It's exactly the same has having to add a callback with the
>> proper parameters, you also need to understand them.
> Sure, you have to know what you are doing either way. That is not a
> justification for not providing type safety in my book.
>
>>> What's the point of this static assertion? Structures of different types
>>> cannot alias even if they have the same layout and representation, AFAIK.
>> Because the libvlc API mimicks the vlc_vout_display API I did for rendering:
>> https://code.videolan.org/robUx4/vlc/blob/libvlc/callbacks/59/include/vlc_v
>> out_display.h#L458
> I don't think LibVLC API should, or even can, mimick the vout display API,
> since the latter is not supposed to be stable.

It's actually not the display API but the vout render API. I'll probably 
move the callbacks into a separate header and live vlc_vout_display.h 
alone. That will clear up some confusion (that I also had). For now this 
API can match the libvlc API because it's easier to handle that way. 
That doesn't mean it will always be the case. The libvlc API still 
stands on its own.

>
> -- 
> 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