Current Server Time: 13:35 (Central Europe)

#apertus IRC Channel Logs

2022/09/05

Timezone: UTC


09:20
elafon
left the channel
09:21
elafon
joined the channel
11:44
elafon
left the channel
11:44
balrog
left the channel
11:49
elafon
joined the channel
11:49
balrog
joined the channel
17:00
se6astian
MEETING TIME, who is here?
17:01
Bertl_oO
is here ...
17:01
Bertl_oO
changed nick to: Bertl
17:02
se6astian
hi Bertl, any news to report?
17:03
Bertl
unfortunatel nothing new to report, was swamped with (unrelated) work
17:03
Bertl
*unfortunately
17:04
se6astian
right, same here unfortunately
17:04
se6astian
anyone else here?
17:04
se6astian
anuejn / vup I saw lots of github activity recently
17:05
vup
right
17:05
vup
most of this was not really that interesting
17:06
vup
we mainly worked on upgrading all the dependencies of narui
17:06
vup
and added hidpi / scaling support to narui
17:06
vup
furthermore anuejn is working on macos support across narui and the recorder
17: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.
17: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
17: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
17: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)
17:10
vup
There are some other areas which will benefit from explicit communication in this style aswell, for example dropping frames
17: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)
17: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"
17:12
vup
doing this leads to unnecessary processing, so these frame drops should be communicated similar to the caching behaviour
17:13
vup
all in all this is mainly some maintance / polishing work in preparation for finally adding a gui to the recorder
17:13
vup
I think that covers most of it
17:13
se6astian
thanks for the insight, sounds good
17:13
se6astian
anyone else who wants to share/report?
17:17
se6astian
alright then, many thanks all participants, MEETING CONCLUDED
17:32
Bertl
changed nick to: Bertl_oO