Skype Meeting Broadcast - recommendations when feeding video clips into Event?

Brass Contributor

Hi all - 

 

Giving this new network a try!   We are using Skype Meeting Broadcast to conduct company-wide town halls and the like.  We're a media company so in general these meetings include talking heads as well as frequent use of clips and sizzle reels  into the event.

 

Today we are accomplishing this using an Inogeni SDI->USB or HDMI->USB converter to feed the video into essentially the speaker camera feed in the Producer client.   We're noticing some variable quality depending on the clip.   Does Microsoft have recommendations on the clip format (encoding type, bitrate, etc.) to achieve best quality.

 

We're not certain if the artifacting we are seeing is coming from the SFB client that is acting as Producer or if on the backend in whatever it is that Skype Broadcast Meetings does to create the event feed for viewers.

 

Thanks so much!

 

Dave

17 Replies

Great question, I'm very interested to hear the recommended path on this as well - not only for SfB Broadcast, but just general SfB conferencing as well with multiple video endpoints. 

Yeah, fantastic question.

 

So we generally use the same style of production in our high-end deliveries, I think with a difference of having a high-end board do all the mixing & normalization prior to it going down SDI or HDMI to ingestion by the SFB client.  There's a ton of different options here - from the setup you have to the Magewell we use to a dedicated capture card in a higher-end workstation. 

 

In every case they should be delivering 1920 video into SFB ingest and then we package and stream that up to Azure.  The client does have base encoding requirements for hardware and so I wonder if in some of your videos you're exceeding that.  Here's the article that goes through this technically https://technet.microsoft.com/en-us/library/jj688132.aspx - while not related to broadcast it does represent the client and media stack capabilities to encode the raw USB bitstream to H.264.

 

The only recommendation I have is to look into maybe front-ending everything by a board to normalize the input into the SDI->USB converter.

Hi. We do live webinars which integrate live video, computer demos, sizzle reels, and b-roll videos. We have integrated Professional Cameras, connected to Newtek's Tricaster to do the video mixing, virtual sets, overlays, and then feed the output into a PC using the Magewell device that converts SDI to USB. The USB is seen by the Skype Meeting Broadcast as a webcam and we broadcast that out on Skype Meeting Broadcast.

Appreciate the reply - thanks for the input.   We are running our sources through a board - we believe the source of our issue may end up being a bid of compression within our AV stack introducing this.

 

Thanks so much!

 

Try epiphan for live feeds, from any camera, you can also use epiphan to stream desktop content straight into your meeting.

 

If you have media stored on you pc, you can also use manycam, it is a software solution to switch input. You can select a player to feed in your camera feed, or even a file, it will play straight into your video screen of skype.

Thanks Ton - those are great ideas!

Thanks Jamie - we're basically running from a similar pre-produced setting and then pushing into a USB 3.0 device (Inogeni), and until recently we've had no issues. As Dave first mentioned here in his initial post, we saw the audio oddity back on August 2nd, and we couldn't recreate it - until today.

 

What's been obvious from the moment we noticed the audio drops is that there is audio DSP occurring somewhere in the signal chain. Even bypassing the Inogeni gives the same result. Feeding it a straight pink noise, Skype plays it for about a second, then kills it completely. Other samples we give it that have very high levels of plus 8K, it samples then squashes within one second. Clearly there's a noise sampling happening, then an NR noise print applied. (It would seem that the sample/noise-print is a constant process, not a one time application.) And then other DSP comes into play as well, with AGC and compression getting involved. 

 

Interestingly, we have yet to find the exact culprit, as we can feed it music that it has major issues with, then a different song with the exact same digital specs but it plays fine all the way through, seemingly untouched by the DSP. All of this leads to the possibility that Skype is deciding what should and shouldn't be DSP affected within the first few seconds of the audio provided.

 

We've opened a case with MS - Case number:    116081614549306

 

So the question today - is Skype determining that DSP is warranted in those first few seconds, then throwing the kitchen sink of DSP at it?

@Jamie Stark and @Dean Suzuki we are still struggling with this (case # referenced above by Michael)  We are now with the PG on this as there is definitely an issue that we can now trace to some sort of DSP happening either Skype client side or in the backend.    We can reproduce this 100% of the time on media clips that contain music components - basically it seems the processing is trying to suppress what it interprets to be background or other noise.

 

In short we are really struggling - the service works great when we are doing talking heads, slides, etc.   And will even do great when rolling a video clip with speakers and light background music.  However when we load up anything like a "sizzle" marketing clips that is music in the foreground - we get squashed and the audio disappears for seconds at a time repeatedly.

 

Wanted to post this clarficiation as at first we didn't have the definitive behavior - but now we know this is in fact AUDIO processing related and nothing to do with the H.264 video encode per se.

 

This is a concern for us as well - we are still considering a live streaming and VOD solution, and we have SfB on-prem already with O365 and running Hybrid. We're looking at Skype Meeting Broadcast as a realtime town-hall delivery system, and those frequently include stored video vignettes that need to be passed through from our live presenters/live audience through the Broadcast feed - and naturally, to store that for VOD in Office 365 Video later for our attendees that weren't able to attend live. 

 

Is Microsoft addressing this in their roadmap without incorporating these ManyCam and other workarounds because of the quality issues, or even just making PowerPoint embedded videos work and be supported by Microsoft during a Skype Meeting Broadcast. 

Just found this thread, wondering where everyone landed on this.

Dave, I'm in the same boat. Did you ever get a resolution with the PG?

Sad to say I am facing the same issue. We are opening a ticket with MS on it and see where ti takes us. 

@Joshua Foley can you share with the result of MS ticket when you will have but I dare they have nothing on it and we need to wait SfB Meeting Broadcast within Teams as it seems to be within product roadmap.

https://blog.thoughtstuff.co.uk/2017/11/skype-broadcast-meeting-to-move-to-microsoft-teams/

SfB Meeting Broadcast integration within Teams seems to be in Q2 meeting roadmap of Teams https://skypeandteams.blob.core.windows.net/artefacts/Skype%20for%20Business%20to%20Teams%20Capabili...

 

Has everyone given up on playing music in the foreground of their broadcasts?  I have found that other broadcast services such as Livestream have no problem with foreground music.  Skype Meeting Broadcast just mutilates it.

I am also dealing with this issue. Different music creates different results, often not acceptable results. 

 

We work with multiple cameras and audio sources during a broadcast. The video is mixed with a small SDI switcher and the audio is mixed with various audio boards. The audio final audio mix is sent to the video switcher for embedding in to the SDI output signal. We use the Magewell SDI to USB3 device to connect everything to SFB, pretending to be an external webcam.

I have recently begun to suspect that SFB only uses the left channel of audio for the SFB stream. Any sound that is fed on the right channel only is not heard by any participants in the broadcast. 

Has anyone else experienced this anomaly?

 

thanks