Current Server Time: 11:35 (Central Europe)

#apertus IRC Channel Logs

2021/11/27

Timezone: UTC


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