Twitch has been messing with streams again and putting 15 second placeholder countdowns for ads. You know, so adblockers can't skip streams.
@lynne how does that appear on mpv?
@wolf480pl They also have a stream uplink disconnect stream replacement _enabled_by_default_.
Which part of _do_not_touch_the_stream_ do they not understand?
They're so ruthless they even strip the H264 SEI.
@lynne Since when is "do not touch the stream" anything twitch agreed to? I thought they were transcoding in the past, so touching the stream in other ways doesn't seem all that surprising.
I guess it can break the stream in subtle ways, and the more you know how this stuff is supposed to work, the more annoying it will be. Still, it's kinda like being upset that a hotspot at a train station has a captive portal. Of course it does, they're assholes by default.
@wolf480pl They haven't had the capacity to transcode every stream for a very long time now. Currently they only transcode partners and such.
The biggest issue is that changing bitstreams after init breaks a lot of decoders, especially hardware ones on SoCs. And the second biggest issue which might as well be side-by-side with the first is that timestamps jump. This screen starts at timestamp 0. After it ends, the normal stream is shown, which has a start timestamp of however much time the streamer has streamed, since streams always start at 0.
Timestamp jumps with HLS are nasty because timestamps directly relate to which segment you need/expect to download. So a lot of players just freeze, expecting a segment that never arrives.
Its easy to write a good HLS demuxer that works for streams. Its much more difficult to write one which works on streams and elsewhere, which is what multimedia frameworks are expected to provide.
@lynne what the fuck...
are the timestamps part of the container or part of the h.264 codec?
If part of the container, can't they demux, then modify, then remux with new monotonic timestamps?
They could modify or cludge the timestamps of their replacement streams to be "close enough" to let pretty much all players go with it but instead they insert an HLS discontinuity flag, which is usually ignored by demuxers because its not well defined and has kind of lost its meaning.
But hacking their timestamps is kind of difficult due to the alignment requirements and latency requirements. Believe it or not, this is a huge problem to DASH/HLS streamers, if megacorp-sponsored tech conferences are to be believed, because every second talk is "Here at X-corp we do Live OTT DASH/HLS Ad insertion that messes up the least, aren't we awesome for bringing you prescription med ads while watching Nemo on Hulu?".
@lynne latency... right...
@ivesen I know all about that. First, they messed up the timestamps and signaled ads via SCTE-35 protocol. That's right, they signaled ad insertion so ad blockers were written in a day to cut the inserted segments off. Someone who works in broadcasting WTF'd because they were misusing a broadcast protocol on the internet that's traditionally used to signal regional cable providers to insert their own ads.
They stopped since this broke a lot. But during the 5 or so months they did it, they _never_ removed the SCTE-35 flag. That's incompetent.
Then, around November and until February, they did by far the most messed up thing by "tweaking" the timestamps. To prevent anyone else but their own player playing back a stream so ads would get played. On every stream. So normal, compliant players broke because what do you expect when the timestamps jumps up N seconds in the future and you think you've missed segments. Their player hacked around this.
Now it seems they're making a weird hybrid scheme to keep ads shown.
A Mastodon instance for people interested in multimedia, codecs, assembly, SIMD, and the occasional weeb stuff.