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,231  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: 29  Thanks: 1 times
Was thanked: 7 time(s) in 7 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,231 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: 24  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: 24 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,231 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
|
|
|
|
|
|
Rank: Member
Groups: Registered
Joined: 3/21/2022(UTC) Posts: 29 Thanks: 1 times
Was thanked: 7 time(s) in 7 post(s)
|
Originally Posted by: congoblue 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 @congoblue, sorry things went wrong. Your problem is likely the 4G connection. At least here in Germany I made the experience that 4G networks have latency spikes up to 2000 ms every 40 seconds or so. This will kill the RTMP protocol and things will go orange on vMix RTMP streaming. Running two streams over the same RTMP mobile connection makes things worse, since the double amount of bandwidth is needed on the upstream to the mobile tower. In short: Do not use RTMP over mobile networks, if you can help it. If you can't help ist, get a mobile bonding solution and hope for the best. The better way ist to have a SRT->RTMP gateway somewhere in a datacenter on a VPS (Virtual private server). Than built your ingest stream like this: vMix -> SRT -> Mobile Network -> "Big Internet" -> SRT IN Gateway / RTMP OUT Gateway -> "Big Internet" -> YouTube Ingest THe gateway can be ffmpeg doing the translation or some Docker container doing it for you. My favourite is currently Datarhei Restreamer. If handling this is not for you, ask an IT friend to do it for you. Some more options: - restream.io seems to offer SRT ingest on their premium plans. I just read it, have no personal experience.
- Run OBS somewhere and ingest your SRT source there. Send the output stream to YouTube as RTMP. Make sure the connection from OBS to YouTube is stable and no mobile/WiFi.
- Try Multistreamer, this is the universal stream converter tool (commercial software). Here also make sure the RTMP connection to YouTube travels on a solid connection.
Tip: If you would check the quality of your connection, try the packet loss tester website at https://packetlosstest.com/. Pick the proper settings (Chrome only) and see what you get in terms of late packets and packet loss. Good luck and let us know how you move on. Best, Christian
|
|
|
|
|
|
Rank: Member
Groups: Registered
Joined: 10/30/2023(UTC) Posts: 24 Location: Hull Thanks: 2 times
Was thanked: 5 time(s) in 5 post(s)
|
Thanks Christian. The weird thing is this has operated fine using the same 4G equipment for over 2 years. But I guess there could have been some changes in the network recently. Unfortunately we are renting a school building and we are not allowed to connect to their fibre internet so mobile is the only option.
I realise running 2 streams is worse for the local connection, but as many others are reporting similar issues with Youtube I still think that it is possible the problem is at Youtube's servers, so as a test I was wondering if sending a backup might help. The difficulty is that this problem only shows up on a Sunday morning when we have started our church service so there is little freedom to test at this point. I cannot reproduce the problem at any other time (using the identical hardware setup, but at my house about 1km away so maybe a different cell tower).
Maybe Youtube will get a move on and implement their SRT ingest which they have been beta testing.
I am also going to try updating my VMix machine to Windows 11 as Windows 10 seems to be a common factor for this problem.
|
|
|
|
|
|
Rank: Member
Groups: Registered
Joined: 3/21/2022(UTC) Posts: 29 Thanks: 1 times
Was thanked: 7 time(s) in 7 post(s)
|
Hi, this is not cool. No way to get the school admin to patch you an "Internet only" link at your venue? About the 4G towers you are right, probably experiencing changes in the mobile network. Also, mobile cells tend to "breathe", so maybe somewhere around your tower someboy eles is streaming at the same time and you are now sharing cell tower bandwidth. Please do a packet loss test (https://packetlosstest.com/) and see what you get. During the stream, you can also ping a.rtmp.youtube.com and see if you get packet loss and/or changing roundtrip times. Since YouTube uses RTMP through their higly dynamic system, packet loss and jitter on mobile links can make things even worse. I agree, SRT ingest at YT for all yould be great, until than you need to use a cloud gateway SRT->RTMP. From which country are you? About vMix on Windows 11: I am wondering what is the root cause, I doubt the issue lies with Windows 10 in general. Did you check if you have the up to date network drivers on your system? This is just a wild guess, but since we are talking network issues here, a check would not do any harm... Best, Christian Originally Posted by: congoblue Thanks Christian. The weird thing is this has operated fine using the same 4G equipment for over 2 years. But I guess there could have been some changes in the network recently. Unfortunately we are renting a school building and we are not allowed to connect to their fibre internet so mobile is the only option.
I realise running 2 streams is worse for the local connection, but as many others are reporting similar issues with Youtube I still think that it is possible the problem is at Youtube's servers, so as a test I was wondering if sending a backup might help. The difficulty is that this problem only shows up on a Sunday morning when we have started our church service so there is little freedom to test at this point. I cannot reproduce the problem at any other time (using the identical hardware setup, but at my house about 1km away so maybe a different cell tower).
Maybe Youtube will get a move on and implement their SRT ingest which they have been beta testing.
I am also going to try updating my VMix machine to Windows 11 as Windows 10 seems to be a common factor for this problem.
|
|
|
|
|
|
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
