[vlc-devel] [PATCH] Add Rust backed cue sheet parsing module

[Thomas Guillem]

Hello,

On Thu, Aug 20, 2020, at 18:04, Rémi Denis-Courmont wrote:
> Hi,
> 
> Either Rust is used as a special niche with its custom API, like Lua. Or it wraps (a relevant subset of) the plugin API.
"Or it wraps (a relevant subset of) the plugin API."
That is what I prefer. To make sure we have the same understanding, let's take an example with a possible Rust demux module.

Such module will need the vlc_stream API, but also the es_out API.
The vlc_stream API should be easy to port to Rust, but I don't know what to do about es_out that have a big set of va_args+enum.

Personally, I would not port es_out to Rust. Here is what I propose: A Rust demux module could have a demux() function that read data via vlc_stream and send the result via some rust callbacks. The C module wrapper is then propagating these callbacks to es_out controls.

Now, let's take a Rust packetizer; I don't think it needs any VLC API. The rust module is feed with data and return some data + callback when fmt change.


> It makes no sense to have to maintain dedicated glue code for each and every Rust module, especially if they're for the same VLC capability.

Sorry, I don't really understand this sentence.

> 
> Le 20 août 2020 10:51:13 GMT+02:00, Kartik Ohri <kartikohri13 at gmail.com> a écrit :
>> Hi!
>> On Thu, Aug 20, 2020 at 1:43 PM Steve Lhomme <robux4 at ycbcr.xyz> wrote:
>>> On 2020-08-19 17:22, Alexandre Janniaux wrote:
>>> > Hi,
>>> > 
>>> > On Wed, Aug 19, 2020 at 05:04:08PM +0200, Rémi Denis-Courmont wrote:
>>> >> And then I would expect that the interface from Rust is not ad-hoc, but rather wrapping the plugin API directly.
>>> > 
>>> > I'm not sure to understand this correctly.
>>> > 
>>> > Does it mean that rust should use vlccore function for the plugin
>>> > behaviour, or that the plugin should directly expose itself without
>>> > a C wrapper, or something else?
>>> 
>>> Have generic Rust code that handles the VLC filter API and then each 
>>> filter be written in Rust without caring of the C binding. That seems 
>>> cleaner IMO so when we update the filter API we only have this binding 
>>> to update.
>>> 
>>> And then we could do the same kind of generic binding for codecs and 
>>> pretty much every other module type.
>>  
>> Before beginning the development on this, I had a discussion with Romain and
>> Thomas. It was decided that this approach is not very good. The rationale is that
>> the Rust Bindings for the VLC API will need to be regenerated for even a minor
>> change in the VLC API. This will be cumbersome. Also, since Rust will be used 
>> sparingly in the codebase it is probably better to have separate rust code that 
>> expose a C interface. I think Thomas and Romain will be able to better explain
>> the reasons behind the approach here.
>> 
>>> _______________________________________________
>>> vlc-devel mailing list
>>> To unsubscribe or modify your subscription options:
>>> https://mailman.videolan.org/listinfo/vlc-devel
>> 
>> Regards,
>> Kartik 
> 
> -- 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20200820/69872b81/attachment.html>