3 ms·

Mozilla could just use the host platform's codecs like Safari (Quicktime) and IE (DirectShow), or use a cross-platform abstraction like Opera (GStreamer), or sh

by blasdel 16y ago

Mozilla could just use the host platform's codecs like Safari (Quicktime) and IE (DirectShow), or use a cross-platform abstraction like Opera (GStreamer), or ship an easily-replaced dynamic library like Chrome (libavcodec), but of course they probably won't. They'll stick with their jackass NIH attitude and continue to link directly with liboggplay and libwebm.

jrockway 16y ago
They'll stick with their NIH attitude and continue to link directly with liboggplay and libwebm. Jackasses. You're the jackass for not implementing this. Open Source is not a bureaucracy where you do whatever your boss tells you to do. You do stuff because you want to. The current set of Firefox developers doesn't want to support H.264. You do. You both have the same source code and the same number of hours in a day. So add it yourself. If people want to, they will use your version instead of Firefox. Remember Netscape? Neither do I...
- blasdel 16y ago
  I actually did start working on this about a year ago — and realized that I didn't actually have to write any code! A Mozilla developer had already written a gstreamer backend for use in Fennec, because the original implementation couldn't play Theora in real time on any of the Maemo devices. Of course, there was a Mozilla lead in the main bugzilla thread shooting down any suggestions that it be used in Firefox. So it comes down purely to the maintenance burden — but the codebase was organized so that I'd need hostile forks of Gecko, XULRunner, and Firefox. No thanks. Shortly afterward Chrome was usable on Linux, and I no longer had an itch to scratch.
  - doublec 16y ago
    I was the original author of the GStreamer patch. It wasn't developed for Fennec - it was originally developed as a backend for the Firefox desktop browser. I wrote about it here when I first developed it: http://www.bluishcoder.co.nz/2008/04/firefox-html5-video-with-gstreamer.html http://www.bluishcoder.co.nz/2008/04/firefox-html5-video-wit... Once it was decided to not use GStreamer for the desktop we continued with the work on the Ogg backend and the patch bitrotted. It was subsequently picked up by another Mozilla developer for Fennec work. The patch is currently waiting on review (by me) and as I understand it it will be landed but disabled at compile time for third parties to enable if they want it. I'm not involved in that decision or whether it would be in desktop Firefox however. An H.264 specific backend wouldn't be too hard to do. It should only be a few days work to get a ffmpeg backend going for H.264 support. I had a partial one implemented that I used for testing although it has bitrot quite a bit now. Your point about having to maintain a fork still stands however as there's no pluggable API for backends.
doublec 16y ago
This doesn't affect your point at all, but just so you know, Firefox 4 doesn't use liboggplay nor anything called libwebm.
- blasdel 16y ago
  Awesome, they must have cleaned up their act when they implemented WebM. Do you know what it uses now? (I'm on my iPhone now)
  - doublec 16y ago
    Use of liboggplay has been dropped in favour of implementing Ogg support directly using just libogg, libvorbis and libtheora. The WebM support is implementing using libvpx (Google's VP8 reference decoder library), libnestegg (a WebM container library), and libvorbis. They're all still builtin however so this doesn't do anything to change your NIH assertion.
ZeroGravitas 16y ago
You realize that Mozilla didn't invent Vorbis, Theora, Ogg, WebM or VP8 but rather adopted them because they fitted their mission of creating an open web. On the level of code they've used multiple 3rd party libraries on various platforms and at various times. Which makes accusations of NIH syndrome rather bizarre. Notably they shifted focus to WebM even after they'd implemented Theora since it fulfilled the requirements better. I see no reason why they wouldn't do the same for H.264 if it was licenced in the standard W3C manner. Why make up fake reasons for them to not adopt it when they're very clear it's a licencing issue.

by blasdel 16y ago

jrockway 16y ago

They'll stick with their NIH attitude and continue to link directly with liboggplay and libwebm. Jackasses. You're the jackass for not implementing this. Open Source is not a bureaucracy where you do whatever your boss tells you to do. You do stuff because you want to. The current set of Firefox developers doesn't want to support H.264. You do. You both have the same source code and the same number of hours in a day. So add it yourself. If people want to, they will use your version instead of Firefox. Remember Netscape? Neither do I...

blasdel 16y ago
I actually did start working on this about a year ago — and realized that I didn't actually have to write any code! A Mozilla developer had already written a gstreamer backend for use in Fennec, because the original implementation couldn't play Theora in real time on any of the Maemo devices. Of course, there was a Mozilla lead in the main bugzilla thread shooting down any suggestions that it be used in Firefox. So it comes down purely to the maintenance burden — but the codebase was organized so that I'd need hostile forks of Gecko, XULRunner, and Firefox. No thanks. Shortly afterward Chrome was usable on Linux, and I no longer had an itch to scratch.
- doublec 16y ago
  I was the original author of the GStreamer patch. It wasn't developed for Fennec - it was originally developed as a backend for the Firefox desktop browser. I wrote about it here when I first developed it: http://www.bluishcoder.co.nz/2008/04/firefox-html5-video-with-gstreamer.html http://www.bluishcoder.co.nz/2008/04/firefox-html5-video-wit... Once it was decided to not use GStreamer for the desktop we continued with the work on the Ogg backend and the patch bitrotted. It was subsequently picked up by another Mozilla developer for Fennec work. The patch is currently waiting on review (by me) and as I understand it it will be landed but disabled at compile time for third parties to enable if they want it. I'm not involved in that decision or whether it would be in desktop Firefox however. An H.264 specific backend wouldn't be too hard to do. It should only be a few days work to get a ffmpeg backend going for H.264 support. I had a partial one implemented that I used for testing although it has bitrot quite a bit now. Your point about having to maintain a fork still stands however as there's no pluggable API for backends.

doublec 16y ago

This doesn't affect your point at all, but just so you know, Firefox 4 doesn't use liboggplay nor anything called libwebm.

blasdel 16y ago
Awesome, they must have cleaned up their act when they implemented WebM. Do you know what it uses now? (I'm on my iPhone now)
- doublec 16y ago
  Use of liboggplay has been dropped in favour of implementing Ogg support directly using just libogg, libvorbis and libtheora. The WebM support is implementing using libvpx (Google's VP8 reference decoder library), libnestegg (a WebM container library), and libvorbis. They're all still builtin however so this doesn't do anything to change your NIH assertion.

ZeroGravitas 16y ago

You realize that Mozilla didn't invent Vorbis, Theora, Ogg, WebM or VP8 but rather adopted them because they fitted their mission of creating an open web. On the level of code they've used multiple 3rd party libraries on various platforms and at various times. Which makes accusations of NIH syndrome rather bizarre. Notably they shifted focus to WebM even after they'd implemented Theora since it fulfilled the requirements better. I see no reason why they wouldn't do the same for H.264 if it was licenced in the standard W3C manner. Why make up fake reasons for them to not adopt it when they're very clear it's a licencing issue.