livepeer / livepeer/go-livepeer
Return more info about segments from orchestrator to the broadcaster
Open
Nobody has claimed this yet.
area: transcoding
status: icebox
type: enhancement
- Dominant language
- Go
- Stars
- 586
- Forks
- 226
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 19
Description
Abstract
We want more info about segments passing through our system.
- In HTTP push handler duration of incoming segment is provided by sender using HTTP header. It could be inaccurate or missing. Orchestrator decodes source segment anyway, so it could return accurate duration information to the broadcaster.
- We're returning number of pixels in the source segment from LPMS to the orchestrator, but not passing this information up to the broadcaster. It would be good to have this info on broadcaster.
- We're returning number of pixels in transcoded segments, but not segments durations. Currently we assume that it is same as the source segment's, but it would be good to know, and it will also be needed for #1621
Motivation
More info will allow to better optimize our system.
Proposed Solution
- Modify LPMS to return duration of segment (add it to the MediaInfo struct).
- Add duration information to the TranscodedSegmentData struct.
- Add source segment's pixel information to the TranscodeData struct.
Implementation Tasks and Considerations
Testing Tasks and Considerations
Known Unknowns
Alternatives
Additional Context
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with ffmpeg/ffmpeg.go and its MediaInfo struct, then inspect net/lp_rpc.proto at the TranscodedSegmentData and TranscodeData definitions. Trace how these values move between LPMS, the orchestrator, and broadcaster. Done means source and transcoded segment durations and source pixel information are available at the broadcaster, with affected Go and protobuf tests passing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100