Question / Help Video shutters on twitch for viewers, audio is ok

[Roboserg]

So I am from Germany, streaming on twitch, 100 viewers on average. My problem - many viewers (5-10 per stream every time I stream) say that video shutters, but audio is fine. I had these complaints for month. Dont know what to do, need you help.

Info about my stream:

My internet is 100/5 mbits, latency to Frankfurt server is 10 ms. Have 0 drops per stream (about 6-7h). Streaming with 2400 bitrate, buffer size the same. Using CBR as twich suggests. Video at 720p. CPU preset - faster. Was using multithreaded optimizations. Was also testing my speed with speedtest.com for Frankfurt - 100/5 as it should be.

I am really desperate here, my specs seem perfect, yet 10+ viewers constantly complain. My viewers are mainly Russians, but they say other twitch streams dont shutter / freeze, only mine. I was having exact same problem with some other streams too tbh.

 

[Kharay]

If it is only a limited number of users (5 - 10 users on a total of 100 is a fairly low percentage), it could simply be... their connection to Twitch being an issue.

Fact of the matter is, Twitch has been getting worse over time for quite some time now and they may simply be experiencing this problem. As long as you aren't dropping any frames while they are experiencing this problem, it really most likely is something about their connection to Twitch.

That said -- could you post a recent OBS log of a session that had people complaining? http://obsproject.com/forum/viewtopic.php?f=5&t=97

 

[Roboserg]

Yes here is it:
http://pastebin.com/sZeJBZRQ

Problem is, they all say they dont have this problem with other streams. And they all got same problem - audio is fine, but the video is freezing for couple of seconds every minute or so.

 

[Kharay]

02:45:57: Total frames rendered: 982830, number of late frames: 1738 (0.18%) (it's okay for some frames to be late)
02:45:57: RTMPPublisher::SocketLoop: Graceful loop exit
02:45:57: Number of times waited to send: 0, Waited for a total of 0 bytes
02:45:57: Number of b-frames dropped: 0 (0%), Number of p-frames dropped: 0 (0%), Total 0 (0%)

Late frames -- Literally what it says, frames not being rendered in enough of a timely fashion for OBS to also be able to encode them, basically.
Dropped frames -- Connection having trouble.

Now, 0.18% late frames is obviously not 0% but still, it is a very, very acceptable margin and does not explain what some of your users are experiencing. Not by a long shot. That said, you could consider going with Veryfast instead, which will reduce the number of late frames to 0% for you and should look essentially the same. If they would still experience this mild video stutter at 0% then there really is not much you can do. Sometimes it really just is Twitch.

 

[nrw2000]

Today twitch use US servers for viewers in Europe. It's crazy and cause lags for streams with bitrate more than 2000 (more than 1500 sometimes). You can check twitch server by following steps:
1. Start view any stream
2. Open windows task manager
3. Go to performance tab and click to resource monitor
4. Go to network tab
5. Expand network activity
6. Select FlashPlayerPlugin_[version].exe
7. Find line with remote port 1935 and remember remote IP address
8. Go to http://www.ipligence.com/geolocation and check country for IP address above

If found country in Europe - you are lucky.

 

[nrw2000]

Today twitch use US servers for viewers in Europe. It's crazy and cause lags for streams with bitrate more than 2000 (more than 1500 sometimes).

Yesterday, twitch lag for streams with bitrate 1400-1500, good progress! Hashd.tv works fine with bitrate 3000 and higher, but zero viewers on it :(

 

[Pugget]

Today twitch use US servers for viewers in Europe. It's crazy and cause lags for streams with bitrate more than 2000 (more than 1500 sometimes). You can check twitch server by following steps:
1. Start view any stream
2. Open windows task manager
3. Go to performance tab and click to resource monitor
4. Go to network tab
5. Expand network activity
6. Select FlashPlayerPlugin_[version].exe
7. Find line with remote port 1935 and remember remote IP address
8. Go to http://www.ipligence.com/geolocation and check country for IP address above

If found country in Europe - you are lucky.

Could you post the exact steps you are taking to produce this result? This should not be happening with 100 viewers on the stream, ever, never, ever, and if it is, it needs to be debugged. Under normal circumstances, we do not use US servers for streaming to Europeans (nor the other way around). If you don't want to post your information, feel free to PM it to me. Thanks!

Edit: We do use 1935 for our IRC servers in San Francisco (along with several other common, and normally open ports) - are you sure you weren't just seeing the chat connection? What was the hostname of the box?

 

[Krazy]

I think some people wrongly assume that the IP they are seeing is where they are actually getting their video from (I used to assume this as well)

A better tool is this: http://sourceforge.net/projects/jtv-dow ... s/release/

You simply enter the channel name of a livestream, and it will pull up useful info like bitrate, viewers, let you choose between the different transcodes, etc. The important bit here, however is the "node" section. This will show where you are actually getting your video from. Here is an example: http://i.imgur.com/KA7KxbV.png

You can see for me, the node line is "video3-2.iad02" which means the server from Ashburn (IAD is the abbreviation for Dulles airport which is right there). European nodes will be along the lines of "video6-1.ams01" which would be an Amsterdam node. So, as Pugget mentioned it's EXTREMELY unlikely that you will be sent all the way to a US node, and the IPs and data you are using are not correct.

What's the real issue? I honestly have no idea. It's possible that the servers are just that overloaded. Streaming really has exploded in popularity over the last couple years. It's also possible ISPs are doing throttling at certain times of the day, or have hidden bandwith limits, or don't have good peering agreements (an increasing problem here in the US -_-) with other ISPs, etc, etc.

 

[paibox]

So, while I'm being told that the IP the Flash player connects to doesn't actually matter, the fact does remain that for me (and many other Europeans) it has been pretty much impossible to watch the live feed (Source) for a rather long time now.

While the tool Krazy links shows a number of video##-#.arn01 nodes, which is supposedly a Stockholm server (which would make sense, since I'm in Sweden), it's literally impossible for me to watch a stream with a bit rate above 1500 or 2000 or so without major stalls. Curiously enough, I used to be able to watch European streams just fine (adam_ak, tornis), while US streams would be completely unwatchable (sevadus, manvsgame). Recently, though, the European streams have started acting up as well.

I guess this could quite possibly be my ISP's fault, but it just seems weird when so many Europeans are reporting similar problems with similar bit rates. (Not just in this thread.)

 

[Kharay]

paibox, any particular stream? It would be good feedback to have people from different regions in Europe try the same stream at the same quality. Just to see whether or not it is indeed a (semi-)local issue.

 

[paibox]

Sure, the stream I'm watching right now (to test it) is http://www.twitch.tv/Eg_fLoE

But basically, any stream with a bit rate around 3000 should do for testing this. I've not had a stream around that bit rate play back properly for months.

 

[alpinlol]

i do have the same problem as an european viewer .... some streams work without a problem no matter how many viewers some streams are just unwatchable due to the nonstop laggs with continuing sound or even with the msg you are experiencing stuttering blah decrease quality blah .... i start getting pretty pissed because this has been a problem for over 4 months now and i report every stream with the hope that its going to get fixed in the future

 

[nrw2000]

Sure, the stream I'm watching right now (to test it) is http://www.twitch.tv/Eg_fLoE

But basically, any stream with a bit rate around 3000 should do for testing this. I've not had a stream around that bit rate play back properly for months.

Tested from Moscow. "Source" - video stuttering each 10 seconds, audio is fine. Using Amsterdam server according to JTV Downloader. "High" is working well.
ISP download speed - 60Mb.

It's weird. Twitch streaming from 192.16.65.164 and according to http://www.ipligence.com/geolocation it's US ip. But according to JTV Downloader it's video2-2.ams01 (Amsterdam).

P.S. Today I found only one way to stream with bitrate 2000 - use live-ord.twitch.tv for upload. In this case twitch use video21-2.sfo01 for viewers without lags.

Edit: Twitch making some magic? Now all my streams downloading from videoXX-X.sfo01 (San Francisco?) independently from which upload server I use.

 

[Kharay]

Sure, the stream I'm watching right now (to test it) is http://www.twitch.tv/Eg_fLoE

But basically, any stream with a bit rate around 3000 should do for testing this. I've not had a stream around that bit rate play back properly for months.

Same phenomenon here. And it even goes as far as not being able to watch my own stream as I am streaming. Even at bitrates lower than 3000. And interestingly enough, the VODs are just fine to watch. No lag, no stutter, caching is very smooth.

 

[Pugget]

The IP the flash player connects to is the real IP - but it connects to many IPs, and we use 1935 for more than RTMP. Your best bet is to use a packet sniffer to figure out who you are talking RTMP to.

There are a large number of reasons a stream can stutter, and only a few are directly under our control. We have been having issues with ingest in the EU the past week, which continued today much to our chagrin, and we continue to work on solutions; that would cause "lag" on the broadcaster side, which is then seen by all viewers. We have a firm grasp on what the problem is now, and are working on solutions. Much of the stream stutter on streams broadcast from EU was likely due to such ingest issues over the last week.

In general, please encourage your ISP to peer with us; it helps us, and it will help you! ISPs need to hear from their users in order to care about such issues.

 

[Krazy]

Yes, peering is a large part of the reason streaming video (on any site) suffers from poor performance. The TL;DR is that it's a giant dicking waving contest, with no actual reason. There isn't any sort of bandwith shortage, so all these "problems" are generally artificially created.

 

[paibox]

It was a popout player, so if you're using 1935 for more than RTMP in that one, I would be sort of weirded out. Either way, I can't do much about the peering, Telia are notorious for not listening to their customers.

On a side note, I got pushed over to level3 earlier today, and I was able to watch a stream properly for the first time in months. It was glorious, but it sadly only lasted for that one stream. :)

Also, these are definitely not issues on the ingest side, US broadcaster, stream works fine in the US, etc, all that. I understand if you can't do anything about it, but it's still frustrating.

 

[Luk]

Hooking into this discussion as I've been unable to watch almost any stream on Twitch.tv that runs at a bitrate of >2000. I'm living in western Germany and my ISP is Telekom. I'm connected with a 50mbit/s down- and 10mbit/s upstream.

The problem exists with streams from EU and US. I'm currently watching http://twitch.tv/voyboy and Source always has the same pattern.

1. Start stream
2. During the first five seconds the stream is stuttering (audio+video, "Your stream appears to be..." -warning)
3. Approx. 3-6 seconds of perfectly fine stream
Download of ~200-350Kbytes/s
4. Video freezes, randomly displays a new frame every one or two seconds, download speed drops completely, audio is 100% fine
Download drops to 50Kbytes/s
5. Download catches up again
Burst at 400Kbytes/s, goes back to 250Kbytes/s
6. Go to 3.
This is how it looked in the Task Manager:


This has started about three weeks ago. I've used different browsers, different flash plugins, a command-prompt-program that should "fix" it (it displays the average/current bitrate every second) and nothing has improved it at all.

Today I noticed something different when watching a Minecraft stream ( twitch.tv/sevadus ) which is most likely from the US, too: I was able to watch Source without an issue!

Sadly I didn't record any information about which IP was streaming to me, but the observable network-usage pattern changed.
This is how it looked in the Task Manager:


Although those pictures might look like they've been painted by a 3-year-old, they are pretty accurate (as far as it can be without a scale on that y-axis).

It really is a pain not to be able to watch any stream on the Source setting since almost every single one is above 2000kbit/s and "High" looks very bad when there's much motion in the video :(

EDIT: Ah yes, I have to also say that VODs are never stuttering. They may take some seconds to actually start up, but their loading speed is always way above the actual playback bitrate.

 

[Kharay]

Yes, sadly, transcoding is not really proving to be really "High" quality as the high quality label would suggest. Just now I locally recorded something in OBS at superfast but at VBR Q-10 with a buffer size of 0, so vbv would just use whatever it needed. The recording was spot on. Uploaded it you Youtube (which also transcodes). The result... facepalm.

Same goes for Twitch's transcoding. It's just not the same. WTB [Source].

 

[Pugget]

Luk,

Can you try and grab the IPs or server names of the servers that are producing both the crappy and good content? That would be most awesome!