livepeer / livepeer/go-livepeer

After O process fails, B continues to report multiple renditions in the manifest, and serve stale transcoded content.

Open
#2,234 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

area: HLS Playback need: investigation
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`

![image](https://user-images.githubusercontent.com/2212651/152542600-cbe40646-0ba8-41ed-8788-f8854d1c2ea8.png)

## Additional Comments

None.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.