Current Server Time: 19:40 (Central Europe)

#apertus IRC Channel Logs

2021/11/27

Timezone: UTC


00:25
mithro
left the channel
00:27
mithro
joined the channel
01:05
danieeel
left the channel
01:52
danieel
joined the channel
02:48
Guest9233
left the channel
02:48
fredy_
joined the channel
04:07
vup2
Bertl_oO: for which assembly variant should the gerbers be generated?
04:15
Bertl_oO
that depends, but usually the Beta variant
04:18
vup2
ok
05:26
Bertl_oO
off to bed now ... have a good one everyone!
05:26
Bertl_oO
changed nick to: Bertl_zZ
10:48
se6astian
good day
11:07
se6astian
eventually got to create the c tool to combine A+B frames into a raw12 quickly
11:07
se6astian
speedup is great already
11:07
se6astian
0.05s per frame
11:07
se6astian
vs montage taking ~0.3s
11:09
se6astian
colors are wrong though, probably because input is BGR and output shall be RGB
11:20
se6astian
yep that did it
11:20
se6astian
0.07s now per frame
11:20
se6astian
still a very good speed up
11:21
se6astian
and code can probably be optimized a lot as well
11:26
se6astian
plus multiple file conversions in parallel with multithreading
12:14
anuejn_
se6astian: nice
12:14
anuejn_
do you have a link to the code?
12:15
se6astian
Will Push in a few minutes
12:15
se6astian
Optimizations welcome
12:26
se6astian
https://github.com/apertus-open-source-cinema/misc-tools-utilities/tree/master/raw-via-hdmi/bgr-merge
12:27
se6astian
gcc -O3 -o bgr-merge bgr-merge.c
12:27
se6astian
./bgr-merge file1.bgr file2.bgr output2.raw12
12:33
aombk3
left the channel
12:39
se6astian
anuejn_: I would also like to ask you about ideas regarding the following challenge:
12:40
se6astian
the recorder and all file conversions should be pause-able or stoppable at any time if a new recording is started
12:41
se6astian
how can the conversions be resumed easily without starting from scratch at any conversion step
12:41
se6astian
also if the recorder software is reopened
12:41
se6astian
I mean this recorder script https://github.com/apertus-open-source-cinema/misc-tools-utilities/tree/master/raw-via-hdmi/raw12-hdmi-recorder
12:41
se6astian
not yours :) sorry for confusion
12:43
se6astian
the conversion steps mainly regard "split" and "montage" or the "bgr-merge" tool above that is supposed to replace montage: https://docs.google.com/drawings/d/1OX83QFdwphGZRrPg773UaYnnY0QYonqOttPOoBtNEwI/edit
13:06
anuejn_
se6astian: hmm... why cant we do overything "online" i.e. while recording
13:06
anuejn_
that would solve the issue of needing to pause / resume stuff
13:23
Bertl_zZ
changed nick to: Bertl
13:23
Bertl
morning folks!
13:31
se6astian
Doing all conversions in realtime would be even better of course
13:31
se6astian
But do we have the resources?
13:35
Bertl
se6astian: why does the bgr merge script do complicated rgb/bgr conversion?
13:36
Bertl
(well, actually C program, not script ;)
13:42
se6astian
are you asking why its doing the conversion?
13:42
se6astian
or why its doing the conversion in a complicated way?
13:43
Bertl
why it is doing the conversion in the first place
13:43
Bertl
i.e. why not change the format with ffmpeg when recording?
13:47
Bertl
something like '-filter format=rgb24'
13:47
Bertl
if the pipeline down the stream 'requires' rgb
13:48
Bertl
note that the native capture format for the magewell devices seems to be bgr though
13:50
se6astian
I tried but there was an issue with ffmpeg, dont remember exactly anymore though
13:50
se6astian
need to test
14:00
se6astian
anuejn_: how far is your recorder development for hdmi input?
14:08
anuejn_
currently working on it, tho i dont know when it will be ready
14:08
anuejn_
changed nick to: anuejn
14:09
se6astian
can you observe that resources to do real time conversion are plenty?
14:10
se6astian
my original approach was to just dump the input stream and do the rest afterwards...
14:10
anuejn
yup i am quite sure that it is rather easy to do that realtime
14:10
se6astian
very good!
14:10
anuejn
even with your unoptimized version you are getting 50ms per frame
14:10
anuejn
which is already fast enough on a dual core system?!
14:11
anuejn
so even your current code should be able to run in realtime
14:11
se6astian
right, but you run the data through the gpu as well no?
14:12
se6astian
how do you plan to read/input the hdmi/usb3 data currently?
14:12
se6astian
because we suspect ffmpeg is already reducing our input performance somehow
14:12
se6astian
Bertl tested with a magewell sdk provided native C capture tool and it significantly increased performance at least for the PCIe magewell capture device
14:13
se6astian
for USB3 we suspect it should help as well but not tested yet
14:16
se6astian
as Bertl is adapting the code currently
14:16
se6astian
any progress on that front Bertl?
14:27
anuejn
with ffmpeg you are just using v4l2, right?
14:27
anuejn
we can do that as well in the rust recorder
14:30
se6astian
yes, the sdk tool reads from the device directly though
14:33
se6astian
off to the supermarket now
14:34
Bertl
the problem with the USB version (vs the PCIe one) is that the SDK doesn't seem to support HDMI based timing
14:35
Bertl
this means that while the PCIe SDK allows to get data for each captured frame, the USB version only allows to request so and so many frames per second
14:35
Bertl
which obviously leads to either dropped or duplicate frames
14:36
Bertl
and we probably want to favor duplicate over dropped frames there ;)
14:37
Bertl
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
14:38
anuejn
is that sdk open source?
14:38
anuejn
and why do you think that v4l2 gives us a big performance hit?
14:41
Bertl
I do not think the SDK is completely open source and I'm not saying that v4l2 gives us a big performance hit, after all the v4l2 interface is used (at least on Linux :) by the SDK to some degree
14:42
Bertl
the problem with 'just' using v4l2 is that you can't set many of the important options to get an optimized stream
14:43
anuejn
ah, i see
14:43
Bertl
so for example, running ffmpeg with a framehash gives plenty of dropped and duplicate frames
14:44
Bertl
while using the SDK in an unoptimized way (no special buffering, etc) already yields an insignificant number of dropped or altered frames and no duplicates
14:44
Bertl
think 1 in 1000 vs 1 in 1000000
14:46
anuejn
I see
14:46
Bertl
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
14:48
Bertl
on the USB device, it probably boils down to a few USB requests
14:48
Bertl
not sure what the mechanism for the PCIe version is though
16:36
Bertl
off for now ... bbl
16:36
Bertl
changed nick to: Bertl_oO
17:06
se6astian
tested rgb instead of bgr output from ffmpeg, seem to work fine! the magic parameter is -pix_fmt rgb24
17:44
Bertl_oO
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
17:45
Bertl_oO
note that the filter option should propagate back to the device, so no overhead when the device supports it
17:45
Bertl_oO
(at least in theory :)
17:50
se6astian
well the ffmpeg output still reports BGR24
17:50
se6astian
but it seems to convert on the fly then
19:59
se6astian
pushed recorder fixes/additions