Forum Discussion
Skype Meeting Broadcast - recommendations when feeding video clips into Event?
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
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!
- 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.
- nomorephones
Microsoft
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.
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?
nomorephones 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.
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!
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.
