Trouble getting HTML5 vidio to play, in Firefox 33 - html

I'm preparing to update some old pages to HTML5, and was surprised to see that it worked in Chrome, but not the latest Firefox (v.33.1... also tried v.32). What is odd is this... In Firefox it actually WILL play IF you "coax it". If you move the video position slider to someplace beyond the start (about 5 seconds in) and THEN click play, all is well. Further inspection showed that when I click play, the file pointer was jumping to the end of the file leaving my "poster" photo intact, leading the viewer to think there is nothing else they can do. If, however, you manually move the pointer back to anyplace beyond the first couple of seconds of the file (really!), and THEN click the PLAY button, FF will play the rest of the video fine.
Sometimes i think that to the more technically minded among us, the universe doles out the weirder problems, while God laughs.
I'd suspect video file corruption, but all my conversions were made with the very reliable ffmpeg utility, and tested with VLC. Again, it works fine from Chrome, which supposedly uses the same video format. Here's a link...
FF will play the older type ogv files, so if this is one of those things where FF, now at version 33 is at fault, I'll have to detect the browser and write the order myself with a document.write(). But it would be nice to know if there is a more straigh forward solution.
Note that I have tried adding the mime types to my HTACESS file. But the fact that the behavior is the same when point my browsers directly the file on my local machine, makles me doubt that is the problem.
http://pixyland.org/peterpan/OurWedding2a.html
And here is the page code
<!DOCTYPE html >
<html>
<head>
<title>Our Fairy Wonderful Wedding Day... The Arrival!!
</title>
<link rel="shortcut icon" href="/pixyland.ico" >
</head>
<body marginwidth="10" leftmargin="10" rightmargin="10" bgcolor="#33cc99" link="#333399" >
<table align="center" border="1"><tr><td align="center">
<div id='vtLocation' align="center">
<video width="640" height ="480" controls poster="Imagezz/Wedding/arIMG_2280.JPG">
<source src ="../vids/Arrival.mp4" type="video/mp4"> <!--cSafari / iOS -->
<source src ="../vids/Arrival.webm" type="video/webm"> <!-- Firefox / Opera / Chrome -->
<source src ="../vids/Arrival.ogv" type="video/ogg" > <!-- older Firefox / Opera / Chrome -->
<!-- download as last resort -->
<p>If you are unable to view the video, here are some links to download <br>
in a a few well supported video formats. You may be able to just download <br>
and play one of these files without the browser.<br><br>
<strong>Download Video:</strong>nbsp;
nbsp;"MP4"
nbsp;"WEBM"
nbsp;"Ogg"
</p>
</video>
</div>
</table>
</body>
</html>

Found this suggestion that may be worth trying
fmpeg -i input.webm -codec copy -avoid_negative_ts 1 output.webm
https://stackoverflow.com/a/19639848/1686036
It seemed to help me, although it could be something else "unusual" with FF

Related

HTML5 video tag not working in IE when tested from localhost (XAMP /Apache)

Just as the title says. I've been working on a site and had added a big html video for the main page.
I looked over online...myme types checked, h264 encoding checked. I looked over old versions of the file i've been working on and noticed an old pure HTML file which loaded the video in all browsers with no problem (which I guess discards any encoding or video quality issues)
It all was working neat. Even displaying in firefox, chrome an IE. BUT for some reason the video does not load in IE whenever the file extension for the page it's on is .PHP. To be precise, whenever i try it from my LOCALHOST (XAMP with Apache server)
I also checked the dev tools and under network it does show it as the right content type and no error whatsoever (getting normal 200 result)
Here's the snippet of the video tag used:
<div id="video_container">
<video autoplay loop poster="video.jpg" id="header_vid">
<source src="imagenes/video.mp4" type="video/mp4">
</video>
LOL, and just noticed...not even the poster image is showing in IE...wtf.
I'm so confused, could anyone enlighten me a bit please? Could it be something related to the path used? been digging around the net for days _
Check if your url is formed properly when you are using .php extension on IE. Same issue addressed quite a few time here.
mp4 from PHP - Not playing in HTML5 Video tag ||
Play mp4 file through php in HTML5 Video Tag in Chrome?
I notice IE doesn't like the properties without value, so try
<video autoplay="" loop="" poster="video.jpg" id="header_vid">

html5 audio tag mp3 playback issues on FF and IE

I recently realized that some mp3 files causes the "seeker" slider of an HTML5 audio control to fail on Firefox and Explorer.
Specifically, I can move the slider to the desired position, but the sound jumps to an incorrect time. Therefore, when the slider comes to the end, the song is already playing, and the current time keeps incrementing.
In addition, the track length (it's supposed to be a fixed value, loaded from the metadata) has a strange behavior given that point: it starts incrementing as the current time...
I found no differences between the files that work correctly and the files that don't (Not even in the codecs), but I suspect is a browser support related issue, since I didn't experience that problem using Chrome.
Just in case, you can download the file here:
http://www.4shared.com/mp3/JzSPjx3Qba/Quartet_12_Mov_1.html
And this is the test code I'm using:
<html>
<head>
<title>Test Page</title>
</head>
<body>
<audio controls="controls" id="player">
<source src="Beethoven - String Quartets/Quartet 12 Mov 1.mp3">
</audio>
</body>
</html>
Thanks!

VideoJS won't load video in Chrome

The system I am working on is set up like this:
Files (in DB) <-> ContentServer <-> Webpage
Say I have a link to a video, and someone clicks that link, the contentserver finds the requested file, generates a Guid to represent that file, and then builds a page which uses the Guid for the "file". This Guid does not have a file extension (naturally).
When using VideoJS in IE and Firefox, this appears to work just fine. However in Chrome it's not working at all. The video doesn't appear to even be loading, much less loading and playing. Below is an example of how I have it set up. Anyone have any ideas how I could make this work on Chrome?
<html>
<head>
<link href="/Video/video-js.css" rel="stylesheet" type="text/css">
<script src="/Video/video.js"></script>
</head>
<body>
<video id="video" class="video-js vjs-default-skin" controls preload="auto" width="640" height="264">
<source type="video/mp4" src="/content/7cb55f87-b240-45e0-9890-ec383fd019c9"/>
</video>
</body>
</html>
It appears the problem lies in Apple products and Google Chrome not playing nicely with ASP.Net. Chrome and Apple products first send a request for the first two bytes of content. If they don't receive these two bytes - they fail. ASP.Net does not have the capabilities to handle byte-range requests, regardless of whether or not the server it is on can. So, if you are using ASP.Net and you intend on using video, you should account for the fact that you will have to roll your own byte range request handler, or use one of a very few third party extensions that are out there.

IE9 not displaying mp4 video?

IE9 is driving me CRAZY with it's support for HTML5 video, as far as I understand it, it supports the H.264 codec, so any files with a .mp4 extension on the end.
The problem is, it's not playing video files with a .mp4 extension . . .
It's even more unusual in that if I test it locally, IE9 will play the mp4 video, it just doesn't play it on the server, this is also nothing to do with MIME types, I added the following MIME type to the server:
.mp4 - video.mp4
And in the network panel in the IE developer tools, it's listing it's type as "video/mp4" the only unusual thing is that the Network panel shows IE is requesting it 3 times (I have no idea why this could be)
I'm at the end of my tether, so much so that I actually wrote the code below to try and fix it (I would really hate to use this on a live site, it's horrible):
<!--[if !IE 9]><!-->
<video controls="controls">
<!--<![endif]-->
<!-- This is a horrible way to do this, but I cannot figure out for the life of me why IE9 won't play this video :( -->
<!--[if !IE 9]><!-->
<source src="video.ogv" type='video/ogg; codecs="theora, vorbis"'/>
<source src="video.mp4" type="video/mp4">
<!--<![endif]-->
<!-- If HTML5 video is not supported, the following Flash video will play -->
<p>flash video stuff is here</p>
<!--[if !IE 9]><!-->
</video>
<!--<![endif]-->
This fixes it by forcing IE9 to use the flash video for browsers that don't support HTML video (instead of doing this by default IE9 just seems to display a blank box, no error message, no anything). Unfortunately this solution is so horrible I'm almost ashamed to have written it.
Does anybody know what could be causing this? Or how I can fix it?
EDIT: Not sure if this is of any significance, but I used http://www.freemake.com/free_video_converter/ to convert the files to the correct formats
I'm running into the same problem. IE9 would play the video when you run the HTML file locally, but the thing stops working when you put it on the server. The problem must have something to do with the video file. You'd think that it can't be, given that it works locally. But that appears to be case. When I downloaded the sample video file at the VideoJS web site (http://vjs.zencdn.net/v/oceans.mp4) and put it into my own setup, IE9 plays it back just fine. So IE9 is somehow more picky when it plays a remote file.
I'll update this answer when I figure out what magic parameters are needed to make IE9 happy.
UPDATE: Okay, I think I figured it out. I spent some time comparing the MP4 file that works with the one that doesn't work. In the former, the random-access index ("stss" atom) is located near the beginning of the file. In the latter, it is located at the end of the file. Both locations are legal, but apparently IE9 is too stupid to look for it at the end of the file when it's downloading the file from the web.
The solution is to move the random-access index to the beginning of the MP4 file, using a tool that comes with ffmpeg: qt-faststart.
Note: I tried another tool: QTIndexSwapper. It seems to leave the file corrupted.
I still have absolutely no idea what was causing this, I spent hours digging and digging and in the end asked someone else to try in their version of IE9, for some reason it worked on their computer and not mine.
I'm not entirely sure why, I'm just putting it down to my version of IE9 being broken in some way (which is frustrating considering how much time I spent trying to sort this out!)
There is a answer on stackoverflow.
Maybe this is useful for you:
HTML5 - mp4 video does not play in IE9
I hope this helps...

Audio not loading in HTML's audio tag

I'm testing the audio HTML tag.
And it is working on my testing env, but for some reason not on my production env.
I simply use: <audio src="/sandbox/test.mp3" controls="controls"></audio>.
The testing site is on Windows and the production site is on Linux, but that should make any difference I think.
I can download the track so I know it is in the right place.
The production url is: http://pieterhordijk.com/sandbox
As stated the exact same code works on testsite.
Anybody has any idea as to why it doesn't load my audio?
PS
I'm testing using:
Chrome 11.0.696.68
EDIT
Now I'm on Chrome 13 (Canary Build) and the MP3 loads.
But the WAV only loads the first second(s).
http://pieterhordijk.com/sandbox/test.mp3 is served as audio/mpeg, which is good. However, when I download it with Opera, it comes out corrupted for some reason and I cannot add it to Foobar's playlist or anything. But, it does download fine with wget, so that may just be an issue with Opera or something funky the server gives to Opera. Loading the mp3 with <audio> doesn't work in Opera of course anyway since Opera doesn't support that format.
http://pieterhordijk.com/sandbox/test.ogg is served as audio/ogg, which is good. And, it also contains vorbis now instead of flac (since you fixed it). It won't play in Opera remotely, but plays fine if I download the file and open it in Opera locally. It plays in Foobar fine too.
http://pieterhordijk.com/sandbox/test.oga is served with the wrong mime type. It's served as text/plain, but should be served as audio/ogg (you can fix this in .htaccess). But, it does contain vorbis and is playable with Foobar. Again, this one won't play remotely in Opera. But, if I download it and open it in Opera locally, it plays no problem.
http://pieterhordijk.com/sandbox/test.wav is served as audio/x-wav, which is good. But, the wav file isn't acceptable for streaming since it's 30.9MB in size and playback can be horrible unless it's fully been fetched. This one does play in Opera remotely at least.
However, things work fine on my site. See http://shadow2531.com/opera/testcases/plugins/temp/peehaa/test_audio_vorbis.html. Your oga file plays in Opera no problem and it should fall back to the mp3 for UAs that don't support Vorbis.
With that said, it seems like it's something with how your server is serving up the files. The only difference I noticed is that your server is sending a Vary: Accept-Encoding header. But, not sure if that's the cause or not.
Now, as you'll see from my test page, it's using:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title></title>
</head>
<body>
<p>
<audio controls width="300">
<source src="test.oga" type='audio/ogg; codecs="vorbis"'>
<source src="test.mp3" type="audio/mpeg">
test.oga
test.mp3
</audio>
</p>
</body>
</html>
That's how you can fall back to other types. See http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-source-element for more info. If mp3 and vorbis are not enough, you could add aac audio in an mp4/m4a container as another fallback.
I had a similar issue, for some reason it would not load local MP3 files, the solution for me was to use OGG files and all worked. My local dev system is Linux/apache2 and I tested with Firefox 8, and Chrome 15. The audio tag did work with remote MP3 and OGG files though, I don't know why they were not working locally, again OGG worked locally.