#apertus IRC Channel Logs

that depends, but usually the Beta variant

off to bed now ... have a good one everyone!

good day

speedup is great already

vs montage taking ~0.3s

yep that did it

still a very good speed up

plus multiple file conversions in parallel with multithreading

do you have a link to the code?

Optimizations welcome

gcc -O3 -o bgr-merge bgr-merge.c

the recorder and all file conversions should be pause-able or stoppable at any time if a new recording is started

also if the recorder software is reopened

not yours :) sorry for confusion

se6astian: hmm... why cant we do overything "online" i.e. while recording

Doing all conversions in realtime would be even better of course

se6astian: why does the bgr merge script do complicated rgb/bgr conversion?

are you asking why its doing the conversion?

why it is doing the conversion in the first place

something like '-filter format=rgb24'

note that the native capture format for the magewell devices seems to be bgr though

need to test

currently working on it, tho i dont know when it will be ready

can you observe that resources to do real time conversion are plenty?

yup i am quite sure that it is rather easy to do that realtime

even with your unoptimized version you are getting 50ms per frame

so even your current code should be able to run in realtime

how do you plan to read/input the hdmi/usb3 data currently?

Bertl tested with a magewell sdk provided native C capture tool and it significantly increased performance at least for the PCIe magewell capture device

as Bertl is adapting the code currently

with ffmpeg you are just using v4l2, right?

yes, the sdk tool reads from the device directly though

the problem with the USB version (vs the PCIe one) is that the SDK doesn't seem to support HDMI based timing

which obviously leads to either dropped or duplicate frames

the interesting part is that the SDK interface for USB seems to work for PCIe as well, so it might be that this goes the other way too and we could get the PCIe functionality even from the USB devices, but this needs some testing of course

and why do you think that v4l2 gives us a big performance hit?

the problem with 'just' using v4l2 is that you can't set many of the important options to get an optimized stream

so for example, running ffmpeg with a framehash gives plenty of dropped and duplicate frames

think 1 in 1000 vs 1 in 1000000

but likely the mechanisms to get all that working are already there in some way, they just need to be used properly, so likely by watching the SDK do stuff, we can figure out a way to replicate it without the SDK

not sure what the mechanism for the PCIe version is though

that works if the card supports rgb as format, the filter option should do the same trick but also works on cards which do not support rgb format

(at least in theory :)

but it seems to convert on the fly then