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 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!
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?