vMix Forums
»
General
»
General Discussion
»
Youtube "real-time buffer too full" and orange flashing Stream button
Rank: Administration
Groups: Administrators
Joined: 1/13/2010(UTC) Posts: 5,229  Location: Gold Coast, Australia Was thanked: 4332 time(s) in 1528 post(s)
|
We do not recommend changing Windows network settings, as this could mess up things even more. As this issue only effects a very small number of YouTube streamers and not any other streaming providers, a change on the computer side of things is unlikely to help. One test you can try is to ping a.rtmp.youtube.com from the command line: Quote:ping a.rtmp.youtube.com
Pinging a.rtmp.youtube.com [142.250.67.12] with 32 bytes of data:
Reply from 142.250.67.12: bytes=32 time=17ms TTL=115
Reply from 142.250.67.12: bytes=32 time=16ms TTL=115
Reply from 142.250.67.12: bytes=32 time=16ms TTL=115
Reply from 142.250.67.12: bytes=32 time=16ms TTL=115
Ping statistics for 142.250.67.12:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 16ms, Maximum = 17ms, Average = 16ms One theory is it relates to specific servers in specific locations, as a.rtmp.youtube.com automatically routes to what it thinks is the nearest server using a process called "Anycast". If the ping times are quite high (>100ms) then it indicates YouTube is not picking the best server for your location.
|
 1 user thanked admin for this useful post.
|
|
|
|
Rank: Newbie
Groups: Registered
Joined: 10/21/2022(UTC) Posts: 9  Location: ankara Thanks: 5 times
Was thanked: 1 time(s) in 1 post(s)
|
Originally Posted by: admin  We do not recommend changing Windows network settings, as this could mess up things even more. As this issue only effects a very small number of YouTube streamers and not any other streaming providers, a change on the computer side of things is unlikely to help. One test you can try is to ping a.rtmp.youtube.com from the command line: Quote:ping a.rtmp.youtube.com
Pinging a.rtmp.youtube.com [142.250.67.12] with 32 bytes of data:
Reply from 142.250.67.12: bytes=32 time=17ms TTL=115
Reply from 142.250.67.12: bytes=32 time=16ms TTL=115
Reply from 142.250.67.12: bytes=32 time=16ms TTL=115
Reply from 142.250.67.12: bytes=32 time=16ms TTL=115
Ping statistics for 142.250.67.12:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 16ms, Maximum = 17ms, Average = 16ms One theory is it relates to specific servers in specific locations, as a.rtmp.youtube.com automatically routes to what it thinks is the nearest server using a process called "Anycast". If the ping times are quite high (>100ms) then it indicates YouTube is not picking the best server for your location. ping a.rtmp.youtube.com Pinging a.rtmp.youtube.com [216.58.214.140] with 32 bytes of data: Reply from 216.58.214.140: bytes=32 time=84ms TTL=56 Reply from 216.58.214.140: bytes=32 time=73ms TTL=56 Reply from 216.58.214.140: bytes=32 time=84ms TTL=56 Reply from 216.58.214.140: bytes=32 time=85ms TTL=56 Ping statistics for 216.58.214.140: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 73ms, Maximum = 85ms, Average = 81ms
|
|
|
|
|
|
Rank: Newbie
Groups: Registered
Joined: 10/21/2022(UTC) Posts: 9 Location: ankara Thanks: 5 times
Was thanked: 1 time(s) in 1 post(s)
|
We have been broadcasting 10 hockey games a day on the same network via Blackmagic Web Presenter for 9 days. But when I try to stream via Vmix, it doesn't take more than 2 minutes for me to go to yellow. I don't think the problem is with YouTube. I think the problem is related to Windows.
|
|
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 10/1/2013(UTC) Posts: 196 Location: Bovalino (Italy) Thanks: 86 times
Was thanked: 3 time(s) in 3 post(s)
|
I find myself in the same conditions. Network on 4G LTE modem, speed test with excellent performance, like 40 mega down 40 up. Until last week everything was ok, today I find myself doing a live broadcast and after a few minutes the vmix stream flashes. If I stop everything and restart, it starts fine then after a few minutes it flashes again. I had to lower it to 1.5 megs to finish the transmission. I also have win10.
|
|
|
|
|
|
Rank: Member
Groups: Registered
Joined: 3/21/2022(UTC) Posts: 24  Thanks: 1 times
Was thanked: 5 time(s) in 5 post(s)
|
Originally Posted by: nerdygirljoni I'm getting so frustrated and losing money. Does anyone know how to debug if a windows update is causing "real time buffer full" error? I'm more on the creative end of things and not so much the technical stuff so I don't even know where to begin, or what to say to viewers /big cry shrug/ Hi, things are complex, so lets try to break it down: - You need a stable network connection. Fiber or copper DSL is best, WiFi is a no-go and mobile networks can be tricky.
- Make sure you stream with constant bitrate (CBR) activated. If you don't, traffic shaping in the providers backbone can do all strange things. Cutting video from Powerpoint still slide to a moving crowd will most certainly create a hiccup in the upstream. Bitrate will rise, traffic shaping does not keep up and vMix can not transmit its video buffeers, you get the dreaded orange flashing.
- RTMP is no good, even if YT and lots of others support only this. RTMP is 20 years old, runs on TCP and is brittle in mobile networks, unstable networks and across continents. It gets worse with higher bitrates as well. The reaseons are complex, but unfortunately the problem is there. (Read this for details.
- In short: Use RTMP only up to 6-8 Mbit/s, use it on the same continent, use it on stable networks. Do intensive tests.
- On mobile networks, use SRT to get into the "real" Internet. You can set up a instance of DataRhei Restreamer on a VPS and go from there via RTMP to YT or other ingest points.
- Bandwidth tests are not enough. They help to set your bitrate - do not use more than 75% of what the speed test gives you. The other killer are jitter and packet loss. Try this website with Chrome/Edge and the proper parameters to get an idea how good your uplink is.
- If you stream to a Wowza server, make sure all the buffer parameters for ingest are set up correctly.
On mobile networks: - Use 5G if you can.
- Measure the available bandwith and adapt your upstream bandwidth accordingly.
- Use HEVC instead of H.264, if possible. Same quality, less bandwidth.
- Use SRT. Use SRT. Use SRT. :-)
- If you use bonding technology, understand how it works and do extensive tests. Use SRT.
Sorry that this is not easier, but hopefully these points may help you a bit. Good luck and let us know how is goes. Christian
|
1 user thanked ckvideo for this useful post.
|
|
|
|
Rank: Administration
Groups: Administrators
Joined: 1/13/2010(UTC) Posts: 5,229 Location: Gold Coast, Australia Was thanked: 4332 time(s) in 1528 post(s)
|
Originally Posted by: bulent_atlas
Pinging a.rtmp.youtube.com [216.58.214.140] with 32 bytes of data:
Reply from 216.58.214.140: bytes=32 time=84ms TTL=56
Reply from 216.58.214.140: bytes=32 time=73ms TTL=56
Reply from 216.58.214.140: bytes=32 time=84ms TTL=56
Reply from 216.58.214.140: bytes=32 time=85ms TTL=56
Ping statistics for 216.58.214.140:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 73ms, Maximum = 85ms, Average = 81ms
This is interesting as it indicates Google is doing anycast via DNS instead of by IP. (The IP here is different to what we see in our tests from Australia for example) You can try setting your DNS servers in Windows to the Google DNS as per the following, then reboot and see if the ping has better results: https://developers.googl...ed/public-dns/docs/using
|
|
|
|
|
|
Rank: Member
Groups: Registered
Joined: 10/30/2023(UTC) Posts: 23  Location: Hull Thanks: 2 times
Was thanked: 5 time(s) in 5 post(s)
|
This problem seems to be getting worse. This week I was unable to get a good connection on any of the youtube ingest servers despite going round a / b / x / y several times.
I tried different CBR settings but it makes no difference. My video machine doesn't have the hardware to do HEVC unfortunately.
We are only streaming at 3.5Mbps and have a tested upload speed of 20Mbps.
If I go back through the recording it looks like Youtube is accepting one in every 2 or 3 frames. So apparently they are receiving at about 1.5Mbps
Thanks to all the VMix users and admins for their responses as it's almost certainly not a VMix problem but all advice is useful.
|
|
|
|
|
|
Rank: Member
Groups: Registered
Joined: 10/30/2023(UTC) Posts: 23 Location: Hull Thanks: 2 times
Was thanked: 5 time(s) in 5 post(s)
|
Another Sunday, another difficult streaming day.
This week I tried a different approach. I set VMix to stream to both a.rtmp.youtube.com and b.rtmp.youtube.com (using the backup URL from the Youtube livestream page). Both streams going over the same 4G network connection. Today Speedtest was showing me 65mbps down and 20mbps up speed.
Initially the stream ran OK with both stream 1 and 2 showing Red (OK) on Vmix.
At 10.32 (GMT), stream 2 (b.rtmp) started flashing orange but stream 1 (a.rtmp) stayed on solid red. The youtube live control page started giving me warnings:
Warning: Please configure both primary and back-up streams correctly. The comparison of the streams failed because one of the streams has an invalid configuration.
Warning: In the current configuration, the video's primary and back-up streams have different frame rates. You need to configure the streams to have the same frame rate.
This is a bit strange as both streams were being fed the same data by VMix, but I assume youtube is looking at the actual frames it is receiving rather than the settings of the stream. According to the vmix log it was dropping roughly 50% of frames on the b.rtmp stream.
So the big question is still, what is causing these frames to be dropped? I can't think it's anything at my end since the a.rtmp stream was getting through OK (and in fact both of them were for a while). The actual youtube livestream looks fine as I presume they used the a.rtmp stream which was not having problems.
Just for interest these are my ping results (using Google DNS 8.8.8.8 and 8.8.4.4):
Pinging a.rtmp.youtube.com [216.58.212.204] with 32 bytes of data:
Reply from 216.58.212.204: bytes=32 time=57ms TTL=114
Reply from 216.58.212.204: bytes=32 time=58ms TTL=114
Reply from 216.58.212.204: bytes=32 time=67ms TTL=114
Reply from 216.58.212.204: bytes=32 time=57ms TTL=114
Ping statistics for 216.58.212.204:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 57ms, Maximum = 67ms, Average = 59ms
Pinging b.rtmp.youtube.com [64.233.184.134] with 32 bytes of data:
Reply from 64.233.184.134: bytes=32 time=62ms TTL=114
Reply from 64.233.184.134: bytes=32 time=64ms TTL=114
Reply from 64.233.184.134: bytes=32 time=79ms TTL=114
Reply from 64.233.184.134: bytes=32 time=65ms TTL=114
Ping statistics for 64.233.184.134:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 62ms, Maximum = 79ms, Average = 67ms
|
|
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 3/17/2017(UTC) Posts: 433  Location: Luzern - Schweiz Thanks: 65 times
Was thanked: 56 time(s) in 50 post(s)
|
|
|
|
|
|
|
Rank: Administration
Groups: Administrators
Joined: 1/13/2010(UTC) Posts: 5,229 Location: Gold Coast, Australia Was thanked: 4332 time(s) in 1528 post(s)
|
Please keep this thread specifically about YouTube. Your logs look like the classic internet issues either on your ISP end or on the streaming provider's end and aren't related to the YouTube issues discussed here. See below: https://www.vmix.com/kno...mes-show-orange-or-amber
|
|
|
|
|
|
vMix Forums
»
General
»
General Discussion
»
Youtube "real-time buffer too full" and orange flashing Stream button
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.
Important Information:
The vMix Forums uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
