187171 2018-06-29 01:31:21 -0700 [GStreamer] mp4 video hosted on http server won't load 2018-08-02 03:29:05 -0700 1 1 1 Unclassified WebKit Platform WebKit Nightly Build Unspecified Unspecified RESOLVED WORKSFORME P2 Normal --- 1 pnormand webkit-unassigned bugs-noreply cturner oldest_to_newest 1437721 0 pnormand 2018-06-29 01:31:21 -0700 https://sbc-qsystem-dev.pathfinder.gov.bc.ca/sbc_new.mp4 See also https://github.com/Igalia/meta-webkit/issues/18 1437793 1 pnormand 2018-06-29 08:30:09 -0700 This seems to be yet another issue with our internal GStreamer httpsrc element. 1445690 2 cturner 2018-07-27 04:20:20 -0700 I had some reports that r228603 "[GStreamer] Push smaller buffers from HTTP source" was causing MP4 files hosted via HTTP to fail loading in a downstream installation. It seemed like it might be related to this. However, that doesn't seem the case here. What I have noticed is that this test works just fine for a number of runs. However, when it finds its way in the web / network cache, an interesting thing starts to happen. I see, 0:00:01.403721513 21 0xaea790 DEBUG webkitwebsrc WebKitWebSourceGStreamer.cpp:503:operator():<source> Started request (NetworkProcess) retrieving https://sbc-qsystem-dev.pathfinder.gov.bc.ca/sbc_new.mp4 priority 2 (NetworkProcess) Retrieval: revalidation already in progress for 'https://sbc-qsystem-dev.pathfinder.gov.bc.ca/sbc_new.mp4': and then, 60 seconds later, (NetworkProcess) Speculative revalidation completed for 'https://sbc-qsystem-dev.pathfinder.gov.bc.ca/sbc_new.mp4': and the file starts playing. If I rm -rf ~/.cache and rerun the test, it doesn't stall for a minute at the start until the resource ends up cached again. If I run with the file hosted on my machine, I don't see such pauses. So it seems something to do with a combination of caching and "speculative revalidation", which I'm unfamiliar with at the moment. Does this match the situation your end Philippe? 1446854 3 pnormand 2018-08-01 03:57:53 -0700 I wasn't the one affected by this issue. The original bug reporter is Gil, see the downstream Github issue mentioned in comment 0. 1447215 4 cturner 2018-08-02 03:29:05 -0700 I can't reproduce this on trunk. https://trac.webkit.org/changeset/234497 may well have helped, but the issue described in the GitHub ticket I can not reproduce. I'm closing this, please reopen if you have more information running with a recent WebKit (r234497 or later would be best).