I have big collection of CC music, which I want to stream.
I want adaptive streaming for users with low internet connection to not wait every 5 sec for buffering.
I read about mpeg-dash, hls, etc and it seems that mpeg-dash supports only mp4 and ts containers, I am not sure if I can do what I want.
I have LC-AAC-320k and HE-AAC-64k files. Quality matters, and I hear the difference between HE-AAC and LC-AAC-320 even on realtek audio.
Is it possible to do adaptive streaming for these formats with support for Chrome, Firefox, Safari? If not, is there any way to detect low bandwidth (often buffering) and switch to HE-AAC?
Related
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
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.
I have an MP4 video that is variable bitrate, so the average bitrate doesn't necessarily stay consistent throughout the entire file. Because my video is a capture of a computer screen, some parts of the video are very low bitrate because nothing is happening, and other parts are a much higher bitrate because there's a lot of activity on the screen.
How does Chrome decide how much video to buffer for progressive download HTTP(S) videos? I'm running into a problem where Chrome tends to buffer too little, so playback stutters.
If there's no way of convincing Chrome to download a certain time of video (and I don't want to just preload the entire thing), can I author the MP4 some special way to solve the problem? I'm using FFmpeg and MP4Box. Maybe it's up to the HTTP server?
If you want more control over the playback of the video, you should definitely check out MediaSourceExtensions. They define a whole model for video playback, defining sourceBuffers where you can put video data, etc.
Beware it is not a simple to use API still, and the information on how to use it is very fragmented.
In your case, if you go the MSE route, you can either keep using h264 (which is probably the codec your mp4 is wrapping) or switch to webm.
In case of going the MP4, h264 route, you'll need to generate a fragmented MP4 (fMP4) and write some JavaScript to control the way you work with the MP4 fragments (segments in MSE parlance).
MP4Box has support for the -dash protocol, which will segment an MP4 in a way that is suitable for consumption via MSE. FFmpeg also has support for generating fragmented MP4.
I've got an HTML5 <video> element whose source is a .m3u8 (HLS stream)
I have an M3U8 with three different renditions: 640x360, 960x540, and 1280x720
On Desktops I have a Flash Player for playing the video, so the HTML5 fallback is only intended for mobile (iOS and Android) - I am doing all of my testing on an iPad and, once it's working, I will try it out on Android and hope everything works the same.
My goal is to, at any point in time, figure out what rendition the video element is playing. The rendition is subject to change as the user's bandwidth changes.
I tried using the .videoHeight property, but it always returns 480 regardless of the rendition being downloaded - which is particularly odd because 480 isn't even an option.
Does anyone know how I can figure out the rendition being downloaded?
Cleaning up some old questions that never received answers:
Unfortunately this one is just not possible. The HTMl5 video spec and HTML5 video implementations in most browsers are intended to abstract away all of the underlying magic involved in playing videos. You give it a source, it plays. Everything else is completely hidden and you have no access. No access to metadata channels, no access to audio channels, no access to bitrate and resolution information,...
At best I developed a solution to guess which resolution was playing. Every 10 seconds a 1 MB file was loaded over AJAX. I measured the speed at which this downloaded to guess at their current bandwidth. I know that QuickTime will only play a rendition if you have double the required bandwidth. So if the 960x540 rendition requires 1400 kbit/s then it won't play unless you have 2800 kbit/s bandwidth.
It's not very good (and wastes 6 MB of bandwidth per minute) but it's better than nothing.
I'm trying to listen to a live audio stream on a webpage with a latency of less than 3 seconds. So far with ogg vorbis streams generated using ices & icecast, I've been unable to get latencies less than 7 seconds. All players I've used so far (html5 audio tag in Firefox, Opera, Safari; VLC as well) seem to introduce similar delays. It's unclear at this point how much latency is introduced in ices/icecast vs. the client-side player. I've tweaked ices and icecast settings, to no avail.
Has anyone achieved better latencies than this in a similar ices/icecast setup? I wouldn't expect an ogg vorbis decoder (be it html 5 in a browser, VLC, or whatever) to delay an audio stream for multiple seconds. Am I incorrect? I can't find any info on controlling buffer sizes or the decoding in browsers.
With a different architecture (html 5, firefox, WSGI server serving wav format audio), I was able to achieve latencies around 1-2 seconds. By default, the firefox began playing the wav file 5+ seconds behind, but I could advance playback by setting audio.currentTime ahead, and only be 1-2 seconds back (somewhat fragile). However, I'd much prefer to use icecast, and streaming wavs obviously doesn't scale.
Thanks in advance for any ideas.
The Icecast and Shoutcast servers themselves have internal buffers. I know the shoutcast one can be configured (look in the advanced directives in the docs).
There are some archived discussions threads about Ogg / Vorbis related delay:
Vorbis codec delay
Delay
The answer seems to be that you have to tweek the Ogg container format, and then the remaining delay of Vorbis should not be too high.
However, I also often read that the new Opus codec is better suited for low delay/latency. See e.g. here or here.