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
Related
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.
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 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
I'm not building the next YouTube or iTunes, but I do need to give my users the ability to upload their videos and audios -- then present it on the web at the highest possible quality with the lowest possible file size.
Questions:
FOR INPUT: What video and audio formats should I support? I'm guessing I should try to support the most common formats, but I'm not entirely sure what they are. Also, I'm not sure if I should support the most common formats. Maybe there is a reason not to support a certain format.
FOR OUTPUT: What video and audio output formats should I generate? I'd like to use HTML5's and tags, but know I should consider supporting non-HTML5 browsers. Should I do OGG, MP4 and FLV for videos? What about audios?
Given an unknown video and audio file uploaded by the user, what command should I use to generate the desired output formats. I'd like one command to convert to particular outputs -- and hopefully not have to do anything different to the commands depending on the input (it'll be a pain for me to know what the MIME type is of the file, etc. and can't really do an "if input is a WMV, then run this command" logic).
Suggestion FFMPEG experts?
Support what you actually support. Build FFmpeg with support for as many formats as feasible, and then instead of giving users a list of supported formats just report if FFmpeg choked on their file. Users can (barely) tell what the container format is, and that's not enough information for you to know if you can transcode it correctly.
Use h264 video in an mp4 container, and aac audio in an m4a container. Since the videos are going to be played online, there's no reason to support many formats if one will do. HTML5 and Flash can both play those formats, so don't give yourself extra problems by having numerous output formats apart from the myriad input formats you'll get.
ffmpeg -i <input video file> -c:v libx264 -c:a libfaac output.mp4. Of course that's just a start, and you might well want to adjust the quality (-qscale), bitrate (-b), etc. You'll have to tune the parameters somewhat to fit your needs, sadly there is no single configuration for "highest possible quality with the lowest possible file size."