Current Server Time: 09:20 (Central Europe)

#apertus IRC Channel Logs

2019/03/18

Timezone: UTC


00:51
illwieckz_
changed nick to: illwieckz
02:31
Spirit532
left the channel
02:33
Spirit532
joined the channel
02:46
aombk2
left the channel
03:04
Bertl
off to bed now ... have a good one everyone!
03:04
Bertl
changed nick to: Bertl_zZ
04:02
aSobhy
left the channel
05:43
BAndiT1983|away
changed nick to: BAndiT1983
06:19
mrohit[m]
Hello, I am working on my proposal parallel to playing around and getting to know the system.
06:19
mrohit[m]
So do you have a specific format of the proposal?
06:19
mrohit[m]
And what points do you expect to be covered in the proposal
06:35
BAndiT1983
changed nick to: BAndiT1983|away
06:42
se6astian|away
changed nick to: se6astian
06:43
se6astian
mrohit[m]: check our gsoc profile page
07:23
mrohit[m]
Thanks, and sorry, that was poor research on my part I guess. I'll start working on it accordingly
08:26
illwieckz_
joined the channel
08:27
illwieckz
left the channel
09:24
se6astian
changed nick to: se6astian|away
09:54
Spirit532
left the channel
09:54
Spirit532
joined the channel
09:55
se6astian|away
changed nick to: se6astian
10:23
aSobhy
joined the channel
11:42
parimal
joined the channel
12:22
RexOrCine|away
changed nick to: RexOrCine
12:54
Bertl_zZ
changed nick to: Bertl
12:54
Bertl
morning folks!
12:58
se6astian
good day
12:59
apurvanandan[m]
good morning
13:10
Bertl
hey apurvanandan[m]! what clock speeds did you test your serdes setup with ISE?
13:13
apurvanandan[m]
I set the clock period to 1 ns which means 1 GHz
13:14
Bertl
and ISE implemented that just fine for what FPGA?
13:14
apurvanandan[m]
but this was in simulation
13:14
apurvanandan[m]
Spartan 3E
13:14
Bertl
I presume RTL simulation, yes?
13:19
apurvanandan[m]
It was behavioural simulation
13:20
Bertl
yes, that's what I meant, so try with gate level simulation (post implementation simulation) instead and see what data rates you can achieve in e.g. Spartan
13:23
Bertl
note: the design is somewhat naive but fine except for a few minor details ... the main purpose of the challenge task is to get an idea what is required to deserialize data at 600MHz :)
13:25
danieeeel
changed nick to: danieel
14:19
apurvanandan[m]
For Spartan 3E its reaching 50 MHz , for Virtex 6 its reaching 555MHz.
14:20
apurvanandan[m]
in post-route simulation
14:20
Bertl
so there is some room for optimization :)
14:21
Bertl
what is the most critical path?
14:22
danieel
3e has lessinput luts afaik.. so combinatorial logic issues.. pipelining might help here
14:31
apurvanandan[m]
I am trying to find the bottle neck.
14:44
mrohit[m]
sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/RqCvlQTaSKgTAntzeMqUqtbu >
14:47
Bertl
looks like your newly created system cannot resolve properly
14:50
mrohit[m]
So what should I try?
14:51
Bertl
vup2 or anuejn might have some ideas ...
14:53
mrohit[m]
Okay, I will wait for them to join the room
14:53
mrohit[m]
Thanks, Bertl
15:04
parimal
left the channel
15:19
aombk
joined the channel
15:26
kingsocarso
joined the channel
15:34
BAndiT1983|away
changed nick to: BAndiT1983
15:59
anuejn
seems like there are some networking issues either on your side or on the side of the arch linux arm folks
15:59
anuejn
i would just retry :)
15:59
se6astian
changed nick to: se6astian|away
16:00
anuejn
arch linux arm has some fuckups sometimes... not too stable
16:01
mrohit[m]
I tried it twice @anuejn. I'll try it once again tonight
16:01
anuejn
hm...
16:02
anuejn
can you try to open a build shell and curl mirror.archlinuxarm.org
16:03
Bertl
how is /etc/resolv.conf set up during the build?
16:04
Bertl
(might just be an unreachable nameserver :)
16:05
anuejn
it is manually set to some open dns server
16:06
Bertl
mrohit[m]: so maybe check that this nameserver is actually reachable at your location
16:06
anuejn
https://github.com/apertus-open-source-cinema/axiom-beta-firmware/blob/master/makefiles/host/run_in_chroot.sh#L25
16:06
anuejn
185.121.177.177
16:07
anuejn
this is the used nameserver
16:07
Bertl
you can try with e.g. dig mirror.archlinuxarm.org @185.121.177.177
16:08
Bertl
(seems to be quite slow here, maybe replace it with 8.8.8.8 or so?)
16:14
BAndiT1983
changed nick to: BAndiT1983|away
16:23
apurvanandan[m]
Please verify that except the clock speed all the IOs are as desired.
16:23
apurvanandan[m]
https://imagebin.ca/v/4adR8tVXzPaG
16:23
apurvanandan[m]
Simulation screenshot
16:24
apurvanandan[m]
https://ibin.co/4adR8tVXzPaG.png
16:27
mrohit[m]
Yes Bertl , I guess the nameserver is the problem here, the dig command returned time out
16:27
Bertl
does 8.8.8.8 (google nameserver) work for you?
16:28
mrohit[m]
Yes it does
16:28
Bertl
then maybe just replace it with that and you should be fine
16:29
mrohit[m]
Ya, I am rebuilding it now with the change
16:29
niemand
joined the channel
16:29
niemand
left the channel
16:29
niemand
joined the channel
16:31
Bertl
apurvanandan[m]: well, from the short trace it looks like the output differs from the input, no?
16:37
apurvanandan[m]
Its in the 8 bit mode so MSB of input is taken in the LSB of output .Rest of LSBs are zero
16:37
apurvanandan[m]
In 12 bit mode it looks like
16:37
apurvanandan[m]
https://imagebin.ca/v/4adW9rb31I6r
16:38
apurvanandan[m]
https://ibin.co/4adW9rb31I6r.png
16:40
Bertl
okay, then it looks reasonably fine
16:42
se6astian|away
changed nick to: se6astian
17:16
BAndiT1983|away
changed nick to: BAndiT1983
17:29
Dev_
joined the channel
17:30
Dev_
left the channel
17:32
mrohit[m]
I tried the build with the google nameserver(8.8.8.8) and it seems to be working fine. But I am getting another error : failed retrieving file 'community.db' from mirror.archlinuxarm.org : Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds
17:32
mrohit[m]
I guess this error is due to unstable arch linux arm because the packages prior to the community.db were downloaded at a really high speed but this package failed
17:33
mrohit[m]
I have tried this twice and the results are same
17:34
Dev_
joined the channel
17:35
mrohit[m]
I am talking about the build of the Beta firmware here
17:37
Dev_
Hey BAndiT1983 , https://github.com/apertus-open-source-cinema/opencine/blob/master/Source/OCcore/Image/MLVLoader.cpp , in load function , one of the todos is change switch into hash map of function pointer , is it important ?
17:38
Dev_
it will unnecessarily cause removing of type
17:39
BAndiT1983
hi Dev_
17:39
BAndiT1983
what's the problem with that?
17:42
Dev_
I was finding out how to do this , it will result into erasing types ,
17:43
Dev_
We need to keep track of RAWI and VIDF headers , why can't just use switch , just curious
17:44
BAndiT1983
do you want to maintain a very long switch for every tag type?
17:46
Dev_
but i guess we need to deal with few headers (mainly VIDF which contains frame here)
17:46
BAndiT1983
https://docs.google.com/spreadsheets/d/1ItNuLj34JlK6bZgiAJLrmG7p3iyCmCju4XYyiwjqJOM/edit#gid=0
17:46
BAndiT1983
and what about other tags? what happens if we need them, should we stumble over a very long switch/case every time to fix problems?
17:47
BAndiT1983
for me it's easier to have a map with handlers, instead of spaghetti code
17:48
BAndiT1983
hashes are already defined in .h file, so there is no disadvantage there
17:48
Dev_
yeah , that's right , why do we need otherwise , i couldn't figure out why ? , we just need to access frames of VIDF
17:48
Dev_
otherwise -> (other tags)*
17:48
BAndiT1983
???
17:49
BAndiT1983
please google about image processing, it's not only about image data, there is white balancing, gamma curve, linearization and much more
17:49
BAndiT1983
this parameters are often supplied by cameras
17:50
BAndiT1983
also sync points, audio data etc. etc. etc.
17:50
Dev_
okay , getting what u are saying ,
17:51
Dev_
I will try to change Switch -> hashmap ,
17:51
BAndiT1983
if the process would be that simple, just to show data, then there would be no trouble to create tons of proper apps, but RAW data is much more difficult and has no single solution
17:51
BAndiT1983
unordered_map is your friend usually
17:52
Dev_
so we also need more read function for those function , too
17:52
Dev_
okay
17:53
BAndiT1983
check the specs at google docs, link above
17:53
BAndiT1983
it also contains apertus proposal
17:53
BAndiT1983
check if you can load video data, it worked for first frame
17:53
BAndiT1983
you can grab test files at magiclantern forum
17:54
BAndiT1983
also you could inspect what the problem is, if a file is not loading properly
17:54
Dev_
yes i have sample mlvs
17:54
BAndiT1983
it's very simple to load it in processingtest
17:54
BAndiT1983
just needs a bit of manual intervention maybe
17:59
Dev_
will see this ,
17:59
Dev_
please check this and point out if u find anything wrong in this : The present static allocators contain buffer and unordered_map to store and track down the memory respectively, for reading frames can we store each frame into this buffer subsequently
18:00
Dev_
or it will create problem while processing frames with debayering algo, implemented in OCcore/image
18:01
BAndiT1983
the frames should be stored consequently, but it can happen that a different frame should be loaded instead of one available, e.g. user clicks in the track bar,
18:01
BAndiT1983
plan is to preload several frames, depends on available memory etc., static allocator should be smart enough to remove oldest frame and replace with new data
18:02
BAndiT1983
but we could get away by loading subsequently every time
18:02
BAndiT1983
start simple first
18:03
BAndiT1983
an array instead of map could be used, but it's trickier to seek for oldest frame etc.
18:05
BAndiT1983
size can be always same value, as the frame are equal each time
18:06
Dev_
if user clicks in the track bar : do u mean if user seek the slider of vlc player (or other ) in between
18:06
Dev_
size can be always same value : okay
18:06
BAndiT1983
yes, the slider
18:07
ashu
joined the channel
18:08
Dev_
how do we come to know about , which frame should start frameserving at this point of time (point of silder)
18:09
Dev_
we should have acess to frames before that ,
18:09
Dev_
isn't it ?
18:09
BAndiT1983
that's a part of the task, either VLC/mplayer asks for a frame at some time or even frame number
18:09
ashu
changed nick to: Ashu
18:09
BAndiT1983
we have access beforehand, but frames have to be served in right order
18:12
Dev_
it is the read callback of FUSE which is reading the data for vlc/mplayer ,
18:12
BAndiT1983
ok, what does it mean for us?
18:15
Dev_
what does it mean for us : so do we need to change read callback , for supporting sudden change in silder positon
18:15
Dev_
slider*
18:16
BAndiT1983
yes, and how can we accomplish this?
18:17
Dev_
this is what i have to understand :) , i will try
18:17
BAndiT1983
the answer is not difficult, try to think about it right now
18:17
BAndiT1983
my prototype is not crashing when seeking some time position
18:18
Dev_
yes, but my avi file do buffer a lot
18:18
BAndiT1983
what do you mean?
18:18
Dev_
the c/c++ challenge , actually the avi file which i am creating only works on vlc and buffer a lot
18:19
BAndiT1983
what does it buffer?
18:20
Dev_
it takes time to load , like in playing youtube video wiith good speed internet
18:20
Dev_
without*
18:20
BAndiT1983
really?
18:20
BAndiT1983
my fuse file is quickly available, like a real file
18:21
Dev_
i was talking about MY avi file
18:21
Dev_
yours is fine ,
18:22
BAndiT1983
then you should search for the cause of the problem, check your loops, maybe there is something fishy going on
18:22
BAndiT1983
valgrind could help with profiling
18:22
Dev_
the answer is not difficult : there is off_t offset in readcall back , i think that is keeping track of data ,
18:22
Dev_
don't know how to change it , but i will think surely
18:22
BAndiT1983
https://github.com/BAndiT1983/OC_FrameServer/blob/dev/FUSEHandler.cpp
18:22
BAndiT1983
seeking is already working there
18:23
BAndiT1983
i'm cheating a bit, because data holds 30mb of data, as the frames are not interrupted by other data
18:23
BAndiT1983
actually whole file is kept in this buffer
18:24
BAndiT1983
but for bigger files we need another strategy, e.g. hold header data in one buffer and image data in different one, also keeping track of important positions in file is necessary
18:25
Dev_
important positions ??
18:26
BAndiT1983
yes, like header, image data etc.
18:26
BAndiT1983
if the player/editor asks for a position in image data, then you have to provide correct offset
18:26
BAndiT1983
but for metadata only it would be ok to provide only header and tags
18:27
BAndiT1983
that's why splitting the virtual file could help with managing nested data
18:31
Dev_
if the player/editor asks for a position in image data, then you have to provide correct offset : i will think about it ,
18:32
BAndiT1983
check the link to prototype, everything is there, just in basic form, but still gives an idea
18:32
BAndiT1983
if you have questions, then ask
18:33
Dev_
who gives this size_t size parameter ?
18:33
BAndiT1983
which line?
18:34
Dev_
42
18:34
BAndiT1983
it's fuse callback, so the answer is fuse
18:35
Dev_
and what will be its value everytime
18:35
BAndiT1983
as far as i remember it contains the size of chunk to read
18:36
kingsocarso
left the channel
18:36
Dev_
so u mean , if we slide the slider , the off_t offset will change , line number 42
18:36
Dev_
agian
18:36
BAndiT1983
yes
18:36
kingsocarso
joined the channel
18:36
BAndiT1983
offset is the global offset into the file
18:37
Ashu
left the channel
18:37
Dev_
then it will start from that position , it all makes sense now :)
18:37
BAndiT1983
great to hear
18:40
Dev_
also one last things is , shouldn't we change unordered_map of static allocator to map , it will store the _current offset into sorted order ,
18:40
Dev_
https://github.com/apertus-open-source-cinema/opencine/blob/master/Source/OCcore/Memory/StaticAllocator.cpp
18:40
Dev_
sorry this one
18:40
Dev_
https://github.com/apertus-open-source-cinema/opencine/blob/master/Source/OCcore/Memory/StaticAllocator.h
18:40
Dev_
line 31
18:41
BAndiT1983
ordered map is sorting a lot, this is slower
18:41
BAndiT1983
you could use vector instead
18:42
BAndiT1983
just think about which parameters have to be known from map or struct in a map, so we can get the right frame
18:43
BAndiT1983
as i said, size can be equal and preset while loading, but we have to know frame number, position in the static allocator buffer
18:43
Dev_
but as we keep adding frames , the _currentoffset will increase , and at the end we the first frame , which should be on first ,
18:43
Dev_
won't be there
18:43
BAndiT1983
static allocator should go in circles
18:44
Dev_
(we the ) -> (our first frame *)
18:44
BAndiT1983
if it should read beyond its boundaries, then you reply with left memory size to fuse and start to place new frames from the beginning of the buffer
18:44
Dev_
static allocatos should go in circles : yes makes sense
18:45
BAndiT1983
also seeking backwards shouldn't be forgotten
18:46
BAndiT1983
i will try to change prototype a bit, so it show some animated lines, this would make it easier to check if the idea of seeking works
18:47
BAndiT1983
*will show
18:48
Dev_
in your prototype , seeking backword is also working , but if we use static allocator in cycle , that will be problem with big files
18:49
BAndiT1983
why?
18:50
Dev_
once the reading done , i think buffer should be cleared ?
18:50
BAndiT1983
which buffer are you referring to?
18:51
Dev_
the static alloctors buffer ,
18:51
Dev_
don't we ?
18:52
BAndiT1983
static allocator does the job in the same way, nothing changes
18:53
BAndiT1983
i would suggest to inspect whole MLV file while loading and create a list of frame positions (offsets), maybe even just of image data of each frame
18:53
BAndiT1983
then it would be not much of a trouble to walk forward or backward and load the data
18:54
Dev_
will that case ever come , that we run out of memory and can't allocate more space and have to clear the buffer
18:55
BAndiT1983
you just overwrite old frames
18:55
BAndiT1983
that's the point of static allocator combined with ring buffer
18:56
BAndiT1983
if there is more memory available then you could allocate multiple pages, each 1gb or 512mb big
18:56
Dev_
so in that case backword seeking won't be possible , i was saying that
18:56
BAndiT1983
why?
18:57
Dev_
you just overwrite old frames : if we do this
18:57
Dev_
then how ?
18:57
BAndiT1983
don't see any problem there, as it's the idea of many video players out there
18:59
Dev_
okay , so let me first focus on code of how to extract and store the frame data consequently , and how it can be passed to debayered
18:59
Dev_
that will good
19:00
Dev_
be*
19:01
Dev_
i will update u soon ,thanks for your time
19:01
BAndiT1983
no problem
19:01
BAndiT1983
https://www.geeksforgeeks.org/operating-system-allocation-frames/
19:02
BAndiT1983
it's about managing multiple allocated pages
19:02
BAndiT1983
and some gstreamer info on their memory management -> https://gstreamer.freedesktop.org/documentation/plugin-development/advanced/allocation.html
19:04
Dev_
bookmarked , Thanks agian
19:04
Dev_
i will see
19:05
Dev_
left the channel
19:05
mrohit[m]
Hey BAndiT1983 , did you take a look at my code for T872?
19:06
BAndiT1983
hi mrohit[m], sorry had not much time lately, my new job is taking a lot of time and energy
19:07
BAndiT1983
will check it tomorrow, want to resume apertus° work today, it came too short lately, because of previously mentioned reasons
19:08
BAndiT1983
marked it, so i don't forget it
19:09
mrohit[m]
Oh..it's fine...let me know when you take a look, didn't knew about your switch in job btw..
19:12
mrohit[m]
Regarding T1121, can you point me to some beginner tasks for systemd so that I could get to delve a bit deeper about the task
19:12
BAndiT1983
i've mentioned the switch some time ago, is probably somewhere in the logs
19:12
BAndiT1983
you don't need to dive into systemd pretty much, i have removed dependencies
19:13
BAndiT1983
but this series is not bad to get an overview -> http://0pointer.de/blog/projects/journal-submit.html
19:14
mrohit[m]
yup, I have read this article
19:14
BAndiT1983
was asked by vup2 and anuejn to get rid of systemd, which i did some days ago
19:15
BAndiT1983
daemon was never really using it, so the service description file is totally sufficient
19:16
illwieckz_
changed nick to: illwieckz
19:16
mrohit[m]
So the task still remain to move the scripts from firmware to daemon..right?
19:16
BAndiT1983
yes
19:17
BAndiT1983
will add direct CMV register access soon, then the scripts can be implemented using daemon
19:17
mrohit[m]
okay
19:21
mrohit[m]
and the handshake package already resides in description.json, so what exactly needs to be implemented for the Web Remote?
19:22
BAndiT1983
i don't have an overview of webui at the moment
19:23
BAndiT1983
many things are prototypes, no tested properly yet and probably need a lot of adjustments
19:25
mrohit[m]
okay
19:26
mrohit[m]
So what would you suggest as a starting point to work for the task?
19:27
BAndiT1983
you tell me, as i don't know your preferences
19:29
mrohit[m]
As of now, I have understood the first goal of the task and I am still working to get to know all other completely
19:30
mrohit[m]
So I don't have a concrete plan as of now, but would like to go with the scripts
19:30
BAndiT1983
recreating scripts is only a small part of the task
19:31
BAndiT1983
there are many other areas, where the daemon needs work
19:31
mrohit[m]
Such as?
19:32
BAndiT1983
https://lab.apertus.org/T1121
19:32
BAndiT1983
there are several tasks already in the list, but daemon lacks some other adapters, like sysfs
19:32
BAndiT1983
to read temperature or voltage
19:33
BAndiT1983
it needs to be implemented, if i won't get some free time to start it
19:34
BAndiT1983
also evaluating is a task, to check if we can cover almost any parameter with already available attributes in flatbuffers or json
19:37
mrohit[m]
So how do we evaluate those? I guess we figure out the parameters which are dependent on each other and how they are dependent...right?
19:38
BAndiT1983
for example, but mostly if we can represent enough parameter info or if we need additional attributes
19:39
BAndiT1983
parameters will be grouped into presets later, so we can provide pre-defined ones
19:40
mrohit[m]
Okay..
19:44
mrohit[m]
Thanks BAndiT1983 , will let you know if I have any further questions
19:45
BAndiT1983
no problem
20:10
se6astian
off to bed
20:10
se6astian
good night
20:10
se6astian
changed nick to: se6astian|away
20:16
niemand
left the channel
20:41
RexOrCine
changed nick to: RexOrCine|away
21:05
BAndiT1983
changed nick to: BAndiT1983|away
22:02
Spirit532
left the channel
22:02
Spirit532
joined the channel
22:31
intrac
left the channel
22:42
intrac
joined the channel