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
- Queries
- All Stories
- Search
- Advanced Search
All Stories
Mar 12 2018
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.
Mar 11 2018
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. (Technically speaking, we could even just use netcat to serve the folder to the browser.)
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.
Connection to daemon is done by UNIX domain sockets, then flatbuffers package is sent over it. Split is intentional, so we can deactivate them separately (was asked by @Bertl).
FYI: This is what we are working on for the specification of the C&C. It is neither finished, nor valid JSON or anything else.
"split the control daemon and rest server" -> that would be the approach with websockets, which I prefer and we are investigating right now.
moreover, what is the transport mechanism for the flatbuffers? notwork? unix sockets? files? fifos?
why do we split the control daemon and rest server into two different programs? couldnt the contol daemon directly expose some kind of web compatible api (websockets / rest), the webapp and the cli should use?
Mar 10 2018
Mar 8 2018
Would it be worth building a docker or vagrant profile to unify the build and development process?
More details: UP 2 Squared with Intel Pentium Quad Core up to 2.5Ghz N4200 with USB3 OTG, 1x SATA, 1x mPCI-e and 1x M.2 2230 E-key starting at around 320$ excl. taxes.
Dimensions: 85.6 x 90mm
Mar 7 2018
Mar 5 2018
"We are an association of visually impaired photographers since 2009, participating to photographic festival exibitions. We are based in Carcassonne, in the South of France.
Mar 4 2018
@malita With HDMI know-how we mean that you have a basic understanding how HDMI works, how the data is encoded and transported between source and sink and what the building blocks of an HDMI image are ... Tim does a nice overview of HDMI here https://media.ccc.de/v/33c3-8057-dissecting_hdmi
Hi,
I am from University of Peradeniya Sri Lanka. And I like to engage in the project. Can you please explain what is meant by " HDMI know-how " in the prerequsites section?
Correct cmv_hist3 link: https://github.com/apertus-open-source-cinema/beta-software/tree/master/software/cmv_tools/cmv_hist3
Mar 3 2018
Mar 2 2018
All the important stuff (until new videos are added)
Mar 1 2018
Great! I take it you mean this flavor of libwebsockets: https://libwebsockets.org/
We can test by replacing Pistache by libwebsockets, but it takes some time (maybe on weekend), as currently preparations for GSoC and my packing for move to new city are ongoing.
Here is some information about websockets vs. ajax
Feb 28 2018
@jatha Have you set Travis CI up?
That sounds great!
As a new Beta is finally connected to the server, i could test again if i can finally set gain through daemon. If it works, then more usage cases can be implemented and tested. As it is necessary before we know what we need to supply to the camera, but most work should be done by daemon, also using pre-defined (stored in binary files) stuff like FPGA bitstreams.
As far as the API goes, I would like to suggest versioning it according to a reference standard that documents the REST call, its expectations and all values. The current state (at T865) is what I would consider to be V0 - because it is not systematically standardised. As soon as everything is "written in stone", I would propose promoting the API to V1.
No complete reference yet, as it was created while developing. Have no direct access to the hardware, so it takes more effort to test.
Yes, looking often into Lab and IRC.
Andrej, are you tracking this conversation too?
Is there a complete list of all current and valid REST package requests?
Cool - I saw that referenced in the C code, but didn't know how to expect / construct it from the JS.
There is a thing missing, which i forgot to tell. REST sends a JSON package, format is described in https://lab.apertus.org/T865.
I totally understand the issue with node running on the box, and is why I suggested the C library for websockets.