livepeer / livepeer/go-livepeer
After O process fails, B continues to report multiple renditions in the manifest, and serve stale transcoded content.
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 586
- Forks
- 226
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 19
Description
## Bug Description
When an O/T process fails, the B continues to report transcoded renditions in the `.m3u8` manifest, and serves stale (cached, i.e. not live) transcoded content.
## Observed Behaviour
Steps to reproduce the behavior:
1. Download version 0.5.27 of Livepeer `wget https://github.com/livepeer/go-livepeer/releases/download/v0.5.27/livepeer-linux-amd64.tar.gz`
2. Unzip `tar -xzf livepeer-linux-amd64.tar.gz`
3. start O/T `./livepeer -orchestrator -transcoder -serviceAddr 127.0.0.1:8935 -v 99`
4. start B `./livepeer -broadcaster -httpAddr :8936 -cliAddr :7936 -rtmpAddr :1936 -orchAddr 127.0.0.1:8935 -transcodingOptions P720p30fps16x9,P576p30fps16x9,P360p30fps16x9,P240p30fps16x9,P144p30fps16x9 -v 99`
5. start `ffmpeg` to stream into B `ffmpeg -re -f lavfi -i testsrc=size=1920x1080:rate=30,format=yuv420p -f lavfi -i sine -c:v libx264 -b:v 10000k -x264-params keyint=60 -c:a aac -f flv rtmp://127.0.0.1:1936/test_source`
6. Run the following `curl http://localhost:8936/stream/test_source.m3u8`
7. Observe that multiple renditions being served by the B
8. Kill the O/T process (ctrl-C)
9. Run `curl http://localhost:8936/stream/test_source.m3u8` again
10. Observe that the B is still reporting multiple renditions being served
11. Run `ffplay http://localhost:8936/stream/test_source/source.m3u8`
12. Observe that the `source` rendition of live content is still being served (note the sequence number)
13. Run `ffplay http://localhost:8936/stream/test_source/P144p30fps16x9.m3u8`
14. Observe that a stale (not live) `144p` rendition is still served by the B (note the sequence number is lower than in step 12.)
## Expected Behavior
At step 10, I would expect the B to only be reporting availability of the `source` rendition.
At step 14, I would expect that no stale `144p` content is being served by the B.
## Environment
- Livepeer Version: `0.5.27`

## Additional Comments
None.
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
Reproduce the failure with the Livepeer 0.5.27 commands, focusing on the broadcaster's /stream/test_source.m3u8 endpoint after the O/T process is stopped. Compare the reported renditions and sequence numbers for source.m3u8 and P144p30fps16x9.m3u8; done means only source remains available and no stale transcoded content is served.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- audio-video-rtc
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100