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

Query pacing higher than expected from playlist segment duration #20

Open
gmarzot opened this issue Jan 20, 2021 · 6 comments
Open

Query pacing higher than expected from playlist segment duration #20

gmarzot opened this issue Jan 20, 2021 · 6 comments

Comments

@gmarzot
Copy link

gmarzot commented Jan 20, 2021

I am observing qps rates approximately 10x higher than expected. for instance this playlist exhibits higher qps than expected compared to segment duration.

https://bitdash-a.akamaihd.net/content/sintel/hls/playlist.m3u8

this is VOD so not sure what pacing is designed or expected. but it would be useful to pace the GETs according to segment duration

Hopefully not missing something obvious

@gmarzot
Copy link
Author

gmarzot commented Jan 21, 2021

also tested with live DASH. the pacing of video and audio segment GET's appears correct based on appearance in manifest but the manifest GET rate is excessive. in many cases (AzuremediaPlayer) a single manifest GET is done and all subsequent audio/video GET URLs are calculated from segment duration. even without that intelligence i would think the manifest GET rate should not be higher than the segment GET rate

image

@gmarzot
Copy link
Author

gmarzot commented Feb 4, 2021

here is a PR for the DASH VOD and Live pacing: #21

@diego-ferrand
Copy link
Contributor

Hey @gmarzot , we just launched a pre-release which has some modifications to the time/pacing of the requests. It doesn't have all changes proposed in your PR, so please check it out and let us know if it works for you.

If you see the pacing issue is still present, we will apply the solution proposed in your PR.

@gmarzot
Copy link
Author

gmarzot commented Sep 27, 2022 via email

@gmarzot
Copy link
Author

gmarzot commented Oct 12, 2022 via email

@RicardoPoleo
Copy link

Hello @gmarzot,

Thanks for taking the time to test the changes, we really appreciate it.

Regarding the changes you sent in the PR, we migrated those in the new code and will be public in the next release (giving you credits ofc 😉).

We wanted to see how the recent changes performed first (if we had any regressions and how the community reacted to them). Once we release the fix, we will hope you give them a try (if those still don't work, we would love to have a test session to see how it behaves and what needs to be fixed to make it more accurate/real).

Once again, thank you very much for your time and your help 🚀

Best Regards

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

No branches or pull requests

3 participants