Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Live stream latencies #68

Open
benhylau opened this issue Dec 3, 2018 · 3 comments
Open

Live stream latencies #68

benhylau opened this issue Dec 3, 2018 · 3 comments
Labels
enhancement New feature or request

Comments

@benhylau
Copy link
Member

benhylau commented Dec 3, 2018

We have touched on the topic of how real-time this stream is, so I want to start documenting here.

Playing from ipfs-server m3u8 (origin):

screen shot 2018-12-03 at 5 27 34 pm

Playing from m3u8 on ipfs-mirror:

screen shot 2018-12-03 at 5 27 57 pm

Playing from m3u8 on ipfs-mirror but ts chunks from ipfs.infura.io:

screen shot 2018-12-03 at 5 30 41 pm

In all cases observed latency is between 1 to 1.5 min, although I have seen as much as 2 min occasionally.

@benhylau benhylau added the enhancement New feature or request label Dec 3, 2018
@darkdrgn2k
Copy link
Contributor

Latency improved a bit when we removed FFMPEG re-encoding form the pipeline
#76

Last test test i did show 20-30 seconds

@mercora
Copy link

mercora commented Jan 27, 2021

apparently the RTMP server is setup to create 20s fragments so i am going to assume that's where most of the latency comes from. is there a good reason not to go lower with the fragments length?

@benhylau
Copy link
Member Author

It's the minimum we can go based on how fast IPFS can pin. If we go much lower we build up a queue IPFS can't consume fast enough. 20s is what we found acceptable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants