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.
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.
VLC is amazing, I love the work you guys are doing and heartily recommend it to my friends and family as well!
This and I have donated money as well. VLC is one of the apps I install shortly after getting a new box. Being cross platform is a great boon.
> 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 !
Fisher-Yates was one of the first algorithms my CS course exposed me to; nicknamed the knuth shuffle, not 100% why but it is in TAOCP.
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!
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?
[0] https://observablehq.com/@jobleonard/shuffle-vectors
[1] https://arxiv.org/abs/1902.04738
Shuffling a vector at once is "trivial": https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle#T...
I am not sure to understand what to look in the first link, nor the connection with the second link.
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
Ah ok, thank you for the details!
In that case, indeed there is some overlap (when removing an item, the randomizer only swaps 2 items in the "non-ordered" part).
Spotify has a nice blog post about shuffling music. Not the exact same thing, but interesting nonetheless.
https://labs.spotify.com/2014/02/28/how-to-shuffle-songs/
Interesting, I didn't know about the tetris randomizers!
https://simon.lc/the-history-of-tetris-randomizers
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.
Wonder how PCG compares then[0].
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.
[0] http://www.pcg-random.org/
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.
The main issue would be naively using mod to obtain a number in range of (0-n].
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.)
TBH, I think this is acceptable for a playlist random order, even if it's not perfectly evenly distributed.
Incidentally, my loud opinions about guideline Tetris aside, this actually helps me understand this a lot better.
> But here, we’re in C, so there is nothing
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 mean, I'm sure your `vlc_vector` you've spent so much time optimizing and securing
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…
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?
[1]: https://www.youtube.com/watch?v=YTy_JOxGOd4
Personally, I'd love to :)
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.
[1] https://www.youtube.com/watch?v=YTy_JOxGOd4&t=875
> interface with other languages…
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.
> why C is a good thing and not a liability these days?
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.
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 ?
Definitely, we are aware of this stupid behavior, it will be fixed (at the latest) in 4.0.
I just proposed a patch to fix the problem on VLC 3: https://mailman.videolan.org/pipermail/vlc-devel/2019-May/12...
(proposed != merged)
And actually Thomas already implemented it in VLC 4: https://code.videolan.org/videolan/vlc/blob/f93fef718c3c61e2...
\o/
(we discussed about it, I didn't remember he already did it)
What if I have two items on the playlist that both fails, is it going to remember 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.
Merged: http://git.videolan.org/gitweb.cgi/vlc/vlc-3.0.git/?p=vlc/vl...
So it's fixed in the next release (VLC 3.0.7).
Merci Romain pour tout ce taf :)
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.
Mac OS only? VLC works on Windows/UWP/Phone, Linux, macOS, iOS, Android, Chrome OS, Apple TV, and those are only the officially supported platforms.
IINA is a (macOS only) UI for the mpv (which is crossplatform).
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.
VLC has a plugin called VLsub which works almost perfectly as subtitle downloader.
And it is inside VLC by default.
And yes this plugin is awesome.
smplayer which is a front-end to mplayer (or mpv?) has a great subtitle finder/downloder - I have used it with great success for years now.
Oh wow thank you for that referral this looks -amazing- and I have exactly the same use case as you.
Complication is not a world a would use to describe any vlc experience.
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.
Apart of that it works wonderfully.
> -For some reason sometimes it hangs in Fedora and I have to kill the process manually.
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.
>-I wish that the progress bar allow more control of when to jump.
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.
https://wiki.videolan.org/QtHotkeys/
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.
VLC stays out of your way too. You don't need to faff with playlists at all if you don't want to.
IINA has playlist support, FWIW.
> 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 was the one that got me:
> model.get(4); // out-of-range, undefined behavior (probably segfault)
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 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?
IMO, an infinite queue does not really apply to VLC.
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/
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).
> Is there some API to be able to script VLC?
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.
> I personally would be more interested though if it would introduce some concept of an infinite queue
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.
> but when that finished, it should continue playing, with related/similar songs, or maybe according to some other rules/genre or so.
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.
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…
Edit: It's online again.
The website seems to be unreachable right now, here's the archived version: http://web.archive.org/web/20190522045257/https://blog.rom1v...
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/
> when a video is paused, it will stop the computer from going to sleep
This seems to be fixed:
- https://trac.videolan.org/vlc/ticket/3724
- https://trac.videolan.org/vlc/ticket/19463
- https://trac.videolan.org/vlc/ticket/20092
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.
I thought VLC was better than scams like that.
That sounds more like you downloaded it from some top google result site like download.com, cnet or some other sketchy site
Did you get it from https://www.videolan.org/ ?
I just got the exact same ad by disabling my adblocker and going to the Windows download page. Here's a screenshot[1].
[1]: https://imgur.com/a/2M2ns6i
Got the exact same ad after disabling my ad-blocker and refreshing once.
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.
Jeez, it's easy to forget how unusable the web is without an adblocker nowadays.
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.
[1]: https://imgur.com/a/2M2ns6i
The windows store version is a bit different than the one you an download from the website though.
> I thought VLC was better than scams like that.
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?
Hi, first of all I love VLC, but I have to say that if an ad is being served on my website, I would absolutely consider myself responsible for it.
(Or maybe I misunderstood, and this is an ad on some other page such as google search results.)
If it's displaying on your site, and cheapening your brand, it's your responsibility to fix it. You allowed the ad to display.
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".
You realize that you cannot filter all ads from AdSense, right? We already spend > 2 hours per day to clean them.
mpv.io
VLC continues to be riddled with crashes in the menus, because of a bug in how they use A List, that is almost 10 years old.
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.
> VLC continues to be riddled with crashes in the menus, because of a bug in how they use A List, that is almost 10 years old.
Could you be more specific, please? Which menu, in which circumstances?
I'd have to install it again to reproduce it, but I believe there are several menus that don't expect certain things to be empty.
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.
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.
Why does a video viewer need a "playlist"? Isn't that feature already accomplished by the file open dialog?
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.
Why does an HTML viewer need history and tabs? Aren't these features already accomplished by the xterm window the user must be invoking it from?
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.
On an inferior system, absolutely. On Windows, I run it either from an icon click or the Run dialog. No terminal invocation is needed.
You are right. Browsers are even worse in that respect!
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.
Classes with 4-6 minute videos.
What about sequential playing without user interaction?
What about persistent arbitrary play ordering?
Any solution to this would just be implementing a playlist.
> What about sequential playing without user interaction?
> What about persistent arbitrary play ordering?dropbox is just a remote folder which I can sync with rsync, right?
> 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.
> cvlc `ls | shuf`
gives you a different sequence every time
Okay, I have assumed "persistent" being a loop. The loop is being randomized but it is fixed once arguments are passed to cvlc.
why would you want to see a movie twice on the same binge?
VLC is useful as an audio player as well.
because they are watching music videos...
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.
Binge watching TV shows is a habit not to be overlooked.
Same reason it needs an integrated email client.
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 :/
Unusable in what way? It's still working just fine for me.
It can't play some videos properly for me but otherwise, it works for me too.
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.
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.
I'm glad that supporting "previous" in random mode will not be useless, then :)
Thank you for your work.
> Just downloaded the nightly build...it's horrible.
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.
Thank you.
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.
This will be changed in VLC 4.0. You will be able to sort the media library and the playlist by filename.
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.
Notice that you can still use "cvlc" that has a very elegant interface (i.e., zero pixels).
Did VLC ever lose it's reputation of being the worst video player of all time?
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".
VLC being the worst thing ever was a meme back in 2007. Everyone saying that he used it got flamed into oblivion.
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.
The Internet is a big place, we were probably hanging out in different circles cause I never heard that.
Indeed. In my circles around that time we were all switching to VLC.
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.
Uhm did it ever have it?
Yes, VLC being the worst was a meme back in 2007. To the point where people got involved in the project, just to fix it from being so bad.
Where was that a meme?
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).
So it was actually a specific group that had a specific problem with it and it wasn't a wide spread and general opinion. Well...
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.
4chan
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.
Can you share the files where you see that?
VLC 4.0 will get gapless audio and a different audio management, that will improve the quality.
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.
No. Right now it's on the verge of being the worst audio player too. Takes forever to seek in a 2h+ audiofile.
Mp4 files? What format? What OS?
I made a short video: https://streamable.com/96v6n
this is the audiofile: https://meta.metaebene.me/media/mm/fs235-sechzehn-bar-blonde...
I will look at that, thanks.
This is fixed for VLC 4.0 then.
In the nightly build? Was it a new bug or old one?
Yes, the nightly build.
mp3, m4a, doesn't really matter. Win32
Edit: Ubuntu and VLC 3.0.4 has the same problem.