A new core playlist for VLC 4
blog.rom1v.com
blog.rom1v.com
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.
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 !
Also generating a double (from 2 ints) to be converted to an int is a bad idea. Should be just 'random.nextInt(7)'
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.
I implement it relatively frequently (~once a year) as it is often quicker to write than find an implementation.
Surveying some peers I was very surprised to find they weren't aware of it!
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).
(I personally think naming the algorithm after both is a good compromise)
I am not sure to understand what to look in the first link, nor the connection with the second link.
> 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
In that case, indeed there is some overlap (when removing an item, the randomizer only swaps 2 items in the "non-ordered" part).
there's your problem.
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?
I agree, that's a waste of time I would have preferred to avoid. The lack of a such basic structures is something I really dislike in C.
> Remind me again, why C is a good thing and not a liability these days?
Ubiquity, portability, performance, interface with other languages…
One annoying point is that the core API, used by the modules, can change at any time (the modules are updated along with the API).
If there are Rust bindings for the core API [1], every API change must be reflected in Rust (and in modules written in Rust). This is problematic.
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.
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.
Writing it in C for a marginal performance gain just isn't worth it.
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.
That's the wrong question. The question should be:
"If I rewrite this in a different language, will it be a net-benefit? If so, just how long will it take to reap said benefit?"
The trade-offs add a lot of nuance to that question and make it a harder choice.
(proposed != merged)
Instead, wait some delay before starting the next item, depending on the
number of consecutive errors
What if I have two items on the playlist that both fails, is it going to remember the number of consecutive errors ?
Yes, it will, the counter is reset only on successful playback.
\o/
(we discussed about it, I didn't remember he already did it)
So it's fixed in the next release (VLC 3.0.7).
- 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.
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.
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.
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.
Apart of that it works wonderfully.
Check your hardware acceleration drivers (vaapi, vdpau) and try to disable it in VLC preferences.
> -I wish that the progress bar allow more control of when to jump. I finish jumping back too much.
You can customize the default jump (the one with the arrows) in the preferences.
Shift + Arrow - jump 5 seconds
For cases like yours this is what I use, and usually it gives enough control in the context of a movie.
(Note that apparently you need to restart VLC for the changes to take effect.)
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? :/
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 so do not miss working with C.
Having higher level abstractions and a working, useful standard library is just too nice.
> model.get(4); // out-of-range, undefined behavior (probably segfault)
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 implemented my own music player at some point, where my main focus was around this concept of an infinite queue. (https://github.com/albertz/music-player/blob/master/WhatIsAM... https://news.ycombinator.com/item?id=4771999) One reason was that I wanted to take this concept much further than any existing music player. E.g. even introducing some clever machine learning models to guide the infinite music queue.
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?
How should it do that? VLC is not a music database, it's "just" a player of the media files that you feed to it.
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.
If all songs are correctly tagged (which cannot be assumed in VLC), what Spotify does is interesting: https://labs.spotify.com/2014/02/28/how-to-shuffle-songs/
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).
https://wiki.videolan.org/Documentation:Building_Lua_Playlis...
(I recently changed its implementation to use the new playlist/player [1], but the API was kept unchanged not to break existing scripts)
[1]: https://code.videolan.org/videolan/vlc/commits/3b46a2c42c5c1...
> 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)
Not supported.
So basically binge mode, and what online services use to maximise “engagement” and feed you into a never-ending procrastination loop.
I realize people are different, but this is something I really don’t want in my local software.
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…
The website seems to be unreachable right now, here's the archived version: http://web.archive.org/web/20190522045257/https://blog.rom1v...
This seems to be fixed:
- https://trac.videolan.org/vlc/ticket/3724
I thought VLC was better than scams like that.
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.
This is the ads from Google or some other ads providers. We don't control this.
The VLC Torrent Streamer, though, should be just the VLC/bittorent plugin, no?
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".
The only way I can make sense of it, is that they must build VLC against a modified Qt distribution, or something they just never update.
I've totally switched to SMPlayer and MPV.
Could you be more specific, please? Which menu, in which circumstances?
I think one triggers when selecting "Open Capture Device".
There is a closed bug report for this, that was closed I think as unable to reproduce. Years old.
I'll see if I can get back to exactly what it was.
What about persistent arbitrary play ordering?
Any solution to this would just be implementing a playlist.
cvlc *
cvlc `ls | sort -R`Results in a same sequence once the loop completes. You should use `cvlc -Z` instead; I also happen to use `mplayer -shuffle` for this exact purpose.
gives you a different sequence every time
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.
It seems unintuitive and often if files are missing metadata you can't sort the playlist or tell what's what.
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.
https://blog.steve.fi/it_eats_the_pain.html
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.
The nightly build is not really usable yet, because it's in the middle of the transition to the new UI in qml.
It will get fixed before the release.
Edit: Ubuntu and VLC 3.0.4 has the same problem.
this is the audiofile: https://meta.metaebene.me/media/mm/fs235-sechzehn-bar-blonde...
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.
VLC 4.0 will get gapless audio and a different audio management, that will improve the quality.
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.
These days I would say MPV is a better player for simplicity and performance but I still keep VLC as the workhorse.