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
Commit 966ce5a seems to imply that calling wait_event() with no timeout should wait forever. But this is not what happens: it passes -1, which will return immediately.
Well, I'm not entirely sure what behavior mpv_wait_event() should have. Currently, it accepts a relative timeout, and if the timeout is 0 or negative, it doesn't wait. Maybe this should be changed? E.g. the poll() system call interprets negative timeouts as infinite timeout.
Currently, you can pass an unrealistically high number like 1e20 to get an infinite timeout.
Slightly digressing from this, maybe the timeout should be an absolute target time (using mpv_get_time_us()), instead of a relative timeout?
The text was updated successfully, but these errors were encountered:
Absolute time seems silly to me, it could be built on top pretty easy (or with a different call if you want OS level realtime absolute based timing or whatever exists out there). I feel like < 0 should mean infinite, very high number seems like a hack.
Commit 966ce5a seems to imply that calling
wait_event()
with no timeout should wait forever. But this is not what happens: it passes -1, which will return immediately.Well, I'm not entirely sure what behavior mpv_wait_event() should have. Currently, it accepts a relative timeout, and if the timeout is 0 or negative, it doesn't wait. Maybe this should be changed? E.g. the poll() system call interprets negative timeouts as infinite timeout.
Currently, you can pass an unrealistically high number like 1e20 to get an infinite timeout.
Slightly digressing from this, maybe the timeout should be an absolute target time (using mpv_get_time_us()), instead of a relative timeout?
The text was updated successfully, but these errors were encountered: