4 ms·

> There is a lot more than just codecs and formats in a media player. :D As you are the VLC lead, I understand where you are coming from. Nevertheless, depend

> There is a lot more than just codecs and formats in a media player. :D 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).

jbk 10y ago
> 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. 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...
- gajjanag 10y ago
  > The glue is quite large. 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/ 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.

jbk 10y ago

> 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. 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...

gajjanag 10y ago
> The glue is quite large. 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/ 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.