4 ms·

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 star

by jbk 10y ago

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

astrange 10y ago
I think you could run ffmpeg through emscripten… slowly. Should be fine for SD and retro video though! Would be really surprised to see threading working. Would be REALLY surprised to see SIMD working.
gajjanag 10y ago
> 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.
supercoder 10y ago
Yes but isn't FFMpeg where the real value is ? VLC itself is a bit of a mess, the UI is clunky and and isn't a great media player experience. Would seem like the best of both worlds to use the web for UI but have FFMpeg deliver the frames.
- mdip 10y ago
  I tend to agree with you on this, personally. I can't speak to the code quality or whether or not VLC is a mess (I've never really looked) but I think the point here is the ability to play back (almost) any video/audio/subtitle format around which is met by both VLC and FFMPEG quite well. Being able to do that in a browser, without plug-ins, in a performant manner is important from an archival perspective (broadest audience support for the broadest array of file kinds/types). 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.
- jbk 10y ago
  > Yes but isn't FFMpeg where the real value is ? 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.
indexerror 10y ago
This has already been done. https://github.com/muaz-khan/Ffmpeg.js/ https://github.com/muaz-khan/Ffmpeg.js/

by jbk 10y ago

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

astrange 10y ago

I think you could run ffmpeg through emscripten… slowly. Should be fine for SD and retro video though! Would be really surprised to see threading working. Would be REALLY surprised to see SIMD working.

gajjanag 10y ago

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

supercoder 10y ago

Yes but isn't FFMpeg where the real value is ? VLC itself is a bit of a mess, the UI is clunky and and isn't a great media player experience. Would seem like the best of both worlds to use the web for UI but have FFMpeg deliver the frames.

mdip 10y ago
I tend to agree with you on this, personally. I can't speak to the code quality or whether or not VLC is a mess (I've never really looked) but I think the point here is the ability to play back (almost) any video/audio/subtitle format around which is met by both VLC and FFMPEG quite well. Being able to do that in a browser, without plug-ins, in a performant manner is important from an archival perspective (broadest audience support for the broadest array of file kinds/types). 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.
jbk 10y ago
> Yes but isn't FFMpeg where the real value is ? 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.

indexerror 10y ago

This has already been done. https://github.com/muaz-khan/Ffmpeg.js/ https://github.com/muaz-khan/Ffmpeg.js/