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.
Related
I wanted to write a little website which provides quite long audio playbacks.
Because I have a very limited webspace I wanted to compress the .wav files I have with the tool wavpack. The compression works pretty good and the vlc media player is able to play the file but used within a website via the audio tag it does not work. I noticed that windows is not able to display the bitrate nor the length of the audio file in its detail page maybe this is an indicator that the file is not properly converted/compressed?
Does someone know if the current browser support wavpack, what the correct MIME type would be or if there is another lossless compression for .wav files.
Thank you all in advance.
Unfortunately, there is no MIME type for WavPack (see here and there).
But that's probably not a problem! Actually, in the default mode, WavPack only compacts your WAV files. As mentioned on their website (emphasis mine):
In the default lossless mode WavPack acts just like a WinZip compressor for audio files. However, unlike MP3 or WMA encoding which can affect the sound quality, not a single bit of the original information is lost…
So, if you use the default mode:
you gain a bit of disk space/bandwidth compared to the original audio
you don't lose any quality
For the purpose of a website, you would be better off encoding your files to a lossy format (AAC, Ogg Vorbis, MP3, etc.) which will give you a real compression gain.
In the end, you have two solutions:
You don't care about bandwidth / You care about quality: Use pure WAV files
You care about bandwidth / You care less about quality: Use AAC or Ogg Vorbis
Is there any way to stream mkv files on webpage using javascript/html or any other technologies? I found many questions about this, but I really want to know the answer - is this possible in any way? Maybe ajax, javascript, php, html? Maybe some external libraries? Anything?
I was wondering how youtube works. Is there possible to upload mkv file? Is so, how that videos are streaming to end user?
I know that browser doesn't support mkv natively, but maybe is some way to forcing html to do that?
Any help will be appreciated.
YouTube most probably works using the DASH protocol format. On the server side, the source audio and source video are separately divided into segments of different bitrate/quality. A manifest keeps an index of all possible segments values and their location. This allows to switch quality during playback in the player.
On the client side, the DASH (should be the same with the other main technology: HLS) manifest is used by the player to locate the segments to load in order to feed the content in two separate SourceBuffer, one for audio and one for video and both are being played synchronously together in the MediaSource. For an example player that handles this, see the Shaka Player developed by Google.
Conclusion, there is no need to use a container like mkv but each channel (video, audio) needs to point to a browser supported codec encoded segments.
You don't need anything special for streaming pre-recorded media files. A normal HTTP/1.1 or HTTP/2 server will work just fine. The browser is generally capable of seeking into the file using range requests.
Matroska (MKV) is a container format, and it actually is widely supported because it's basically the same as WebM. WebM is a subset of Matroska... the key differences being that there are suggested codecs for use. (Matroska itself supports almost anything.)
Your audio and video tracks in the file can use a variety of codecs... the key is to use codecs compatible with browsers. Opus for audio and VP8 for video will take you far.
From there, simply reference your video file in a <video> tag.
Is there a way to control how much of the file will be buffered ahead, once you click play, much like Youtube once did?
If you use the built-in video support in the browser then there is no way to control the amount of data that's being buffered. It depends on the browser implementation and there is no API to control it.
Browser implementations are quite good and typically a browser buffers just a small portion of the video before playback begins. Browsers don't download the whole file. However if a file gets completely downloaded by the browser before playback begins then possible causes include:
Maybe the file is very small and the browser has decided to buffer the whole file in memory.
Maybe the header of the file (required to initialize the video decoder) is not at the start of the file but at the end and the browser has to download the whole file until it reaches it. This is uncommon nowadays but old video encoders used to place the mp4 header at the end of the file instead of at the beginning because it simplified the encoder's implementation.
I've noticed that browsers behave oddly if an mp4 file doesn't have a segment index (used for seeking) in its header. Some browsers download the whole file so that they can build a segment index themselves.
If your server is old/misconfigured then the browser may decide that range requests are not supported and download the whole file (or disable seeking).
If you require to control the buffered amount before playback begins then you have to use a more sophisticated protocol (MPEG-DASH, HLS) and a javascript player that allows you to control this parameter. Youtube use MPEG-DASH and have their own player that they've developed over the years.
I'm pretty sure you c an't stop the HTML5 video from buffering the entire video, but here is a useful link for working out how much of the video has been buffered.
https://developer.mozilla.org/en-US/Apps/Build/Audio_and_video_delivery/buffering_seeking_time_ranges
Like mylescc mentioned, preventing the video element from buffering might not be possible, without a workaround (described in a similar posting). However, depending on your use case, you can also make use of existing player implementations, which provide this functionality, like the bitmovin player, dash.js, etc.
Here's the deal, through a huge series of events, I am stuck using Safari on Windows for video playback in HTML5.
I can't use any other browser, Chrome is out of the question, I must use Safari and it has to be on Windows for hardware compatibility.
The best format I've found is a h.264 Quicktime file, but I'm still getting some frames dropped and a bit of tearing.
The video is being played in 1920x1080 resolution and I have tried down-sampling to 720p, which causes noticeable quality loss and no noticeable gain in performance.
I'm looking for one of the following two as a solution:
- A plugin for Safari (that's Windows compatible) to use something other than Quicktime for HTML5 video. I've looked and the WebM (VP8) plugin is only for OSX.
- Any video format configuration that will decode faster in Quicktime on Windows. I've even tried ProRes to no avail, it's even slower than h.264.
Update...
Ogg Theora can be played in Quicktime with XiphQT, but I've ran into many issues when trying to playback various Ogg video formats.
With h.264, if you are using x264 (eg: Handbrake) to transcode/encode video, the following can be set in advanced mode:
cabac=0:ref=1:me=umh:bframes=0:weightp=0:8x8dct=0:trellis=0:subq=6:tune=fastdecode
These parameters:
ref=1, set the reference frame limit to 1, using more reference frames requires more processing.
bframes=0, disables b-frames, not sure on this but I believe that forces P-frame which are faster
cabac=0, disables CABAC compression, which would make the output smaller but take more processing
tune=fastdecode, set's the tune preset to optimize the output specifically for decoding
The other options I am not as sure of and have yet to find solid evidence on their impact towards decoding, let alone if they have any impact on decoding. For example, the "me" setting is for subpixel strength in the transcoding process, it has an effect on video quality, but understanding how frames change, it could have an impact (in some videos) on the decoding process. That is something I do not know, but am stating for a better understanding of where I am coming from.
More about these settings can be found here:
http://mewiki.project357.com/wiki/X264_Settings
Can I click on some time and eventhough the video is not downlaoded till that time and the video starts playing from the time I clicked?
If yes, what would be a better option for viewing streamed video- HTML5 or flash player like JW player? WHich one will have less lag?
HTML5 browsers generally don't support this, however I believe the video tag in Safari will work with the Apple HTTP Streaming format for this functionality. For something that works across all browsers, Flash Player can do it using either RTMP streaming or HTTP Streaming (either with our without OSMF to support this). Probably the easiest place to start is with OSMF, which supports both RTMP and HTTP streaming of video.
I have tested this with Firefox and Firebug and while you can "seek" to a point in the video without having to watch video preceding the point you wish to seek, this still causes the entire video file to download.
Indeed, each time you seek in Firefox 4, the entire video downloads.
This may change and improve as HTML 5 video implementations become more mature and may differ based on the actual browser being used.
More information on the test here:
http://www.stevefenton.co.uk/Content/Blog/Date/201106/Blog/HTML-5-Video-In-Real-Life/