Current Server Time: 17:22 (Central Europe)

#apertus IRC Channel Logs

2019/03/22

Timezone: UTC


23:04
BAndiT1983
changed nick to: BAndiT1983|away
00: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
00:51
Bertl_oO
what device are you targeting at the moment?
00:57
apurvanandan[m]
zynq-7020
00:59
Bertl_oO
okay, so the BUFG on the -1 parts is limited to 464MHz
01:00
Bertl_oO
you can get a report from vivado with report_pulse_width -all_violators
01:00
Bertl_oO
the BUFIO OTOH can do up to 600MHz even for the -1 parts
01:02
Bertl_oO
so you want to use the I/O buffers (DDR) to reduce your clock early
01:10
apurvanandan[m]
Ok Thanks, I will see to it.
01:11
Bertl_oO
note that you can do DDR easily without any special units by sampling on both clock edges
01:13
apurvanandan[m]
Ohh nice
01:18
Bertl_oO
okay, off to bed now ... have fun!
01:19
Bertl_oO
changed nick to: Bertl_zZ
01:26
shivamgoyal
joined the channel
01:27
shivamgoyal
left the channel
02:30
parimal
joined the channel
03:32
thiblahute
left the channel
03:34
thiblahute
joined the channel
04:46
kingsocarso
left the channel
05:30
BAndiT1983|away
changed nick to: BAndiT1983
06:38
se6astian|away
changed nick to: se6astian
06:54
BAndiT1983
changed nick to: BAndiT1983|away
07:23
Spirit532
left the channel
07:23
Spirit532
joined the channel
07:23
fizz
joined the channel
07:48
fizz
left the channel
08:15
Spirit532
left the channel
08:15
Spirit532
joined the channel
08:30
Bertl_zZ
changed nick to: Bertl
08:30
Bertl
morning folks!
10:00
thiblahute
left the channel
10:01
thiblahute
joined the channel
10:55
aman_
joined the channel
10: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.
10:58
Bertl
Hello aman_!
11:06
Guest27507_
joined the channel
11:08
aman__
joined the channel
11:11
aman_
left the channel
11:13
se6astian
changed nick to: se6astian|away
11:14
Guest27507
left the channel
11:14
Guest27507_
changed nick to: Guest27507
11:31
Y_G
joined the channel
11:32
Y_G
Thanks @anuejn and @vup2,I will go through them
11:40
aman__
left the channel
12:17
Y_G
left the channel
12:33
aman_
joined the channel
13:02
aSobhy
joined the channel
13:10
kingsocarso
joined the channel
13:35
parimal
left the channel
14:10
Bertl
off for now ... bbl
14:10
Bertl
changed nick to: Bertl_oO
14:30
futarisIRCcloud
left the channel
15:20
BAndiT1983|away
changed nick to: BAndiT1983
15:43
aman_
left the channel
16:01
Dev_
joined the channel
16: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
16:09
BAndiT1983
hi Dev_, what's your repo?
16:09
Dev_
for AVI generation
16:09
Dev_
I have PMed you
16:10
BAndiT1983
when?
16:10
Dev_
right now
16:10
BAndiT1983
don't see anything
16:11
Dev_
https://github.com/kakashi-Of-Saringan/T782-challenge , okay here it , looks like web client have some problem with PM
16:12
Dev_
please check
16:12
BAndiT1983
using namespace std; is not a good practice
16: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
16: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
16:15
BAndiT1983
no need for separate lines, if you don't have line breaks
16:15
BAndiT1983
file << graywidth <<" ";
16:15
BAndiT1983
file << grayheight <<"\n";
16:15
BAndiT1983
also line break should be std::endl
16:16
BAndiT1983
why is it mixing up file.write() and file <<?
16:16
BAndiT1983
2 methods for writing? they seem rather similar
16:17
Dev_
Actually , we have to change width into const char for writing using write
16:17
Dev_
play i will change iit
16:17
BAndiT1983
this could be replaced by ternary operator and a boolean switch, e.g. file << grayscaleOutput ? "P5" : "P6"
16:17
Dev_
it*
16:18
BAndiT1983
you have to go with some consistent way, either file.write() or file <<, but mixing them makes it hard to follow
16:19
Dev_
file << grayscaleOutput ? "P5" : "P6" , it seems nice
16: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
16:20
Dev_
okay i will change these things
16: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
16:21
Dev_
okay , please take your time
16:21
Dev_
i will remind u some other time
16:22
Dev_
thanks
16:22
BAndiT1983
you AVI generation is similar to Supragyas, also told him back then, that it's not maintainable
16:22
BAndiT1983
alirght
16:22
Dev_
I could able to change it with some recursion ,
16:23
BAndiT1983
to give you a hint, AVI is built like a tree, that's why recursion is easier to use
16: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
16:23
BAndiT1983
check the frame server prototype, at one of the top methods it builds the tree
16:23
BAndiT1983
just saying, otherwise more people will struggle with this task
16:24
Dev_
yes, i will try to change it
16:24
BAndiT1983
have used this while implementing -> http://yaai.sourceforge.net/yaai/fileformat.html
16:25
BAndiT1983
there i've got the idea of recursion, as the tags have often similar info in them
16:25
Dev_
yes , it was there in refernces , the challenge also includes recursion
16:26
Dev_
but it doesn't build a tree like form
16:28
Dev_
left the channel
16:30
BAndiT1983
what doesn't build a tree?
16: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
16:52
Dev_
joined the channel
16:55
RexOrCine|away
changed nick to: RexOrCine
16: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
17:03
virtuous
joined the channel
17:03
virtuous
left the channel
17:05
BAndiT1983
Dev_, FindSize() is rather error-prone and difficult to maintain
17:05
BAndiT1983
you are calculating a lot manually, which can result in failures, especially when adding unit tests the problem can occur
17:08
Dev_
yes , makes sense
17: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
17: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
17:17
BAndiT1983
the prototype is rather baasic, so it's not providing advanced features
17:17
BAndiT1983
also the virtual file content is stored in a 30mb buffer, which shouldn't be the case for real one later
17: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
17:20
Dev_
so we have to fetch that frame again each time for real frameserving , right ?
17:21
BAndiT1983
probably, if it is not currently stored in some buffer, see static allocator
17: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
17: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 ?
17:25
Dev_
(in one go)*
17: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
17:29
BAndiT1983
if i'm not mistaken, then we need around 60MB for 4k frame
17:29
BAndiT1983
http://jan.ucc.nau.edu/lrm22/pixels2bytes/calculator.htm
17:30
BAndiT1983
this site even says 72MB
17:30
BAndiT1983
4096x3072x48bit
17:30
BAndiT1983
48bit / 3 = 16bit per channel
17:31
BAndiT1983
if i take 4k dimensions of 3840x2160, then it takes 47MB
17:33
Dev_
i think we can provide this much memory , so extracting all the frames at once can also work ,
17:34
BAndiT1983
?
17:34
BAndiT1983
are you sure? just multiply 25 frames by 50mb
17:35
BAndiT1983
what is your result there?
17:35
Dev_
1250 MB, more thans one GB
17:35
BAndiT1983
correct, and 25 frames are just a 1 sec
17: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
17:36
BAndiT1983
otherwise performance would degrade
17:37
Dev_
yes , makes sense
17:38
Dev_
What if video player request the frame which aren't requested yet ,
17:38
Dev_
and not in buffer
17:39
Dev_
by forword seeking
17:41
BAndiT1983
this was a topic some days ago
17:42
Dev_
is it in irc logs , couldn't find
17: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
17:43
BAndiT1983
it's a bit oversimplified theory, but this is the general idea
17:43
BAndiT1983
i doubt that a player would request part of a frame, if the frames are not some sort of diff image
17:44
BAndiT1983
http://irc.apertus.org/index.php?day=18&month=03&year=2019
17: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
17:46
BAndiT1983
diff frames -> https://stackoverflow.com/questions/29022690/computation-of-b-frames-in-mpeg-video-coding
17: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
17:47
BAndiT1983
if we know the header size, then it's not a problem to calculate right frame and offset into its data
17:49
Dev_
yes , it clear now . thanks for help .
17:50
Dev_
its*
17:50
BAndiT1983
no problem
17:50
Dev_
left the channel
17:51
BAndiT1983
changed nick to: BAndiT1983|away
17:52
BAndiT1983|away
changed nick to: BAndiT1983
19:05
BAndiT1983
changed nick to: BAndiT1983|away
19:31
aSobhy
left the channel
19:36
BAndiT1983|away
changed nick to: BAndiT1983
20:04
aSobhy
joined the channel
22:06
aman_
joined the channel
22:48
BAndiT1983
changed nick to: BAndiT1983|away
22:50
futarisIRCcloud
joined the channel