There is a lot more than just codecs and formats in a media player. :D
Also, porting ffmpeg might be hard, while VLC has some simpler codecs to port for a start (libmpeg2 for example).
Also, porting ffmpeg might be hard, while VLC has some simpler codecs to port for a start (libmpeg2 for example).
As you are the VLC lead, I understand where you are coming from. Nevertheless, depending on the perspective, a media player can be legitimately viewed as codecs+formats+some glue.
For example, ffplay that is shipped with FFmpeg has < 5k lines of code, and although not as full featured as VLC, definitely serves for basic media playback needs.
Or if that is too extreme, per the Open Hub stats, mpv does media playback with ~ 100k lines of code, once again in < 1/4 of the lines of FFmpeg (even with the hardcoded lookup tables ignored).
The glue is quite large.
> For example, ffplay that is shipped with FFmpeg has < 5k lines of code
I hope you are joking. Look at the performance of ffplay...
Then how is that mpv gets the "glue" work done with significantly fewer lines than VLC, as I pointed out?
> I hope you are joking. Look at the performance of ffplay...
I am obviously not joking here. I used (and still use) ffplay for a large chunk of media playback. The only reason I do not is for the rare hardcoded sub need, which may get at least partially addressed in a future gsoc project. The gsoc idea is on the wiki and has been discussed to some degree on the mailing list, so this is not a mere speculation.
A blanket statement about performance is also obviously false here; it really depends on the codec/config settings. For example, I simply tested with the first link (a 2160p hevc video) at http://4ksamples.com/, to really put all three media players under their paces. This was on my laptop, a Core i7 2.4 GHz Haswell, with Intel graphics on Arch Linux, with default configuration for all of ffplay, mpv, and vlc. Played essentially fine with mpv and ffplay, with minimal stutter. VLC was the only one on which playback actually crashed, with numerous "[hevc @ ...] Could not find ref with POC ..." messsages, stalls, and display artifacts rendering playback useless along the way before the crash at ~ 00:30.
Would be really surprised to see threading working. Would be REALLY surprised to see SIMD working.
Would seem like the best of both worlds to use the web for UI but have FFMpeg deliver the frames.
Unfortunately, the ultimate goal -- taking the control of "what codecs are supported for streaming" away from the browser vendors probably won't be met. The biggest issue there is supporting reliable playback across a variety of processors with performance/battery constraints. For desktop users it might be a doable thing, but unlikely for mobile. Granted, we're doing things on our mobile devices that would have been positively unimaginable 7 years ago, so who knows?
At the end of the day, though, it's codec support that is the big win from my perspective -- lavc/lavf or FFMPEG -- not necessarily getting all of VLC ported.
Not only. Look at the VLC source code to see why.
> VLC itself is a bit of a mess, the UI is clunky and and isn't a great media player experience.
If it's that bad, why so many people use it? Sorry, but your comment is harsh, unexplained and very subjective... Especially coming from someone working for Apple.