Current Server Time: 23:15 (Central Europe)

#apertus IRC Channel Logs

2019/03/22

Timezone: UTC


00:04
BAndiT1983
changed nick to: BAndiT1983|away
01:48
apurvanandan[m]
Bertl, In T871 SerDes, I have been trying a lot to increase the clock speed above 500MHz but I am just reaching there. Everything goes fine in post map simulation but all goes wrong in post route due to S/H of FFs. I have tried various timing schemes for sending data till now. I am getting this unmet timing constraint warning due to clk in IBUFG/BUFG which I am currently unable to resolve. Please give some direction
01:51
Bertl_oO
what device are you targeting at the moment?
01:57
apurvanandan[m]
zynq-7020
01:59
Bertl_oO
okay, so the BUFG on the -1 parts is limited to 464MHz
02:00
Bertl_oO
you can get a report from vivado with report_pulse_width -all_violators
02:00
Bertl_oO
the BUFIO OTOH can do up to 600MHz even for the -1 parts
02:02
Bertl_oO
so you want to use the I/O buffers (DDR) to reduce your clock early
02:10
apurvanandan[m]
Ok Thanks, I will see to it.
02:11
Bertl_oO
note that you can do DDR easily without any special units by sampling on both clock edges
02:13
apurvanandan[m]
Ohh nice
02:18
Bertl_oO
okay, off to bed now ... have fun!
02:19
Bertl_oO
changed nick to: Bertl_zZ
02:26
shivamgoyal
joined the channel
02:27
shivamgoyal
left the channel
03:30
parimal
joined the channel
04:32
thiblahute
left the channel
04:34
thiblahute
joined the channel
05:46
kingsocarso
left the channel
06:30
BAndiT1983|away
changed nick to: BAndiT1983
07:38
se6astian|away
changed nick to: se6astian
07:54
BAndiT1983
changed nick to: BAndiT1983|away
08:23
Spirit532
left the channel
08:23
Spirit532
joined the channel
08:23
fizz
joined the channel
08:48
fizz
left the channel
09:15
Spirit532
left the channel
09:15
Spirit532
joined the channel
09:30
Bertl_zZ
changed nick to: Bertl
09:30
Bertl
morning folks!
11:00
thiblahute
left the channel
11:01
thiblahute
joined the channel
11:55
aman_
joined the channel
11:58
aman_
Hi! I am Aman Roy. I am planning to apply for GSoC this year for Management of image sensor calibration files[T720]. Working on C challange.
11:58
Bertl
Hello aman_!
12:06
Guest27507_
joined the channel
12:08
aman__
joined the channel
12:11
aman_
left the channel
12:13
se6astian
changed nick to: se6astian|away
12:14
Guest27507
left the channel
12:14
Guest27507_
changed nick to: Guest27507
12:31
Y_G
joined the channel
12:32
Y_G
Thanks @anuejn and @vup2,I will go through them
12:40
aman__
left the channel
13:17
Y_G
left the channel
13:33
aman_
joined the channel
14:02
aSobhy
joined the channel
14:10
kingsocarso
joined the channel
14:35
parimal
left the channel
15:10
Bertl
off for now ... bbl
15:10
Bertl
changed nick to: Bertl_oO
15:30
futarisIRCcloud
left the channel
16:20
BAndiT1983|away
changed nick to: BAndiT1983
16:43
aman_
left the channel
17:01
Dev_
joined the channel
17:04
Dev_
Hey BAndiT1983 , Can u please check my C/C++ challenge , if u have time in hand ! , Now it bypasses the problem of calculating sizes manually using recursion
17:09
BAndiT1983
hi Dev_, what's your repo?
17:09
Dev_
for AVI generation
17:09
Dev_
I have PMed you
17:10
BAndiT1983
when?
17:10
Dev_
right now
17:10
BAndiT1983
don't see anything
17:11
Dev_
https://github.com/kakashi-Of-Saringan/T782-challenge , okay here it , looks like web client have some problem with PM
17:12
Dev_
please check
17:12
BAndiT1983
using namespace std; is not a good practice
17:13
BAndiT1983
final_image[count * 3] looks a bit awkward, as it repeats this calculation over and over, either do it at the beginning in a separate variable or think of different loop conditions
17:15
BAndiT1983
avoid blanks at the beginning of methods, it's important to have consistent code, but blank lines are just telling me, that people are not bothering with readability and maintenance later, this is a common sign which can also be met in code from big companies
17:15
BAndiT1983
no need for separate lines, if you don't have line breaks
17:15
BAndiT1983
file << graywidth <<" ";
17:15
BAndiT1983
file << grayheight <<"\n";
17:15
BAndiT1983
also line break should be std::endl
17:16
BAndiT1983
why is it mixing up file.write() and file <<?
17:16
BAndiT1983
2 methods for writing? they seem rather similar
17:17
Dev_
Actually , we have to change width into const char for writing using write
17:17
Dev_
play i will change iit
17:17
BAndiT1983
this could be replaced by ternary operator and a boolean switch, e.g. file << grayscaleOutput ? "P5" : "P6"
17:17
Dev_
it*
17:18
BAndiT1983
you have to go with some consistent way, either file.write() or file <<, but mixing them makes it hard to follow
17:19
Dev_
file << grayscaleOutput ? "P5" : "P6" , it seems nice
17:20
BAndiT1983
AVISizes is really not what i expect, have you checked the frame server prototype and how to avoid this calculations? as they can result in more errors
17:20
Dev_
okay i will change these things
17:21
BAndiT1983
have only checked quickly, will look a bit later into it, came not long ago from work and want to switch off a bit from development
17:21
Dev_
okay , please take your time
17:21
Dev_
i will remind u some other time
17:22
Dev_
thanks
17:22
BAndiT1983
you AVI generation is similar to Supragyas, also told him back then, that it's not maintainable
17:22
BAndiT1983
alirght
17:22
Dev_
I could able to change it with some recursion ,
17:23
BAndiT1983
to give you a hint, AVI is built like a tree, that's why recursion is easier to use
17:23
Dev_
i will check your prototype for more changes , actually now i was working on proposal so didn't have much time to look for it
17:23
BAndiT1983
check the frame server prototype, at one of the top methods it builds the tree
17:23
BAndiT1983
just saying, otherwise more people will struggle with this task
17:24
Dev_
yes, i will try to change it
17:24
BAndiT1983
have used this while implementing -> http://yaai.sourceforge.net/yaai/fileformat.html
17:25
BAndiT1983
there i've got the idea of recursion, as the tags have often similar info in them
17:25
Dev_
yes , it was there in refernces , the challenge also includes recursion
17:26
Dev_
but it doesn't build a tree like form
17:28
Dev_
left the channel
17:30
BAndiT1983
what doesn't build a tree?
17:30
BAndiT1983
if you mean the prototype, then it's not true, as it uses recursion to walk through every node, starting at the first one
17:52
Dev_
joined the channel
17:55
RexOrCine|away
changed nick to: RexOrCine
17:56
Dev_
sorry for not being specific : my code of avi genration also uses recursion , for finding size of each header . See findSize function in AVisizes.cpp , where will call this function once and store sizes in unordered_map
18:03
virtuous
joined the channel
18:03
virtuous
left the channel
18:05
BAndiT1983
Dev_, FindSize() is rather error-prone and difficult to maintain
18:05
BAndiT1983
you are calculating a lot manually, which can result in failures, especially when adding unit tests the problem can occur
18:08
Dev_
yes , makes sense
18:12
Dev_
Also one last thing is(in context of frameserver) : I was debugging the prototype , It prints offset and sizes each time a read callback is called , right . If we seek backward , no printing of offset and size will takes
18:14
Dev_
So is my assumption is correct that , if a particular frame is requested second time , Our virtual AVI file can provide that frame itself and we don't need to find it again in buffer
18:17
BAndiT1983
the prototype is rather baasic, so it's not providing advanced features
18:17
BAndiT1983
also the virtual file content is stored in a 30mb buffer, which shouldn't be the case for real one later
18:18
BAndiT1983
clicking on the timeline in VLC works, but going frame by frame backwards isn't working properly yet, i assume that it has to do with missing keyframes, that VLC is complaining aobut
18:20
Dev_
so we have to fetch that frame again each time for real frameserving , right ?
18:21
BAndiT1983
probably, if it is not currently stored in some buffer, see static allocator
18:22
BAndiT1983
if the RAM is big enough we could try to get multiple large pages, but for most cases we would get the frames over and over
18:24
Dev_
If the RAM is big ... : The idea of inspecting the whole RAW input while loading and reading all the frames will fail , if the RAM is small , right ?
18:25
Dev_
(in one go)*
18:27
BAndiT1983
you can calculate amount of required RAM to see what we would need for at least 5 to 10 frames, more is better, but just start simple at firstz
18:29
BAndiT1983
if i'm not mistaken, then we need around 60MB for 4k frame
18:29
BAndiT1983
http://jan.ucc.nau.edu/lrm22/pixels2bytes/calculator.htm
18:30
BAndiT1983
this site even says 72MB
18:30
BAndiT1983
4096x3072x48bit
18:30
BAndiT1983
48bit / 3 = 16bit per channel
18:31
BAndiT1983
if i take 4k dimensions of 3840x2160, then it takes 47MB
18:33
Dev_
i think we can provide this much memory , so extracting all the frames at once can also work ,
18:34
BAndiT1983
?
18:34
BAndiT1983
are you sure? just multiply 25 frames by 50mb
18:35
BAndiT1983
what is your result there?
18:35
Dev_
1250 MB, more thans one GB
18:35
BAndiT1983
correct, and 25 frames are just a 1 sec
18:36
BAndiT1983
now imagine files of 2 minutes, this is not that simple to store in 16GB RAM, where a part is already occupied and the memory fragmented, so we have to stream to one or multiple memory blocks
18:36
BAndiT1983
otherwise performance would degrade
18:37
Dev_
yes , makes sense
18:38
Dev_
What if video player request the frame which aren't requested yet ,
18:38
Dev_
and not in buffer
18:39
Dev_
by forword seeking
18:41
BAndiT1983
this was a topic some days ago
18:42
Dev_
is it in irc logs , couldn't find
18:42
BAndiT1983
first you would iterate through source data, lets say MLV file, you would write down a last of all frame positions, maybe just of image data, as the size is always the same, then you would generate AVI info and create a second list of AVI frame positions, if the player aasks for certain offset in memory, you would check which frame is meant and send it over
18:43
BAndiT1983
it's a bit oversimplified theory, but this is the general idea
18:43
BAndiT1983
i doubt that a player would request part of a frame, if the frames are not some sort of diff image
18:44
BAndiT1983
http://irc.apertus.org/index.php?day=18&month=03&year=2019
18:46
Dev_
i doubt that a player would request part of a frame, if the frames are not some sort of diff image : , if it request for some part then we can transfer that many bytes
18:46
BAndiT1983
diff frames -> https://stackoverflow.com/questions/29022690/computation-of-b-frames-in-mpeg-video-coding
18:47
BAndiT1983
it's not about how many bytes, but the offset it requests, has to be evaluated, so we can respond with correct data there
18:47
BAndiT1983
if we know the header size, then it's not a problem to calculate right frame and offset into its data
18:49
Dev_
yes , it clear now . thanks for help .
18:50
Dev_
its*
18:50
BAndiT1983
no problem
18:50
Dev_
left the channel
18:51
BAndiT1983
changed nick to: BAndiT1983|away
18:52
BAndiT1983|away
changed nick to: BAndiT1983
20:05
BAndiT1983
changed nick to: BAndiT1983|away
20:31
aSobhy
left the channel
20:36
BAndiT1983|away
changed nick to: BAndiT1983
21:04
aSobhy
joined the channel
23:06
aman_
joined the channel
23:48
BAndiT1983
changed nick to: BAndiT1983|away
23:50
futarisIRCcloud
joined the channel