plugins.twitch: add --twitch-supported-codecs #5769
Conversation
|
Btw, setting |
|
This seems to work. I've been able to watch the stream of r0dn3y with any of the selected streams working, including the 1440p120 hevc stream, but the behavior of the parameter is kind of weird. The current stream of r0dn3y offered 480p30 (avc), 720p60 (av1), 1080p60 (av1) and 1440p120 (hevc). Now when I pass |
|
This is not "parameter specific" and has nothing to do with the plugin implementation. It's just the data which is returned by the multivariant playlist when setting the See the examples in the OP. I have no idea why they don't return all the streams when
|
|
I don't know why but I have h265 in |
|
I also get Edit: Actually the playlists for just |
You can enable HEVC support on firefox by setting |
|
h265 is irrelevant, because it's a patent encumbered codec, hence the development of AV1 by the AOM. As said in the OP, I'm surprised that Twitch even offers streams using this codec in their beta program, because this is all about AV1 support. If you request the multivariant playlists on Twitch and set There is no reason to add h265 here, because Twitch won't use it. |
|
While I do understand you reasoning for preferring AV1 Twitch mentions both AV1 and HEVC on their beta page and obviously allows both AV1 and HEVC streams being served. Why not just add the value |
That is surprising, tbh... Let me update the plugin arg real quick, with support for all possible name combinations. |
bastimeyer
force-pushed
the
plugins/twitch/supported-codecs
branch
4 times, most recently
from
62c3d06
to
535ce45
Compare
|
Rebased to master and made some changes to the new plugin argument setup, so the allowed argument values are defined there and not in the UsherService class. Simply sideloading the plugin from the PR branch won't work anymore. To anyone who wants to try out this PR, you'll have to install from the PR branch, because it relies on new code on the master branch. |
Add the temporary `--twitch-supported-codecs` plugin argument for being able to set the client's video codec preference. Set the default value to "h264" to ensure that no compatibility issues arise on clients without AV1/HEVC decode capabilities.
bastimeyer
force-pushed
the
plugins/twitch/supported-codecs
branch
from
535ce45
to
539b77e
Compare
Free public streams (even with ad) don't require patent royalties for hevc/h.265 |
|
The new AV1 and H265 streams are backed by MP4 containers instead of MPEG-TS, which have slightly different streaming capabilities. MP4 is a lot more susceptible to the stream becoming corrupt if packets are dropped or partially written, MPEG-TS inherently allows this and can just re-sync the stream on errors. I'm not sure how much of a problem this is in regular use, I'm not sure if streamlink buffers whole segments before writing them or not, but I imagine at least when using |
I'm aware of them having switched the container format, but that shouldn't matter. Streamlink does support HLS maps (initialization sections), which is requirement for fMP4, so we're perfectly fine here. The error resilience of an MPEG transport stream should only be relevant for non-bi-directional data transmissions like DVB, and not for HTTP(S) connections over TCP (with TLS). Twitch is not the only platform which (now) uses fMP4 HLS streams. I've never seen such errors with other fMP4 streams which you worry about. In regards to stream discontinuities, this also shouldn't matter, because this is based on full HLS segments and not on partial segment data, and (most) decoders should be able to recover from a gap of data here as well. If |
|
The problem would be if something happened to the connection mid-segment download, either on the user or the server end. MP4 (ISOBMF) boxes use length prefixing, MPEG-TS uses a fixed packet size and sync bytes. If a write of an MP4 segment is interrupted without writing the specified box length, the stream will get out of sync with no way to re-sync. For MPEG-TS, the demuxer will notice that the sync byte isn't correct and it will re-sync to the next sync byte. So the problem situation is for example if there was some error in the middle of downloading segment 1000 and it was only partially written to the output, when it starts downloading and writing 1001, the demuxer would still be assuming it's reading the partially written box from segment 1000, and when it "finishes" reading the box and tries to parse the next one it will just see garbage data and be unable to continue decoding the stream. |
|
I consider this issue far too rare for it being relevant. A segment download would need to stop mid-way for some reason while the next segment or another one after that (#5603) would need to continue regularly, so parts of the incomplete bitstream of the previous segment get skipped. As said, this would only work when data gets streamed to the output buffer. This is not worth making sacrifices in terms of output delay or implementing bitstream inspection in Python before writing data to the output, which would be slow and also rather complex (see https://github.com/beardypig/pymp4). If a user has an unstable connection and the bitstream-continuation of the HLS segments can't be guaranteed due to that, then they shouldn't set the stream option (which also gets enabled when |
|
I agree it's probably a rare issue, so not sure if it's worth pursuing, but I also don't really think it would be that complex. You don't have to implement full MP4 parsing, you just need to parse the first 32 bits of the top-level box to get the length, buffer that amount, and then write it out, and repeat. If the segment EOFs before the length amount is read, discard the buffer. The buffer would only have to hold the single largest box, which in an fMP4 stream should be fairly small (kilobytes range). |
|
It's March now... Have there been any developments on the side of Twitch? |
|
@bastimeyer I have not seen anything from them regarding this. |
This comment was marked as off-topic.
This comment was marked as off-topic.
A timeline has not been announced. Though AV1/HEVC is intended to be experimented with more widely as part of the Enhanced Broadcasting beta. So it'll be more than just my channel soon™ |
Add the temporary
--twitch-supported-codecsplugin argument for being able to set the client's video codec preference.Set the default value to "h264" to ensure that no compatibility issues arise on clients without AV1 decode capabilities.
Resolves #5768
The set of returned streams by Twitch depends on the broadcast and which codec(s) the channel uses for its stream upload(s) (channels can now upload multiple qualities at once according to the Nvidia announcement from a couple of days ago where they talked about their Twitch and OBS partnership on that matter).
There doesn't appear to be any re-encoding in AV1 done by Twitch (yet) and from what it looks like, only one "480p" h264 stream is included as a fallback when
av1,h264is chosen.No idea why
av1does include one720p60h265(hvc1/HEVC) stream.av1,h264does not. It's possible that this is just forwarded from the user's input who also uploads anh265stream (which Twitch accepts for some reason)...h264av1av1,h264