Current Server Time: 20:54 (Central Europe)

#apertus IRC Channel Logs

2021/11/29

Timezone: UTC


01:13
intrac
left the channel
01:14
intrac
joined the channel
01:50
fredy330
left the channel
01:50
intrac
left the channel
02:03
intrac
joined the channel
02:30
fredy330
joined the channel
04:37
illwieckz
left the channel
05:06
Bertl_oO
off to bed now ... have a good one everyone!
05:06
Bertl_oO
changed nick to: Bertl_zZ
07:12
illwieckz
joined the channel
07:21
illwieckz
left the channel
07:39
illwieckz
joined the channel
08:04
Spirit532
left the channel
08:32
se6astian
good day
08:40
Spirit532
joined the channel
11:22
intrac
left the channel
11:22
intrac
joined the channel
12:08
Bertl_zZ
changed nick to: Bertl
12:08
Bertl
morning folks!
14:14
se6astian
lattepanda now has a small touch screen attached
14:14
se6astian
I can go from recording there to playback of the same clip in a few seconds
14:14
se6astian
works very well
14:15
se6astian
this means we now have a self contained camera/recorder system!
14:15
se6astian
battery for lattepanda is also ordered
14:15
se6astian
standard USB/PD power brick should do
14:15
se6astian
and can also power the beta via dual USB power
14:15
se6astian
so entirely self contained and entirely mobile power supply!
14:15
se6astian
great day!
14:23
vup
nice
14:23
vup
now only the live preview while recording is missing :P
14:23
se6astian
true
14:23
se6astian
but we have two hdmi outputs on the beta
14:23
se6astian
one for recording one for viewing
14:24
vup
true, but at some point we want to use both for recording right?
14:24
vup
(and a shield for preview?)
14:24
se6astian
it would double FPS yes
14:24
se6astian
and remove the need for 2 monitors
14:24
se6astian
where 1 would be enough
14:24
vup
yeah that aswell
14:26
se6astian
now the question for me is how/where to control camera parameters
14:26
se6astian
on the recorder screen?
14:26
se6astian
or on a smartphone?
14:29
se6astian
or the axiom remote as well of course
14:30
se6astian
so all those are possible obviously but the question for me is what we want to have read first
14:30
se6astian
the remote will take more time
14:30
se6astian
but smartphone control over wifi works right now
14:30
se6astian
so would the recorder (small addition)
14:31
se6astian
what is most convenient though as first step?
15:00
se6astian
*ready first
15:18
vup
Well i guess the recorder so you have just a single device is probably most convenient?
15:19
vup
(Down the line we of course also want controls in the rust recorder as fourth option)
15:21
vup
se6astian: Oh also could you do a run of https://zsmith.co/bandwidth.php#download on the latte panda and upload the resulting bmp somewhere?
16:09
se6astian
will do
16:10
se6astian
hmm, does that website resolve for you currently?
16:11
vup
yes it does
16:12
vup
https://files.niemo.de/bandwidth-1.11.1.tar.gz
16:20
se6astian
thanks
16:32
se6astian
running
16:33
se6astian
does it test CPU only or also the M.2 SSD?
16:34
vup
its a memory bandwidth tester, so CPU only
16:34
vup
or rather combination of CPU and DRAM
16:35
se6astian
right
16:39
vup
Bertl: do you by chance know if there is a way to force eagle to overwrite the file when using `WRITE`, if a file with the same name already exists?
17:00
se6astian
MEETING TIME, who is here?
17:01
vup
is here
17:02
se6astian
any news vup? :)
17:02
vup
a bit, nothing mayor
17:03
se6astian
please do
17:04
vup
Well, motivated by the openmoko oui id application I started going through many of the files in axiom-firmware, nctrl and webui and added proper license information
17:04
vup
(to the individual files)
17:04
vup
there a still a few files missing information, but those I can't do myself, as I need information about the license and copyright
17:05
vup
there is a list of outstanding files here: https://github.com/apertus-open-source-cinema/axiom-firmware/pull/194
17:05
se6astian
I suspect Bertl is the author of the missing ones
17:05
se6astian
Bertl: can you confirm?
17:06
vup
furthermore I also started working on automation to generate schematic pdfs, gerbers and more from all the various pcb schemaics and board files
17:07
vup
the ideas here is instead of manually generating all the pdfs and gerbers to start putting the `.sch` and `.brd` files in a git repo and then automatically generate all the artifacts
17:08
vup
and then finally generate a website where one can easily find all the files and download them
17:08
vup
finally anuejn and I also continued a bit with the rust recorder and narui
17:08
vup
first we tested them on MacOS
17:09
vup
the recorder works flawlessly (apart from the `Display` node) on MacOS
17:09
vup
and we finally fixed the problem in `narui` that made it hang after rendering the first few frames on MacOS
17:10
vup
so `narui` is now also working well on MacOS
17:10
se6astian
wonderful!
17:10
vup
(this currently needs this fix for the vulkan abstraction library we are using: https://github.com/vulkano-rs/vulkano/pull/1766) otherwise you will hang / crash your GPU on MacOS and also on linux when using a intel GPU :)
17:11
vup
second, I looked at the cpu bitdepth conversion again and figured out how to bring the rust compiler to properly generate vectorized code: https://github.com/apertus-open-source-cinema/axiom-recorder/pull/20
17:12
vup
this brought the (single threaded) bitdepth conversion from about 70fps to about 350fps for 3072x4096 raw12 frames on my laptop
17:12
se6astian
amazing!
17:12
vup
with this optimization it is now also very clear that we are hitting the maximum memory bandwidth available on most consumer devices very quickly
17:13
vup
the maximum fps I can get on my laptop seems to be about 600fps, that maxes out the available memory bandwidth
17:14
vup
so in the future we will probably have to think about combining processing steps to do more computation per byte
17:15
vup
but this is a topic for the future, for now anuejn and I designed the new processing system for the recorder that finally makes things possible like combining two frames into one, which will finally make it possible to use the recorder for the hdmi based raw recording
17:15
se6astian
hurray!
17:16
vup
this is not implemented yet, but anuejn and I are quite fond of the design we came up with, lets see how long it takes us to implement it :)
17:16
se6astian
fingers crossed
17:16
vup
I think thats it from me this week :)
17:16
se6astian
how can you switch which 2 frames you get?
17:16
se6astian
in case its not the matching A+B pair?
17:18
vup
ah we havent thought about cases like this in depth, we mostly thought about the general framework that allows a node based processing graph with different input and output rates for the nodes, which does multi-threading and dropping frames under load
17:19
se6astian
ok
17:19
se6astian
quick updates from me: I worked more on the raw hdmi recording scripts/tools and documentation
17:20
se6astian
today I managed to go from recording on the lattepanda to viewing the same clip in a matter of a few seconds (for a short clip though)
17:20
se6astian
so the general process works
17:20
se6astian
(read more about it in the log from a bit earlier today)
17:20
se6astian
my chaos communication congress talk got accepted and will be prerecorded in december
17:21
se6astian
I am now starting to design a 3d print enclosure to put lattepanda, monitor, battery, etc. onto the back of the CP enclosure
17:21
se6astian
so we should soon have a full self contained camera with batteries
17:21
se6astian
for this purpose I wanted to discuss audio recording
17:21
se6astian
should we ignore it for now
17:22
se6astian
or simply plug a USB audio device into the lattepanda
17:22
se6astian
the sync between video and audio is the big topic...
17:22
vup
the sync is usually does in the postprocessing anyways, right?
17:23
se6astian
well, the film clap method yes
17:23
se6astian
but then there is no point in recording audio in the camera
17:23
se6astian
as it can be done externally anyways
17:24
vup
yeah
17:24
se6astian
sometimes its convenient to have matching audio for the video though
17:24
vup
how good does the sync usually need to be? How many ms difference are acceptable?
17:24
se6astian
without extra effort (extra devices, extra manual sync steps)
17:25
se6astian
we should aim for 1fps accuracy IMO, so 40ms with 25 fps
17:26
vup
hmm
17:26
vup
thats quite a lot
17:26
se6astian
yeah we humans are quite tolerant there :)
17:26
se6astian
I think I read somewhere that the 5-6 fps out of sync range is where it becomes generally noticeable
17:27
vup
I wonder if we could achive 40ms relatively easily with a simple USB audio device
17:27
se6astian
my question is how we can "sync" in theory on the recorder side at all
17:27
se6astian
or do we just record both and measure where we are?
17:28
se6astian
would the system time become the timestamp for both audio and video?
17:28
vup
yeah thats what I am trying to figure out aswell
17:29
vup
if there was some kind of hardware timestamp from the audio device or something similar it should be quite doable
17:31
se6astian
it means though that we need to write a system timestamp into the HDMI raw frames we capture as well somehow
17:31
se6astian
or maybe ffmpeg can do that already somehow
17:31
vup
well
17:31
vup
we probably want to do that on the beta itself
17:32
se6astian
then we need to sync time between beta and recorder though
17:32
vup
or record audio on the beta :P
17:33
se6astian
also possible but would require HDMI audio signal then to recorder
17:33
vup
but timestamping the frames on the recorder has the problem that we don't really know the latency between the frame capture and it being received by ffmpeg
17:33
se6astian
correct
17:34
se6astian
this would need testing
17:34
vup
se6astian: well we could also stream it over ssh, the recorder is currently connected over ssh aswell anyways, right?
17:34
se6astian
yes
17:34
se6astian
true
17:34
se6astian
its not much data
17:34
vup
(or not even ssh, but just tcp)
17:35
se6astian
anyways, audio is not an important topic, but if we can achieve it with little effort it would have a real world benefit easily
17:35
se6astian
right thats it from my side I think
17:36
se6astian
Bertl: are you with us?
17:37
se6astian
right, anyone else who wants to report anything?
17:39
se6astian
ok then, many thanks vup & anuejn!
17:39
se6astian
MEETING CONCLUDED
17:40
se6astian
bandwidth tool is still running
17:40
se6astian
result is a bmp at the end?
17:41
vup
yeah it produces a bandwidth.bmp in the folder you are running in in the end
17:42
vup
afk for now
17:49
Bertl
sorry, had an emergency ...
17:49
Bertl
but nothing to report here this week either
18:02
se6astian
tahnks
18:02
se6astian
thanks
18:02
intrac
left the channel
18:06
intrac
joined the channel
18:07
Bertl
off for now ... bbl
18:08
Bertl
changed nick to: Bertl_oO
18:09
se6astian
vup: done: https://paste.pics/0c69502e289512a02fdea0ba4f248757
19:45
danieel
left the channel
19:47
danieel
joined the channel
20:03
elafon
left the channel
20:04
elafon
joined the channel
21:39
elafon
left the channel
21:39
danieel
left the channel
21:39
intrac
left the channel
21:39
Spirit532
left the channel
21:39
lexano
left the channel
21:39
balrog
left the channel
21:39
kbeckmann
left the channel
21:39
tpw_rules
left the channel
21:44
elafon
joined the channel
21:44
danieel
joined the channel
21:44
intrac
joined the channel
21:44
Spirit532
joined the channel
21:44
lexano
joined the channel
21:44
balrog
joined the channel
21:44
kbeckmann
joined the channel
21:44
tpw_rules
joined the channel
22:27
vup
se6astian: wow very interesting
22:28
vup
can you upload it somewhere without lossy compression?
22:29
se6astian
Will do tomorrow
22:29
vup
awesome, no rush
22:34
se6astian
Are the results surprising?
22:39
vup
well partly atleast
22:40
vup
on this you can very cleanly see the three cache levels
22:41
vup
but on my laptop for example its much more noisy and one can only really see two cache levels?
22:41
vup
(https://files.niemo.de/bandwidth.bmp)
22:43
vup
and also the cache seems to be a lot faster
22:43
vup
but then the actual memory bandwidth lower?