Slashdot Mirror
VLC Reaches 2.1
An anonymous reader writes "With a new audio core, hardware decoding and encoding, port to mobile platforms, preparation for Ultra-HD video and a special care to support more formats, 2.1 is a major upgrade for VLC. The popular video player app also features support for 4K video as well as a partial Windows 8 and WinRT port for all those folks out there who don't know what else to do with their Surface RT."
I installed it last night and really the only thing I can say about it so far is that it seems to work the same as I'm used to. That is high praise for a new release with many new features, I think. We'll see what happens when I try to play more exotic files with multiple languages and subtitles, but so far so good.
What is really exciting to me is the claimed support for mobile platforms. That kind of support for video is something I've really missed on Android.
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
I would assume not all features are up and running in the port.
I hear this a lot-- VLC sucks, uses bad codecs, supposedly looks worse than XYZ player, etc. But every time I actually try to use MPC-HC, I find that the ability to Seek within a video file is lacking. It either takes a long time to Seek, or it doesn't go exactly to the place I wanted it to. VLC seeks perfectly every time, no matter what video codec/container format I am viewing. And I _never_ have to install any 3rd party codec packs. To me, that's way more important than a minor difference in quality that I have never noticed (or taken the time to _try_ to notice). Then again, I like to download 720p instead of 1080p because the files are smaller, so quality is obviously not 1st priority. I'll keep using VLC, thanks!
You can take it with you on a thumbdrive, don't need to install it, it works perfectly.
It supports virtually all codecs (I remember some problems with old .RM files in the early days, but they were obsolete even before then).
It's a compiled .exe that has some interchangeable DLL's that sit in the same folder and can be swapped without waiting for a new binary release.
It's nice, lightweight, very nice features, very configurable, free AND has all the client/server stuff too.
Personally, SMPlayer (and MPlayer's) early history on Linux was horrible - there was no one GUI that was nice enough on it (I can remember a dozen "XPlayer" where X was just the GUI someone slapped onto MPlayer, and you often had to download the win32 codecs separately - the codec situation was a bit of a faff at times, and I managed to crash it quite a lot).
By comparison, the VLC I use and install every day on hundreds of computers to be the default DVD and media player? I never really witness it crash. It plays everything I throw at it (including obscure CCTV formats). It's tiny and will even run from a network share. And it works the same on Linux, Windows and everything else.
You can say a lot of the same for both MPlayer and VLC - the question really is which one you preferred when you first used it (and when that was), so it's hardly a surprise that some don't like one or the other.
Show me a commercial media player with better support for video formats than VLC.
And that's the other major problem with OSS
Seriously, the "waaaa it broke!!11one!" type of bug reports are equally useless for both closed and open software. Not only that, in neither model do they get fixed.
In both models, the developers complain about the stupidity of getting such bug reports---the internet is full of whinging developers of closed software complaining about users.
The *only* difference is that the OSS mailing lists are public so you get to see the whinging.
SJW n. One who posts facts.
VLC is a fantastic free program, but the attitude some/one of their devs have towards it's users is disheartening for the project as a whole.
A friend recorded a video with her phone, and held it so the video was taken in "portrait mode" vs. "landscape mode". On a PC I was surprised when VLC was unable to correctly orient itself as I was use to my Mac's native application always orienting properly.
I spent the time looking for solutions on their forum and the devs responses is nothing short of arrogant:
https://trac.videolan.org/vlc/ticket/7766
Essentially users are told this is not a bug in VLC because the videos use a non-standard way of marking the video as rotated. Further they go on to say if a user wants to look at it, as it was shot, they need to manually tweak the rotation on the transform for playback. After a 7 step menu navigation process, this has the side effect of having to change the transform back for the next video you wish to play if it was shot in landscape mode. Essentially this has to be done on a video-by-video basis.
I'm hoping there are some Open Source projects that actually implement this correctly, but from the few I've tried so far, they all seem to have the same bug as VLC when it comes orientation. Standard or not, ignoring this rotation bit is rendering the program as crippled for 100,000's of people shooting videos this way. Coincidentally, I haven't found a commercial program that is subject to the bug, everyone I've tried (e.g., Quicktime, Adobe Premier, etc...) renders it properly.
I can always hope that, eventually, someone on the team will see the value in implementing this fix.
As I state time and time and time again to my clients:
If I can't reproduce it, I probably can't do anything to fix it.
- Show me the computer that does it.
- Show me the actions that make it happen (it doesn't have to be PERFECTLY reproducible, just enough that I stand half-a-chance of going through the debug logs. / debugger and finding out WHAT crashed / went wrong).
- Show it happening, right now, in front of me, somehow.
If it's really that prevalent a problem, it's hard to imagine that the above isn't trivially possible. If it's hard to trigger or obscure and requires very particular inputs (e.g. a single example of a particular corrupt file or similar), then a) it's probably not a massive world-wide issue, b) how do you expect anyone to fix it without being in that same situation themselves?
Open/closed source makes NO difference. It's simple debugging. When my network "breaks" and "doesn't work", I need to be able to see it do it. Without seeing it, I can only stab in the dark at potential fixes unless you're describing a problem I know very well already. Without seeing it, I can't even tell if it's not just your computer that's broke and not the network (or application, or website, or whatever).
The amount of "fixes" I see every day just by being in the room with the people who constantly report "major problems" that impact that work every day and stop them working, which resolve themselves by the sheer presence of me standing in the room watching them try to make it happen again is unbelievable. In some cases, I'm sure there is a problem that will trigger eventually and I'll see it and stand a chance of fixing it. But for 99.9% of those problems, we get to that stage because people are ADAMANT that something is broken that I am responsible for and when they come to demonstrate it in front of my superiors to try to explain why they've got NO work done, they are completely unable to. For days on end. With a dozen people around their computers constantly trying to break it deliberately.
The problem evaporates under inspection because - actually - it's usually not a problem at all, or they are doing something they shouldn't (and know full well, so don't reproduce that in their demonstrations), or our offer to replace/rebuild the crappy old machine they insist on using that's the only trigger for the problem is denied because of personal attachment to that broken, crashing, corrupt setup.
If you cannot reproduce a bug, even 1% of the time, in front of someone who has an idea how to debug it then - closed source or not - it's almost impossible to fix. And the more stab-in-the-dark fixes we try, the more frustrated you will be that they don't work.
Demonstrate it. Capture it on video. Provide debug logs. It's not hard on a general-purpose machine capable of running VLC to get such things (on smartphones, etc., it's infinitely more difficult). File a bug. Then we can look at say "Hey, it looks like X is crashing, I wonder why?" or "Can I have a copy of that media file? Oh look, byte X is corrupt... we'll have to handle that case but I suggest you redownload it." or even "God, I don't know! Can we get some other people to try to reproduce this so we can fix it?".
I'm not saying your problem will be fixed. But it stands a better chance that no doing your end of the debug work on the ONLY machine that is exhibiting this problem and interfering with your use of the program (where there are millions of other happy users).
It's not a fob-off. It's not about open-source. It's simple - if you think something is broke, you can't just say "It's broke". You have to give a clue about what's broke or - in the worst case - show us it breaking.
You wouldn't do that to a photocopier engineer. Or a mechanic. Or a doctor. You wouldn't say "It doesn't work" and then not show them what's wrong, or give them the thing to let them play with it and try to reproduce it. What makes you think a software engineer is able to magically and remotely diagnose a problem they can't even see or reproduce?
The problem with VLC is endemic of a lot of open-source code. It's basically where the programmer is king and everyone else is a peon. Great if you're a developer, but it fails in that a modern non-trivial program needs much more than just a programmer (and that the project lead on most open source is a programmer doesn't help). Hell, programmers and engineers generally are the WORST people you want to develop certain aspects of your application - notably stuff related to UI, UX and documentation.
The issue is that open-source generally "ranks" people in terms of LoC submitted (or commits, or whatever). Designers, technical writers and other stuff don't usually generate things considered "valuable" to the developer - how many times have you heard this refrain - "you have the source, there's your documentation".
And the UI and UX is very important these days but also heavily discounted because they generally make life difficult because implementing a widget here instead of there seems like a pointless exercise. Especially when they want to re-do how things work (see all the pushback to how Apple decided to reinvent how people used computers by doing auto-save (and even allowing versioning and "going back In time" to see how a document looked at a prior point, even allowing one to manipulate a previous save).
That said, VLC's UI is generally sufficient (especially compared to many other media players), though it could use a bit of tweaking (like disassociating the mousewheel from the volume control - Allowing one to reduce the range of the volume control (or peg it at 100% so you don't accidentally set it to 117% or having to live with it at 98 or 105% because you can't get it back to 100%).
Sorry, I don't buy this, because VLC implements plenty of patented stuff - besides all the MPEG formats (heavily patented) and image formats (most of which are patented), and audio formats (also patented).
If you created a player that was trying to avoid patented stuff, you'd be left with a player that does Vorbis, Theora, WebM and a few other formats. And be of little use because the formats people really use (h.264 currently, DivX/MPEG-4 ASP before) are all heavily patented.
Of course, there's some things where it's understandable - like DVD and Blu-Ray playback where the copy protection on both generally interferes with straight playback as they should. VLC does not have much in the way of fixing issues related to copy protection - being that it's a full time job. (See how much an AnyDVD license is and that you have to subscribe because it changes so much).
I don't know why VLC developers hate frame-by-frame.
They don't.
If I want to read something on a piece of paper in a video let's say, I can't just advance one frame at a time.
You can. Try pressing "E"...
You can activate "play and exit" in the playlist settings, which does exactly what you want.
Alternatively, putting "vlc://quit" as the last item in a playlist will also quit VLC after it is done playing.