In the ten or so years I've used it, I've only come across one file that VLC wouldn't play (excluded DRMed files) - a (possibly malformed) 24hr long MP4 I recorded a few years ago. Pretty much everything chokes on it (VLC crashes straight away), though oddly enough Windows Media Player handles it fine until you try to seek to a different time.
I've dabbled with other media players/codecs in the past, but usually end up back at VLC not long after due to its versatility. Impressive stuff.
It helped me recover some GoPro footage that went corrupt. You feed it a known good video from the same camera/same settings and then it basically uses the structure of the good footage to rebuild the bad footage. It worked a treat after I found a good file for it.
My dad's friend is a lawyer in Boston and I remember he had a big case and needed to review some of the evidence urgently - it was security cam footage. However he had no idea how to play the video file, it was in some obscure format. Nothing but VLC worked. I'm pretty sure he ended up winning the case.
What bothers me are the crashes. A crash probably translates into an arbitrary code execution when a malicious file exploits it.
I've seen files that mplayer won't play that VLC will (though I've seen more of the opposite), but when mplayer can't parse a file it tends to simply not play it rather than crashing. So I'm not going to use VLC on files from the untrusted internet.
Lots of modern anime rips have had corruption issues with VLC in the past[0]. It's actually become a meme in those communities[1]. As x264 and 10bit encodings became ubiquitous, I think VLC's support also became fairly sufficient. However, the anime community is known for being early adopters of new encoding strategies. I believe it would benefit the development of VLC if some developers could check out what those encoders are doing every so often. It seems like they're always a few years ahead of how everyone else is encoding.
One big change was VLC switching to use mplayer's libass rather than their own (buggy, quite likely to the extent of allowing remote code execution) ass parser. These days VLC mostly seems alright, though it'll take a while for it to gain my trust.
I had the same problem, and the fix was quite obvious once you read it: if you have 64bits OBS and 32bits VLC, VLC crashes when you open the video. Use both 64bits or 32 bits software, and you're fine.
This codec was RE'd 2 weeks ago and was merged in FFmpeg and libavcodec this weekend, by a member of the VideoLAN non-profit organization.
Expect it in VLC soon.
I tried that at the time, but all of the tools I tried either crashed or only recognised the audio track (tried ffmpeg, QuickTime in OS X and Windows, Handbrake, VirtualDub, MKVToolnix, and mpegstreamclip plus a few others; mostly ffmpeg-based stuff crashed AFAICT - most of the others either errored out or just listed the audio track).
I ended up recovering most of the footage by re-recording the screen whilst it was playing in Windows Media Player. Not ideal, but it was a low-ish quality capture of a webstream anyway, so any quality loss wasn't particularly important.
In the ten or so years I've used it, I've only come across one file that VLC wouldn't play (excluded DRMed files) - a (possibly malformed) 24hr long MP4 I recorded a few years ago. Pretty much everything chokes on it (VLC crashes straight away), though oddly enough Windows Media Player handles it fine until you try to seek to a different time.
I've dabbled with other media players/codecs in the past, but usually end up back at VLC not long after due to its versatility. Impressive stuff.