Bug 87575 – [GStreamer] http/tests/media/video-buffered-range-contains-currentTime.html is failing

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Zan Dobersek]

http/tests/media/video-buffered-range-contains-currentTime.html is failing since it has been introduced in r118577.
http://trac.webkit.org/changeset/118577/

Failures occur on all the Gtk builders, the diff looking like this:
--- /home/slave/webkitgtk/gtk-linux-64-debug/build/layout-test-results/http/tests/media/video-buffered-range-contains-currentTime-expected.txt 
+++ /home/slave/webkitgtk/gtk-linux-64-debug/build/layout-test-results/http/tests/media/video-buffered-range-contains-currentTime-actual.txt 
@@ -1,7 +1,6 @@
+FAIL: Timed out waiting for notifyDone to be called
 Test that the painted buffered range contains currentTime.
 
 EVENT(loadedmetadata)
 EVENT(seeked)
-EVENT(ended)
-END OF TEST

[Chris Dumez]

The test also fails on EFL port with the same diff.

[Ami Fischman]

What the test does is:
- video.load()
- onloadedmetadata: seek to 0.5s short of the end of the video
- onseeked: start video.play()
- onended: finish the test

The diff posted shows 'seeked' is fired (so video.play() is called) but it times out before 'ended' is fired.  Some possibilities for why this can happen are:
1) The ports never fire 'ended'.  I'd expect that to break lots of media tests but glancing through efl/Skipped I see lots of media tests skipped.  Can someone who knows the port confirm that ended *is* fired for some (green) test that relies on it?
2) Seeking takes too long, eating most of the timeout interval for the overall test, so playing another 0.5s of video times out.  This can happen if there are no keyframes/index in the media format chosen for the port or if the ports' media engines can't take advantage of fast seeking in the media.  If this is the case the test should pass reliably when run with a longer timeout.

Can someone who knows one or both of these ports try these out?

[Philippe Normand]

(In reply to comment #2)
> What the test does is:
> - video.load()
> - onloadedmetadata: seek to 0.5s short of the end of the video
> - onseeked: start video.play()
> - onended: finish the test
> 
> The diff posted shows 'seeked' is fired (so video.play() is called) but it times out before 'ended' is fired.  Some possibilities for why this can happen are:
> 1) The ports never fire 'ended'.  I'd expect that to break lots of media tests but glancing through efl/Skipped I see lots of media tests skipped.  Can someone who knows the port confirm that ended *is* fired for some (green) test that relies on it?

GTK and EFL both use the same MediaPlayerPrivateGStreamer engine. Not sure about EFL but GTK passes a fair amount of media tests :)
And yes the 'ended' event is fired, though there might issues in some cases.

> 2) Seeking takes too long, eating most of the timeout interval for the overall test, so playing another 0.5s of video times out.  This can happen if there are no keyframes/index in the media format chosen for the port or if the ports' media engines can't take advantage of fast seeking in the media.  If this is the case the test should pass reliably when run with a longer timeout.
> 
> Can someone who knows one or both of these ports try these out?

Well in our case I guess the test.wav file is used. Is there any reason why the test loads an audio file BTW?

var mediaFile = findMediaFile("audio", "../../../media/content/test");

[Ami Fischman]

(In reply to comment #3)
> Well in our case I guess the test.wav file is used. Is there any reason why the test loads an audio file BTW?

Yes.  For the test to be effective in testing the new functionality introduced in its CL it must be able to set up the condition that the buffered range containing currentTime is not a singleton range starting from 0 and extending past the currentTime.  It's quite fiddly to set that up that condition with video media because by the time metadata is considered loaded quite a lot of the video data is buffered as well (because of how the videos are encoded, and because the video duration must be quite small to keep file size in svn down).
With audio, on the other hand, metadataloaded is fired quite early, while most of the file is not yet buffered, and it's much easier to trigger the condition that separate ranges are reported buffered.

[Chris Dumez]

In this particular case, the "ended" event is not fired because the EOS detection fails. In HTMLMediaElement::mediaPlayerTimeChanged), it detects EOS by doing the following comparison: "currentTime() >= duration()". Unfortunately, due to some precision problem, this check fails for us.

My proposal is to tweak MediaPlayerPrivateGStreamer::currentTime() so that it returns duration() if m_isEndReached is true and if m_playbackRate > 1.
There is already such tweak for playbackRate < 0 so I'm merely extending it.

[Chris Dumez]

Created attachment 147062 [details]
Patch

[Chris Dumez]

Comment on attachment 147062 [details]
Patch

Clearing flags for now as this seems to cause some other tests to fail.

[Chris Dumez]

Created attachment 147068 [details]
Patch

Synchronize the position and the duration in MediaPlayerPrivateGStreamer::didEnd() instead. This no longers causes any regressions.

[Philippe Normand]

Comment on attachment 147068 [details]
Patch

Merci Christophe!

[WebKit Review Bot]

Comment on attachment 147068 [details]
Patch

Clearing flags on attachment: 147068

Committed r120082: <http://trac.webkit.org/changeset/120082>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.