-
Notifications
You must be signed in to change notification settings - Fork 17
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
Comments
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 |
here is a PR for the DASH VOD and Live pacing: #21 |
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. |
cool. I will definitely try it out
…-G
On Tue, Sep 27, 2022 at 2:41 PM Diego Ferrand ***@***.***> wrote:
Hey @gmarzot <https://github.com/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.
—
Reply to this email directly, view it on GitHub
<#20 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB7T3IDK72LRNBIDPIYCIGLWAM5UFANCNFSM4WK7OUNA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Hi Diego,
We did try it out. I am seeing some of the same problems. VOD sources seem
to generate too many manifest gets and the pacing is not governed by
segment duration.
The manifest gets for DASH should not be more frequent that minUpdate
setting.. and actually a single manifest get can be used and each
subsequent segment get can be calculated from the duration of the p[revious
segment (this is more like AMP and other DASH players) ...
HLS live seems to be paced ok .. i guess since the new segments don't show
up in the manifest until they exist .
I am not sure how relevant my previous patch is w/ current code but the
concepts above would make the plugin more like a real; player load for
HLS (live and VOD) and DASH (live and VOD)
Thanks and let us know if you would like any more info.
We would be happy to set up a joint test session if you think you have
these problems solved.
best regards
Giovanni Marzot
…On Tue, Sep 27, 2022 at 2:52 PM Giovanni Marzot ***@***.***> wrote:
cool. I will definitely try it out
-G
On Tue, Sep 27, 2022 at 2:41 PM Diego Ferrand ***@***.***>
wrote:
> Hey @gmarzot <https://github.com/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.
>
> —
> Reply to this email directly, view it on GitHub
> <#20 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AB7T3IDK72LRNBIDPIYCIGLWAM5UFANCNFSM4WK7OUNA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
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 |
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
The text was updated successfully, but these errors were encountered: