GNOME Bugzilla – Bug 705703
qtdemux: seeks to large offset/EOS when attempting to start playback from http source
Last modified: 2018-11-03 14:49:24 UTC
The attached MP4 video stream does not play. It appears to get an invalid seek position upon start up (see attached log). It works fine when played as a local file. It fails when served from Apache WebServer using souphttpsrc. To reproduce: gst-launch-1.0 playbin uri=http://192.168.0.106:818/B-04.MP4
Created attachment 251214 [details] Log showing seek event when trying to start playback
Here is a link to video stream: https://www.dropbox.com/s/lu80qythwqv26xf/B-AVC_MP4_MP_SD-04.MP4
Seems to work fine here with latest GIT master via HTTP
I will sync up with GIT master and retest - thanks.
I tried it with the latest gstreamer and it doesn't play for me. I will attach the log with debug=4.
Created attachment 253318 [details] Log file from run where file doesn't playback
We have made some changes to gst-plugins-bad gstmpdparser.c. Do you this could be causing the issue?
I can adjust logging if you need more info.
I got rid of the changes we had made to ext/dash and just ran it. It plays fine as a local file but doesn't play via HTTP on Apache server. I know it works for you so I am attaching two logs - one from local file playback where it works and the other from the apache run. It feels like it must be some kind of timing issue since it works for you and it also works when played back locally as a file. Perhaps you could compare your successful log results to the failed log results and determine what the problem potential might be.
Created attachment 253463 [details] Log file from local file where playback is successful
Created attachment 253464 [details] Log file from run where playback of same file doesn't work from apache server
I didn't test this with dash, only the raw MP4 file as you gave in the original comment above. Does it work for you if you just play the MP4 file and does it fail if you play it via DASH?
I didn't try it with dash either. It just fails to play when streamed from Apache HTTP server.
I can confirm that now, it fails only when using a queue2 in buffering mode right after the http source. For example when playing via playbin. Without that it works. http://people.freedesktop.org/~slomo/B-AVC_MP4_MP_SD-04.MP4 if someone wants to try.
<qtdemux0> pushing from stream 0, offset 56, size 2204, dts=0:00:00.000000000, pts=0:00:00.066666666, <qtdemux0> pushing from stream 0, offset 2260, size 812, dts=0:00:00.033333333, pts=0:00:00.200000000, <qtdemux0> pushing from stream 0, offset 3072, size 142, dts=0:00:00.066666666, pts=0:00:00.133333333, <qtdemux0> pushing from stream 1, offset 193745443, size 140, dts=0:00:00.046439909, pts=0:00:00.04643 <qtdemux0> pushing from stream 1, offset 193745583, size 159, dts=0:00:00.069659863, pts=0:00:00.06965 <qtdemux0> pushing from stream 0, offset 3214, size 130, dts=0:00:00.100000000, pts=0:00:00.100000000, <qtdemux0> pushing from stream 1, offset 193745742, size 190, dts=0:00:00.092879818, pts=0:00:00.09287 <qtdemux0> pushing from stream 0, offset 3344, size 551, dts=0:00:00.133333333, pts=0:00:00.166666666, <qtdemux0> pushing from stream 1, offset 193745932, size 189, dts=0:00:00.116099773, pts=0:00:00.11609 <qtdemux0> pushing from stream 1, offset 193746121, size 187, dts=0:00:00.139319727, pts=0:00:00.13931 So, as you can see from the piece of log above (when playing locally), this file has the audio samples located much ahead than where they should be. In push mode, buffering reaches its maximum capacity before any audio is received and is able to reach the sink. Any suggestions on how to handle those situations? It seems to be common with ASF from what I know. Maybe there is some way to fix both?
That file has an interleave of ... 140MB (actually I don't think you could even call it an interleave, all the audio is after all the video) ! Options: 1) You queue (140MB) until you have the audio. Not great, massive delays. Also your only option if the http server doesn't accept range queries. 2) You constantly seek forward/back. the http source ends up doing plenty of new queries, would be suboptimal. 3) Mitigate 2) somehow by grabbing bigger chunks. i.e. grab at least 5s of audio/video at each go instead of the next 3 buffers as it seems to be doing right now. For that last option, you could try modifying qtdemux (and asfdemux) to detect (in push mode) that massive interleave and change the way in which it pulls from upstream. Doing it this way also has the advantage of leaving enough time for httpsrc+queue2 to buffer a lot more (if there's enough bandwidth maybe it'll be able to grab the equivalent of a minute of data in 5s).
Some notes: * shouldn't be an issue with playbin3 * buffering should happen in queue2 * qtdemux can do all those getranges, that's not an issue What could be an issue is queue2 not buffering enough. Keeping open.
*** Bug 691162 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/89.