You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Imported from the old issue tracker. Created by Romain:
rbouqueau: Suggested by Jack: would allow to make one request in advance instead of retrying. We should add a timeout to avoid keeping sockets opened by error.
slarbi: I don’t fully understand, do you mean that the server should keep the connection alive, and loop to handle multiple requests. + (the timeout conditions) ? wouldn’t this imply any changes from the client side ?
rbouqueau: Since this is a realtime communication, we could imagine we receive a stream.
However here, with MPEG DASH, this stream is divided into segments. Each segment is a TCP request.
In low latency, segments are being delivered as they are being created (“fragment” per fragment).
The client requests segments sequentially. However, to ensure the lowest latency, it requests them in advance. So it polls, gets some 404s, until the segment is available.
jackjansen suggested that we accept all requests and we timeout if no data arrives. That would avoid the client to poll.
rbouqueau: by chance I’ve found also this command-line in my emails: gpac -i counter_video_360.mp4 reframer:rt=on @ -o http://localhost:8080/live.mpd:gpac:hmode=push:segdur=4:cdur=1:profile=live:dmode=dynamic:asto=3
slarbi is last comment relevent to this ticket ?
rbouqueau Yes, that’s a command-line to push data. I don’t remember exactly why I was enthusiast enough to post it here, but useful nevertheless.
The text was updated successfully, but these errors were encountered:
Imported from the old issue tracker. Created by Romain:
rbouqueau: Suggested by Jack: would allow to make one request in advance instead of retrying. We should add a timeout to avoid keeping sockets opened by error.
slarbi: I don’t fully understand, do you mean that the server should keep the connection alive, and loop to handle multiple requests. + (the timeout conditions) ? wouldn’t this imply any changes from the client side ?
rbouqueau: Since this is a realtime communication, we could imagine we receive a stream.
However here, with MPEG DASH, this stream is divided into segments. Each segment is a TCP request.
In low latency, segments are being delivered as they are being created (“fragment” per fragment).
The client requests segments sequentially. However, to ensure the lowest latency, it requests them in advance. So it polls, gets some 404s, until the segment is available.
jackjansen suggested that we accept all requests and we timeout if no data arrives. That would avoid the client to poll.
rbouqueau: by chance I’ve found also this command-line in my emails:
gpac -i counter_video_360.mp4 reframer:rt=on @ -o http://localhost:8080/live.mpd:gpac:hmode=push:segdur=4:cdur=1:profile=live:dmode=dynamic:asto=3
slarbi is last comment relevent to this ticket ?
rbouqueau Yes, that’s a command-line to push data. I don’t remember exactly why I was enthusiast enough to post it here, but useful nevertheless.
The text was updated successfully, but these errors were encountered: