(In reply to Alessandro Decina from comment #56)
> (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?
Some consumers of the audio content may rely on the duration being
accurate, like web apps using the decoded file via WebAudio or
MediaStreams API for example.
> Do all the backends report exactly that duration or is it just that
> the test written against a specific backend?
Hmm... The Windows Media Foundation backend is reporting a duration of
3.343673 or that file, and content/media/test/manifest.js lists its
duration as 3.29. :{
Anyway, the test that's failing is:
http://mxr.mozilla.org/mozilla-central/source/content/media/test/test_buffered.html?force=1#34
This is checking if video.buffered.end(0)==video.duration
I think you can make this test pass by changing GStreamerReader::GetBuffered()
to cap the range end time to the media duration here:
http://mxr.mozilla.org/mozilla-central/source/content/media/gstreamer/GStreamerReader.cpp#601
I see that GStreamerReader::GetBuffered() is using
gst_element_query_convert()... Does gst_element_query_convert() just do
a byteoffset/length*duration estimation, or is it using some deeper
understanding of the stream in order to get more accurate byte-to-
timestamp mappings?
If gst_element_query_convert() is just doing an estimation, you could
just use GetEstimatedBufferedTimeRanges() [http://mxr.mozilla.org
/mozilla-central/source/content/media/VideoUtils.h#142] instead, it's
used in other backends already to estimate the buffered ranges, and caps
the end time of the buffered ranges to the duration.
> > 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?
Yep.
> Yes 3gpp was copied there from the list of codecs supported by GONK i think.
> I'll remove it.
Great, thanks!
> > 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 [details] [diff] does this, although i'm not sure the
> behaviour is 100% right.
Thanks! I will test this patch's behaviour.
--
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
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
