Since this has turned into a "dump on VLC" thread: thank-you, VLC devs, for all the work that you do. I've been a diehard VLC user since 2006/2007, when I happily discovered a single .exe program could handle all of the files that I was continuously updating the ever-growing K-Lite Media Pack in order to handle. It found additional use as a Portable App that lived on the flash drive in my pocket, allowing me to pull it out at late-night piracy parties and confidently play the unviewable file that someone had grabbed off Kazaa.
To this day, it's the one program I can recommend to friends and family to install, regardless of OS/platform, that I will be confident can handle anything they throw at it. You guys do great work.
> The randomizer stores a single vector containing all the items of the playlist. This vector is not shuffled at once. Instead, steps of the Fisher-Yates algorithm are executed one-by-one on demand.
Fisher-Yates is the generalization of what is known as the "7-bag randomizer" in the Tetris community (same problem: you want to distribute 7 pieces randomly but want to avoid repetition). It's funny how what you think as inconsequential trivia about your niche hobby can turn out in unexpected places !
IIRC, Knuth made it famous (because TAOCP). Often with the naming of these things there is a misalignment with who discovered/published it first and who popularized it first.
(I personally think naming the algorithm after both is a good compromise)
Also known as card deck shuffle, but indeed I have always known it as Knuth.
As for peers part, perhaps they use a library function - Java has java.util.Collections.shuffle. OTOH is a single line, provided the generator can produce a random number [0-n).
Looks like he reinvented shuffle vectors on his own. I think a lot of people have over the years, but crazy enough nobody bothered to publish it until February this year! Maybe it felt too intuitive?
That the shuffle vector is a data structure that shuffles upon push/pop while still maintaining O(1):
> From a CompSci angle: this is a data-structure with a built-in Fisher-Yates shuffle. Big-O is the same when you want to shuffle a whole array of n elements at once, namely O(n). The difference is that instead of initiating the vector, then shuffling the whole thing, the shuffling is applied "lazily" as you add elements to it.
> This may have benefits in some situations: if you have a "random bag" where you often add a few elements at a time, then want to pick elements at random. One very naive way to do it would be to shuffle the bag every time you pick an element, which as mentioned is O(n). Using a shuffle vector, you can add elements by push, and grab a random element with pop. Since one swap per insertion is enough, picking a random item from our bag is O(1) instead.
It looks like your approach has a lot of overlap with this data structure (which specializations specific to your use-case).
The data structure is explained in the first link, and was (officially) introduced to CompSci (as in, described in an academic publication) in the paper in the second link. However, in all likelihood a lot of people came up with this approach over the years. For example, when I first shared the notebook in the first link on Twitter, a few game devs came forward saying they implemented something similar for their games before.
So I'm just connecting your approach to the wider context of what others have done in this space
This article, while a nice summary, does miss some details that are quite important. TGM in particular uses Mersenne Twister as its PRNG, whereas NES Tetris probably uses a linear congruential generator (as was common for many games on 8-bit game consoles to the best of my knowledge.) MT behaves dramatically differently than LCG, and while it may seem like a minor detail, actually feels quite different to play from Math.random implementations I've tried, even when using the same TGM algorithm.
Maybe it helps to think of these randomizers as noise generators, and then try to figure out what the ideal noise "color" for fun play would be? I guess blue noise for example would be like too predictable random bag generators.
flip note: I dunno which 'Math.random' you mean, the Java version should not be used for anything meaningful (perf. related) as it is a shared 'java.util.Random' that exhibits a contention point, albeit a CAS (not synchronized) but a contention point nonetheless.
Also generating a double (from 2 ints) to be converted to an int is a bad idea. Should be just 'random.nextInt(7)'
In particular I’m thinking of JavaScript, but the same thing could be said about libc random. In at least a few puzzle games, the PRNG used has noticeable side effects.
I understand the issue with modulo bias, but there's plenty of techniques for dealing with that issue. (Not to say that people always do, even in real-world code, but oh well.)
I mean, I'm sure your `vlc_vector` you've spent so much time optimizing and securing is as good as or even better than `other_project_vector` and `some_library_vector` or maybe even `some_other_vector`
All of which were implemented by various projects out of necessity because the language they chose doesn't have such an essential data structure in its standard library and because the culture around the language values NIH more than anything else.
Remind me again, why C is a good thing and not a liability these days?
There was quite a bit of interest in getting Rust parsers into VLC a few years ago[1], is there any update on this -- will we ever see core VLC code using Rust?
Many languages that compile to native code allow you to export functions in a way that they can be called from other C code.
This means you'd write your actual code in whatever language you want (possibly one that does have a generic vector in its standard library - but I guess these days that's anything but C) and then you'd just export a usable-by-C interface so other languages still get to interface with your implementation.
c and c++ are still great choices when you care more about performance than correctness.
a media player doesn't (or shouldn't at least) modify any of my essential data, so the worst it can really do is crash every now and then. for a program like vlc, mild instability is not a bad trade-off if it means less dropped frames on old computers.
I wouldn't agree with that---media players are often fed untrusted content from the Internet, so a security issue in a shared media player API can be critical. See the Android StageFright vulnerability from a few years back.
Writing it in C for a marginal performance gain just isn't worth it.
> a media player doesn't (or shouldn't at least) modify any of my essential data
Ask the Android team about the stagefright exploit.
Media players provide a huge attack surface. They are constantly exposed to untrusted files which are also very enticing for users to open (as opposed to, say, some spreadsheet)
Yes. A media player normally doesn't modify your essential data, but when it's written in an unsafe language, it is very likely to do so one way or another.
I would argue the opposite; a media player is one of those applications where you just need "good enough" performance. Good enough to play 4k/8k/whatever content, without dropping any samples/frames, without causing my fans to spin up. After that point I would much rather have rock solid stability and security than more performance.
Will their ever fix the infinite loop you get when you open a broken file and VLC just try to read the 1-file playlist indefinitely and the UI gets stuck forever ?
I used VLC for years, but more recently have found the Mac app IINA https://iina.io/ to be a (not perfect but) substantially nicer tool in the same niche (i.e. an open-source video player that handles whatever I throw at it). VLC is just too full of incidental complication.
Two things that convinced me to switch to IINA was integrated subtitle downloader and ability to position those subtitles onto lower matte in letterboxed videos.
Isn't it? It's really clean for the basic stuff, but off the top of my head:
- Codec conversion has one of the most opaque interfaces of any program I know.
- Recording, while simple in interface, has a lot of gotchas, and you're likely not to get what you expect.
- Having a separate volume control I'm sure isn't complicated for anyone here, but it's come up several times as an issue with my parents/grandparents.
- There are so many settings, many in very technical language, that there are entire pages whose function is basically a mystery to me.
I love VLC, and I really think they've nailed the basics, but the program at large suffers from kitchen-sink syndrome, and many of the less common features have had very little thought put into making them simple.
>There are so many settings, many in very technical language, that there are entire pages whose function is basically a mystery to me.
Honestly, I love that about VLC. There are plenty of shell commands I have no idea how to use properly, for instance, but knowing that they are there if I ever do need to learn how to use them is great. The modern theme of stripping out functionality in favor of perceived simplicity undermines these great comprehensive tools like VLC. If you don't know what a setting does that shouldn't be a problem; you probably never have to touch it then. Sure, some of the functions seem pretty old school today, but I'd hate to see VLC dumbed down.
I don't at all object to the complexity of the settings. (Or, I do in a more limited way, but that's not the point of my comment.) I'm disagreeing only with the parent's suggestion that all experiences with VLC are very simple.
On your point: I think having many settings, including very technical ones, is great. I think putting no thought into how to present them clearly is not. Documentation does not to my mind excuse poor interface.
IINA is simply great. It's video player that just work. The same experience when I use PotPlayer on Windows.
My experience with VLC never good. Even the modern version. It somehow feels...clunky? Some random error randomly happened. As the matter of fact, I just download the latest version and test it about 5 minutes ago on my iMac, open some video, and BAM, some weird glitch happened on my screen (like graphic card error) It disappear when I quit it though.
Yet everyone, every tech author always recommended it. Maybe I'm just unlucky? :/
I have yet to find a single player in recent years that does not "just work".
If I want to have advanced settings for various things (mainly a/v decoders), I would choose carefully, but to "just work" I would say almost all actively developed media players can do that fine.
I don't know about Win10, but the default Win7 media player is still a steaming pile of poo. Can't play many formats, stupid and uncustomizable keyboard shortcuts, occasionally decides to display some videos as audio+visualization instead, insists on trying to default you to the worst possible settings after every update.
I'd say so, I've not used anything other than VLC for the last 5+ years on Linux and Windows and don't remember that it failed to play anything, even the stuff customers threw at us.
>" VLC is just too full of incidental complication."
That surprise me, how is VLC complicated?
I use it all the time and it just works.
My only problems:
-For some reason sometimes it hangs in Fedora and I have to kill the process manually.
-I wish that the progress bar allow more control of when to jump. Frequently, in a video, I don't understand what somebody just said but, when I try to go back, I finish jumping back too much.
VLC has very short, short, medium, and long jumps. Go to the preferences to set your own hotkeys to whatever works (I have [ and ] for very short jumps, it's perfect for the use case you describe, when you just want to hear a phrase again).
(Note that apparently you need to restart VLC for the changes to take effect.)
Been using IINA on Mac for a while too. It's simple and stays out of your way. Just plays the video/file I want it to play and has sane keyboard shortcuts to skip ahead/back. No faffing around with playlists.
> User interfaces need random access to the playlist items, so a vector is the most natural structure to store the items. A vector is provided by the standard library of many languages (vector in C++, Vec in Rust, ArrayList in Java…). But here, we’re in C, so there is nothing.
I so do not miss working with C.
Having higher level abstractions and a working, useful standard library is just too nice.
This sounds interesting. I personally would be more interested though if it would introduce some concept of an infinite queue, because that is usually the way I listen to music. I want to be able to select some music and to queue that, but when that finished, it should continue playing, with related/similar songs, or maybe according to some other rules/genre or so.
Many other music players have this. Also e.g. Spotify. Or iTunes DJ mode. Amarok had this. Sometimes it was called PartyShuffle.
I like the separation of the playlist/queue and the UI. But if it is an infinite queue, it is not possible to get a full copy of it. Only maybe to the finite preselected upcoming queue. But maybe that is not much of a problem then. The core infinite logic usually is implemented like: If the queue of songs contains less than N next songs, select some more songs from some database, according to some probability distribution.
I was actually quite happy with it, but it took too much time to really polish, to make it cross platform, etc. Now I mostly use Spotify, which gets close to what I wanted to implement in the first place. And they are working to improve the intelligent infinite queue, or generate playlists automatically in other ways.
So, now that there is some work by VLC on the playlist, I was wondering, how easy is it to extend that? E.g. maybe some Python interface, so I could maybe plugin some neural network, and add new songs to it when it runs out of songs. That would be really nice.
Related to that, what is the current state in VLC about other music player related features, like e.g. gapless playback?
Is there some API to be able to script VLC? E.g. that I can develop a plugin/module or external app/script, where I have a DB, and maybe a GUI (maybe web interface) for the DB as well.
For the API, I would need:
* Some way to get the current playlist.
* Some way to get which item in the playlist is currently being played.
* Some way to add items to the end of the playlist.
Also, maybe in addition:
* Some way to mark that the logic about playlist handling (adding to it, shuffling, etc) is handled by this external module (such that VLC does not do shuffling as well).
The logic of this external module is pretty simple then for the infinite queue: When the currently played item reaches almost the end of the playlist, it would add some more songs to it. For this logic, it would maybe also nice to remove some of the earlier played songs (otherwise the playlist would just grow and grow).
> Some way to mark that the logic about playlist handling (adding to it, shuffling, etc) is handled by this external module (such that VLC does not do shuffling as well)
Yes, VLC also should not provide that (such a music DB) (I think).
But when it provides some API, a plugin/module, or even another external app could provide that logic, i.e. the music DB itself, also the UI to search in the DB, and then also the logic to add something from this DB to the VLC playlist. It would be nice if there is an API such that VLC can be extended to make that possible. But yes, I definitely think that it should be a separate and optional module/plugin/app/script.
> Thus, the playlist may not be bound to the event loop of some specific user interface. Moreover, the playlist may be modified from a player thread; for example, playing a zip archive will replace the item by its content automatically.
As you probably figured out, this is quite hard to do correctly :) I have a similar design in some software I've written, but sadly I get a number of crashes that tell me that I've haven't done it quite right…
I dumped VLC due to the simple reason that when a video is paused, it will stop the computer from going to sleep. The developer thinks this behavior is OK and refused to fix it so I just found a nicer and minimalist player called https://mpv.io/
Last time I downloaded VLC on Windows, an ad on the download page started download for "VLC Torrent Streamer" or something equally confusing. I never launched that EXE but started wondering what kind of crapware I would have gotten if I had.
When I look at the download page now, there are no ads (disclaimer: I use an ad-blocker and I use noscript). Furthermore, VLC is available from the Microsoft Store, so that you don't have to fetch untrusted executables anyway.
Here is what the official Videolan download page looks like on Windows Chrome without adblocker: https://imgur.com/a/ZWZdtk5
The VLC download is started in the background, but the "Download Now" buttons are highly misleading. This time it's Avast rather than "VLC Torrent Streamer".
Videolan should be ashamed using dark patterns to trick people into installing adware.
I just got the same ad they're talking about[1] -- you need to go to the Windows download page (as in, click download) and have your adblocker disabled.
I've used VLC since around 2001. I always thought of VLC as a powerful media player that you could throw any format at and it'd just play (including subtitle formats, colouring, etc). Not to mention the powerful filtering and network options.
I've also been blocking ads since the same time and I would have never seen this ad. It definitely cheapens the brand and strips away some of the "warm fuzzy" feeling I get when I think "VLC".
I used VLC for many years without issue, but eventually it became unstable on my system and then wouldn't even launch, even after a fresh re-install. So to share something with others who may be looking for an alternative, MPC-BE with madVR and LAV audio decoder is amazing. I had some issues with MPC-BE out of the box: video tearing and muffled dialog during movies. madVR improves video rendering performance and LAV audio improves audio decoding.
You see it as a video viewer but plenty of people use it as a general media (including music) player. If you’ve got 100 songs queued up, then keeping track of a playlist is definitely necessary.
You're being sarcastic, but there's a grain of truth in your argument against tabs. It does feel like the kind of thing the OS should provide for any app.
I agree that it's an overrated feature, but there's plenty of use cases. Eg you want to play an evening of cool videos in a loop on a projector somewhere, your kids are allow to watch exactly two Paw Patrol episodes, etc.
I use it to stream an IPTV playlist. With VLC 3 large playlist of channels would never load correctly or would take a lot of time. The recent nightlies have been much much better and content loads pretty much instantaneously.
TBH I now mostly use desktop VLC for my mp3 library. The various remote interfaces are awesome for controlling playback from a smartphone. Therefore VLC is at least to me an audio player.
The VLC Android App is unusable since an update earlier this year. Any plans to fix that? I reverted to an older version and would like to come aboard again once the bugs are fixed & bad UI decisions corrected. There was plenty of feedback on the playstore to act on and there was at least one bug fix release, but current reviews are still negative :/
Just downloaded the nightly build...it's horrible.
I hope there is a way to reverse everything to how it is at the moment.
There is a point in software where the UI reaches it's optimum. It is at that point with VLC atm. I never had any issues with the playlist. The playlist is not a especially relevant part in the whole thing. I drag files/folder in there and it does what it does.
Please don't overdo it...
I'd rather see the render to chromecast issues fixed. Can't pause with VLC or the video stops after a few seconds resuming and I need to start over.
> I never had any issues with the playlist. The playlist is not a especially relevant part in the whole thing.
The playlist rewrite I detail in this blogpost is an internal technical refactor, so you're absolutely right, it's not a relevant thing for the users.
It is independant of the UI. In theory, it could have been used with the old UI, but technically a big part of the old UI code would have needed to be rewritten to use the new core playlist.
Since a new modern UI is being developed, this was not worth the effort to do the work twice. So only the new UI will use the new playlist/player.
> Just downloaded the nightly build...it's horrible. I hope there is a way to reverse everything to how it is at the moment.
The master branch is a development branch. Everything has been merged recently to avoid that everyone work on their own branch and resolve conflicts all the time, and the new components need to interact (playlist, player, clock, media library, qt ui…). But it's in development, it's not a release.
12 years ago I wrote a blog post being annoyed that when using Xine in "random shuffle" mode - pressing "previous track" did not replay the previous track.
If VLC can now do that properly, which I think is what I took from your blog post, that's a huge change which makes me very happy, and would make me switch back.
while we're nagging about problems with vlc, one thing I desperately need is some trivial way to have files in the playlist labeled by filename instead of metadata.
It seems unintuitive and often if files are missing metadata you can't sort the playlist or tell what's what.
The version of my favourite anime series I have on my machine unfortunately has a mistake where every single episode has the same incorrect title metadata.
It never had it. It had, and probably still has, the reputation of being the best video player on Windows - it was bullshit-free, and the only one that worked OOTB with whatever you threw at it, without making you install these things called "codecs".
I use VLC from at least 2006 (perhaps earlier, i remember the old icon) and i never remember hearing that "meme". Perhaps it was in some closed circle you were or something, but i remember VLC always having a top-notch reputation with mplayer being the only that could contest it in terms of codec support.
It was never the worst, and is among the best. It rose to prominence back in the days of codec packs, media player classic, and the numerous configuration headaches. VLC always just worked with pretty much any file, even a youtube url. It was also one of the first to handle container formats like mkv/matroska.
These days I would say MPV is a better player for simplicity and performance but I still keep VLC as the workhorse.
I want to like MPV, but whenever I try it VLC seems to handle playback problems like corrupted sections in files or performance problems more smoothly.
VLC is great: it's cross platform and handles basically anything you can throw at it, and works well in a pinch. And I say this as someone who works on another video player.
I'm using VLC since the codec pack times and it always did what it was supposed to do. Never had any relevant issues with that. I only knew it as THE go to program if you didn't want to bother with codecs anymore. I've never heard about this "meme" before.
It was notorious for crash bugs and poor implementations of "advanced" format features. A major fansub group got fed up of complaints to the point where they put out an episode that deliberately triggered bugs in VLC's ASS rendering to make their subtitles unreadable on VLC (I think this was gg with code geass episode... 16? 17?). That particular problem was solved when VLC abandoned their subtitle rendering code and switched to using mplayer's libass, but for a long time there were similar concerns about support for other formats (e.g. rendering 10-bit video correctly).
GG were the most trollish about it (since I figured you'd want a specific documented incident to refer to), but it was a widespread and general opinion among anime video encoders (and to the best of my knowledge any video encoders who were pushing the boundaries at the time shared the same views, though I'm less familiar with the non-anime communities).
No, that's just one documented instance. VLC being bad was a meme outside the anime community, too. It affected anyone trying to utilise modern features for video playback.
Heh, I remember talking to Hocevar (one of the original authors) about how bad VLC had become and he told me that he knew and that he wasn't involved anymore.
It certainly is the worst audio player, clipping like no tomorrow. No plugins, audio level at 100% or below. I know it must clip if levels are above 100%, but in this case it must be just a decoder bug.
I'll try to search for the clipping files. It's been some time, and I don't remember exactly what it was. They did play perfectly in other players.
I do remember the offending song had a deep sine wave bass. The issue sounded like non-saturated clipping, integer overflow.
It drove me crazy, because at first I suspected my bluetooth headphones, etc. I tried to reset VLC completely, reinstall, tried to reduce levels below 100%. But nothing helped.
Edit: Couldn't find the files for now. I'll make sure to send them to you once I find them.
To this day, it's the one program I can recommend to friends and family to install, regardless of OS/platform, that I will be confident can handle anything they throw at it. You guys do great work.