Better stream controls for Orchestrators
Titan Node
I think more control over video handling is a great feature and will defiantly need to be handled, but currently our ability to handle Live video is so oversaturated I'm not sure this is a critical task at the moment.
I would rather see resources go towards implementing AV1 or other features that would potentially increase demand.
But of course I agree, handling different loads will be important. Would hate to see a 4k VOD come in a hit the GPU so hard it stops Live video from keeping real time.
Maybe another way to handle this issue would be to focus on fixing the "Max Sessions" limit setting which doesn't consider segment difficulty. We could instead focus of how many "pixels per second" a GPU can handle first?
Idk just some thoughts :)
Hunter Hillman
Authority Null Can you say more? What's the value of seeing which streams are VOD?
> set flags to send specific types of streams to a chosen GPU.
Is this for live/VOD, or for streams with certain characteristics (i.e., send HEVC codecs to a certain GPU)?
Authority Null
Hunter Hillman: Being able to identify which streams are VOD can help us figure out how we need to optimize our setups to meet current demand.
This also plays into the second point - if we know we're getting VOD streams, we can invest in GPU's that are better suited for VOD and send streams to those GPU's.
The answer to your second question is both. Since VOD tends to hit the GPU's differently from live, we'd need more control to better use multi-GPU setups. Being able to narrow that down even further by sending certain profiles, bitrates, etc, to specific GPU's is something many node operators would like to see and can bring a nice performance lift to the network imo.
This is also a massively useful feature for pools, which often house 50+ GPU's of all shapes and sizes, and could really use added granularity, which is very hard to develop independently, without knowing which streams are VOD and which are live.
There may be an issue or feature request specfic to the characteristics point, although i'm not sure as I couldn't find it before making this one.
Hope that helps!
Hunter Hillman
Authority Null:
If VODs are tending to hit GPUs differently from live, isn't that a problem with how we're sending VODs? AFAIK a segment should be a segment.
Thom Shutt Can you weigh in here?
re: more granular control over where to send streams, I agree that this should be a thing - but I think it should be oriented around bitrates, profiles, etc rather than live vs. VOD. I know a few pools have implemented something like this - I wonder if any would be open to making a code contribution to go-livepeer?
Marco van Dijk
Hunter Hillman: with 'hit differently' is meant that the inputs and requested renditions for VoD workflows differ vastly from livestreams (which is more homogenous and seems to have way easier decodes). For live workflows segments also come in at realtime speed, but VoD can go through segments quicker (although I'm not sure how quickly Livepeer's VoD pipeline sends segments and this is also different from how Xeenon/other B's might have their VoD pipeline implemented)
Having some insight in whether a stream is Live or VoD would make it easier to track these differences. Similarily, currently only info on requested renditions is exported from go-livepeer on the O side, so exporting info on the input of transcodes might be a good feature to add as a first step.
On the last note:
For the video-miner pool we distribute streams based on encode difficulty. Transcoders are ranked based on measurements taken on the Orchestrator. This is only implemented for split O/T setups and are not GPU but transcoder specific.
So unfortunately much more work is needed here to be able to upstream this. Even with this limited implementation however the performance improvements and data coming out of this have been very promising!