Just my idea: As the daemon is planned for user-space first, it would be not a big problem to test on local machine. Actually developing it currently on LinuxMint with Unix domain sockets which are meant just for local usage, other languages need wrappers of course to be able to use commands which came over network. Don't want to allow to access the daemon over network for security purpose at the moment.

Told on IRC just a moment ago, that it is a preparation for GSoC. It's faster if i start it, than a student who has never seen the system. Afterwards a student can proceed on improving, like adding new protocols as UART or similar.

Build tested in clean VM, documentation added and adjusted -> https://wiki.apertus.org/index.php/OpenCine.Build_Instructions

Good solution for this thing is to install Jenkins, e.g. through Docker, and let it build the packages for you. Either manually or fully automatic, e.g. nightly builds. Jenkins is not limited just to building, it's a batch task machine. So you could give it all the tasks which should produce repeatable results, like firmware images, OC nightlies, unit testing.

Removed old stuff, added links to Wiki and Lab. Started to adjust Wiki also.

Merged branches.

Hello and welcome,

You still shouldn't forget, that ARM processors have not infinite resources to process things. If it's possible we should use JIT versions of languages or ones optimized for ARM. Had just a glimpse at it on google while lunch break at work.

How about: Gratis Wissen zum Bauen großartiger Kameras

Maybe someting in that direction. ;)

I've mentioned it, because of Sony. Their cameras are marked wit Alpha, not sure if other letters are used too.

A word of caution, just because some language is hip at the moment, doesn't mean that the performance or feature set is suited for embedded systems. It should be evaluated first. I still vote for C/C++ for the backend, it maybe complex for some people, but it's giving the most performance (usually).

Great progress guys, now i have to deliver the software, i suppose. Damn the pressure to succeed. :D

Current script, space for improvement:

Will try to integrate steps into automatic install script for OC development VM.

Looks good, especially on dark background.

I like the second and the third one, but second one a bit more, as it's contrast makes it easier to recognize the letter C.

Very good, it will come handy, as the whole OC thing has to be polished up.

Current state:

Another take:

Could you also upload this images without background, e.g. for launcher, where the buttons are styled by stylesheets? Thanks in advance.

Looks good, maybe you can prepare some of them as separate files, then i would include them so people get the idea.

Just a quick test in the launcher, haven't added proper handling of the size yet, so padding is off.

I like the lens idea, let's hear what other people think about it. Would also prefer "simple" design, as it's the trend nowadays.

Added basic player functionality, file path is hardcoded at the moment.

Alright, time for apertus° stuff:

First success, used some sample footage with 4k and 2k.

Started through setting U-Boot as kernel manually. I suppose QEMU is not replicating the search for boot.bin on first partition, as the hardware does (needs verification). Built newest U-Boot (2017) from Xilinx to check if there would be less problems, than with one from 2014 from apertus°.

Progress is now retrieved properly by copying file block-wise. Some evaluation of optimal block size has to be done.

First tests with xxHash done, now the code will be split into useful chunks. After that bigger clenaup is on the list. If more algorithms are required later, then we need some extended interface and wrappers for xxHash and others.

Maybe a bar graph is better for fast overview of current state. Like that but the bars change their length according to state: http://www.slideteam.net/media/catalog/product/cache/2/thumbnail/543x403/0e7a751fc24f39b632cb88e6c5925d9b/s/e/sequential_timeline_with_gear_bar_graph_and_social_icon_flat_powerpoint_design_Slide01.jpg

Have to check if it is fixed in rOPENCINE4219b140bf4c.

Also see Visual Studio -> View -> Task List (limited visibility of TODOs) or better one: https://visualstudiogallery.msdn.microsoft.com/c5d16a00-fe89-4a9e-8fba-a5c1a9f38841