flowplayer

Open full view…

HTML5 Video File Not Found

Joel Cochran
Thu, 24 Apr 2014 18:04:32 GMT

Relevant data: 1) This is HTML5 player, Commercial 5.4.6. 2) We use Viddler as our video host. The way Viddler works, we link the Source(s) to viddler URLs. Those URLs provide Redirects to the actual Video files. 3) The original URLs return as Content Type "text/plain". 4) In Chrome and FireFox, the redirected video links show immediately as Status 206, Type video/webm. 5) In IE11, the redirected video link shows as "Pending" until the entire video has loaded. The problem: 1) We occasionally get reports of "HTML5 Video File Not Found" on desktop FireFox and IE (though I've personally never been able to replicate it). 2) Our users in India are reporting that while they can watch the videos on Desktops, they always get this message on Android tablets and Phones, as well as Windows Phone. I don't have any further specifics than that. Ideas: Could the initial "text/plain" response (before the redirect) be causing some kind of false failure? Here is a link you can test: http://www.wintellectnow.com/Videos/Watch/authoring-jquery-plugins

Joel Cochran
Thu, 24 Apr 2014 18:05:12 GMT

Oh, and I can't seem to get posts in the correct categories.

bbbo
Thu, 24 Apr 2014 18:40:19 GMT

hmm, cannot reproduce so far... but yes an intially wrong content-type might cause problems; and indeed you cannot open the video source links like http://www.viddler.com/file/d/855af2ea.webm?vfid=718b0c5a4326d2de65bcad038f669f9e directly in any browser. Which means they are not html5 compliant. Some browsers might tolerate, but iOS for example is very picky about redirects.

Joel Cochran
Thu, 24 Apr 2014 18:45:59 GMT

Yes, I never have any luck reproducing it either, which is very frustrating. We have tested the site on iPads and it seems to work correctly. The video does download though when you click the link.

bbbo
Fri, 25 Apr 2014 05:39:02 GMT

yeah, but you cannot play it directly in a browser tab (which is equivalent to putting the source into a plain <video> tag

Joel Cochran
Fri, 25 Apr 2014 13:20:53 GMT

I have a feature requirement to be able to start a video at a specific position (where the user last left off). To accomplish this, I have the following code: .bind("resume", function (e, api) { if (api.conf.initialPosition) { api.seek(api.conf.initialPosition, function (e, api) { api.conf.initialPosition = undefined; }); } (from http://www.wintellectnow.com/assets/flowplayer/wn_videoplayer.js if you want to see all of it) Since this is in the resume function, it shouldn't run until after the video starts to load. Can you think of any reason this might cause the problem?

bbbo
Fri, 25 Apr 2014 15:48:05 GMT

I don't think this is the reason. I tested again with various VMs and Android devices, could not reproduce once. Speculation: perhaps some of the users are behind some sort of forced proxy which impacts the redirect or the timing, so the browser get's confused. Perhaps set up the video example with a aplain <video> tag and check if the problems shows there too.

Joel Cochran
Fri, 25 Apr 2014 15:59:52 GMT

I'm testing something else right now: I'm intercepting the Redirect on the Server and sending the actual URL to the client. This should bypass the redirect issue altogether. Also, since it's our India users that are having the most issues, this will reduce their roundtrips and help with any potential latency issues that could be the cause.

Joel Cochran
Wed, 30 Apr 2014 16:53:55 GMT

Still having numerous reports of problems, and not just from India. The issue finally happened to me: in Chrome 34.0.1847.116 (current version), I opened a video and received the error. I immediately refreshed the screen and this time the same video played no problem. I tried it on another machine (same browser) and received the error three times in a row on https://www.wintellectnow.com/Videos/Watch/operating-system-support-and-debugger-concepts. Refreshing did not help. I went to https://www.wintellectnow.com/Videos/Watch/performance-counters and had no issues, it played the first time. My co-worker tried a dozen or so videos, and only one of them worked for her in Chrome (same version). Refreshing did not help. I tried all the same videos, and they all worked for me. She tried it on IE11 and they all worked first time. She then tried FireFox with no issues. She then went back to Chrome and it worked for several videos, then all of a sudden it stopped working again. A customer reported the same experience with the videos not playing in Chrome but working in IE11. At this point the issue feels completely random, not to mention extraordinarily frustrating. I don't know if it is a problem with the player or the video service (I'm inclined towards the video service) but ANY input you could provide would be most welcome.

FRCC
Wed, 30 Apr 2014 17:08:02 GMT

That's a similar problem I had. Like your case, our users in china had html5 video not found error mostly the first they tried to watch the videos. Second time (refresh) it worked. I'm using AWS so I think the issue happens when the source hasn't been pushed to the edge location. I don't know. I can't reproduce the error most of the time. It's frustrating, and it gives me the idea that the html5 video is so not stable. I had to change back to flash. data-engine="flash" will always work. On mobile it'll just fallback to html5. That's my solution for now. Looking for better ideas.

Joel Cochran
Wed, 30 Apr 2014 20:54:13 GMT

I noticed that I had preload set to "auto". I set it to "none" and published to our Staging server. Please feel free to test any of the "Free" videos in this list: https://b55a19c61d2049d592027d448bf9f6bf.cloudapp.net/Videos/Index

FRCC
Thu, 01 May 2014 18:42:03 GMT

I tried setting preload to "none" but still no avail.

bbbo
Fri, 02 May 2014 19:07:43 GMT

you are still using preload="auto" in the last link (works for me though in every device). Use a splash setup (not poster) and enable preload none and see if that helps.

bonsak
Wed, 22 Jun 2016 07:51:14 GMT

I get this behaviour in Chrome 51 with flowplayer on the dl page of our ftp server. Heres the link: http://www.raserbil.no/_zOqeZ897szkuuR Preload is set to false and splash is set to true. I know this is not necessarily a flowplayer problem but any tips or help is appreciated.

bbbo
Wed, 22 Jun 2016 10:06:20 GMT

you're using the wrong content-type (it _must_ be video/mp4 , not application/octet-stream ) and using delivery as an attachment. you _must_ use normal byte-range requests without such content-disposition headers for html5 video, otherwise at least seeking will break, among other things.

bonsak
Wed, 22 Jun 2016 10:55:26 GMT

Thanks. I'll check with the guys who make the ftp server were using if we can set this up better. The weird thing is that it works in fine in fine in both Safari and IE.

bbbo
Wed, 22 Jun 2016 11:08:59 GMT

doesn't load at all for me in IE9.... Did you try this with a long clip? With the attachment content-disposition, seeking to unbuffered positions usually does not work in IE and Safari...

bonsak
Wed, 22 Jun 2016 11:22:39 GMT

We usually don't serve files longer than a couple of minutes so i wouldn't know how longer files behave. I've tried a couple of our 1-2 min videos and seeking works fine in Safari. Its a little sluggish in IE but it works there as well.

bonsak
Wed, 22 Jun 2016 14:32:12 GMT

Ive managed to modify the server to return the correct type but the problem is still there in Chrome. This link will return the correct file: http://www.raserbil.no/_R2x2oi-2Zz-uvR It seems that this is not so much a Flowplayer problem as it is a Chrome problem.

bbbo
Wed, 22 Jun 2016 17:22:10 GMT

test it in a plain <video> tag please. if the problem persists, there is nothing we or you could do.

bonsak
Wed, 22 Jun 2016 19:15:14 GMT

No difference, but thanks for all the kind help.