#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

yes

or pulled out the single ethernet cable that had the "do not unplug" sticky note on it...

this is a very bad label, as people won't react properly, it must say: "this is the internet, do not unplug!"

looks like YT is back online

and gmail

anuejn, were you talking about digesting stills?

hi btw

> seems like it is somewhat faster (~60fps with the beta 4k images on my laptop)

I guess it wouldn't make sense to h264 stills

is the main video readout method still HDMI capture as the wiki says?

so it could as well be stills

so that is the way I am experimenting with

the camera as device

which then runs said software

after real-time h265 encoding, I mean

Bertl_zZ: is working on a solution with an ultrascale zynq

but we also considered multiple other platforms

the stuff I am working on is currently more leaning towards using an intel based board

hm... let me dig that out

NXP has some wild SoCs and I think they're expensive (20USD per part) but I mean, we're comparing stuff to Ultrascale here

hm... sadly I cant find the relevant meetings

well we currently use the hardware accelerated h264 encoding, I think any solution not having that won't be competitive, atleast power wise

yup

well maybe I am about to change that :P

vup: :)

EmilJ: I do not own a computer fast enough to do unaccelerated encoding in realtime

just as a point of reference: encoding 1080p30 video takes about < 0.8W on my laptop

Hmm, yeah... I undershot

but probably h264 is not the compression we end up using for most applications

yeah

(if you are interested, I found https://gopro.github.io/cineform-sdk/ to be a good introductory read on wavelet image compression)

oh yeah, benched my ryzen 3600, was able to do 40FPS transcoding h264 to h265 (source and destination both 1080p30)

Yeah I guess h265 is a bit more demanding hardware wise

the NXP SoCs are too sucky to encode 4k

we might go with an fpga

With a hard encoder core?

https://irc.tywoniak.eu/file/1/26zZSKkRBZuavwNx

gererally i find wireless video very fascinating

good day

MEETING TIME!

BAndiT1983: messaged me he will be occupied now unfortunately but has nothing new worth reporting

a bit and I will also share some news from anuejn

please!

the recorder can now successfully receive data sent from the zynq to the usb3 plugin module, however there are still some problems

and furthermore sometimes it seems like data gets lost

yes

to do that efficient is a bit tricky, because we want to avoid copying the data around

didn't we agree to reserve some codes for this purpose?

that part is not hard

The idea is, after figuring out where the frame starts, to read a smaller (than one frame) buffer from the usb3, such that when reading the next frame the buffer is aligned to the start of the frame

this is complicated by the fact, that one cannot read buffers smaller than 2048 * 4 bytes from the ft601, so some final adjustment has to be done after that. (Also frames + padding always have to be a multiple of 2048 * 4 bytes)

well anyways, its not really hard, but anuejn did not get to implementing the alignmenTyet

so we need to figure out how to handle that best

either by reading more quickly on the computer side, or maybe adding backpressure from the machxo2 to the zynq

moving some work (mostly allocating new buffers) done on the computer from the thread that does the receiving to another thread eliminated most of the lost data

do we have resources for a second fifo or can we make the fifo larger?

maybe a few more words can be squeezed in by using a dram fifo

Ok, so I also played around a bit with the recorder this week and I started to implement a way to do zerocopy video encoding

We currently do the debayering in the recorder with vulkan, and using a extension we can export a vulkan buffer as something called dma-buf. This is a linux framework to share GPU memory between processes and even access GPU memory from the CPU (CPU access will most certainly be very slow when using a dGPU, but using a iGPU its very fast)

In our previous tests, copying the data took more than 70% of the time needed in the encoding process, so that should help quite a lot with the speed there

so yeah, now I am working on getting the encoding part working and landing the mesa patch necessary to get writable access to the dma-buf from the CPU

great progress

vup: sounds nice!

right :)

ok brief updates from me then:

for review and release in a few days I would assume

and on thursday we will visit another electronics manufacturing facility with very low cost machines

we still plan to have Tele produce the AXIOM Beta hardware though

There were several meeting over the course of the last week regarding the AXIOM Micro

yay!

like full featured vs low complexity

at least

to arrive at something called R2.1 currently

but not adding anything new (maybe only minor additions, nothing major)

the goal is to make it very affordable so reaching a certain production volume is vital

how about a crowdfunding campaign with a given target volume?

(once the price estimate and design has been fixed)

anuejn / vup also said they do not want to fund development

rather develop until its ready for production and then funding the production and fulfil right away

yes, so currently a lot of discussion is ongoing what a Micro R2.1 could cater to users

for recording lectures or streaming conferences

of course it should also be a development platform (Zynq + Image acquisition)

that a raspberry pi camera cannot do ( which we will never be able to compete with from the price anyway)

thats it from my side

sure, thanks!

hello from xthenode aka medusade...

in this process, I did a board rendering (2.1D), which required to update our scripts to imagemagick v7

the board renderings can be seen here (not the latest though): http://vserver.13thfloor.at/Stuff/AXIOM/BETA/PANEL/axiom_beta_mixed_panel.top.png http://vserver.13thfloor.at/Stuff/AXIOM/BETA/PANEL/axiom_beta_mixed_panel.bottom.png

I also finished the TE0714 carrier board which we plan to use for testing our impedance/loss test strips on the edge of the panel

most excellent!

which basically has been haunting us since the early power board designs and can, under certain circumstances, lead to 5V on the 3.3V power rails for the CSO modules

I think, if nothing unexpected pops up, we should be ready in the second half of this week

as usual, any additional reviews are more than welcome!

i.e. do not hesitate to look through the files and report any findings and/or ask if there are any potential issues

my suggestion would be to create a 'new' board file which only contains traces ('wires') from the LVDS class and simply generate gerbers for that as well

we already have everything ready

perfect then

I was more intereted if we need to update the results, but I assume the LVDS traces didnt change anywhere

and if you had look at the results and if they match your expectations

ok

also the UI is much more flexible and can be configured to work with easily

let's hope that it will be useable in the upcoming 6.x release

great, many thanks, anyone else with topics/questions?

you wrote "I'm interested in working with the camera sensor using the now totally cool raspberry pi for the purpose of ultra large image capture of fine art."

I am not sure we can assist much on the raspberry pi front though

please elaborate

work with the raw image data...

the idea would be to hook into the sensor controller to get the raw data...

the pi would be used for the portable version, but the development would be one on a pc

done on pc

right, meeting concluded

hi, actually me and bluez also wanted to share some updates ':D

has there been a daylight change btw?

ah right

yeah, at the moment it's probably a good idea to stick to IRC

that's it from me!

bluez is having trouble with his computer so shall i share on his behalf?

vup: the one you and anuejn had built

sure, please share bluez report

"Spent some time with the ip integrator and also vivado in general. Its all quite new to me. But i couldn't give much time because of some delayed exams that were held last week... But i will be able to give full time from this week!"

vup: yes please! i had a doubt in the build instruction too

many thanks for the updates!

yes yes, we have submitted them

ok if the meeting is concluded, metaldent what problems do you have with the webui?

vup: the doubt i have is after doing `yarn watch` what's the meaning of the step "Then open a browser and see the webui :). " ?

so navigate to localhost:3000 in your browser and the webui should be visible

:)

wouldn't it require the IP (or some other info) of the camera?

or the webui?

no, the webui and nctrl will be running on the camera

well, you kind of need to have the IP for that though :)

wait, the webui will be running "on" the camera?

ssh daemon?

but that doesn't have anything to do with the webui

then to get the ip "ifconfig"...

usb 2 serial terminal?

then easy as pi...

That one even automatically redirects you to the webui as it pretends to be a captive portal

is the "Connect via SSH" feature mentioned in the Home working?

is nfs supported?

xthenode: yes if you plug in a wifi stick it acts as a hot-spot by default

NFS is for nfsmount

but I don't see why it shouldn't work

it allows building code directly to the target device...

and gdb remote debugging...

nctrl is running i think..

okay, trying...

sure

I wonder if a FOSS webcam would appeal to the same type of people who buy Talos POWER9 workstations

maybe, there is still the closed source bootrom of the zynq...

yeah

oh right, ew

To what degree are the ARM cores crucial for what the Micro is?

so maybe just a custom zynq board

so you can do a lot more there (like comfortably boot linux and run a bunch of software there)

hmmm, now I'm curious how usable would be Zephyr on a soft-core