
<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Hello,<br></div><div><br></div><div>On Thu, Aug 20, 2020, at 18:04, Rémi Denis-Courmont wrote:<br></div><blockquote type="cite" id="qt" style=""><div>Hi,<br></div><div><br></div><div>Either Rust is used as a special niche with its custom API, like Lua. Or it wraps (a relevant subset of) the plugin API.<br></div></blockquote><div>"Or it wraps (a relevant subset of) the plugin API."<br></div><div>That is what I prefer. To make sure we have the same understanding, let's take an example with a possible Rust demux module.<br></div><div><br></div><div>Such module will need the vlc_stream API, but also the es_out API.<br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div><br></div><blockquote type="cite" id="qt" style=""><div>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.<br></div></blockquote><div><br></div><div>Sorry, I don't really understand this sentence.<br></div><div><br></div><blockquote type="cite" id="qt" style=""><div><br></div><div class="qt-gmail_quote"><div>Le 20 août 2020 10:51:13 GMT+02:00, Kartik Ohri <kartikohri13@gmail.com> a écrit :<br></div><blockquote class="qt-gmail_quote" style="margin-top:0pt;margin-right:0pt;margin-bottom:0pt;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;"><div dir="ltr"><div>Hi!<br></div><div dir="ltr">On Thu, Aug 20, 2020 at 1:43 PM Steve Lhomme <<a href="mailto:robux4@ycbcr.xyz">robux4@ycbcr.xyz</a>> wrote:<br></div><div class="qt-gmail_quote"><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;"><div>On 2020-08-19 17:22, Alexandre Janniaux wrote:<br></div><div> > Hi,<br></div><div> > <br></div><div> > On Wed, Aug 19, 2020 at 05:04:08PM +0200, Rémi Denis-Courmont wrote:<br></div><div> >> And then I would expect that the interface from Rust is not ad-hoc, but rather wrapping the plugin API directly.<br></div><div> > <br></div><div> > I'm not sure to understand this correctly.<br></div><div> > <br></div><div> > Does it mean that rust should use vlccore function for the plugin<br></div><div> > behaviour, or that the plugin should directly expose itself without<br></div><div> > a C wrapper, or something else?<br></div><div> <br></div><div> Have generic Rust code that handles the VLC filter API and then each <br></div><div> filter be written in Rust without caring of the C binding. That seems <br></div><div> cleaner IMO so when we update the filter API we only have this binding <br></div><div> to update.<br></div><div> <br></div><div> And then we could do the same kind of generic binding for codecs and <br></div><div> pretty much every other module type.<br></div></blockquote><div> <br></div><div>Before beginning the development on this, I had a discussion with Romain and<br></div><div>Thomas. It was decided that this approach is not very good. The rationale is that<br></div><div>the Rust Bindings for the VLC API will need to be regenerated for even a minor<br></div><div>change in the VLC API. This will be cumbersome. Also, since Rust will be used <br></div><div>sparingly in the codebase it is probably better to have separate rust code that <br></div><div>expose a C interface. I think Thomas and Romain will be able to better explain<br></div><div>the reasons behind the approach here.<br></div><div><br></div><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;"><div>_______________________________________________<br></div><div> vlc-devel mailing list<br></div><div> To unsubscribe or modify your subscription options:<br></div><div> <a href="https://mailman.videolan.org/listinfo/vlc-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/vlc-devel</a><br></div></blockquote><div><br></div><div>Regards,<br></div><div>Kartik <br></div></div></div></blockquote></div><div><br></div><div>-- <br></div><div>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté. <br></div><div>_______________________________________________<br></div><div>vlc-devel mailing list<br></div><div>To unsubscribe or modify your subscription options:<br></div><div><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></div></blockquote><div><br></div></body></html>