search

livepeer / go-livepeer

Official Go implementation of the Livepeer protocol
http://livepeer.org
MIT License
538 stars 169 forks source link

Segmenter always skips up to first 5 seconds of stream #884

Closed darkdarkdragon closed 2 years ago

darkdarkdragon commented 5 years ago

Describe the bug Broadcaster, at start of the stream, always drops first frames, up to five seconds.

To Reproduce Steps to reproduce the behavior:

  1. Start local broadcaster node

  2. Start streaming into it ffmpeg -re -i BigBuckBunny.mp4 -c:a copy -c:v copy -f flv rtmp://localhost:1935/fix

  3. Download first segment wget http://localhost:8935/stream/fix/source/0.ts

  4. ffprobe 0.ts

  5. See that timing of first segment starts from start: 2.500000 or from 5s

Expected behavior Expecting to first ts segment to start from zero time, same as in the RTMP stream.

This is due to how currently segmenter works - broadcaster makes RTMP stream available on other tcp port, and spawnsffmpegthat reads RTMP stream from that port. Due toffmpegstartup time,ffmpeg` misses first dozens of frames, and creates first segment on next keyframe.

Possible solutions:

  1. Buffer RTMP stream till ffmpeg spawns and connects to our server.
  2. Write own segmenter in Golang.
j0sh commented 5 years ago

The diagnosis of the behavior is correct, this happens because there's a delay between when the stream comes in, and when the segmenter latches on to the stream.

We actually need to explicitly handle this situation in LPMS by dropping the initial frames in the segmenter until the next keyframe. (Otherwise first segment is unplayable.) https://github.com/livepeer/lpms/blob/master/ffmpeg/lpms_ffmpeg.c#L119

This isn't perfect but it feels somewhat OK for live streams where earlier data isn't as critical.

darkdarkdragon commented 5 years ago

We actually need to explicitly handle this situation in LPMS by dropping the initial frames in the segmenter until the next keyframe.

From my observation ffmpeg's segmenter does it already - segment always starts at keyframe, so I don't see what to do here.

This isn't perfect but it feels somewhat OK for live streams where earlier data isn't as critical.

Yes, probably it is. I've put this here so everyone aware about it, plus it will be a problem if decide to use RTMP for VOD.