StreetJelly BLOG: Community News, Video Streaming, Online Busking, and more…
Home » Posts tagged "webrtc"

Optimize your Broadcasting and Viewing

Special guest post submitted by StreetJelly co-founder, Martina!

HOW TO OPTIMIZE YOUR BROADCASTING AND VIEWING EXPERIENCE ON STREETJELLY

StreetJelly offers multiple broadcasting options to accommodate various technical capabilities and preferences. Each broadcasting option is a different technology and requires certain settings on your computer. As addressed in previous blogs, there have been changes in streaming technology during the last year or two. The once widely common and very user friendly Flash-based method is being quickly replaced by WebRTC and OBS. While Flash broadcasts in a fairly continuous stream, WebRTC broadcasts in packets (picture them like chunks) and requires more bandwidth and very steady bandwidth. The overall steadiness is key to a smooth, uninterrupted broadcast. A musician can have overall very good bandwidth (600 to 700 kbps) but still experience broadcasting issues if there are drastic, sudden drops.

Over the course of the last year the overall, use of bandwidth across the internet has increased immensely. Many people are using more bandwidth than ever due to cultural changes like watching TV and movies streamed over the internet. The usage of other surrounding households can affect your personal bandwidth, especially if you are using cable internet. Being in an urban area is not a sure ticket to a great internet connection anymore. Densely populated areas, apartment complexes, hotels and schools are often a victim of huge swings in bandwidth usage. These fast increases by your neighbors can temporarily affect your own bandwidth. You might also be dealing with intentional throttling of bandwidth by your internet provider. Musicians and viewers can achieve an enjoyable and stress free musical experience with just a few clicks of your mouse that can make all the difference.

“Photon” app on iPhone, click the Flash icon

Depending on which broadcast method a musician chooses, a performance is either mobile ready or requires Flash to view. Most shows are mobile ready which means they can be viewed on mobile devices without any additional adjustments. Flash broadcasts require you to “allow” Flash on your mobile device. You can do this by installing an app like Photon or Puffin. After the app is installed Flash still needs to be activated by clicking on the Flash symbol. Depending on your device you might have to do this each time you view a show in Flash. Viewers using desktops also need to allow Flash. Since major browser companies turned off Flash, it needs to be turned on in your browser settings. Many times when browser updates are downloaded the Flash setting will be turned off and needs to be reset after each update. This is a browser imposed inconvenience and not initiated by StreetJelly. By hovering over the artist’s picture on our home page you can tell whether a performance requires Flash. If you see a mobile symbol, the show is mobile ready. If not, the show requires Flash.

Here are some small and simple adjustments you can try for a smooth broadcasting and viewing experience, especially those of you dealing with low or inconsistent bandwidth.

Check that you have Flash installed (a browser update might have uninstalled it even if you just checked a few days ago). You can do this in your browser settings (generally under Plugins) and enable Flash if necessary.

Turn off all other devices and programs in your household which affect your bandwidth, especially everything using large amounts like watching TV or programs like Facebook.

There are 2 volume meters, one on your computer and one on the bottom of the broadcast screen. If you have no sound, please check that neither one is turned off. For musicians broadcasting, check whether you selected the correct sound source. If you broadcast through a mixer this device will become your sound source.

If a viewer experiences issues with broadcasts cutting out, it can either be a bandwidth issue from the musician or an issue with viewer’s computer; such as a slow computer with little memory. You can try to switch to a different browser and see whether that might work better for you. It is very important to turn off all other programs which have a large amount of graphics or video features. Your computer might simply not be fast enough to handle the StreetJelly stream and Facebook feed at the same time. If multiple viewers have trouble watching a certain performer, the problem lies generally on the musician’s end. In this case a bandwidth issue is the most likely cause.

We are looking forward to your next visit to StreetJelly.com and would like to thank musicians and viewers alike for being part of this wonderful community.

WebRTC Streaming Survey Findings …and news

In April 2017, we sent out a survey to the streaming musicians that have used the WebRTC broadcasting method.  The questions were simple, “did WebRTC work for you?”  “What kind of browser / computer did you use?”  And so on.

For the hundreds of surveys we sent out, response was above 60%.  Thank you all so much, that is a great response rate for any survey.

The main question, “how well the WebRTC technology worked for everyone,” is what we really wanted to know.  It also had the most interesting answer:  from a scale of 1 to 7 (1 being it didn’t work at all, and 7 being it worked great) …the responses were evenly spread from 1, 2, 3, 4, 5, 6, 7.  Statistically speaking, that’s really hard to make a conclusion from that answer.  Normally, one would expect a rating-scale answer to skew to one side or the other, or in the middle.  A statistician or survey-guru would probably conclude the question was flawed.  But the question was pretty simple, did it work or not.

So what does it mean for us?  Well, best explanation is that it confirms what we already know:  the new WebRTC technology is not working perfectly and to our complete satisfaction (more about that in a minute).

Some of the other questions in the survey; browser type, operating system, webcam type, were meant to help correlate if those who had problems were using any particular type of platform.  Again, the answers were spread wide.  No correlation to hardware or system could be concluded.

One question did stand out with a surprise answer.  The question was whether a musician relies on viewers in the chat for streaming help, or whether they use a trusted friend or techie.  The sliding scale, 1 to 7, was skewed far to the “rely on any viewers in the chat” side.  In fact, not a single person answered #7 (as of 4/22) that they use “a trusted friend, colleague, or tech person.”

In our opinion, this is quite a surprise.  You all know the admins on StreetJelly are also active in the chat community.  We have a different perspective of what’s going on because we also have access to the video servers, bandwidth logs, etc.  We see many disruptive comments in the chat about video quality, bandwidth, etc. that are just not technically true.  As much as we try to help, those false comments get repeated over and over again.  I hate to say it this way, but it’s much like the “fake news” phenomenon of late.  The surprise answer to this questions means many musicians are unknowingly getting and listening to conflicting advice.  We at StreetJelly need to step up our game and get more help out to those that need it.  But we also need your help.  Nothing disrupts a show more than the same misinformed chat viewers constantly complaining about someone’s low bandwidth.  We can all help by explaining to the viewers that we understand the internet provider and networks are slow – and there is nothing we can change right now in the middle of the performance.  {rant over}

Survey conclusion and a bit of news…  We are not 100% satisfied with the reliability and success of WebRTC, yet.  It’s new technology, for sure, and we fully expect many improvements from the browser makers in the months to come.  But we also have the looming deadlines (not yet exactly known) when all plugins and Flash will be discontinued from all browsers …eventually.  We do not want to be relying on only one broadcast method, specifically WebRTC, when that day arrives.

StreetJelly will be releasing an alternative broadcasting method in the coming weeks by allowing musicians to stream directly to the StreetJelly Cloud with the OBS Studio broadcasting software platform.  This is a significant change in how StreetJelly approaches the complexity of video streaming to our musicians.  We always strive to make it as easy as possible – one click and it should just work.  OBS Studio is fantastic software, and it far surpasses other broadcasting software like Adobe’s FMLE.  However, it is much more complicated to use than a simple webpage click-a-few-buttons approach.

OBS Studio is stand alone, open source, free software you must download and install on your computer.  StreetJelly will give you all the info, URLs, and credentials it will take to connect up to our cloud.  There will still be a “broadcaster page” on StreetJelly for the musician.  This page will bind the stream coming from OBS to a show and chat on StreetJelly.  We will try to make it as simple as possible for those who wants to tackle OBS, and provide as much help and tutorials as we can.

This is a major change in streaming for some.  But for those wanting to take it on, it also brings with it many new features to your performance.  A few examples include multi-cameras, video transitions and fades, alternate audio sources, audio mixing, and so on.  Exciting times ahead.

We will be releasing the OBS broadcasting in phases.  Stay tuned.

Your Favorite Browser – Fantastic or Rocky?

Special guest post submitted by StreetJelly veteran, Martina!

Why using a certain browser can make all the difference between a fantastic broadcast and a rocky one.

Recently, Firefox and Chrome browsers made significant technical changes by disallowing plugins. This will affect musicians and viewers. I would like to explain this fairly complex subject in a condensed version. We understand that these changes have caused some StreetJelly users confusion and frustration. Hopefully, this blog will help all of you to have a much better and smoother streaming and viewing experience.

Not all browsers made changes at the same time and many updates will follow. This is the reason why we sometimes recommend one browser over another. Our recommendations go hand in hand with new developments in streaming technology and their direct impact on our broadcasting tools.

The Flash broadcaster
These developments have no effect on this broadcasting option. The only thing we noticed is that some viewers don’t realize that this change turned off Flash on their computer and it needs to be turned on in the browser settings. This might be necessary each time there is a new browser version. Internet Explorer still allows plugins but for a limited time.

The old plugin Jellycaster
Chrome and Firefox do not allow plugins anymore and therefore the old Jellycaster is not functional on those browsers.

The new Jellycaster WebRTC
This is an entirely different streaming technology and expected to totally replace Flash in the future. Currently, this method of streaming is still going through some growing pains. Flash works very well for people with lower bandwidth, but all the new streaming technologies require higher bandwidth. It is not only the amount of bandwidth which is important but also the steadiness. RTC is a technology which streams chunks of data, also known as packets. Flash streams more like a continuous stream, like water in garden hose. Currently, Chrome is using a different type of packets than Firefox and both browsers have a different way of letting the stream go through firewall ports. Which browser works better depends on each individual network setup, steadiness of internet connection and other factors.

We currently recommend to try Chrome first since its approach to RTC appears to work better for a lot of people. Ultimately, it is a matter of trying it out. It is extremely important to always have the latest version of any browser when using RTC since there are significant updates on a regular basis.

For anyone who is struggling with low bandwidth, it is important to maximize what you have available. Check that all other devices in your streaming location which use bandwidth are turned off and programs are closed. Sometimes we might not think of it that very common pages like Facebook can be a strain on your bandwidth. This is just one of many examples. Generally, anything with video falls in this category and, of course, watching TV on the computer.

I hope this helps a little to explain why browsers can make all the difference and why we change our recommendations to adjust to all the rapid developments in technology.

Fighting WebRTC Audio Sync Issues

Fighting WebRTC Audio Sync Issues
Subtitle:  Mainly with Chrome

Audio Sync issues are when the audio and video get out of “lip-sync.”  The sound does not line up with what you see.  Many folks call it a “lag.”  (We also have heard people call it a “latency” problem, but that is an incorrect description.)  This problem can happen with any broadcasting software, but it appears to happen more often on Chrome streaming with WebRTC.  This does not mean, “Firefox is better than Chrome,” or any one browser is superior.  We are only saying this one specific problem happens to a few broadcasters while on Chrome.

The guts of how WebRTC streams, also known as the encoder, processes the audio and video separately. They are streamed separately, they travel across the internet separately, and it is your computer at home that has to put it back together in-sync.  When a moment in time of the audio and video are sent across the internet too far apart from one another, the result is audio that does not match video.  That’s just the way it works!

Processing audio is easy from a computer’s point of view, there is less data to manage.  Video, on the other hand, takes massive amount of data and processing to produce a video signal.  The CPU (central processing unit) of the computer, a.k.a. the brain, can only handle so many calculations at one time.  When there is too much data to process when streaming, it is generally the video that gets processed slower than the audio.

The result: the audio is encoded first, and the video lags behind.  Look closely at a sync problem broadcast – you will almost always hear the sound / voice first, then witness the video catch up.

How to fix this problem?  Start by understanding that anything that can free up your computer’s CPU from tasks, or reduce the amount of video data to process, will help:

  • Make sure your browser is running the latest version. We will say this a 1,000 times… it’s very important with WebRTC to be on the latest version because the browser makers release significant changes with each new release.  To check / update Firefox or Chrome, go to Help >> About.
  • Turn off any software running on your computer you do not need for streaming.  Anything to free up your CPU will help.  Close multiple browser windows and tabs, close music recording software, close any games and video intensive software, and so on.  And close dang Facebook!
  • Choose 4:3 SD (standard def) streaming on StreetJelly.  Obviously, 720p HD takes way more CPU cycles to stream.
  • Adjust your webcam to the lowest decent quality.  Your webcam may be set at very high HD settings. The encoder then has to convert that video to lower quality for streaming.  That takes a lot of CPU power to do that.  In the hardware settings for your camera (not on StreetJelly):
    • Match the screen size of the webcam to the screen size chosen for broadcasting on StreetJelly.  For example: 640 x 480
    • Set the frame rate (if available) to 15fps, frames per second.  The WebRTC encoder defaults to 15fps, so it will get converted anyway.
    • Set quality (if available) to medium, or somewhere around 80%.  Different webcam vendors approach this setting differently, but the key is to dial it off the very top, but don’t go all the way to the bottom.
  • Remove any webcam effects from your broadcast.  This includes extra graphics embedded into the video (snowflakes, alien heads, swirly do-dahs, etc). All these require massive CPU processing to generate.
  • Remove any lighting effects in your home studio.  Yes, we mean swirly lights in your room in the real world.  This affects compression. The more areas within your video frame that do not change over time, the more your video gets compressed into smaller data chunks.  This reduces the amount of bandwidth needed to stream and process.
  • In your computer’s video settings (at the hardware level):  make sure any “hardware acceleration” settings are turned on.  I’m sure that sounds vague, but there are far too many video card drivers, manufacturers, scenarios, etc. to write about in a single blog.  The key here is to maximize the CPU and GPU (graphics processing unit) settings.
  • Get a faster computer! 🙂

UPDATE APRIL 19th, 2017

So we know Chrome can be a CPU hog, and these issues can get the audio out of sync.  One thing to try – and definitely check – is the Chrome “use hardware acceleration” setting.  Hardware Acceleration is a feature on most computers to use the GPU (graphics processing unit) for video processing. In Chrome, this can be controlled with an Advanced Setting called:  “Use hardware acceleration when available.”

Normally, this setting should be checked.  Check it now with these instructions:  http://www.pcadvisor.co.uk/how-to/internet/how-turn-off-gpu-hardware-acceleration-in-google-chrome-3605455/

For some with audio sync issues, UNCHECKING this setting may help.  It’s not a guarantee, but worth a try.  Sometimes a computer’s video card drivers could be out of whack (I literally had that problem with an old Lenevo laptop).  Using software to process the video software can possibly fix (or avoid) a hardware issue.

For a bit more detail about Chrome and Hardware Acceleration, here’s another nice article:  https://www.lifewire.com/hardware-acceleration-in-chrome-4125122

Firefox v52 Turns Off Plugins

On March 7th, 2017, Firefox released browser version 52 that turns off all access to (npapi) plugins, except Flash.

That’s a very loaded statement as it affects a huge amount of websites, systems, and people all over the world.  This is not breaking news, however.  It has been in the works and made public for a very long time.  Chrome has already turned off plugins on its browser back in 2016.

What does this mean for the old style Jellycaster (with the nanoCosmos plugin) on StreetJelly?  It means the old Jellycaster will no longer work in Firefox.  We recommend that musicians migrate over to our WebRTC stereo version of the Jellycaster.  WebRTC is a non-plugin technology new for browsers.  Read more about WebRTC here.

Do you still want to use the old style Jellycaster?  That’s ok, we understand that different computers work better with different technology.  And when you have one thing setup, it’s a pain to switch over to something new.  That being said, the old style Jellycaster is still available in Safari and Microsoft’s old IE “Internet Explorer” browser.  (Note, this is not the new MS Edge browser found in Windows 10.  That does not support npapi plugins, either.  The IE browser is installed on Windows 10, it’s just not readily visible.  To launch IE, go to the Win10 search bar and type “IE”.  Best to pin the icon to your desktop or menu so you can easily find it the next time.)

There is a TEMPORARY workaround in Firefox to still use the npapi plugins.  But this workaround will last you only about a month until v53 is launched on April 18th, 2017.  In v53, plugins will be turned off permanently (except Flash).  The fix involves messing with the Firefox config settings.  If you so desire, here are all the instructions:  http://winaero.com/blog/firefox-52-npapi-plugins-support-disabled/

 

Don’t hesitate to Contact Us if you need help.

 

WebRTC and Live Streaming

What is WebRTC and how it applies to live streaming in 2017?
Subtitle – The Rise and Fall of Plugins.

By definition, WebRTC stands for “Web Real Time Communications.” Wikipedia defines it as: a collection of communications protocols and application programming interfaces that enable real-time communication over peer-to-peer connections. That makes a whole lot of sense, right? In practical terms, it means that browsers and mobile devices can talk with each other, hardware on your computer, and other websites in a gee-whiz cool new way. This improves live streaming by making it easier to access your webcam and microphone, and efficiently broadcast crisp clear video and audio across the internet. WebRTC is easier to understand by explaining what it’s not – it is NOT a plugin.

“Howdy, plugin pardner.”
When the wacky web world (www) first started, it was mainly text, with some basic images and logos to make it look pretty. The “browser” was invented to read this text. That’s all it needed to do, browse and display “pages” over the “web.” Hence, the webpage was born. By its very nature, a browser can not – and should not – do anything but read a webpage and display it to the viewer. It could not in anyway have writing capabilities or access anything on your computer. This was a major security feature built into all browsers from day one. A webpage anywhere in the world, presumably even a webpage made by nasty people, could be read. But it could not access your hard-drive and delete everything you owned. Makes sense, right?! That very basic notion of a browser being unable to access any of your hardware, webcams and microphones included, made surfing the internet safe.

In the early days of live streaming, ‘er web-camming, we had to download and install specific software onto our computers to get video to stream. Adobe’s Live Media Encoder (FMLE) was one of the originals. Most of the webcam hardware companies, on the other hand, would also include their own software to get their cams to broadcast. These proprietary bundles usually only worked peer-to-peer with another webcam from the same manufacturer and same software. Sneaky! By the way, this was all before Skype and even the first generation of cam sites. Installing specific software on your computer (remember .exe’s?) was the only way this all worked.

Then along came the brilliant idea of running a mini software program INSIDE a browser and not as stand alone software. We call these gunslingers “plugins.” They still had to be downloaded and installed, but they were a powerful solution that allowed webpages to do more than just display text and images. For us web programmers, the plugin was our hero! We could now make a webpage, and an entire website, act like a real piece of software. We could change an “application” by the next time you returned to our website, without having you to buy or download an entire new version of our software. Oh, the potential we had with the dawn of “Web 2.0.”

Adobe Flash Player was one of the first and most successful plugins for many reasons. The Flash plugin did 99% of all the work we ever wanted to do in a website application. As a programmer, why would you write your own plugin to override the video-card graphics accelerator to smoothly animate a cartoon bird? This was already written and available in Flash, for free! It made our lives much easier. And it made your life better, too. Overnight, websites were no longer static pages, but full fledged software applications. Did Flash do everything we needed for programmers? No. But for the few things we needed extra, we wrote our own tiny plugins. The beauty of it all was that the plugins we created could live side by side with the main Flash plugin that did the heavy lifting.

“This town ain’t big enough for the two of us.”
[Queue the creepy western villain whistling]
As we all enjoyed this web gold-rush of possibilities, the scoundrels out there realized how easy it was to take-over-your-computer with a plugin. After all, a plugin is real software you downloaded from God-knows-where and you gave access to everything holy inside your computer. Yikes. And yes, real exploits existed in this set up. More and more, we learned never to accept a plugin from any website that felt shady. And more and more, Adobe released version updates to make their Flash player – the head-honcho plugin of all plugins – to be safer. To this day, Adobe makes a version update on a regular monthly schedule. It’s remarkable due diligence when you think about it.

The days of the plugin are nearing an end, though. History will recycle them off into the trash heap along with 8-tracks, betamax, and transistor radios. There is a better way, it’s called WebRTC and its brother HTML5. The browser manufacturers have agreed on a common protocol where all browsers, eventually, will be able to access certain hardware on your computer (webcams and microphones in our case) in a safe and secure way. They also will be able to communicate across the internet in a safe and secure way. All this behavior will be built-in and part of the browser itself – nothing to download and install. Plugins are considered so potentially unsafe, that the browser makers agree that they will disable all use of plugins in the very near future. WebRTC has been in the making for a number of years and will replace plugins. WebRTC is currently mature enough to use in a commercial application website …in Chrome.

Wait, what? This only works in Chrome? Not exactly. Firefox and the other main browsers are right up there in implementing WebRTC / HTLM5 with all its features and security. However, the web giant Google makes Chrome. They are the leader and driving force behind this (my opinion). What they create and perfect first in Chrome, like it or not, becomes the de facto standard. StreetJelly is re-writing its broadcasting software with WebRTC first in Chrome. The Firefox configurations and settings are slightly different. We want to make sure all is running smoothly in Chrome, then we’ll tackle Firefox and the rest. In other words, we’ll be broadcasting WebRTC in Firefox, MS Edge, and Safari real soon!

Don’t roll the sunset clip yet…
What about Adobe Flash? How can it go away? Half the web still uses it! That is very true. The browser makers are making concessions to our aging hero. Chrome has already blocked all old-style plugins, but has built in their own version of Flash player internal to Chrome. Whether you refuse to download Flash from Adobe’s website or not, Chrome has its own version already on your computer. Google and Adobe are in a close relationship to make sure it’s safe. Firefox will be cutting all access to old-style plugins by 2017. It, too, will have its own internal version of Flash like Chrome. But eventually, our hero – the Adobe Flash plugin – will fade away forever.

It’s a brave new world …again.

Frank Podlaha
CEO and Founder
…and Chief Propeller-Head

Ok, now queue the sunset…

UPDATE about Firefox: As of today, 1/3/17, Firefox is at Version 50 for the general public. In Version 52, they will turn off the old style plugins (npapi). But you will still be able to turn them back on in the browser settings (type about:config in the address bar). Version 52 is scheduled to be released March 7, 2017. In Version 53, they will turn off old style plugins completely! Version 53 is scheduled for release on April 18, 2017.