#apertus IRC Channel Logs

So do you have a specific format of the proposal?

mrohit[m]: check our gsoc profile page

morning folks!

good morning

I set the clock period to 1 ns which means 1 GHz

but this was in simulation

I presume RTL simulation, yes?

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

in post-route simulation

what is the most critical path?

I am trying to find the bottle neck.

looks like your newly created system cannot resolve properly

vup2 or anuejn might have some ideas ...

Thanks, Bertl

i would just retry :)

arch linux arm has some fuckups sometimes... not too stable

hm...

how is /etc/resolv.conf set up during the build?

it is manually set to some open dns server

https://github.com/apertus-open-source-cinema/axiom-beta-firmware/blob/master/makefiles/host/run_in_chroot.sh#L25

this is the used nameserver

(seems to be quite slow here, maybe replace it with 8.8.8.8 or so?)

Please verify that except the clock speed all the IOs are as desired.

Simulation screenshot

Yes Bertl , I guess the nameserver is the problem here, the dig command returned time out

Yes it does

Ya, I am rebuilding it now with the change

apurvanandan[m]: well, from the short trace it looks like the output differs from the input, no?

In 12 bit mode it looks like

https://ibin.co/4adW9rb31I6r.png

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

I have tried this twice and the results are same

I am talking about the build of the Beta firmware here

it will unnecessarily cause removing of type

what's the problem with that?

We need to keep track of RAWI and VIDF headers , why can't just use switch , just curious

but i guess we need to deal with few headers (mainly VIDF which contains frame here)

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?

hashes are already defined in .h file, so there is no disadvantage there

otherwise -> (other tags)*

please google about image processing, it's not only about image data, there is white balancing, gamma curve, linearization and much more

also sync points, audio data etc. etc. etc.

I will try to change Switch -> hashmap ,

unordered_map is your friend usually

okay

it also contains apertus proposal

you can grab test files at magiclantern forum

yes i have sample mlvs

just needs a bit of manual intervention maybe

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

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,

but we could get away by loading subsequently every time

an array instead of map could be used, but it's trickier to seek for oldest frame etc.

if user clicks in the track bar : do u mean if user seek the slider of vlc player (or other ) in between

yes, the slider

how do we come to know about , which frame should start frameserving at this point of time (point of silder)

isn't it ?

it is the read callback of FUSE which is reading the data for vlc/mplayer ,

what does it mean for us : so do we need to change read callback , for supporting sudden change in silder positon

yes, and how can we accomplish this?

the answer is not difficult, try to think about it right now

yes, but my avi file do buffer a lot

the c/c++ challenge , actually the avi file which i am creating only works on vlc and buffer a lot

it takes time to load , like in playing youtube video wiith good speed internet

really?

i was talking about MY avi file

then you should search for the cause of the problem, check your loops, maybe there is something fishy going on

the answer is not difficult : there is off_t offset in readcall back , i think that is keeping track of data ,

https://github.com/BAndiT1983/OC_FrameServer/blob/dev/FUSEHandler.cpp

i'm cheating a bit, because data holds 30mb of data, as the frames are not interrupted by other data

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

yes, like header, image data etc.

but for metadata only it would be ok to provide only header and tags

if the player/editor asks for a position in image data, then you have to provide correct offset : i will think about it ,

if you have questions, then ask

which line?

it's fuse callback, so the answer is fuse

as far as i remember it contains the size of chunk to read

so u mean , if we slide the slider , the off_t offset will change , line number 42

yes

offset is the global offset into the file

then it will start from that position , it all makes sense now :)

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 ,

sorry this one

line 31

you could use vector instead

as i said, size can be equal and preset while loading, but we have to know frame number, position in the static allocator buffer

won't be there

(we the ) -> (our first frame *)

static allocatos should go in circles : yes makes sense

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

in your prototype , seeking backword is also working , but if we use static allocator in cycle , that will be problem with big files

once the reading done , i think buffer should be cleared ?

the static alloctors buffer ,

static allocator does the job in the same way, nothing changes

then it would be not much of a trouble to walk forward or backward and load the data

you just overwrite old frames

if there is more memory available then you could allocate multiple pages, each 1gb or 512mb big

why?

then how ?

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

be*

no problem

it's about managing multiple allocated pages

bookmarked , Thanks agian

hi mrohit[m], sorry had not much time lately, my new job is taking a lot of time and energy

marked it, so i don't forget it

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

you don't need to dive into systemd pretty much, i have removed dependencies

yup, I have read this article

daemon was never really using it, so the service description file is totally sufficient

So the task still remain to move the scripts from firmware to daemon..right?

will add direct CMV register access soon, then the scripts can be implemented using daemon

and the handshake package already resides in description.json, so what exactly needs to be implemented for the Web Remote?

many things are prototypes, no tested properly yet and probably need a lot of adjustments

So what would you suggest as a starting point to work for the task?

As of now, I have understood the first goal of the task and I am still working to get to know all other completely

recreating scripts is only a small part of the task

Such as?

there are several tasks already in the list, but daemon lacks some other adapters, like sysfs

it needs to be implemented, if i won't get some free time to start it

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?

parameters will be grouped into presets later, so we can provide pre-defined ones

Thanks BAndiT1983 , will let you know if I have any further questions

off to bed