OK, there are a few things that were done in VLC for reasons that could be puzzling or had unintended excellent consequences. Those are not really mistakes, per se.

I can speak about 3 of them:

1) the one mentioned in the interview, where, when VLC was ported to Windows and Mac OS X, instead of using the system codecs, they used the linux-way and bundled the dependencies. It was supposed to be temporary, and we would use the system codecs. This means that we control better our decoders and demuxers than other traditional players, and we did not require codec-pack. That became very popular for VLC.

2) The cone was a temporary icon (and a student joke), and it is sooooo weird for a player, that this became a huge brand because it is so recognizable.

3) The code was split in a lot of modules, to help speed up the compilation time, of the project. That made the code way easier to extend or port to other platforms. Indeed, for example, a lot of modules don't need a lot of maintenance, because they just work. And you can add features or new OS, without understanding the core.

There are 2 other technical reasons that helped VLC getting popular, but those were planned.

The interview is too short to explain all this.

2) The cone was a temporary icon

Turn it sideways (5 degrees per major release) and keep the colors. Eventually it will be a Play Button.

>The cone ... became a huge brand because it is so recognizable.

This is definitely the case, VLC isn't a very memorable name, but the icon is unique. I was searching the other day and after typing "traffic cone", one of the search suggestions was "traffic cone video player".

Do you know how Media Player Classic solved the same problem?

I definitely remember the struggle with codec packs, then a breth of fresh air when ffmpeg codecs would solve most formats, and then just like that forgetting all codec issues by using MPC.

Media Player Classic usually came in the same installer as a bundle of codecs (like K-Lite), so you likely installed the two at once, but the model is still different from VLC, in that the codecs get independently installed into the system media framework, not embedded in the player.

You used to need separate codecs for MPC, but for a long time now it (at least MPC-HC) ships with LAV Splitters and LAV Filters, removing that need.

I love the cone. It is totally recognizable.

You should keep it.

Without the cone we can't have the Santa hat cone, either. Another reason to keep the cone.

My little girl has grown-up seeing the cone on our PCs and knows it's what plays the videos from my DSLR. She has asked to watch "cone videos", which means "videos of me you shot with your camera".

My grand daughter is the same. Total win.

"That one papa. Movie" She is three plus, and can use a surprising number of apps. Communicates with me in emoji too. It is a hoot!

Any device she gets her hands on. If she sees that cone, score!

Thanks a lot for the reply! :-)

jbk explained why this initially was a mistake on r/linux, see https://www.reddit.com/r/linux/comments/d8mhqe/the_one_who_k...:

> It was the fact that it came from the Linux world. So, when porting to Windows/macOS, the codec packages were part of the binary. It was supposed to temporary.

> This interview has cut that part.

One genius move back then was that you could increment the volume over 100%

I think he refers to the fact that by porting VLC to Windows they had to embed all the dependencies (codecs) into the final binary, which is coincidentally why VLC has gained so much popularity.

Yeah, seems like he forgot to finish writing that. I guess he statically linked the libraries when updating windows deps because he didn't know how to do it dynamically and that meant they were stuck shipping them all together? Is that even how that works (I don't really know C et al well).

I'm guessing here that the perceived mistake was that it was better to have a plugin based architecture where you can use all those codecs written by others.