1) Due to some odd wording in the terms of what’s permissible, your stream can’t be lower quality than what you send to other platforms. Because YouTube offers a higher ingestion bandwidth rate (10+ Mbps) than Twitch (6 Mbps), someone appealing to both services that wants to send the maximum bitrate allowed for quality purposes or even with differing resolutions can be hit due to the technicality:

> otherwise degrading, the video quality on Twitch so that it’s worse than on other platforms would make the user’s experience on Twitch less than other services and, therefore, not meet these guidelines.

2) A popular tool for streamers who aren’t bound by exclusivity (anyone not Affiliate/Partner before this came out) used Restream to both stream to multiple platforms as well as integrate a combined chatroom, for example mixing YouTube and Twitch chats, will have to stop doing so. This sucks for viewer interactivity and would be a net negative to smaller streamers:

> You do not use third-party services that combine activity from other platforms or services on your Twitch stream during your Simulcast, such as merging chat or other features, to ensure the Twitch community is included in the entirety of the experience of your livestream.

So, this feels more like a bait and switch to generate positive PR when a lot of the conversation toward Twitch has been negative the past year, and less of an omission of no longer being the top dog of gaming streaming.

Source: https://help.twitch.tv/s/article/simulcasting-guidelines

They write them like this deliberately -- so they can enforce them however they like, and there's nothing clear-cut so they are largely unaccountable. They're "guidelines" after all -- mere suggestions at things you might like to consider. You know, "guidelines", as in "your account has been closed due to your recent breach/es of the guidelines".

So, if I can't ensure that every person watching on OtherPlatform is having a measurably worse time than every person watching on Twitch, I'm risking my Twitch channel? Unless they came here for a bad time, I guess, so every Twitch viewer must be having the experience that they deem as more than or equal to every OtherPlatform viewer.

I guess if I can't comply with that then maybe I just don't have what it takes to be a god/Twitch streamer.

I don't think there's been an Antitrust complaint against Twitch though -- this complaint would have to be formally raised by a competing streaming platform though, unfortunately. It is not enough that it harms creators or consumers (Consumers cannot raise the antitrust issue -- due to quirks in the US law; it is only competing companies such as Youtube, Trovo, etc, whose competition would be harmed by their actions or the US government who can have standing to raise an antitrust complaint - Antitrust violations and anticompetitive behavior harm consumers and other companies indirectly but the courts only give standing to sue to the actual competitors).

https://help.twitch.tv/s/article/simulcasting-guidelines?lan...

Nothing is stopping the streamer, as a first party, from combining chats.

Many streamers are not technically adept. For them it would be easier to use a hypothetical Chat-Combiner-Third-Party-Service, but they are banned from that. They have to install some software on their computer (many cant), that software needs to be configured and nothing stops twich from pulling tricks ro break it. Basically they make it harder for streamers.

1st party: Twitch

2nd party: An entity Twitch has made an agreement with that lets them merge chats

3rd party: Everyone else

I doubt streamers would dual encode their streams anyway. They'd just use the lowest common denominator.

Even hitbox.tv, back when they tried to enter the fray, had live rewind, for instance.

That would also mean added complexity in the ingest server architecture, because large partners would probably be the first get access to the new hardware. While keeping smaller streamers on 720p 2Mbps or something to keep down costs.

https://en.wikipedia.org/wiki/Twitch_(service)#Amazon_subsid...

The second bit simply says "third party service" - nothing stops you from doing the combined chat overlay locally and streaming the result.

Also, twitch is still very much the top dog, but you're right - they're actually having to compete against youtube now.

The spirit of the terms seems to be they don't want combined chat, and are relying on the fact that most streamers are not going to develop their own chat combining software.

If people try to get past this on a technicality, expect them to revise the conditions.

A huge majority of streamers rely on overlays provided by either the companies Streamlabs or StreamElements for things like displaying a chat on their stream, among others.

For the rest of us who also know nothing, could you expand on your thoughts? Information is much more interesting than an internet slap fight :)

But, silly pedantry aside, my point still stands. It seems like Twitch doesn't want chats combined, regardless of the mechanism.

If, as a user, I think the video quality on another platform is superior to that on Twitch and knew that there was an alternative platform where I could watch the same thing at higher quality, the experience on Twitch is clearly less than that on the other platform. This breaches the first guideline.

> The second bit simply says "third party service"

And this is the real point: it simply says. It doesn't clearly specify, there is no definition of these terms. These vaguely/innocently worded hints will be enforced opaquely whenever they feel like it, without explanation of what, specifically, you did wrong.

I think that is either legalese or poor wording in the text of the actual guideline, The FAQ has this to say about personal use of chat combining software:

> The prohibition on third party tools only applies to content presented to viewers either on or off Twitch.

"tools" and "applies to content presented to viewers" I think gives an idea of how they will actually enforce this versus the "service" wording of the guideline

The viewing experience, if you don't include the chat experience, is better regardless of your connection's speed. YouTube seems to have access to better distribution (you'd think Twitch being an Amazon company they'd be more or less on par), the software works better, the ad policy works better.

Many streamers use bots to interact with chat for things like raffles, giveaways, custom coin gamification... and these bots usually don't support multiple concurrent platforms. Because of this stipulation, I've already witnessed multiple streamers say "if you're watching on Youtube and would like to enter, you must go to Twitch and type !X in chat"

Whether intentional or not, this is a sly way make the actual streamers 301 to Twitch.

It might staunch the bleeding. Instead of losing X streamers a month they lose .5X streamers who just simulcast instead of leaving.

It's an admission that they're not the big dog in streaming any more.

while not at their absolute peak of 2021 they certainly still are in relative terms. They've about 70-75% marketshare depending on the source (https://advanced-television.com/2023/09/04/data-twitch-losin....)

I think that's also supported by the fact that practically any other platform has to lure streamers with expensive contracts. If Twitch wasn't the go to platform any more, that wouldn't be the case.

All this means Twitch isn’t able to capture most of the revenue for the streaming business. I don’t know what they can do to fix it. Perhaps this new non-exclusivity deal is a way of shedding some of the deadweight. If viewers of large streams spread out to other platforms then maybe a lot of the non-revenue-producing ones will move off Twitch. Smaller streams that are more subscription-based may be less likely to do so.

I don't think they are. Given the same size total audience it's much cheaper for Twitch to distribute one stream around the world a million times than it is to distribute thousands of streams around the world a few times each. Transcoding only has to happen once, each segment only has to be distributed to each area of the world once, etc. This gets more nuanced when you include things like chat, which gets harder as you scale up, but I highly doubt that cost is significant compared to the video feed.

Those large streamers may be monetizing their viewers through other means, but as long as they're not actively pulling them away from Twitch those viewers are still either watching ads or subscribing. And based on anecdotes shared by some of those big streamers Twitch ads have gotten more and more profitable.

No, they are, according to internal leaks. Basically, after around some thousand viewers, the cost of a stream grows faster than the income it generates. Though, not sure if it's still valid after their increase of ads in the last year.

> Given the same size total audience it's much cheaper for Twitch to distribute one stream around the world a million times than it is to distribute thousands of streams around the world a few times each.

Same size of what? Viewers? Resolution?

> Transcoding only has to happen once, each segment only has to be distributed to each area of the world once

This has two flaws. Each stream is available in multiple resolutions, and the bigger a stream, the higher the chance someone will pick a different resolution than origin. Similar, most stream are kinda local, but with bigger streams, chance raises that it goes into some different corner of the world. So your argument is only valid under the assumption that the baseload of each stream would be exactly same in every detail.

But you also miss the important detail, that traffic costs, and there is only so much you can do to reduce it. But somehow you think that between 1k viewers, 10k viewers and 100k viewers there is no relevant cost-difference?

> And based on anecdotes shared by some of those big streamers Twitch ads have gotten more and more profitable.

Yes, but that's a very recent development.

It's the best use-case for webRTC-based delivery though. They could be saving ~90-95%[1] of their bandwidth cost on these use-cases, I find it very intriguing that they haven't adopted it after all that time.

[1] actual production number when I was working on that topic.

Maybe Twitch's management effectively prefers 3s of latency at 20x the bandwidth cost of 7 seconds of latency, but I have to admit that it would surprise me.

Twitch is an interactive medium, not merely a video stream delivery platform. Streamers chat with their viewers and play games with them. They run merchandise giveaways based on guessing games. Low latency is critical for these applications.

If a stream viewer sees a ton of people guessing random words or numbers in chat before they even see the streamer mention what everyone’s guessing at, they’re going to have a bad experience, leading to disengagement. Twitch goes out of their way to lower the latency. They even offer options in the client to switch to a lower latency mode, at the expense of stability.

But then I eventually understood that you're talking about latency between viewers and then indeed it would be a very frustrating experience.

Fortunately it's not what I'm talking about: I'm talking about having some latency (or rather “buffer size”) for all users, with synchronized playback between viewers. And again we're not talking about a prohibitive buffer size but rather a 5-15s buffer size, which is pretty common for live streaming services.

It also doesn’t solve all of the interactivity issues. If a streamer is directly chatting with their viewers, a 15s latency is huge! It effectively makes normal back-and-forth conversations impossible and therefore leads to disengagement.

Why is this such a problem? Look at the relationship between engagement and monetization. Highly engaged viewers give way more money to streamers than do passive viewers. Highly engaged viewers are simply way more valuable as an audience, so their experience is given top priority. This is why best-effort low latency without synchronization makes sense. Lowest-common-denominator synchronized video sounds much more difficult to achieve if these “power viewers” are your priority audience.

It works exactly as for non-p2p streaming, as the playback synchronization is independent from the p2p part and entirely managed by the video player through its buffer management system. Basically you get the “latest block” from the stream's manifest (that always comes from the CDN) and then the player is playing a few blocks behind and keeping its buffer full.

> What does the latency look like after that? 15-20s for everyone?

Yes, but that's already the case for most live streaming website you can find unless they specifically aim for low-latency (which comes with a QoS drawback since smaller buffer means buffering is more likely for the end user if the connection isn't flawless, so going to low-latency is a trade-off) and it was the case on Twitch itself before 2019.

> It also doesn’t solve all of the interactivity issues. If a streamer is directly chatting with their viewers, a 15s latency is huge! It effectively makes normal back-and-forth conversations impossible and therefore leads to disengagement.

It's less convenient, but at the same time Twitch has worked like that for almost a decade so it's not a complete showstopper. And again, 15s isn't the minimum you can reach, it's going below 5s that's not necessarily feasible (also, when I left my former employer, 5s was the limit but people were working on that so maybe they managed to reach 3s as they were trying to).

> Highly engaged viewers are simply way more valuable as an audience, so their experience is given top priority. This is why best-effort low latency without synchronization makes sense.

Maybe, but how many times more valuable? Has the per user value increase by a factor 20 since 2019? If no, maybe having reduced the bandwidth cost would have made more sense that trying to improve engagement.

Those blocks still need to be sent to the new user's entry point to the CDN. I doubt you're going to save any money by sending every single video stream to every single node in the CDN. You're going to send the video only to nodes that have connected viewers of that particular stream. Then you have the issue of pausing everyone else’s feed until the new user catches up.

Yes, but that's already the case for most live streaming website you can find unless they specifically aim for low-latency (which comes with a QoS drawback since smaller buffer means buffering is more likely for the end user if the connection isn't flawless, so going to low-latency is a trade-off) and it was the case on Twitch itself before 2019.

I think Twitch has moved on from that. Users' expectations have gone way up. They want more interaction with streamers, not less. They aren't going to tolerate a backslide to higher latencies if the only purpose is to save Twitch money. Competition from other platforms, especially YouTube, is fierce.

High latency (>5s) leads to this shallow form of engagement where viewers send one-way comments to the streamer and then wait (and hope) they hear back. Low latency promotes live conversations. This is especially critical on small streams where the number of people in the chat doesn't overwhelm the streamer. And as I said before, smaller streams are less likely to have streamers who lean into heavy third-party monetization strategies. These streamers often develop closer relationships with their viewers and have a higher percentage of subscribed viewers.

Maybe, but how many times more valuable? Has the per user value increase by a factor 20 since 2019? If no, maybe having reduced the bandwidth cost would have made more sense that trying to improve engagement.

I think they are trying to reduce bandwidth costs, but not uniformly across users. My theory is that they are trying to discourage casual viewers who don't subscribe. Getting rid of these "freeloader users" would naturally cause per-user value to go up!

What? The meat of the cost isn't when sending videos segments to the CDN, it's what the CDN charges you for sending those segments thousands of time.

> Then you have the issue of pausing everyone else’s feed until the new user catches up.

No, if the p2p system isn't working well, it falls back to the CDN transparently for the users. And again it's not something theoretical, we ran this in production for up to several hundred thousands viewers, and it was working great.

> I think Twitch has moved on from that. Users' expectations have gone way up. They want more interaction with streamers, not less. They aren't going to tolerate a backslide to higher latencies if the only purpose is to save Twitch money.

Maybe, people getting used to comfort and never wanting to go back is a real phenomenon. But Twitch had many years between when I worked in the field and 2019 to deploy such a system without degrading the experience and to me it's pretty disappointing that they didn't.

The latency between streamer and viewer on Twitch (in low-latency mode, which is the default) is normally less than 5 seconds and often between 1 and 2 seconds. The player actually slightly speeds up the video if it exceeds 5 seconds.

This is essential for interactivity, because the streamer can ask a question and get a response without constant awkward pauses.

Maybe it improves things but we're back to my previous comment:

> Maybe Twitch's management effectively prefers 3s of latency at 20x the bandwidth cost of 7 seconds of latency, but I have to admit that it would surprise me.

You can't be suggesting that the source streamer sends out millions of webRTC streams from their house, can you?

If you use HLS to deliver video to viewers, you can cache segments in a CDN. Your CDN. Someone else's CDN. You'll add some latency, but your bill will be lower.

It's not about just switching protocol nor it is about the source steamer (who should never be exposed, for DDoS/doxing reasons). But instead of delivering the video from the CDN to all users directly, you build a p2p network of viewers and have non-leaf viewers rebroadcast the video segments they've received (either directly from the CDN or from another peer).

It's obviously not as trivial as the description above implies, but it's not very hard either and for live streaming with lots of users it works very well. (I used to work on such a system and deployed it in production for streams with up to 300k concurrent viewers)

P2P may be explored again.

- don't do full P2P, keep twitch as a central server, and delegate only part of the load to P2P to those with good connection, with progressive roll in as buffering grows

- get a 2 minutes padding between the live and actual video streaming, so that you have a decent buffer and margin of maneuver to switch back to twitch server

- create an OBS clone that does streaming and video client with less ads as you said, but that act as an optimized node that works even when you don't what a video (the more you accumulate up time, the less you see adds, you get points, etc)

(Edit: I love how I get downvoted when saying that although I literally built a p2p streaming software and I'm citing actual configuration requirements we had in production back then)

[1] https://www.lumen.com/help/en-us/cdn/mesh-knowledge-base/faq...

From your description elsewhere was it using the WebRTC data channels to deliver DASH/HLS style segments or actually using the MediaStream stuff?

I think the magic info we're missing here is what the Twitch viewers are watching on, and my hunch is it's a lot of mobile for which the P2P idea will not work (and/or provoke angry messages from mobile operators). In the case of smart TV then I can see the P2P idea saving a lot of money, but I don't believe there is even an official Twitch app for Samsung TVs so they don't seem to think that is where their audience is.

Generally 10-20s depending on the size of the video segments. For streams we controlled entirely, we could even go as low as 5s (at the expense of short video segments).

> From your description elsewhere was it using the WebRTC data channels to deliver DASH/HLS style segments or actually using the MediaStream stuff?

The former, but we'd split the segments in much smaller chunks for delivery purpose.

> I think the magic info we're missing here is what the Twitch viewers are watching on, and my hunch is it's a lot of mobile for which the P2P idea will not work (and/or provoke angry messages from mobile operators).

Yeah mobile is more complex than desktop because you must not incur spendings on the viewer side and because battery use is paramount. But you can still get good result by setting the mobile users as leaf node (receiver-only).

> In the case of smart TV then I can see the P2P idea saving a lot of money

Yeah, smart-TV and set top boxes were a very important segment for us. But as you said it's probably not Twitch's market.

You are totally right to call out battery life. I have worked in mobile a long time (including webrtc) and find people persistently underestimate how irrelevant sounding changes, such as vp8 vs h264, can suddenly make things intolerable for a lot of users.

Anyway I'm very frustrated that after 8 years the concept has not been adopted by the industry despite the very positive results we had.

Our main challenge back then was more related to the business model of a third party technology provider because each customer required integration with their entire video pipeline, but the fact that big players still haven't rolled their own p2p distribution tech after all that time is something I really don't understand.

Seems like twitch de facto dominates the gaming "niche".

Once TikTok really took off, you began to see twitch streamers pushing their TikTok a lot more and using that as a way to grow their community on twitch.

The problem now is that both YouTube and TikTok have significant streaming platforms. That means someone with a strong YouTube presence can just skip converting users to twitch as that is already hard enough and just stay on the YouTube platform.

My guess is that this is an effort to stymie that “leak” of twitch streamers that decide to stay on the platform where they’re seeing their biggest growth.

Here’s a video to back up this point: https://youtu.be/0i9gkprYekI?si=pM_u9-Lt_fBQ3glk go to 32:00

Purely from a user perspective it’s even worse now that every stream gets an ad before you can watch any of the content.

And purely from a user perspective it’s even worse because you have to go by game category then scroll through however many pages of channels there are in the category you’re interested in.

They did just add stories as a feature which might help if it’s implemented correctly.

There are a number of things I like about twitch. Top is searching by games. On YouTube I'm lucky if my results are related streams at all, where on twitch, it is 100% the game I wanted ranked high to low.

I also Like the raid mechanic for finding new streamers. Last, I like the twitch community where I find streamers because they are hanging out in other stream chats-something I have never seen on YouTube

I do agree on the twitch raid system too. It’s especially useful for smaller communities that tend to support each other and have relatively similar content.

Might have something to do with their quirky UI and terrible search function.

They stop losing streamers to other platforms because of the previous twitch-only stipulation.

They could probably get viewers back fairly easy through advertising or tie ins to games, but doing that with streamers would likely be harder.

People find a stream on youtube -> they hear the streamer mostly interact with twitch chat -> they think twitch is the main platform (if they want that kind of interaction.)

My best guess is that they are trying to keep more communities on Twitch at the cost of letting some viewers leave. The new rules about not combining chats or other features (sub notifications?) means you have some real network effects that will keep many viewers on twitch and keep the streamer primarily focused on Twitch because there's no low-cost migration path for their community anymore.

Power users will probably use extensions that let them watch a higher quality Youtube stream with Twitch chat enabled, and if most of the community is on Twitch they may want to subscribe on Twitch as well. In the best case scenario Twitch gets all the revenue they would have gotten ($2.50/m from the sub) without any of the cost of delivering the video.

Further, IF they can keep the community and the engagement on Twitch then they might have turned their simulcast weakness into a strength. If viewers organically find the stream on Youtube or Kick or whatever and enjoy it but see that all the chat and alerts are from twitch and want to participate then they might jump over. YouTube's live discoverability is awful right now so its kind of moot but it could be a thing in the future.

Twitch just passes through the stream you provide without transcoding at the top quality level. They only transcode for resolutions lower than you are providing (and ration those transcoding services).

YouTube always transcodes, even if the resolution/bitrate you are streaming is suitable for viewers, slightly lowering quality.

Therefore unless you are providing a lower resolution or bitrate stream to Twitch yourself, you can never fall foul of this. YouTube will always lower the quality from what you provide.

The "no-combining activity" is a direct shot at Restream.io etc which provide unified chat streams.

Nice to see the note about Jacksfilms, it's cool that this is getting into mainstream news

> 11. Simulcasting

> When you are streaming live on the Twitch Services you may not simultaneously live stream or broadcast (“Simulcast”) on any other “Twitch-like Service,” meaning any web-based network, platform, or service that supports live streaming of user generated content, without advance written permission from Twitch. For clarity, you may Simulcast on mobile-first services that support live streaming. This Section does not apply to non-profit or government entities that are live streaming for non-commercial purposes.

Twitch-like being YouTube, Kick, and similars. Mobile first being Tiktok, Instagram, etc - vertical/portrait resolution

https://www.twitch.tv/p/en/legal/terms-of-service/#11-simulc...

I imagine this will be changing soon so for posterity https://archive.ph/Y3Vti#11-simulcasting

My point is just that he really seems to makes an effort to understand live streaming, I'm somewhat cautiously optimistic about the future of Twitch with him on the helm.

Clancy on the other side is so far on a constant quest to explore and live a Streams life and engage with people. Really impressive. But also generally very unusually for someone in that position to appear this active in Public.

Note that Twitch limits stream quality in certain country. For example, in South Korea, content is transcoded to 720p or lower. [1]

[1] https://www.thegamer.com/twitch-korea-limiting-stream-qualit...

The lock and pick are great examples. LPL, McNally Official, and Covert Instruments are great examples of this phenomena.

Mo matter the security or restrictions put in place there is a, not insignificant, portion of the population that will circumvent.

The tighter the grip, the faster the slip.

Strongly believe that no other competitors have gotten their chat dialed down as well as on Twitch. Would be a shame if you go to Youtube to watch on better bitrate but participate on Twitch chat.

> We believe in giving you the freedom to simultaneously stream on other services, but we also want to ensure that the Twitch user experience is not compromised.

If "giving you the freedom" means "taking a small step to restore liberties that we snatched from you" then this sounds good. Accepting that you have done something wrong is always a good first step.

Onto the actual guidelines (never use the 'R' word[1]) -- there's only three, phew!

> You ensure that the quality of Twitch users’ experience of your [stream is] no less than the experience on other platforms or services, including by your engagement with the Twitch community, for example, via chat.

Who decides which "experience" is "less than"?

Compare the number of shoutouts to chat?

Ignore good questions from Youtube users because nobody on Twitch is saying anything interesting? Which leads to a worse experience on Twitch.

The only safe way to comply with this is, I guess, to not mention the other platform, do not interact with the users on the other platform, cripple the video quality on the other platform.

> You should not provide links, or otherwise direct your community, to leave Twitch for your simulcast on other services because we value the community on Twitch and the integral role community engagement plays for all Twitch users.

"Should not" -- OK, but I can some of the time, maybe just a little?

Does "direct your[2] community" include saying "hey youtube"? Again, do not mention the other platform.

What if during your Twitch sanctioned Twitch chat interactions, someone asks "what's the deal with you streaming on Youtube at the same time as here? (and how can I get an internet connection like what you have?)" -- I assume you can answer the question, as long as you say the word 'Twitch' at least as many times as you say 'Youtube'?

It's bizarre that this one includes a rationale for itself. I don't care what your (stated) reasons are, Twitch. You have all the gems already, Twitch. You get to make the r-guidelines, Twitch.

> You do not use third-party services that combine activity from other platforms or services on your Twitch stream during your Simulcast, such as merging chat or other features, to ensure the Twitch community is included in the entirety of the experience of your livestream.

Uh oh, we in the "do nots" now.

Again with the weird rationale thing. It just makes it even more confusing. For example, how would merging the chats exclude people? Surely merging the chats would include Twitch users in more of the experience -- you know, because they can see all of the chat.

> If you fail to adhere to the Simulcast Guidelines, Twitch will send you a warning prior to taking any enforcement action.

OK. So it's Youtube closing channels out of the blue because someone just felt like it, or a computer suggested it.

"""Dear HUMAN,

You may have noticed that you have received 1 warnings on your account. This is never a nice thing to heard -- we know how it feels, friend! :3

The warning/s are pertaining to your recent breach/es of the Simulcasting Guidelines, which you can review at the link below.

We regret to inform you that,

you are ours,

your sincerely real,

Friend Humans at Twitch"""

[0] https://help.twitch.tv/s/article/simulcasting-guidelines

[0+] Bonus: simulcast is a portmanteau that is really unnatural to say (AU)

[1] Rules. The 'R' word is rules. We don't like it because it assigns some responsibility and accountability to the enforcers.

[2] It's funny to see them acknowledge that the audience is there for the streamer, not the platform.

To be fair, they never really executed this rule, unless you were a top-creator in the Millionars-club. Small streamers were doing this all the time since years, never had problems. I think because of reactions to the last scandal, and Ninjas move to multistreaming, they were forced to learn to change their view.