Re-use remote transcoders for a stream

[kyriediculous]

Abstract

The split orchestrator and transcoder architecture enables the creation of transcoding pools. These pools can either be private or public.

When an orchestrator receives a stream it will currently send each segment for a sessionID to a different transcoder.

Analogous to how a broadcaster sticks with the same orchestrator for all segments of a stream as long as it can transcode in real-time, an orchestrator should stick with the same transcoder for a stream.

Motivation

Sending each segment of a stream to a different transcoder could lead to a degradation of performance:

• Transcoders can differ in performance (speed, quality, ...)
• Harder to re-use GPU sessions
• Fanning out on a per-stream basis can negatively impact work retention

Proposed Solution

Current Flow

1. Segment comes in

2. The list of connected RemoteTranscoders is sorted by load

   Each segment in flight for a RemoteTranscoder increments load by 1

3. Select the head of the sorted RemoteTranscoder list

   If the RemoteTranscoder is no longer connected, discard it and continue

4. Send segment to RemoteTranscoder

5. Decrement load for RemoteTranscoder upon return

Since ordering of the RemoteTranscoder list is not guaranteed at any point in time selection is entirely random.

Proposed Flow

1. New segment comes in for stream with sessionID

2. Check if there is a RemoteTranscoder assigned to sessionID

   • No assignment - proceed to step 3
   • Transcoder assigned - proceed to step 4

3. The list of connected RemoteTranscoders is sorted by load, select the head of the list and increment its load.

   load and capacity will be defined on a per-stream basis rather than a per-segment basis. Each stream session for a RemoteTranscoder increments load by 1

4. Check whether the (newly) assigned RemoteTranscoder is still connected

   • connected - proceed to step 5
   • not connected - go back to step 3

   If the RemoteTranscoder is no longer connected, remove it from the list, remove it from the assignment and decrement its load

5. Update RemoteTranscoderManager state to reflect the assigned RemoteTranscoder for sessionID (if necessary)

6. Send segment to RemoteTranscoder

   • success: no-op
   • error: remove it from the list, remove it from the assignment and decrement its load

Implementation Tasks and Considerations

One potential way of implementing this could be as follows:

Add a map to the RemoteTranscoderManager to keep track of the assigned RemoteTranscoder for an sessionID.

type RemoteTranscoderManager struct {
    ...
    StreamSessions: map[sessionID]*RemoteTranscoder
}

RemoteTranscoderManager.selectTranscoder() can be updated to take a sessionID as argument.

func(rtm *RemoteTranscoderManager) selectTranscoder(string sessionID) *RemoteTranscoder {
    rt, ok := rtm.StreamSessions[sessionID]
    if !ok {
        // ... current selection logic
        currentTranscoder.load++
        sort.Sort(byLoadFactor(rtm.remoteTranscoders))
        // Assign currentTranscoder
        rt = currentTranscoder
	}
    }
    
    return rt
}

RemoteTranscoder.completeTranscoder() would also have to take sessionID as an argument and be tied to the transcode session cleanup loop, or a separate cleanup loop.

Testing Tasks and Considerations

• A transcoder should be re-used for a stream with sessionID as long as no error or timeout occurs.

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

This issue now has a funding of 0.35 ETH (921.26 USD @ $2632.18/ETH) attached to it.

• If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
• Want to chip in? Add your own contribution here.
• Questions? Checkout Gitcoin Help or the Gitcoin's Discord
• $1,997,522.65 more funded OSS Work available on the Gitcoin Issue Explorer

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

Work has been started.

These users each claimed they can complete the work by 265 years, 6 months from now.
Please review their action plans below:

1) reubenr0d has been approved to start work.

Work for this almost complete, just left with some minor changes.

Learn more on the Gitcoin Issue Details page.

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

Work for 0.35 ETH (1182.52 USD @ $3378.63/ETH) has been submitted by:

---

• Learn more on the Gitcoin Issue Details page
• Want to chip in? Add your own contribution here.
• Questions? Checkout Gitcoin Help or the Gitcoin's Discord
• $2,291,396.88 more funded OSS Work available on the Gitcoin Issue Explorer