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

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=87575





--- Comment #3 from Philippe Normand <pnormand at igalia.com>  2012-05-28 10:29:15 PST ---
(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");

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.