Current Server Time: 12:50 (Central Europe)

#apertus IRC Channel Logs

2022/09/05

Timezone: UTC


08:20
elafon
left the channel
08:21
elafon
joined the channel
10:44
elafon
left the channel
10:44
balrog
left the channel
10:49
elafon
joined the channel
10:49
balrog
joined the channel
16:00
se6astian
MEETING TIME, who is here?
16:01
Bertl_oO
is here ...
16:01
Bertl_oO
changed nick to: Bertl
16:02
se6astian
hi Bertl, any news to report?
16:03
Bertl
unfortunatel nothing new to report, was swamped with (unrelated) work
16:03
Bertl
*unfortunately
16:04
se6astian
right, same here unfortunately
16:04
se6astian
anyone else here?
16:04
se6astian
anuejn / vup I saw lots of github activity recently
16:05
vup
right
16:05
vup
most of this was not really that interesting
16:06
vup
we mainly worked on upgrading all the dependencies of narui
16:06
vup
and added hidpi / scaling support to narui
16:06
vup
furthermore anuejn is working on macos support across narui and the recorder
16:07
vup
finally we had some design sessions, primarily about some internal parts of the recorder, especially about how to handle node outputs that are needed by several nodes down the line and are therefore cached.
16:08
vup
Currently this is handled a bit unsatisfying, because we simply cache the frame for each node that needs it seperately and simply evict it if the node has read it
16:08
vup
but this means the cache size can grow basically unlimited, especially if one part of the processing cannot keep up with another part
16:09
vup
The working of the cache is currently limited by the information it gets from the downstream nodes, so we have decided that we want explicit communication between the nodes about the caching behaviour (for example if a specific frame is needed again or can be evicted because this is the last time it is needed)
16:10
vup
There are some other areas which will benefit from explicit communication in this style aswell, for example dropping frames
16:10
vup
we have some nodes that can only provides frames in order and cannot skip a frame (for example the webcam input, we cannot do random access to a v4l2 webcam)
16:11
vup
this means every processing node that wants to skip a frame (for example the dual frame raw decoder to align the a/b frames) needs to actually request that frame and then "throw it away"
16:12
vup
doing this leads to unnecessary processing, so these frame drops should be communicated similar to the caching behaviour
16:13
vup
all in all this is mainly some maintance / polishing work in preparation for finally adding a gui to the recorder
16:13
vup
I think that covers most of it
16:13
se6astian
thanks for the insight, sounds good
16:13
se6astian
anyone else who wants to share/report?
16:17
se6astian
alright then, many thanks all participants, MEETING CONCLUDED
16:32
Bertl
changed nick to: Bertl_oO