I built latest trunk on my Fedora box this morning with --enable- gstreamer, and I still get the following test failure in content/media/test/test_buffered.html:
TEST-UNEXPECTED-FAIL| unknown test url | owl.mp3: First range end should be media end - got 3.368, expected 3.3698 (In reply to Henri Sivonen (:hsivonen) from comment #5) > (In reply to Chris Double (:doublec) from comment #3) > > I think we should enable GStreamer in Linux builds even if we don't support > > H.264 in the other platforms yet. > > > > Things to be resolved before we can do this though: > > > > 1) Get the mochitest media tests passing. There's a H.264 video file in the > > tests already. Almost there. > > 2) Ensure Firefox still runs on Linux distributions that don't have > > GStreamer or have older versions. I haven't done this. > > 3) Check that we have new enough GStreamer libraries on build machines. We don't have any GStreamer libs on our build machines. We should get our regression tests running, even if we're not shipping builds with GStreamer enabled ourselves. > 4) Check that when MP4, H.264 and AAC support is present, canPlayType() > behaves as in other H.264 and AAC-supporting browsers. See bug 760140. This is tested by our mochitest content/media/test/test_can_play_type_mpeg.html I checked and this test is passing, so we're reporting that we can at least all the things that we should. > 5) Test that when both H.264 and AAC decoders are absent, canPlayType() > behaves like in Firefox today even if an MP4 demuxer is present. I tested this, I removed by gstreamer plugins and test_can_play_type_mpeg.html fails across the board. > 6) Test that MPEG4 Visual, MPEG2 or other non-H.264, non-AAC encumbered > codecs do not get exposed to the Web as a side effect. I'm not sure that this is the case. I see that 3gpp is listed in GStreamerFormatHelper::mCodecs, we don't want that being exposed in canPlayType or for it to be playable. It's also doesn't look like the GStreamer backend is whitelisting only the codecs that we want to support though. We'd want to only support H264, AAC and MP3, so as to prevent further format proliferation. For example this video plays with GStreamer, but shouldn't: http://www.tools4movies.com/dvd_catalyst_profile_samples/Harold%20Kumar%203%20Christmas%20bionic%20fast.mp4 The video stream here is "MPEG-4 part 2". No other browsers play that file; we can but refuse to in the Windows Media Foudation backend (bug 839055). And we should also refuse to play the file if either the audio or video stream are present but of unsupported formats as well... Does our GStreamer backend already do this? -- 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: Build Firefox with GStreamer support To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1051559/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
