perhaps we should change the title of this thread - or move it to "websockets" REST doesn't seem to make sense anymore...
Needs Triage (15)
- No repositories found for this query.
Sat, Mar 17
Fri, Mar 16
Wed, Mar 14
Tue, Mar 13
Mon, Mar 12
I am not worried about the display of these values in realtime using a Vue value store (modified by websocket information). I think we could get to 30fps with less than 100ms latency - if the hist3 can pump the info out that fast - and still manage the wifi and the websockets...
I would also suggest we try decimating the histogram number of samples and bitdepth drastically and try sending multiple measurements per second, after all as filmmaker you are not interested in details of the spikes, rather see a general value distribution and how it changes when opening or closing a lens aperture for example. I guess test gpu acceleration on smartphones for drawing these could be worth a try.
Ok - I see. Then the interface will also need to show a folder list (with preview / editing options and perhaps metadata viewer - respective to data type.) Do you also expect / hope to send whitelisted commands via some kind of mock-shell?
Wow - I didn't know that that was one of the deliverables.
It isn't currently but could be useful in the future.
Wow - I didn't know that that was one of the deliverables. What do you mean by "etc."? Yes, we can serve from any folder. We would need to investigate the possibility of sym-linking a "DCIM" type of folder, but there isn't any real reason why it shouldn't work.
Can we also easily serve files (like images, etc.) from the camera internal linux user space to clients without lighttp (for photography like applications)? If yes then I guess we could consider getting rid of lighttp.
As far as security is concerned, you are probably right sending and receiving flatbuffers. We don’t want DAEMON to unexpectedly crash.
Here is how we could even serve http with libwebsockets, which would help to do the automatic upgrade to ws:// - it is public domain licensed.
Point of note: Blackmagic Design's Duplicator 4K is an SD card duplicator with built in realtime H.264 and H.265 encoding, yet Blackmagic Design DaVinci Resolve doesn't support H.265
Don't you think there is a bigger security problem when allowing to run websockets permanently in daemon? Also that was a reason for separation of daemon and server. Daemon should just have slim layer, like flatbuffers, for communication. This would also allow different types of servers communicate to the daemon, without opening security holes.
Sun, Mar 11
There will be minimum three connections with the client device, perhaps four.
we could also have multiple clients... ie. one webremote and one cli (in case we are merging the server and the controldaemon).
So I have "implemented something" - the frontend for the WebRemote and worked with the team today to design a spec. But I would still like @jatha to show some evidence that suggests that "the camera has plenty of resources". I find this hard to believe (its only a relatively low-powered dual arm!!!) and only benchmarks running during a camera state where it is filming and executing scripts could change my opinion. (Or alternatively, a video of htop screen.)
Of course - usually you have the whole reverse proxy cruft because you don't know who / how many clients you will have. The luxury behind this WebRemote as we are building it is that we will at most have exactly one client, who has "properly" identified itself with a UUID. We don't care about the rest of the universe.
sorry for being unclear. When writing rest server, i actually didnt think about rest but exposing an interface with webstandarts. we could also replace any rest with websockets.
And furthermore, the only purpose for having lighttpd is to serve the initial html/js/css to the WebRemote. After a ws:// connection has been made we can even turn it off.
Can we get rid of the REST server entirely? I was under the impression that we actually agreed to do websockets...
hm... dont really get, why we would want to disable the rest server / the control daemon seperately. if we dont want to expose http from outside, we could pervent this by binding the rest server to a local adress and do reverse proxying with ligthttpd. in this case disabeling lighttpd would disable the accessibility from outside.