But you only have to encode once, or once per client type as opposed to per-client. And the more efficient decoding is, the wider the range of potential clients and/or the better the quality for a given amount of bandwidth.
I was thinking of the case where the encoding is being done by a centralized 'broadcaster', as opposed to individual users streaming from their own machines; for the latter case I agree with you.
With a live stream, it's generally not parallelizable at all. You won't have future frames to work with unless you add a huge delay in the stream, which generally doesn't mesh well with doing something live.
5 minute delays are common on twitch, especially to circumvent stream snipers. Totally live video is a liability actually and I would guess most live broadcasts have a delay.
In any case, I wasn't referring to inter-frame parallelizability, I was referring to intra-frame parallelizability which doesn't require a delay.
It can take an enormous amount of compute power to encode 4k video at 1:1 speed with these more complex codecs. Multiply for multiple bitrates and resolutions. If you can't encode at 1:1, you add significant delays to 'live' streaming, thus making it not 'live'.
Case in point, a 40 second 1080p clip would take over 8 hours to encode on an i7-4800 - that's less than 2 frames per minute. You need a lot of horsepower to cut that down to 40s / 60 FPS.
Like the other comment said: the point is live streaming, so the encoding has to be done in real-time. Being the slower of the two steps (assuming comparable hardware between sender and recipient), it becomes the performance bottleneck when measured as frames per second.
When measured in, say, total sum of all CPU cycles and hence total energy spent, then yes: the decoder is the bigger deal. So your argument holds for non-live videos.
But you only have to encode once, or once per client type as opposed to per-client. And the more efficient decoding is, the wider the range of potential clients and/or the better the quality for a given amount of bandwidth.
> But you only have to encode once
In real-time. If the encoder is too slow for that it is the bottle-neck.
I was thinking of the case where the encoding is being done by a centralized 'broadcaster', as opposed to individual users streaming from their own machines; for the latter case I agree with you.
1 reply →
Live-streaming is typically a type of broadcast. Some latency (a few or even tens of seconds) is typically OK.
1 reply →
Depends on how parallelizable the encoding algorithm is.
With a live stream, it's generally not parallelizable at all. You won't have future frames to work with unless you add a huge delay in the stream, which generally doesn't mesh well with doing something live.
5 minute delays are common on twitch, especially to circumvent stream snipers. Totally live video is a liability actually and I would guess most live broadcasts have a delay.
In any case, I wasn't referring to inter-frame parallelizability, I was referring to intra-frame parallelizability which doesn't require a delay.
4 replies →
Please do elaborate.
It can take an enormous amount of compute power to encode 4k video at 1:1 speed with these more complex codecs. Multiply for multiple bitrates and resolutions. If you can't encode at 1:1, you add significant delays to 'live' streaming, thus making it not 'live'.
Case in point, a 40 second 1080p clip would take over 8 hours to encode on an i7-4800 - that's less than 2 frames per minute. You need a lot of horsepower to cut that down to 40s / 60 FPS.
[1] https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live...
Like the other comment said: the point is live streaming, so the encoding has to be done in real-time. Being the slower of the two steps (assuming comparable hardware between sender and recipient), it becomes the performance bottleneck when measured as frames per second.
When measured in, say, total sum of all CPU cycles and hence total energy spent, then yes: the decoder is the bigger deal. So your argument holds for non-live videos.