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
|