Peter Körner

Testing this in practice turned a small problem up: after ~12 minutes, the input queue in ffmpeg's decklink code hits 1GB and ffmpeg starts to drop buffers by hitting this...

Ran another test on this tonight and it seems that leaving away the audio makes things work again: ``` ffmpeg -y \ -f decklink \ -i 'DeckLink Mini Recorder (1)@10'...

More tests show, that it's likely a combination. running voctocore with one declink source in 422 worked for 42 hours, added a second one and both stopped working after ~1...

cleaned up the thread, removed false assumptions and added explanation of the issue.

Example of how the problematic processes show up:   And a Video of how this looks in the GUI: https://c3voc.mazdermind.de/permanent/issue-33-gui.mp4

@a-tze yes, true. The screenshot showed the problem when no source would be connected. In this case the colorspace would not matter.

@a-tze is this still a thing after #143 or should we stay at 420?

VLC also registeres them as 4h long. Most probably the wavmux just writes the largest possible filesize into the header and does not fix this, when the file is closed...

Oh, sorry then, I did not realise that.

Hey there! Is there a reason not to build the aarch64 images using a github workflow? If you could drop your current build process into a snippet somewhere I'd love...