How Does YouTube Stream Long-Form Videos to Mobile - html

I'd like to know how YouTube plays long-form videos so quickly, with seeking, on mobile.
This is an example video: https://www.youtube.com/watch?v=eyU3bRy2x44
I can load it just fine on mobile within 5-15 seconds and I can even seek through it.
Are they using HLS? Or are they using any other streaming technology? Are they using MP4 with highly optimized MOOV Atoms placed at the front of the files?
I'd like to know because I want to serve up long-form videos on one of my websites, and they take forever to load even if served from a CDN.
Thank you in advance!

Your videos should not really take a long time to load even with 'normal' HTTP streaming if the CDN is doing its job properly.
One possible problem might be the quality/bit rate of your videos - if they are only available in high quality or high bit rate then this will definitely cause a delay in initial playback.
Many (most?) YouTube videos now will support multiple bit rates, which allows the client device select the bit rate that is most appropriate for the current network conditions. This technique is called adaptive bit rate streaming, as you likely are aware given the reference to HLS above.
MPEG DASH, as Aquary mentions, is an adaptive bit rate streaming format. It is designed to be an open standard - Apple's HLS, Microsofts's Smooth streaming and Adobe Dynamic Streaming are the other main adaptive bit rate formats.
For videos that support adaptive bit rate streaming the client will usually start up at a low or medium bit rate to ensure quick start up and then 'step up' to the highest bit rate the network will support once the video is playing. This helps fast startup. When you jump to the middle of a video the same approach is used to 'start' again from the point you have selected.
You can quite often see this if you look closely at a video when it starts up - the playback quality will improve after a short while as the video steps up through the bit rates to higher quality streams.

YouTube uses MPEG-DASH in HTML5 on the devices that are capable of that. This allows seeking through the media and start from the moment which you select.
Traditional progressive download (AKA pseudo-streaming) is not a good option in case of long videos because by default, media players try to download entire video even though you may stop the playback. Seeking is also supported in PD but your video should be prepared for that and your media server needs to be able to process seek requests properly.

Related

Is there anyway possible to make HTML5 Video run only off of Wifi/Internet?

Is there any way possible to make HTML Video run off of internet, and buffer when the internet connection is weak, or low, for example, the YouTube Player, The basic idea is to chop video, and buffer it before the client clicks play, can this be based on internet connection and wifi? I will do anyway possible to implement this feature!
Thank you.
IMHO, the video element does most of the buffering in the background (depending on the internet connection), and is usually quite good at it. From experience, it is more time-efficient as a developer to try to optimize the size/quality of the streaming video (using tools like Handbrake) rather than try to alter buffering depending on network variables.
That being said, if you are mainly targeting mobile devices, you could could use the experimental Network Information API to get info in Javascript what kind of mobile connection the device is using, and then direct them to a different (low quality) version of the video if they are using 3g or slower.
Alternatively, if you just want the video to start preloading (not playing) as soon as the page loads, have a look at the preload feature on the html video element.

Term for web video split into many chunks transparently to the user

I notice (by looking at the Chromium network tab) an annoying phenomenon of many Web sites that include videos implementing video playing by sending many small video chunks, with the user (behind the Web browser) not aware of this and even being capable of seeking through the video and seeing the current "position" in the video's reproduction relative to the start and end.
What is the professional term/jargon used for this?
Some existing questions that talk about or mention such Web videos:
Play multi part video without interrupts (HTML5)
Chunk audio/video files for web
Are html5 streamed videos cacheable?
videojs: Download/stream video in chunks with quality selecton
How does video on demand work in Youtube?
The term your probably looking for is “Adaptive Streaming” or “Adaptive Bitrate Streaming”. Or maybe you are looking for names of implementations like “DASH” or “HTTP Live Streaming”
Also, it’s not an “annoying phenomenon” it’s a technique that allows for live streaming media with an undetermined length that can adjust to each users internet connection without using expensive media servers and can leverage existing CDNs and caching infrastructure.

HTML5 Video Best Practice

I have a lot of video on my webpage. I noticed that some of them load very slowly. I think the reason is the resolution.
How can I speed up the loading of my video? What are your the past experience with html5 video settings? Which video resolution, frequency rate and so on should I use? Is there an advantage if I use a video player like VideoJS instead of default HTML5 player?
I would be grateful for every snippet of advice!
(Creator of video.js here) what you’d benefit from is a multi bitrate adaptive streaming strategy, creating smaller resolutions of the file for lower bandwidths, helping it always start quickly. You could use video.js with the HLS plug-in, or HLS.JS with the bare video tag. You’d get similar results between them. FFmpeg and any of the encoding services can create HLS files and manifests to support this approach. It does mean hosting more files per video. Mux.com can also help with this at scale, but I’m one of the founders so take that into account.

Fragmented mp4 cannot be played on pure html5 video

I need to use a video tag to serve over 3GB of video on the web.
When the page is loaded, it takes a long time for the media element to receive the 'loadedmetadata event'.
I've found that the size of the moov box is too large (33MB).
So when I re-encoded it with the 'empty_moov + frag_keyframe' option of 'ffmpeg', but it also took longer to fetch all fragmented information from the 'Inspector - Network' tab in Chrome.
Is there a way to speed up loading when playing 'fragmented mp4' with html5 video tag?
You don't mention what protocol you are using to the deliver the video to the browser, but fragmented MP4 is usually delivered with an ABR (Adaptive Bit Rate) streaming protocol. The most commonly used ABR protocols at the time of writing are probably HLS and DASH.
Using ABR allows the client start at a lower bit rate and hence speed up initial playback - it can then step up through different quality levels to reach the optimal quality for the particular device and the current network conditions.
You can see this effect with large streaming services where the video quality will be noticeably lower at start up and then improve after 10-20 seconds. See more more info in this answer:
https://stackoverflow.com/a/42365034/334402
Bowsers generally don't support ABR natively with the HTML5 tag - for this reason you generally will use a Javascript based player which uses the HTML5 MSE (Media Source Extensions) mechanism to support ABR. You can see open source exmamples such as:
http://dashif.org/reference/players/javascript/1.3.0/samples/dash-if-reference-player/index.html
https://shaka-player-demo.appspot.com/demo/#asset=//storage.googleapis.com/shaka-demo-assets/angel-one/dash.mpd;lang=en-US

Possible to stream videos using Amazon S3/CloudFront with HTML5 player?

I want to use an HTML5 video player and stream videos. Is this possible with S3/CloudFront? I understand Amazon uses the RTMP streaming protocol and HTML5's video tag does not support RTMP. Is there any way to stream videos with HTML5 players?
Much of what #Wayne Koorts posted provides the basis for a good answer. The disconnect it seems is that you can "stream" video via progressive download. This works with any html5 compatible video file, as he illustrated.
In order to get the best performance in a progressive download of mp4 files, you need the moov atom meta data to appear at the beginning of the file. Insuring that your mp4 files have this property is one of the reasons that the qtfaststart program is included with ffmpeg.
Of course, progressive download is not a "streaming media server". Streaming media servers were designed to support a number of different features including:
Security and DRM
Adaptive streaming/interleaving (support for multiple bit rates interleaved into a specific file)
Seeking
It seems the particular concern expressed here is the seeking feature. As it happens this is supported fine in html5 and by s3/cloudfront.
What is confusing is that cloudfront of video files has several options. One option is to have the files delivered by their network of licensed Adobe FMS servers. This is where the confusion about the use of RTMP comes into play. However, that is only an option. Files can be distributed to cloudfront in standard "download" form and they will have the seeking property due to the implementation of byte ranges and support for what is popularly known as pseudo streaming.
There seems to be a lot of confusion about the term "Pseudo streaming" but in the case of html5, it's simply the requirement that the HTTP server supports the 1.1 specification. When seeking, the client sends a byte range request and the server is responsible for delivering that portion of the file.
In other words... seeking with the html5 player does work with the cloudfront servers because they are HTTP 1.1 compatible.
As for some of the other functions that streaming servers provide, there are a variety of competitive servers that have implemented "H264 streaming" or elements of MPEG-DASH as an alternative to the use of RTMP and FMS compatible servers. A number of flash based players support these functions, which go above and beyond simple seeking. The JWPlayer and Flowplayer are 2 examples of players that support some or all of the features, however HTML5's video player has no support for any of these features. You can learn more looking at http://h264.code-shop.com/trac#H264StreamingModuleIntroductionversion2
If that's not enough confusion for you, Apple implemented their own "HTTP Live Streaming" protocol, sometimes known as m3u8, which they support in ios and quicktime. I mention this because frequently people want a way to support a variety of different devices.
I hope this helped clarify things a bit.
Something I have done successfully recently is to use the Video.js HTML5 player (open source) video player, with videos hosted on S3. Basically you just upload your video into your S3 bucket, then the code on the page looks something like this (after including the Video.js CSS and JS files into your page):
<video id="example_video_1" class="video-js vjs-default-skin"
controls preload="auto" width="1600" height="900"
poster="http://mys3bucket.s3.amazonaws.com/videoImage.jpg"
data-setup='{"example_option":true}'>
<source src="http://mys3bucket.s3.amazonaws.com/myvideofile.mp4" type='video/mp4' />
<source src="http://mys3bucket.s3.amazonaws.com/myvideofile.webm" type='video/webm' />
</video>
poster is just the still image to display on the video player while the video is loading or not playing. As for the <source> tags, you can link as many or as few of these as you have videos for. More formats just means better support across different platforms (e.g. some vanilla Linux distributions may not play MP4 etc.).
See the Video.js quick start guide here.
When deciding whether to use S3 or CloudFront: IMHO S3 is more appropriate for video in general because the cost is cheaper when you're storing a lot of data (because CloudFront distributes copies of everything to all of its edge servers, although you can limit that somewhat via options). Some people do prefer CloudFront though due to the speed, although remember CloudFront is intended primarily as a content delivery network where super fast response times are required (e.g. for site graphics, stylesheets, JS files etc.), so it's a trade-off depending on your needs. If your videos are all very small then you may find CloudFront actually is appropriate for your needs.
For analysing costs more definitively you can use Amazon's monthly cost calculator.
I am working on some video stuff for a global production. I need to keep cost down but I am looking to be easily scalable and enough features to deliver a pretty complex system securely. AWS seems great, been using them for a few years now and I think the S3 Buckets are amazing. They are free, to a limit. And yes. They certainly do succeed in providing what I believe is streaming video; in that it is housed in S3 and it plays right into my JWPlayer immediately on page load with no jitters or latency.
I can see some of the streaming video delineations are vague and still confusing for me, although #gview did a great job providing us with deeper incite. The complexity of it interest me, but if your agenda is to get that video going, I do not believe HTML5 is your answer. SOAP, REST, HTTP, and even HTTPS are supported and provision-able as far as I know. The documentation at AWS is noteworthy also, very helpful. I will attach a start link here.
# user2352370 : JWplayer..I am undecided. I just purchased the middle tier membership and now upon reading Wayne Koorts above, I think JSvideo is better for a variety of reasons and I will be working with that if I can get a refund. I am not seeing any immediate value in JWvideo, past the styling it provides for the videos. I believe the JWvideo's value to me at least, is limited to the styling of the video. I can use JSVideo to create a variety of fall-backs easily for multiple device and browser types. I can style the JSVideo even, but maybe something is to be said for the simplicity of JWvideo. I am probably going to need it for the onslaught of video post I will have in the months ahead.
Both JWVideo & JSVideo Will Work
I think JWVideo and JSvideo both will do the job, I currently have both on my site for various videos and both do a decent job, have not tested browsers very deep yet though.
Do create a Free AWS account and play with the services for free. Its pretty eye opening if you have been dealing with providers like RackSpace or Host Gator for a while.
AWS Free Tier HomePage
AWS Documentation Site for S3
Was looking at AS3 for hosting videos with VideoJS for my own site and that's why I found your question but when I looked at the example code for VideoJS I noticed that the link was at a company called ZenCoder - http://video-js.zencoder.com/oceans-clip.mp4
http://zencoder.com/en/
I have no association with Zencoder but presumably worth considering if you're looking for cloud based video hosting.