http://trac.webkit.org/changeset/217185 added an extra call to MediaSourcePrivate::waitForSeekCompleted() on MediaSource::seekToTime() that our MediaPlayerPrivateGStreamerMSE (the final receiver) isn't expecting. This is completely breaking the seek behaviour because, unlike MediaPlayerPrivateMediaSourceAVFObjC, the GStreamer MSE player private doesn't have an internal seek state to distinguish the original call from the new one.
Created attachment 322931 [details] Patch
Sorry about that! But keep in mind, there are some WebGL conformance tests that require that the <video> element has a decoded frame available as soon as the "seeked" event fires. The point of the second "waitForSeekCompleted()" was to give the private an opportunity to delay completion of a seek until it's had a chance to decode the frame at the seeded time. So you may want to look into adding that kind of behavior to the GStreamer back-end.
Thanks for pointing it out. However, by now our priority should be to put MSE in GStreamer on a better shape (lots of w3c tests failing, webm support, still some seek corner cases). Then we can focus on proper interoperation with other parts of webkit (WebGL, as you mention).
Comment on attachment 322931 [details] Patch Clearing flags on attachment: 322931 Committed r222966: <http://trac.webkit.org/changeset/222966>
All reviewed patches have been landed. Closing bug.
<rdar://problem/34851779>