New VidiU Webcast - Slow Receiving Laptops

My stake just finished our first stake conference webcast using the new church VidiU/Cloud system. The upload worked great, uploading 2100kbps without a glitch. However, the 2 laptops we used at our receiving building both caps at 500kbps. Why?

I tested using my Alienware laptop, and it was fine streaming at the 2100kbps, but both other laptops, which weren't as fully loaded and a bit older, wouldn't even let my select 2100kbps as a max bitrate (the drop down only showed 500 as the max). Why am I being forcefully limited? Is it really hardware limitations, and if so, what are the hardware requirements to get a better bitrate?

Otherwise though, it worked great! I really like the new system. Just want to get a clearer picture.

coolnsdc wrote:Why am I being forcefully limited?

My knee-jerk reaction is CPU ability.

The documentation only says "Computer with a 4-core processor (for receiving streams of up to 700K quality)"

I believe a i3 is a dual-core with hyperthreading. The i5 is quad-core. I don't know the other CPUs to know what else is quad core.

russellhltn wrote:The documentation only says "Computer with a 4-core processor (for receiving streams of up to 700K quality)"

I thought it might be something like that. I was monitoring the cpu usage, and even on the older laptops, the cpu was only averaging 15%, sometimes up to 20%, but that was it. That's a lot of wiggle room...

russellhltn wrote:The i5 is quad-core.

Only some i5's are quads. The one in my notebook is only dual-core.

My older core2duo notebook had no problem streaming Netflix in full HD. I understand there are are differences, but the requirement for needing a quad-core at the receiving end just seems way over-the-top to me.

Mikerowaved wrote:Only some i5's are quads.

Well, crud. Why'd they do that??

Mikerowaved wrote:but the requirement for needing a quad-core at the receiving end just seems way over-the-top to me.

The question is a quad core of what? I'm keeping my eye on the thread about Android boxes. You can get a quad core for $88. It may be able to do it it - including being a web browser to demo things like FamilyTree.

Also keep in mind:

At scheduling time you have to specify the receiving sites, if you under estimate and more people log on it will reduce quality to conserve bandwidth.

rolandc wrote: At scheduling time you have to specify the receiving sites, if you under estimate and more people log on it will reduce quality to conserve bandwidth.

In my case, I know this wasn't the issue because I had both my laptop and another laptop, and while mine ran at full 2Mbps, the laptop beside mine was limited to 500Kbps, whether mine was running or not.

I'm seeing about 500kbps on any of our laptops regardless of specs. I've tried my new I7 but still only 500kbps receive.

4 cores or lower is limited to 500kbs

8 cores and you can receive up-to the broadcast speed, confirmed by GCS

I have not been able to get a solid answer as to why we can broadcast in HD but are limited to 500kbs on the receive side. I have buildings with FIOS and powerful quad core computers and every test and broadcast is locked at 500kbs.

I can download 4000kbs streams all day long without issue, Hopefully they will remove the cap soon.

rolandc wrote:4 cores or lower is limited to 500kbs

8 cores and you can receive up-to the broadcast speed, confirmed by GCS

Wow. I can understand 8 cores for encoding, but for DECODING?? That just doesn't make sense. Considering a Core2Duo has proven adequate for decoding almost all other streaming HD content, the requirement for 8 cores is mind boggling.

rolandc wrote:I have not been able to get a solid answer as to why we can broadcast in HD but are limited to 500kbs on the receive side. I have buildings with FIOS and powerful quad core computers and every test and broadcast is locked at 500kbs.

I can download 4000kbs streams all day long without issue, Hopefully they will remove the cap soon.

Until they do, I'll be using other means for streaming. To me, this is an unrealistic quality limit being imposed on the stakes.

Mikerowaved wrote:

rolandc wrote:I have not been able to get a solid answer as to why we can broadcast in HD but are limited to 500kbs on the receive side. I have buildings with FIOS and powerful quad core computers and every test and broadcast is locked at 500kbs.

I can download 4000kbs streams all day long without issue, Hopefully they will remove the cap soon.

Until they do, I'll be using other means for streaming. To me, this is an unrealistic quality limit being imposed on the stakes.

I agree.

Well, at least now I have something to report to the stake. Thanks for the info. That would explain why only a high-end alienware laptop would get the full experience in my case.

My opinion, its being done to conserve resources. I am sure they were overwhelmed by the rate stakes are adapting to the new system.

As we all know Webcasting sorely needed updating. In time I am very hopeful the cap will be raised.

That doesn't make sense though. The upload speed is not limited, nor is the download speed if you have a high-end decoding machine. If it was to conserve resources, they would limit it regardless of end-user hardware, and limit the upload speed as well.

Also, as they are using Microsoft Azure to host the webcast system, I don't think it's a limitation of their system since they can easily spin up more VMs as needed.

I'd speculate that it was simply an attempt to lock down a speed that would work for everyone, but didn't really consider that machines are much more capable than they give them credit for. I'd love to hear from the source what their reasoning was.

I'd be curious as to the cost structure of the Azure system. Perhaps there's a cost based on the amount of data sent out from the cloud. The receiving machine specs might be the only usable tool they have to limit speed.

I talked to someone in technical support today that indicated the limitation of the bitrate is based on the image broadcast. In cases where there have been caps on bitrate, its normally because the camera didn't produce a high enough quality video. I was told the media server analyzes the video quality received and determines the bitrate cap for receiver sites.

From what I was told, it doesn't have anything to do with the Receive equipment performance.

stevei00 wrote:I talked to someone in technical support today that indicated the limitation of the bitrate is based on the image broadcast. In cases where there have been caps on bitrate, its normally because the camera didn't produce a high enough quality video. I was told the media server analyzes the video quality received and determines the bitrate cap for receiver sites.

From what I was told, it doesn't have anything to do with the Receive equipment performance.

That wasn't my experience. If I used my alienware laptop, the bitrate cap was 4x what the other laptops could achieve.

stevei00 wrote:I talked to someone in technical support today that indicated the limitation of the bitrate is based on the image broadcast. In cases where there have been caps on bitrate, its normally because the camera didn't produce a high enough quality video. I was told the media server analyzes the video quality received and determines the bitrate cap for receiver sites.

I think someone is confusing "cap" and "actual". If the stream can be adequately described in a lower bit rate, the actual bit rate will be well below the cap. The system isn't going to add additional bits just to make up the difference.

russellhltn wrote: I think someone is confusing "cap" and "actual". If the stream can be adequately described in a lower bit rate, the actual bit rate will be well below the cap. The system isn't going to add additional bits just to make up the difference.

Thanks for pointing that out. Let me clarify. There is a big difference in video quality between 500K and 2000K bitrate, and only my alienware laptap is allowed to do download/process/display the stream at the 2000K bitrate CAPPED and ACTUAL. Using other hardware, I'm CAPPED at 500K, hence my ACTUAL is also 500K.

coolnsdc wrote:

russellhltn wrote: I think someone is confusing "cap" and "actual". If the stream can be adequately described in a lower bit rate, the actual bit rate will be well below the cap. The system isn't going to add additional bits just to make up the difference.

Thanks for pointing that out. Let me clarify. There is a big difference in video quality between 500K and 2000K bitrate, and only my alienware laptap is allowed to do download/process/display the stream at the 2000K bitrate CAPPED and ACTUAL. Using other hardware, I'm CAPPED at 500K, hence my ACTUAL is also 500K.

I have tested and have found the same thing. 500k cap is based on CPU cores.

If you follow all the documentation provided on the technology website regarding the new streaming system, it clearly states not to stream in HD even if you have the available bandwidth due to the load that it puts on the streaming system. Also, with the most recent update for the firmware on the Vidiu, it allows the receiving end units to increase their minimum bit rate to 900 kBps. Many ask why it allows you to stream in HD when the church advises against it. The HD streaming function is built into the Teradek's operating system. That is just an option that is part of the Vidiu. That is just a default.