Comment 70 for bug 1051559

(In reply to Chris Pearce (:cpearce) from comment #54)
> 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

I will look into this, but isn't the resolution we're checking a bit too high? Do all the backends report exactly that duration or is it just that the test written against a specific backend?

> (In reply to Henri Sivonen (:hsivonen) from comment #5)
> > (In reply to Chris Double (:doublec) from comment #3)
>
> > 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.

Is it failing in the expected way?

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

Yes 3gpp was copied there from the list of codecs supported by GONK i think. I'll remove it.

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

Attachment #72711 does this, although i'm not sure the behaviour is 100% right.