I recently used this amazing little utility: http://slydiman.me/eng/mmedia/recover_mp4.htm

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.

Have a look at it, you may find it helps you out.

I don't currently have access to the drives it is stored on, but I'll give it a go next time I do. Thanks for the suggestion.

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.

I have quite a few files VLC doesn't play that MPlayer does. I use VLC as my main viewer but I get a file that doesn't work I try MPlayer.

Please share them with us :)

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.

[0]: http://i38.tinypic.com/34gkavn.jpg [1]: http://i.imgur.com/RWIAe.jpg

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 was going to say: an example that's fairly reproducible, any video recorded with Open Broadcaster Software (OBS) is playable in WMP but not VLC.

However, I just tried it is fixed already, I love VLC.

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.

But that obviously doesn't solve the actual problem.

Codec not supported: VLC could not decode the format "CFHD" (No description for this codec)

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.

(Guy who Reverse Engineered CFHD here) If you could upload a sample of your file somewhere that would be appreciated.

you might be able to reindex or remux this file (save to a new file in the process) to fix it, by the way.

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.