I'm using video.js to play HLS video stream that has multiple qualities in the m3u8 file. I noticed that video.js selects a lower quality than expected for a given quality. I checked the same stream and bandwidth with another HLS player, the "Native MPEG-Dash + HLS Playback" extension for chrome, and it gave a notch up quality, without buffering. This was consistent.
I also went as far as modifying the m3u8 file, cheating, tampering with the stated bandwidth to reflect that related TS segments was of lower bandwidth than it was really. I then played the video again under the same conditions. This time video.js bit on the cheat, and chose the higher quality videos, still without buffering. My conclusion is that although video.js is capable for higher quality, it chooses the lower quality files, probably to be on the safe side, with higher safety margin than other players.
Question: How can I lower this safety margin for video.js? I prefer higher quality with some risk of buffering, than always playing lower quality.
Related
I would like to build automatic tool that will test encoding efficiency on enter website. I'm using webrtc for video streaming and some users with weaker hardware experiencing problems with encoding efficiency. So ideally I would like to measure how the device behaves respectively with vp9, vp8 and h.264 encoding and choose that which will ensure smmoth stream and highest quality. I build simple tool that measures frames per second and resolution in each codec, but it seems that it is not the best measurement - webrtc manages resolution on it's own, sometimes keeps lowers resolution and more stable fps, but it is not always the case, it's quite unpredictable on older computers. I have another idea to make some benchmark, but I'm not sure if it's possible to make meaningful measurement in a few seconds (I don't want user wait too long). And it's problematic to measure cpu usage from website. What's the best approach for this? I would be grateful for some advices, I'm not very advanced in webrtc and maybe I'm missing something.
Recently, I discover that my tutorial videos could be seen at 1.5x playback speed without losses in quality (they are actually better to see, as I normally speak slowly). My problem is that if I change the speed of the video when using a video editor, like Kdenlive, the audio becomes distorted and turns into a mess (higher pitch, I believe).
How could I obtain the same quality as VLC "playback fast" and Youtube "playback speed 1.5" for the audio track? I'm a layman in audio/video editing, so I'm also satisfied with partial answers, like the identification of which terms I should search for in this case.
It might be better to take your audio track and use something like Sound Forge to automatically remove silence. Just be sure to add a pad to that (built into sound forge) otherwise the speech will sound way to chopped and fast.
Aside from that, you could also use Vegas to (then) chop the video to keep pace with your new speech rate. Vegas is a video editing program that is best for this kind of down and dirty editing.
I have built a source client using Portaudio and LAME which streams the microphone input to an Icecast server to be listened to online via the HTML5 tag. I have managed to (supposedly) get the quality of the stream to MP3 320kbps at 44.1kHz and am looking for a way to confirm this using tests and or benchmarks.
I have an indication that these stats are somewhat correct from looking at stream inspectors in software such as iTunes and VLC, but I am looking to get a more in-depth data set.
What I basically want is to be able to test how much of the original file is being lost over the stream and if or how much the quality changes depending on environmental conditions of the broadcaster or streamer.
Does anyone know of any tools, frameworks to get some hard numbers or representations of this data?
If VLC tells you the stream is 320kbit CBR, then it is.
It sounds like what you're looking for is a comparison of the actual audio content. This is highly subjective. MP3 is built to use features of how our hearing works to save bandwidth. For example, quiet sounds are masked by loud sounds. High frequencies are harder to hear and are simply rolled off.
You can compare the spectral analysis between the original PCM-sampled waveform and the MP3 decoded waveform, but this doesn't tell you how humans interpret that sound. For that, you would have to survey humans.
When I watch some video on youtube, sometimes I change the video quality for example from 480p to 720hd by clicking on the bottom right menu:
does this vq= parameter also affects the AUDIO quality of the video?
If you watch it with the high quality option (or HD), you will experience the audio in stereo. So it has more of a surround sound feel, or how you would hear your music on your iPod, where certain things are only heard on the left or right. If you watch it in standard quality, then it is basically in mono, where the sound is distributed evenly to both speakers, and audio is slightly degraded to load faster. You can hear the difference if you change between high quality and standard.
We have some raw voice audio that we need to distribute over the internet. We need decent quality, but it doesn't need to be of musical quality. Our main concern is usability by the consumer (i.e. what and where they can play it) and size of the download. My experience has shown that mp3s do not produce the best compression numbers for voice audio, but I am at a loss for what the best alternatives are. Ultimately we would like to automate the conversion process to allow the consumer to choose the quality vs. size level that they would like.
You should give Opus a try. Example compression command line:
ffmpeg -i x.wav -b:a 32k x.opus
Start here.
As you rightly point out, voice compression is different from general audio compression. You'll find many codecs dedicated to telephony applications, ranging from PCM and ADPCM through later packet based encodings such as CELP used on GSM cellular networks.
Still, VOIP voice encoding is slightly different from that due to the medium used. you can find a good, free (unencumbered and open source (BSD)) library for speech encoding/decoding in the Speex software library.
Again, which you choose depends on the speech you're encoding and the medium it's being transmitted over. Also note that many libraries have several algorithms they can use depending on the circumstances, and some will even switch on the fly based on conditions of the sound and network.
To get more help, narrow your question down.
-Adam
The most frequently used compression formats used in live voice audio (like VoIP telephony) are μ-Law (mu-Law/u-Law is used in the US) and a-Law (used in Europe, etc.) which, unlike Uncompressed PCM, don't support as wide of a frequency range (a smaller range of possible values ignores sounds outside of the necessary spectrum and requires less space to store).
For usability sake it is easiest to use mpeg compressions (mp2/3/4) for streaming to standard media players as the algorithms are readily available and typically quite fast and almost all media players should support it, but for voice you might try to specify a lower bitrate or do your conversion from a lower quality file in the first place (WAV can be at several sampling rates and voice requires a much lower sampling rate than music or effects, it's basically like frame-per-second on video). Alternatively you can use Real Media, WMA or other proprietary formats, but this would limit usability since the users would require specific third party software for playback, though WMA has an excellent compression ratio as well as compression options specific to voice audio.
Assuming your users will be running Windows, there is a WMA speech compression codec that you can use with the Windows Media Encoder SDK. Failing that, you can use ACM to use something like G723/G728, ADPCM, mu-law or a-law, some of which are installed as standard on Windows XP & above. These can be packaged inside WAV files. You'll need to experiment a little to find the right bitrate/quality (probably don't bother with mu-law or a-law). With voice data you can get away with quite low sample rates - e.g. 16000 or 8000, as there isn't much above 4Khz in the human spoken voice.
I think AMR is one of the best speech codecs. I was using it about a year ago and I remember that quality was very good and size levels were rather small.
One drawback, especially in your case is that, as far as I know, it isn't supported by wide range of media players. QuickTime and RealPlayer are two which I know to play .amr files.
Try speex ... unencumbered by patents, good performance both sizewise and CPU-wise. I've been having good luck using it on iPhone.