Skip to main content

Understanding audio bit rate

Scott Murphy

Hi,

The default for audio bit rate is set to auto.  How is the bitrate determined automatically?  Is it normally higher or lower than the recommended for speech (16Kbs)?  If I set it to 16000 would I see faster streaming and upload speed of video recordings?  Or is audio bitrate really only a player setting?  

Thank you!

0

Comments

4 comments

Date Votes
  • Scott Murphy

    Bane,

    Thanks again for that thorough response.  I see what you mean and am now only using webrtc_streaming_if_necessary: true.  It looks like for our application this setting has always had priority over webrtc_streaming: true.  But I am now following your advice and only using the one setting.

    Thanks for clarifying about localplayback and Safari.   

    1
  • Bane

    Hi Scott,

    Audiobitrate parameter is actually specific to video and our (to be released) audio recorder embeddings only. The player would never check nor use the value of this field, rather play it as it is set in video itself.

    Now I always suggest leaving it to auto. The reason is that our system does checks (video and audio) to see how things should or are best to happen and then might decide that some specific audio bitrate has to be used for that one recording while a different in another for optimal performance or to even be able to record.

    We however decided to make it available just so you can use any value that you might prefer instead.

    My suggestion (if you would go down the road of setting it up) would be to try and use it to see how low or high you want it to be.

    I do want to mention that audio data is actually a very small aspect of recording. The video data is much larger in size. So while you will achieve some difference in size, unless you optimize your video the audio optimizations would not lead to huge improvements.

    Now I always like to mention one more detail when it comes to streaming. Streaming is only good if you do not really care about the quality of the video recorded. The streaming protocol (it's nature - and hence how it is implemented in browsers) makes it possible to send massive amount of data quickly, however it has to be aware of the currently available network speed.

    So if you have someone on your network start playing some network game, watching Netflix or anything like that at some point during recording you are likely to notice drop in quality at least for a moment (influenced directly by your local home or office network gear and setup).

    Protocol will be OK with HD resolutions however the video and audio bitrate is then managed automatically by browser (not our system). By this I mean that your setting would be seen as maximum value and protocol would choose anything between 0 and that number during recording.

    If you are not using streaming, rather regular recording, then you can set the audio and video bitrate properly and this would be seen as maximum and minimal requirement and would drop only if absolutely needed (like camera unplugged for example).

    If you want the time of upload to go faster, and keep the quality and optionally play with bitrate, my suggestion would be to also use "localplayback" as true. This will make the video show up as preview during the upload stages.

    Also a reminder that once "verified" event fires, you can remove the embedding, switch the page and any other action you prefer to do as you no longer need to be on the same page, or have the recorder available.

    Hope this helps :)

    0
  • Scott Murphy

    Hi Bane,

    Thanks for the detailed response.  I will follow your recommendation and leave the audio bitrate to auto.  

    Thanks to your detailed response about streaming. I finally understand what the webrtc_streaming_if_necessary option does for the Ziggeo application.  I prefer the webrtc and file_upload capture types over webrtc_streaming because, as you said, quality of the video seems to be much better.  We use r34 at the moment but am looking forward to trying out r35.

    I have been using local playback, as you suggested, and it works well for the user experience.  However, local playback does not seem to work on MacOS Safari or iOS Safari.  It works find for Chrome (desktop and Android) and Firefox.  This leads me to two questions:

    1) Why does Safari MacOS only have the capture_type webrtc_streaming if my application is set to both webrtc_streaming and webrtc_streaming_if_necessary?

    2) Local Playback does not happen on Safari MacOS or Safari iOS.  Is this a known issue?  Is there something else I need to set for these devices?

    Thank you!  

    0
  • Bane

    Hi Scott,

    Happy to hear that it was useful :)

    I finally understand what the webrtc_streaming_if_necessary option does for the Ziggeo application

    Awesome, let me then use this chance to mention all of the current options related to same:

    webrtc_streaming: true = Sets the WebRTC Streaming to be turned on. By default it is false and recommended for live only (this is part of our live implementation we plan to release in future)


    webrtc_streaming_if_necessary: true = Sets the Streaming option to on if otherwise it would not be possible to use WebRTC. This is case for Safari browsers, so I would recommend this to be on true. This option and "webrtc_streaming = true" can never be true in same time as they would conflict one another.


    webrtc_on_mobile: true = Great option to have WebRTC (when possible) available over mobile devices. I would recommend using this one.

    I have been using local playback, as you suggested, and it works well for the user experience. However, local playback does not seem to work on MacOS Safari or iOS Safari.

    Good observation. The localplayback will offer the playback of the video in most cases. In some cases this is not possible at which point it will not be offered.

    This is explained in an article that my colleague wrote a bit back on here: https://support.ziggeo.com/hc/en-us/community/posts/115007208967-Using-Localplayback

    1) Why does Safari MacOS only have the capture_type webrtc_streaming if my application is set to both webrtc_streaming and webrtc_streaming_if_necessary?

    You should never set to true both webrtc_streaming and webrtc_streaming_if_necessary.

    In reality this should cause some issues and is not something we test for how it would behave.

    To have it make more sense let's see it like this:

    webrtc_streaming sets our embeddings to always use WebRTC Streaming protocol. Now with webrtc_streaming_if_necessary make, our system is told to always turn of the WebRTC Streaming unless there is no other option.

    So you could experience different things based on what is set first or how the checks are made through different revisions.

    2) Local Playback does not happen on Safari MacOS or Safari iOS. Is this a known issue? Is there something else I need to set for these devices?

    As per the link above this can happen. It actually does not depend that much on the browser and might change based on browser version. It also does not directly depend on OS rather what "recording engine" was used (browser does this) and other such parameters we have no control over.

    As WebRTC gets better and better implemented into browsers we can expect this to be better supported. Safari is currently the only browser that has the WebRTC implementation done in such a way that only the streaming implementation is available. What happens with this implementation is that it will record and upload the same data right away. As such there will not be any data to be played back from local storage, rather it would play it from online source instead.

    Hope this makes sense :)

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post