Open harshita1804 opened 4 years ago
The startup delay would be the initial video stall (buffer is empty, waiting to download the first chunk). You can treat the first stall time differently in the reward calculation if the start up delay needs to be treated differently (e.g., want to start streaming as soon as possible, then you want to assign larger penalty on the start up delay). Hope this helps!
I had another question, say I predict bitrate for chunks 5 to 9 (N=5) does this mean that in the next iteration I would predict for chunks 10-14 or would I predict for chunks 6-10?
I'm assuming the N=5 is the look-ahead horizon for MPC. Then the next iteration in your question is for chunks 6-10.
Is video startup time logged anywhere? I am assuming that is different from the first chunk download time in rl_server/result/.
Can you better define what you meant by "video startup time"? If it's the time between the very first request to the video URL to the time of receiving the first byte of the first chunk (which includes all the bookkeepings of video player launching ,etc.), then no, we didn't log it. You could add the logging inside python and html and later merge the logs to check the elapsed time.
Yes, that's exactly what I mean. Thanks!
The MPC paper states that the optimization problem in the startup phase also computes the startup delay, I could not see how that was accounted for here. Could you please explain how to compute the start up delay?