Media controls slider is broken in 2.19.90. On http://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_720p_stereo.ogg the slider works fine so long as you do not move it past the buffered portion of the video. But as soon as you move the slider past the buffered portion, the video freezes and cannot ever be restarted. I think the web process is actually hanging here. See also: bug #182653
Created attachment 333560 [details] Backtrace of hung web process Looks like seeks getting issued from the main thread can block the webkit web src from making further progress, which blocks the whole web process. At least I've reproduced the issue. I wonder what happens if we disable the disk cache...
(In reply to Charlie Turner from comment #1) > I wonder what happens if we disable the disk cache... Yes, it's specific the downloadbuffer element, when the queue is instead created by uridecodebin, seeks seem to work ok. I've had a several issues with the disk cache logic in a downstream port as well, thought I'd share it up here as well.
This deadlock happens when seek is called on the main thread, which also has to call back for resource loader (dataReceived, responseReceived) In OGG demuxer during seek, it requests more data to upstream if needed, but between appsrc and ogg demuxer in this case, there's downloadbuffer, which is waiting for upstream's feeding. But at the moment appsrc(webkitwebsrc) can't feed since seek is not finished. Because dataReceived can't be called until seek finishes.
Can we separate the thread for media player from main thread? (I heard that resource loader has to be used in the main thread.) I want to listen opinions for this since I'm not familiar with the webkit multimedia design.
(In reply to Hyunjun Ko from comment #4) > Can we separate the thread for media player from main thread? > (I heard that resource loader has to be used in the main thread.) No with this design. The MediaPlayer has its own thread and almost everything in the MediaPlayerPrivate, which is the one we implement. I don't see how.
The source of the problem here is GStreamer's oggdemux. Seeks are usually done from the main thread and an element should not attempt to pull data therefore from the seeking thread (main thread). Even outside of WebKit where network usually does not require the main thread, this still creates a UI stall until the read is complete: not the best user experience, especially if the file is in a network share or a slow external disk. Other GStreamer elements behave well in this regard, reacting to seeks by updating the segment and having the streaming thread pull the new data by itself. oggdemux is doing wrong in this case: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/639
OK so... RESOLVED -> MOVED?