Using the same video twice in the same page seems to force an unnecessary media reload.
Compare loading a video to loading an image:
<img src="image.png"/>
<img src="image.png"/>
<video src="video.webm"></video>
<video src="video.webm"></video>
According to the Firefox 5 web console, this loads the image once, but the video twice.
I understand from http://www.w3.org/TR/html5/video.html#dom-media-mediagroup that the spec's authors expected a single reload in both cases ("Multiple media elements referencing the same media resource will share a single network request"), but that is not happening to me.
I have tried to play around with server cache parameters (I'm using vanilla web.py), to no avail, and I suspect that's barking at the wrong tree. Is there anything specific I should be looking at? HTML meta elements?
Note that this is the opposite of common issues with having multiple sources for the same video. Here I am concerned with having multiple video elements with the same source playing side by side (e.g. at different points in time).
I think people are misreading the spec here.
If you look at the example in the spec, they specifically talk about a single resource (file) that contains multiple tracks. The two video elements contain a reference to the same file, but different tracks within that file. The two tracks are then played back in sync by means of a media group.
If you have two video tags that reference the same file with the same track, I would not expect them to play in sync by default. I could imagine that by specifying them in the same media group this might achieve that, and therefore allow both elements to use a single connection with a single stream of requests.
If the two videos are not going to be playing in sync, it is unreasonable to expect the browser to load the two videos across a single request set. Note that this is a request set, a video may generate many requests to a server as a video or media session (think stop, pause and restart) may be significantly longer than a server or client is willing to hold open a single connection.
Imagine if the two elements had different controls. You pause the first video and leave the second video playing. 30 minutes go by, and you restart the first video. The browser is simply not going to have cached what might amount to over a hundred megabytes of content from the server to allow it to play the first video without making a new request to the server.
If you expect two discrete pieces of streaming content to be sent over a single connection using HTTP, then I don't believe that is possible (well, currently implemented). That would be multiplexing, and last I checked, HTTP servers don't have any support for multiplexing. Note that this is different from a keep alive connection where multiple pieces of content are served serially, what multiplexing is describing is multiple pieces of content being served in parallel. The usual way to achieve this is simply to have two sockets open, which is a lot simpler for both client and server to deal with than trying to demux a single stream.
If you check the size of the downloaded video, are they both downloading the full video?
In my tests, most browsers download a small chunk (enough to display the thumb) and then the full video when needed - so I'm wondering if you are counting that as two full downloads, when it is actually only one full download and one partial.
I did some tests in June with the help of Bruce Lawson and we discovered that some browsers perform even more loads than the two I've described above.
HTML 5 Video In Real Life (Tests)
If you are using Html 5, then better you can go with Canvas. It will Load the video once.
This work:
<video id="video" class="videohtml5" width="720" height="500" controls="controls" preload="auto" poster="">
<source src="path(1)" />
<source src="path(2)" />
<source src="path(3)" />
</video>
You could of course put the videos in thumbnails and have them load when someone clicks on them, it might help if you can't find something else.
Sounds like this is a bug in the browser you're using, since it's apparently not adhering to the W3C HTML 5 specification. I would recommend you file a bug report for that browser's devs and test to see how this behavior compares with other browsers.
I think it's because you not enabled webm or mp4 resource caching in your server, can check your request header to see if the cache-control exist.
Related
I have videos on my website that are taking very long to load.
I don't think it is my webhost since it also happens on localhost.
Each time there is only 1 video shown to the user, depending which category they chose. (So it is not loading each video always).
The videos that take longer to load are the bigger ones (the biggest one is about 351MB video file)
This is my html code for the video:
<div class='video'><h2>$vidTitle</h2><video width='640' height='360' controls preload='metadata'><source src='$viddir' type='video/mp4'></video></div>
I've also read that it could be that the video indexing could be at the end, could this be the case?
What can I do about this, do I need to use another player thann the default html5 player (I tried this but it didn't really help) | do I need to use a cdn?
How can I solve this?
Thanks!
My understanding is that the preload='metadata' attribute in your video element is supposed to prevent the video from loading.
You could try preload='none' to test. I know that works.
As always, a good place to check is MDN web docs:
mdn web docs : The Video Embed element
I have a two-hours long video, that I want to stream through HTML5 video tag (and ye old good Flash as fallback)
So I have four files: mp4, ogv, webm and flv (500-800Mb each)
My server returns right Content-Type and Accept-Range headers
I know about qt-faststart for .mp4 files and yamdi/flvtool2 for .flv files
Do I need any extra tools for .webm and .ogv? Or any other server setup?
Is it possible to ask browser to don't downloaed the whole file, but cache only ~5 minutes ahead?
depending on the browser the behavior can differ, and the only real control you have is via the preload attribute. Depending on the guidance in the preload attribute the browser will attempt to do what it thinks is right given network conditions etc. You can specify one of three options: none; metadata; auto
none: this assumes that the user won't play the video, so does not preload anything
metadata: just preloads metadata (video dimensions, captions etc)
auto: optimizes for user experience so may only download the next 5 mins, but if bandwidth is available may try and suck down the whole file
Note: if you specify autoplay as well, this assumes the need to gather metadata and at least enough to establish a buffer to play so it becomes a de factor "preload: auto" condition.
http://www.w3.org/TR/html5/embedded-content-0.html#attr-media-preload
On iOS, and I think Safari, we have Apples HTTP Live streaming, which can take a playlist of video files in a certain format, buffer them one by one, and play them seamlessly back to back.
Is there any way to achieve this in other browsers? I can of course detect the video finishing, and then start buffering and playing the next one, but I want to remove the buffering by downloading subsequent videos as each earlier video finishes. I do not want to hack this by stacking up video elements and switching between them. There are various serious consequences to this method.
Perhaps if there is a way to use javascript to download the files into in-memory buffers and somehow point the video element to play from these buffers?
I've seen swapping in video elements for each segment tried, and it's never smooth.
There is an HTML spec in the works that defines exactly the process you're describing, concatenating media segments into a buffer that can be fed into a media element.
http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
This isn't available in browsers today but is working its way into Chrome/Safari. Even when it is, it will take a good amount of work to implement this process.
Your best bet if you need it now would be to use a Flash player that can handle HLS, like OSMF, JWplayer, and soon Video.js.
In html5, you can preload videos, preload the meta information, or not preload at all. The only problem, of course, will be with Internet Explorer which will download everything or nothing at all (and not even show the controls).
This is all controllable with javascript, too. If you want to play them back-to-back automatically, though, this would need to be done with javascript or some third-party tool. Reading where the file is playing is accessible through the API.
I'm using jQuery to dynamically write <video> objects, and running videojs to init them. After I play a video, SOMETIMES when I try to play it again, it just won't play, and from that point on, even after refreshing the page, no videos will play. Each time, the <video> object renders, but the video just doesn't play. Nothing is written to the console. There don't appear to be any errors. Restarting Chrome resolves the issue, but only momentarily. After playing a few videos, the issue comes back again.
I found that closing other tabs in Chrome does indeed fix the problem, so it appears to be some kind of memory issue.
I'm running Chrome 19.0.1084.46
Exactly how many video tags to you have? What do they look like? Do they include preload='none' attribute? Are the source videos all on the server?
I ask because if you have more than six video tags on a single page pointing to the same source server then you could be experiencing "connection starvation":
Chrome allows only six open connections to a single server (based on DNS name in the URL)
the html5 video tag's preload attribute default value is 'auto'
Chrome's auto behavior is to preload some data and leave the connection open ready to pull more data for the video
So, with more than six video tags on a single page pointing to a single server, the videos will not play. To resolve this particular problem, set the preload attribute to 'none'
Stu is correct. But sometimes, in my experience, Chrome ignores the preload="none" attribute and goes ahead and opens a connection anyway. I've had much problem with this when developing a site which had many smaller videos on it. The connections blocked the rest of the content (images, custom fonts (and when custom fonts are delayed, the text does not even render)) My solution was to build an own preloader which loads the images. This made sure I could control at least when the images (which was the most crucial aspect from a design point of view) was loaded.
That solved the problem with images not showing but the problem still remained. So the best solution is to set up subdomains pointing to the same server, like: v1.server.com, v2.server.com, and so on. This means you won't have to move your files and you get the benefit from enabling browsers to have more open connections. Watch out for increased dns lookup time though.
There is a known bug with Chrome. It will not play the same video in multiple tabs at the same time. This is probably what you are running into if you are a developer and happen to have your page open in two tabs at the same time.
The bug has been known for almost 5 years as of this writing. Feel free to visit the Chromium bug report and star the issue. Hopefully it will increase in priority for the Chrome devs.
In the meanwhile, a workaround is to use a random query parameter in your video src. For example, instead of <video src="vid.mp4">, use <video src="vid.mp4?_u=1253412">. This will break Chrome's caching mechanism and allow the same video to be streamed to two different tabs at the same time.
I had a similar but related issue which I can expand on slightly here.
I had 14 different small videos on a page but only 2 were available at a time. Setting preload = 'none' didn't fix the issue so I also used a data attribute to store the src, and remove the src for all videos that aren't currently being viewed.
The title pretty much says it all. I have a spot on a webpage that currently plays a video. I'd like to update the page such that I can add a line of code with a reference to a couple files located in a folder with the source, and the page will play the first video, then the second, etc. until it reaches the final video, and then play the first video again, looping indefinitely. It's extremely preferable that this line of code would be able to play video files, .swf files, pictures (for a pre-determined length of time), etc.
Currently, I'm just using a very rudimentary
<video width="100%" height="100%">
<embed loop="true" showcontrols="0" align="left" src="New Site Folder\DemoVid_sound_mods.avi"/>
</video>
The problem with this, though, is that it only plays one video, and if I want to add more parts to it, I have to edit the video itself, rather than just popping a new file in the folder.
I saw another question answered that mentioned doing this with javascript, but the whole point of this project is to make it exceptionally easy and quick to update. The main thing I'm looking for here is for us to be able to update the page by opening a file in notepad, adding a line of code, saving, and running it.
Any thoughts? Even just a pointer on what commands might be useful here would be helpful. Thanks in advance!
As far as I know you won't be able to do this with the inbuilt html5 video players native to the browser, It's just not the principle on which they are built.
What you are looking for is more of a media playlist style set of features.
You will have to use one of the javascript based html5 video players to get some of these features but even then I'm not sure of the support for swf and image files I've seen a few which do various videos and audio files but nothing HTML5 which also does swfs also as again, the premise of these players is usually to eradicate flash.
My best suggestion for doing all of these in one single embed is to use flash via the longtail/jw player or flowplayer which handles playlists etc or perhaps slideshowpro which I know does both images, video and I think audio too.
Finally.. harking back a decade or so. theres a Language which is pretty underused and suffers varied support called SMIL which supports all of these elements you mentioned however it's uptake sort of fell apart with the introduction of video in flash. I remember that Realplayer and Quicktime could serve SMIL files but I'd be pretty cautious to do anything in SMIL these days.
Hope that helps.
A