• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 330 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

saLoopBackFbdev real frame rate?

Alexander Fagrell
Prodigy 65 points

HI,

We have connected our 720p60 camera (component) to a splitter to both have direct looping to a monitor as well as to our board TI8148 EVM. From the board we us the HDMI as output to the same monitor. 

What we discovered is the frame rate through the board seems to be much lower compared to the actual frame rate. The "calculated frame rate  is 62" but comparing it to direct input (visually) it's not even close (maybe 30 or even less). Is it possible that we are missing some configurations? 

We are usting the V4L2 firmware brought by the ezsdk package version 5.05.02.00.

We using the following bootargs:
console=ttyO0,115200n8 rootwait mem=256M earlyprintk notifyk.vpssm3_sva=0xBF900000 vram=128M ti814xfb.vram=0:40M,1:40M,2:1M root=/dev/nfs nfsroot=192.168.111.112:/home/optilia/targetfs,nolock rw ip=dhcp 

I'm not sure if it is on the capture side or the frame buffer?

Any ideas?


Log from saLoopBackFbdev:

root@dm814x-evm:~/video-app# ./saLoopBackFbdev
VPSS_GRPX : please open fb0 node first.
Driver Name: ti81xxvin
Driver bus info: TI81xx Platform
Driver is capable of doing capture
saLoopBackFbdev:
Mode set is 720P60
VPSS_GRPX : please open fb0 node first.
=============================================================
Capture Format:
=============================================================
fmt.type = 1
fmt.width = 1280
fmt.height = 720
fmt.pixelformat = 859981650
fmt.bytesperline = 3840
fmt.sizeimage = 2764800
=============================================================

Fix Screen Info:
----------------
Line Length - 3840
Physical Address = 88000000
Buffer Length = 41943040

Var Screen Info:
----------------
Xres - 1280
Yres - 720
Xres Virtual - 1280
Yres Virtual - 720
nonstd - 0
Bits Per Pixel - 24
blue lenth 8 msb 0 offset 0
red lenth 8 msb 0 offset 16
green lenth 8 msb 0 offset 8
trans lenth 0 msb 0 offset 0

Var Screen Info:
----------------
Xres - 1280
Yres - 720
Xres Virtual - 1280
Yres Virtual - 5760
nonstd - 0
Bits Per Pixel - 24
blue lenth 8 msb 0 offset 0
red lenth 8 msb 0 offset 16
green lenth 8 msb 0 offset 8
trans lenth 0 msb 0 offset 0

Fix Screen Info:
----------------
Line Length - 3840
Physical Address = 88000000
Buffer Length = 41943040
C: 0
TS: 583538 index 0
Result Time: 16 858918
Calculated Frame Rate: 62 Fps


Thanks
 

  • 0
    TI__Guru**** 476575 points

    Hi,

     

    Can you do cat on sysfs entri mode under display0 folder to check display resolution? If it is 720p, display is configured for the 720p resolution. You can even check the time difference between two frames captures and see if it is 16ms. if both are correct, there could be some issue in the sample application.

     

    Regards,

    Brijesh Jadav

  • 0 in reply to Brijesh Jadav
    Prodigy 65 points

    It is 720p and the time differences between two captured frames are 16 ms. 

    I changed the  saLoopBackFbdev code and put a timer to only queuing and dequeuing the buffer once every second (1 FPS). A buffer of size 4 showed a new frame every forth second and a buffer size of 8 gave a new frame every eighth second. 

    I believe the buffer is shifting (?) everytime it is queuing so the userptr should always be set to the first index of the buffer.

    Tried:

    capt.buf.m.userptr = (unsigned long)fbdev.buffer_addr[capt.buf.index]; --> capt.buf.m.userptr = (unsigned long)fbdev.buffer_addr[0]; 

    Which gives a much smoother video (probably around 60).

    Regards,


    Alexander 

  • 0 in reply to Alexander Fagrell
    TI__Guru**** 476575 points

    hi,

     

    In this hard coding, you are using same buffer for the capture again and again and FBDev is always uses buffer from the index 0. This kind of tells that buffer is not getting switched correctly in the application, which is why you are seeing smooth display. can you check the buffer switching logic in the sample application?

     

    Regards,

    Brijesh Jadav

  • 0 in reply to Brijesh Jadav
    Prodigy 65 points

    Hi Brijesh,

    Well our goal was to have a smooth display which we now have achived. Is it possible that we drop frames with this solution?

    I also tried to mmap each buffer index which also seems to give a smoother video, thus:

    From saLoopBackFbdev sample:
    >>>

    fbdev.buffersize = fbdev.fixinfo.line_length * fbdev.varinfo.yres;
    fbdev.buffer_addr[0] = (unsigned char *)mmap(0,
    fbdev.buffersize * MAX_BUFFER,
    (PROT_READ | PROT_WRITE),
    MAP_SHARED, fbdev.fd, 0);

    if ((int)fbdev.buffer_addr[0] == -1) {
    printf("MMap Failed.\n");
    return -1;
    }
    for (i = 1; i < MAX_BUFFER; i++)
    fbdev.buffer_addr[i] = fbdev.buffer_addr[i-1] + fbdev.buffersize;

    memset(fbdev.buffer_addr[0], 0x00, fbdev.buffersize * MAX_BUFFER);
    >>>

    changed to

    >>>

    for(int i = 0; i < MAX_BUFFER; i++) {
    fbdev.buffer_addr[i] = (unsigned char *)mmap(0,
    fbdev.buffersize ,//* MAX_BUFFER
    (PROT_READ | PROT_WRITE),
    MAP_SHARED, fbdev.fd, 0);

    if ((int)fbdev.buffer_addr[i] == -1) {
    printf("MMap Failed.\n");
    return -1;
    }
    memset(fbdev.buffer_addr[i], 0x00, fbdev.buffersize); // * MAX_BUFFER
    }
    >>> 

    Keeping : capt.buf.m.userptr = (unsigned long)fbdev.buffer_addr[capt.buf.index]

    Regards,
    Alexander