3 ms·

hmmm. i'd consider replacing the sleep with a wait on inotify. having the server and image renderer run on different non-synchronized clocks means that frames

by a-dub 5y ago

hmmm. i'd consider replacing the sleep with a wait on inotify. having the server and image renderer run on different non-synchronized clocks means that frames may occasionally be doubled/dropped.

a-dub 5y ago
here we go, aionotify: https://pypi.org/project/aionotify/ https://pypi.org/project/aionotify/
andrewstuart 5y ago
>> having the server and image renderer run on different non-synchronized clocks Would you mind please helping me understand what this means, in detail? I'm pretty sure there's no clock synchronisation anywhere.
- ficklepickle 5y ago
  I think they mean the clock involved with replacing the image every X ms + the clock in your python code. You could remove the python clock code in favour of being notified when the file changes. That's my tired understanding, anyway.
  - andrewstuart 5y ago
    There's no frame rate built into MJPEG, so the code that calculates frame budget cannot be avoided. It might be a good idea to insert a inotify immediately before the file read. You'd still need the timing code though.
- a-dub 5y ago
  here's an example: f_rate = frame rate = 30 fps (for example) f_period = 1/f_rate = 1/30 = 33ms imagine the server serves every f_period, and the image gets updated on the ramdisk every f_period + delta where delta = f_period/16 because the clock from the image updater is not synchronized with the server and is a little slower (by some idealized fixed amount). in this case, every 16 frames, the image updater would advance past the server, and the server would serve a duplicate frame. in practice, delta is often not fixed, and can be positive or negative and instead is described with a distribution called jitter. both the server and the image updater have jitter, so duplicate/dropped frames will occur as they leap ahead and behind each other with the +/- jitters for each unsynchronized clock getting added to their respective periods for each frame. (this is, of course, assuming they're running at the same rate, which they often do not- which is why ultimately you want one to be the primary clock and the other to be driven by it)
  - andrewstuart 5y ago
    Ah yes this makes sense thanks, that's a helpful and clear explanation. In this case, for my personal needs, I'm OK with this happening - my requirement is not for highly accurate frame timing. Other people might however, in which case your advice should be taken into accoujnt.

by a-dub 5y ago

hmmm. i'd consider replacing the sleep with a wait on inotify. having the server and image renderer run on different non-synchronized clocks means that frames may occasionally be doubled/dropped.

a-dub 5y ago

here we go, aionotify: https://pypi.org/project/aionotify/ https://pypi.org/project/aionotify/

andrewstuart 5y ago

>> having the server and image renderer run on different non-synchronized clocks Would you mind please helping me understand what this means, in detail? I'm pretty sure there's no clock synchronisation anywhere.

ficklepickle 5y ago
I think they mean the clock involved with replacing the image every X ms + the clock in your python code. You could remove the python clock code in favour of being notified when the file changes. That's my tired understanding, anyway.
- andrewstuart 5y ago
  There's no frame rate built into MJPEG, so the code that calculates frame budget cannot be avoided. It might be a good idea to insert a inotify immediately before the file read. You'd still need the timing code though.
a-dub 5y ago
here's an example: f_rate = frame rate = 30 fps (for example) f_period = 1/f_rate = 1/30 = 33ms imagine the server serves every f_period, and the image gets updated on the ramdisk every f_period + delta where delta = f_period/16 because the clock from the image updater is not synchronized with the server and is a little slower (by some idealized fixed amount). in this case, every 16 frames, the image updater would advance past the server, and the server would serve a duplicate frame. in practice, delta is often not fixed, and can be positive or negative and instead is described with a distribution called jitter. both the server and the image updater have jitter, so duplicate/dropped frames will occur as they leap ahead and behind each other with the +/- jitters for each unsynchronized clock getting added to their respective periods for each frame. (this is, of course, assuming they're running at the same rate, which they often do not- which is why ultimately you want one to be the primary clock and the other to be driven by it)
- andrewstuart 5y ago
  Ah yes this makes sense thanks, that's a helpful and clear explanation. In this case, for my personal needs, I'm OK with this happening - my requirement is not for highly accurate frame timing. Other people might however, in which case your advice should be taken into accoujnt.