Recent Features
| |||||||||||||
motion detection is not as easy as it should bemotion detection is not as easy as it should bePosted Oct 25, 2012 15:34 UTC (Thu) by renox (subscriber, #23785)In reply to: motion detection is not as easy as it should be by njs Parent article: Wayland and Weston 1.0 released
>Why not just write some motion detection code?
Because the more complex compression you do, the more latency you add..
(Log in to post comments)
motion detection is not as easy as it should be Posted Oct 25, 2012 19:33 UTC (Thu) by njs (guest, #40338) [Link]
Yes, that's why I made a point of describing an algorithm that should only add a tiny amount of overhead on top of the existing gzip cost, and less than the super-fancy video encoders that are already used? Detecting simple scrolling is really not complicated.
motion detection is not as easy as it should be Posted Oct 25, 2012 19:51 UTC (Thu) by hoegsberg (guest, #57768) [Link]
Yeah, and we're working on more or less the exact rolling hash idea you described. It was kinda weird to see you describe the same approach here... It's still work in progress, but there's a few PNGs here that shows the current status: http://people.freedesktop.org/~krh/rolling-hash/
With just a few MULs per pixel, we can detect if a 32x32 blocks starting at that pixel appears in the previous frame. This should basically be as good as any scrolling/copyarea hint we could've gotten from X or a toolkit, and it detects duplicate blocks in may cases where applications don't scroll but just re-render (like resizing). And of course this technique applies to both fullscreen remote display or per-window remote display.
motion detection is not as easy as it should be Posted Oct 25, 2012 21:07 UTC (Thu) by njs (guest, #40338) [Link]
Hah, awesome. Well, I guess it's the obvious thing to try...
|
|||||||||||||