sambazi

> One version of the question we looked at was: how low a pace rate can you pick for an ABR algorithm, without reducing video QoE?

that is certainly an interesting economical optimization problem to reason about, though imho somewhat beyond technical merit, as simply letting the client choose quality and sending the data full speed works well enough.

addition:

i totally agree that things have to look economical in order to work and that there are technical edge-cases that need to be handled for good ux, but i dont't quite see how client-side buffer occupancy in the seconds range is in the users interest.

i did not read that paper with a focus on adaptive bitrate selection for video streaming services that came out 8 years after the pacing implementation hit the kernel. thx thou

probably also marketing, since "dumb-pipes" may seem outdated when all and everything is getting "smart"

> ts oversubscribed as many users share the same link at some point and that link is not big enough to allow all users to use all their bandwidth at the same time.

that's a definition of oversubscription.

> around 70-95% utilization depending on link size.

2/3's with dumb queues, <100% with the computational tradeoff of sqm

just think about your competitive edge if you could manage to cramp more load w/o affecting latency

looks like they only care for drops and not latency

why would you want to differentiate those?

pretty sure top meant RL ppl IRL aka meatspace.

information coming over unqualified electronic channels is not trustworthy anymore

different use case and requirement for samsung device?

not sure if such a thing can work w/o root

how do you measure productivity?