(In reply to Ralph Giles (:rillian) from comment #87)
- Open a new bug specifically for it, rather than arguing either way in this
bug.
- Provide a factual argument why this is important.
- Provide a patch implementing the new feature.
Starting a thread on mozilla.dev.media would be good too,
Comment on attachment 727111
gst codec whitelist
Punting to Chris Pearce since he seems to be following what behaviour
should be here.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1051559
Title:
(In reply to Alessandro Decina from comment #46)
In addition to that, we could potentially consider importing the
ogg/webm/h264 gst plugins in m-c so there's even more control over those.
If this means we'd be shipping an H.264 decoder, we can't do that.
--
You received this bug notification
(In reply to Markus Popp from comment #33)
Any chance to make testing for early adapters easier? Maybe compile with
--enable-gstreamer by default, but hide behind a pref? Are there any test
builds, maybe on try-builds?
The problem is library compatibility amongst different GStreamer
versions
Comment on attachment 611716
New patch addressing 1st review comments + misc fixes. See comment #263.
Review of attachment 611716:
-
Looks good, just minor comments. r+ with those, and the configure change
you mentioned to address
(In reply to Alessandro Decina from comment #264)
Created attachment 611716
New patch addressing 1st review comments + misc fixes. See comment #263.
I get an error when trying to play a video/mp4 with this patch applied:
GLib-GObject-WARNING **:
Comment on attachment 605705
nsBuiltinDecoder* based implementation
Review of attachment 605705:
-
To build on linux the patch needs some gstreamer header files added to
config/system-headers:
diff --git a/config/system-headers
(In reply to Connor Behan from comment #238)
If the patch is still
not ready, please give Oleg a list of ATTAINABLE GOALS explaining how it
needs to be improved. Since months have gone by without this being posted, I
can only assume that the developers with commit access are either ignoring
Bug 714408 adds support for a media plugin framework for HTML video.
Whilst it is b2g specific at the moment it'd be interesting to refactor
the gstreamer support into that framework so that it'd provide dynamic
loading of gstreamer support if it was available.
This would also involve refactoring
(In reply to comment #229)
Would it be reasonable to add GStreamer support as a non-default compile time
option for desktop FF releases?
This is what I hope will be the result of this bug. GStreamer support
available as a compile time option, turned off by default.
--
You received this bug
Comment on attachment 465180
finding supported gstreamer codec/demuxer plugins
+if (nsnull == supportedCodecs) {
+#ifdef MOZ_GSTREAMER
+ NS_ConvertUTF16toUTF8 CodecTypeUTF8(token);
+ if (!IsGstSupportedType(CodecTypeUTF8.get()))
+return CANPLAY_NO;
+#endif
+} else {
+
Comment on attachment 462048
gstreamer changes alone in single patch
+# The Initial Developer of the Original Code is the Mozilla Corporation.
+# Portions created by the Initial Developer are Copyright (C) 2007
Initial developer should be Mozilla Foundation and update copyright to
2010. This
Note that the part of the original request saying that the YouTube HTML
5 beta doesn't work is no longer correct. Trunk builds of Firefox
support the WebM format which is supported by YouTube. They are in the
process of transcoding their videos to YouTube. You should be able to
play many YouTube
Referring to comment 290, the original video code for Firefox was
actually Ogg support via the low level Ogg libraries. GStreamer support
was implemented later (by me - I'm the original author of the GStreamer
Firefox patch). We then moved back using other, higher level Ogg
libraries (liboggplay,
14 matches
Mail list logo
