[vlc-devel] Rust work (discussion)

Lyndon Brown jnqnfe at gmail.com
Tue Sep 22 20:46:48 CEST 2020


Hi Romain,

Simply put, even now with as much knowledge as I've gained from my work
on the VLC code, I'm in no position to go and kick off production of an
entirely new player; there's still so much that I don't know. I'd be
going back constantly to duplicate vast portions of VLC code,
particularly in areas like codecs and demuxers. Building upon an
existing codebase is both necessary in terms of my insufficient
knowledge to realistically achieve doing otherwise in any reasonable
time frame, and a huge time saver in terms of translating existing
logic that took a huge amount of effort to put together. It would
mostly just end up as a VLC translation anyway. And of course when I
started this, I had no experience with media player code and little
knowledge of the concepts. The plan was always to just contribute
translation work rather than try spinning off a fork or re-engineered
solution.

Although perhaps some people may jump on board with a separate project
and I can appreciate the benefits you highlight, I'd prefer the entire
VLC developer community with it's knowledge and talent adopt a Rust VLC
codebase rather than fragment the community, duplicate future effort,
and possibly struggle without some of VLC's developer talent. VLC is of
course enormous in size and complexity in comparison to a utility like
grep.

Additionally, I feel underqualified to make an overall assessment of
any notable negatives of existing VLC architecture. I'm aware that one
of the biggest issues is the pull vs. push model, but I'm only aware of
that because of the work being put into v4.0 to switch, and of course
that's already being addressed.

That said, the work is already not quite a perfect 1:1 translation of
the code as it was originally intended to be, there are some minor
opportunities I've taken here and there to do something better in Rust,
especially when it comes to using basic language features like struct
methods in place of pure functions, but I've been trying to otherwise
keep significant deviations in architecture to a bare minimum to both
simplify and speed up the project; avoid making things too unfamiliar
for existing developers; and not be too presumptive that such changes
would be welcomed or in cases presume that I truly understand the
design sufficiently well to do so.

Of course who knows what will happen later; this is still very early
days. There's no guarantee that VLC will accept a full switchover, and
there may well be plenty of opportunity later for consideration to be
given to re-engineering certain aspects, especially with the
productivity enhancements that Rust can bring. I can appreciate that in
some ways doing such re-engineering is best done from scratch rather
than as modification to existing code, but I don't think it's practical
in this case to do that.

If anyone does have particular aspects of the existing design that they
dislike and feel could be done in a significantly better way, I'd be
happy to hear about it and can keep it in mind in the initial portion
of the work I'm undertaking myself.

Regards,
Lyndon


On Tue, 2020-09-22 at 10:27 +0200, Romain Vimont wrote:
> Hi Lyndon,
> 
> On Sun, Sep 20, 2020 at 04:25:13AM +0100, Lyndon Brown wrote:
> > Specifically, a years-old project to achieve a complete conversion
> > of
> > the whole VLC codebase (to Rust).
> 
> That's impressive, but if the goal is to rewrite every single line of
> VLC in Rust "at once", why not writing an alternate Rust media player
> project (possibly inspired by VLC architecture) instead?
> 
> This would remove a lot of constraints.
> 
> In particular, the design of an API is heavily impacted by the
> language
> in which it is written. Designing it in Rust from the beginning would
> probably result in a better Rust API.
> 
> And a synchronized "switchover" would become unnecessary: if the
> project
> gets enough traction, people interested would join.
> 
> That's what happened for other projects. For example, rg is a grep-
> like
> tool written in Rust, the author was not constrained by the grep
> design,
> did not require validation and synchronization from grep authors, and
> no
> "switchover" was needed. And many people use it (including me).
> 
> Regards
> _______________________________________________
> 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