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

Your Favorite Browser – Fantastic or Rocky?

Posted on April 14, 2017

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

Posted on March 29, 2017

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

WebRTC and Live Streaming

Posted on December 23, 2016

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.