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.

Linux/AM5728: Capture VPE display issues

Part Number: AM5728
Other Parts Discussed in Thread: TVP5158

Tool/software: Linux

Hi,

I add cmem support to capturedisplay (leran from dual-camera)

I tried to let our board work like this:

camera ---YUYV---> vpe ---RGB24---> display

and then :

./capturevpedisplay 704 288 yuyv 704 576 rgb24 1 3 -s 31:1920x1080

output is :

vip: G_FMT(start): width = 704, height = 288, 4cc = YUYV
vpe i/p: G_FMT: width = 704, height = 288, 4cc = YUYV
vpe o/p: G_FMT: width = 704, height = 576, 4cc = RGB3

allocating cmem buffer of size 0xc6000
ERROR:alloc_buffer:175: drmModeAddFB2 failed: Invalid argument (-22)
ERROR:get_cmem_buffers:198: allocation failed
allocating cmem buffer of addr 0xb1467000

allocating display buffer failed

My question is :

1.I think vpe is works normally.So the issue is on third parameter of drmModeAddFB2 

int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
uint32_t pixel_format, uint32_t bo_handles[4],
uint32_t pitches[4], uint32_t offsets[4],
uint32_t *buf_id, uint32_t flags);

It 's not 0x33424752(RGB3).So what should it be?

2.My CMEM is default value :

40500000-405fffff : CMEM
a0000000-abffffff : CMEM

But why does the allocated cmem address is 0xb1467000.Is that right ?

Best regards

  • Can you try this first with output from vpe as nv12? Also share value of all the arguments passed to drmModeAddFB2() API.

    ./capturevpedisplay 704 288 yuyv 704 576 nv12 1 0 -s 31:1920x1080
  • Hi,

    nv12 will be failed too.But yuyv is fine.

    vpe:/dev/video0 open success!!![ 5136.283158] tvp5158 2-0058: PAL video detected

    Input = 704 x 288 , 1448695129
    Output = 704 x 576 , 842094158
    vip open success!!!
    using 1 connectors, 1920x1080 display, multiplanar: 1
    Setting mode 1920x1080 on connector 31, crtc 34
    [ 5136.577464] tvp5158 2-0058: PAL video detected
    vip: G_FMT(start): width = 704, height = 288, 4cc = YUYV
    vpe i/p: G_FMT: width = 704, height = 288, 4cc = YUYV
    vpe o/p: G_FMT: width = 704, height = 576, 4cc = NV12

    allocating cmem buffer of size 0xc6000
    ERROR:alloc_buffer:163: drmModeAddFB2 failed: Invalid argument (-22)
    ERROR:get_cmem_buffers:186: allocation failed

    Blow is my code:

    int bytes_pp = 3;

    offsets[4] = {0};
    buf->fourcc = fourcc;
    buf->width = w; //704
    buf->height = h; //576
    buf->nbo = 1;
    buf->pitches[0] = w*bytes_pp; //w*3

    buf->fd[0] = alloc_cmem_buffer(w*h*bytes_pp, 1, &buf->cmem_buf);

    if(buf->fd[0] < 0){
    free_cmem_buffer(buf->cmem_buf);
    printf(" Cannot export CMEM buffer\n");
    return NULL;
    }

    buf->bo[0] = omap_bo_from_dmabuf(display->dev, buf->fd[0]);
    if (buf->bo[0]){
    bo_handles[0] = omap_bo_handle(buf->bo[0]);
    }

    ret = drmModeAddFB2(display->fd, buf->width, buf->height, fourcc,
    bo_handles, buf->pitches, offsets, &buf->fb_id, 0);

  • Original capturevpedisplay demo works with nv12 output. The bytes_pp requirement for nv12 format is 1.5. Can you first run the demo with original buffer allocation from omap_drm for nv12 output. Make sure that's working, print the input arguments to the drmModeAddFB2 from that original demo, then switch the buffer allocation to CMEM, compare the input to drmModeAddFB2 from the working and non working solution. 

  • Hi,manisha

    We try to do convert color by ourself .

    0181.capturevpedisplay.c
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    /*
    * Copyright (c) 2013-2014, Texas Instruments Incorporated
    * Author: alaganraj <alaganraj.s@ti.com>
    *
    * Redistribution and use in source and binary forms, with or without
    * modification, are permitted provided that the following conditions
    * are met:
    *
    * * Redistributions of source code must retain the above copyright
    * notice, this list of conditions and the following disclaimer.
    *
    * * Redistributions in binary form must reproduce the above copyright
    * notice, this list of conditions and the following disclaimer in the
    * documentation and/or other materials provided with the distribution.
    *
    * * Neither the name of Texas Instruments Incorporated nor the names of
    * its contributors may be used to endorse or promote products derived
    * from this software without specific prior written permission.
    *
    * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
    * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
    * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
    * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
    * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
    * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
    * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
    * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
    * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
    * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
    * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
    *
    * Contact information for paper mail:
    * Texas Instruments
    * Post Office Box 655303
    * Dallas, Texas 75265
    * Contact information:
    * http://www-k.ext.ti.com/sc/technical-support/product-information-centers.htm?
    * DCMP=TIHomeTracking&HQS=Other+OT+home_d_contact
    * ============================================================================
    *
    */
    #include <stdio.h>
    #include <stdlib.h>
    #include <fcntl.h>
    #include <unistd.h>
    #include <stdint.h>
    #include <string.h>
    #include <errno.h>
    #include <time.h>
    #include <linux/videodev2.h>
    #include <linux/v4l2-controls.h>
    #include <sys/mman.h>
    #include <sys/ioctl.h>
    #include <xf86drm.h>
    #include <xf86drmMode.h>
    #include <omap_drm.h>
    #include <omap_drmif.h>
    #include "dma-buf.h"
    #include "util.h"
    #include "cmem_buf.h"
    #include "cmem.h"
    #include "vpe-common.c"
    #define DEBUG 1
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    vpe-common.c
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    /*
    * Copyright (c) 2013-2014, Texas Instruments Incorporated
    * Author: alaganraj <alaganraj.s@ti.com>
    *
    * Redistribution and use in source and binary forms, with or without
    * modification, are permitted provided that the following conditions
    * are met:
    *
    * * Redistributions of source code must retain the above copyright
    * notice, this list of conditions and the following disclaimer.
    *
    * * Redistributions in binary form must reproduce the above copyright
    * notice, this list of conditions and the following disclaimer in the
    * documentation and/or other materials provided with the distribution.
    *
    * * Neither the name of Texas Instruments Incorporated nor the names of
    * its contributors may be used to endorse or promote products derived
    * from this software without specific prior written permission.
    *
    * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
    * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
    * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
    * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
    * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
    * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
    * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
    * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
    * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
    * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
    * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
    *
    * Contact information for paper mail:
    * Texas Instruments
    * Post Office Box 655303
    * Dallas, Texas 75265
    * Contact information:
    * http://www-k.ext.ti.com/sc/technical-support/product-information-centers.htm?
    * DCMP=TIHomeTracking&HQS=Other+OT+home_d_contact
    * ============================================================================
    *
    */
    /*
    * @File vpe-common.c
    * @Brief vpe specific common functions, used to integrate vpe
    * with other modules.
    *
    * Input buffer must be allocated in application, queue it to vpe
    * by passing buffer index
    *
    * Output buffer allocated in vpe_output_init() as vpe output intended
    * to display on LCD.
    */
    #include <stdio.h>
    #include <stdlib.h>
    #include <fcntl.h>
    #include <unistd.h>
    #include <stdint.h>
    #include <string.h>
    #include <errno.h>
    #include <linux/videodev2.h>
    #include <linux/v4l2-controls.h>
    #include <sys/mman.h>
    #include <sys/ioctl.h>
    #include <xf86drmMode.h>
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The cmem I allocated:

    Block 1: Pool 0: 6 bufs size 0xc6000 (0xc6000 requested)

    Pool 0 busy bufs:

    Pool 0 free bufs:
    id 0: phys addr 0xbcf3a000
    id 1: phys addr 0xbce74000
    id 2: phys addr 0xbcdae000
    id 3: phys addr 0xbcce8000
    id 4: phys addr 0xbcc22000
    id 5: phys addr 0xbcb5c000

    Block 1: Pool 1: 1 bufs size 0x129000 (0x129000 requested)

    Pool 1 busy bufs:

    Pool 1 free bufs:
    id 0: phys addr 0xbc96d000

    The output on HDMI will shake ,and I can't find out what's wrong with that.Please help us .

    Below is the image I stored previously.You can see the image move up one line.

    yuv.zip

  • I looked at capturevpedisplay application for using vpe for yuyv to rgb24 conversion. I find the issue to be with the fourcc format incompatibility between V4L2 and DRM framework. They are same for yuyv and nv12 and hence it works for these two formats. But for RGB format, the specification is different in these two frameworks.

    FOURCC('R','G','B','3') or FOURCC('B','G','R','3') in V4L2 spec translates to FOURCC('R', 'G', '2', '4') in DRM framework.

    I added below section to the switch() section inside the alloc_buffer() function in display-kms.c file
    case FOURCC('B','G','R','3'):
    case FOURCC('R','G','2','4'):
    fourcc =FOURCC('R', 'G', '2', '4');
    buf->nbo = 1;
    buf->bo[0] = alloc_bo(disp, 24, buf->width, buf->height,
    &bo_handles[0], &buf->pitches[0]);
    break;
    case FOURCC('A','R','2','4'):
    case FOURCC('R','G','B','4'):
    fourcc = FOURCC('A','R','2','4');
    buf->nbo = 1;
    buf->bo[0] = alloc_bo(disp, 32, buf->width, buf->height,
    &bo_handles[0], &buf->pitches[0]);
    break;

    With this changes, the capturevpedisplay application works for below arguments -
    #./capturevpedisplay 640 480 yuyv 1920 1080 bgr24 0 1 -s 36:1920x1080

    You need to do similar changes to your application using CMEM buffers.

    Hopefully with these changes/fixes, you do not need to use the software based color conversion and hence will not need to debug the display related issue occurring with that.
  • Hi,manisha

    It's successful after I tried your advice.

    But there is a issue still occur in this demo .

    When we tried to do some proccess(opencv) with buf->cmem_buf.

    The video stream will shake.It will display normally when no proccessed.

    In my opinion,CMEM is a share buf between V4L2 and DRM?

    Is there any other threads can use these cmem buf allocated.

  • Hi,manisha
    I found the problem maybe happen in vpe ?
    I have try to use :
    ./capturevpedisplay 1920 1080 yuyv 1280 720 bgr24 0 3 -s 31:1920x1080  (without deinterlace )
    To proccess(opencv) another camera(SDI 1080P) will be successful.
    If I tried :
    ./capturevpedisplay 704 288 yuyv 704 576 bgr24 1 3 -s 31:1920x1080
    The display from HDMI will be jitter (like without deinterlace)

  • Interlace display feature is broken and there is no plans to fix it.
  • Hi,manisha
    I know that DSS can't support Interlace video display.
    Is that mean If we insert our algo to process video will break the VPE to do deinterlace?
  • I don't understand what you meant by this -

    bulabula_yan said:
    If we insert our algo to process video will break the VPE to do deinterlace?

    What's the data flow for your use case?

  • Hi,manisha

    Our data flow is PAL(576I).

    So I use capturevpedisplay demo to do deinterlace then display (576P) on HDMI(resize to 1080P or other)

    I add our algo in process(),blow is where I added :

    index = vpe_output_dqbuf(vpe);    // buf[index] -> cmem is point to a allocated chache between VPE and DRM 

    proccess(buf[index] -> cmem);    //our algo

    display_buffer(vpe, index);    //display buf[index] -> cmem

    If our algo insert in this demo ,VPE will stop doing deinterlace.

    HDMI will display a 576I  without deinterlace.

  • VPE should not be dependent upon who is the consumer of the output buffer.

    Does your algorithm takes lot of time, depriving VPE of the buffer it need in real time?
    How about if you disable the cached read/write, just to make sure cache cleaning is not causing the problem
    You may also try to remove the display from the pipeline and do a file write and check if you see the issue with filewrite output too.
  • Hi,manisha

    I tried to add :

    usleep(5000);

    display_buffer(vpe, index);

    before display.

    If usleep is more than 2ms then the buffer will be interlaced sometime.

    Our algorithm needs 30ms at one time.The input must be PAL(576I).

    Is there any solution?

  • If the vpe is fed 50 interlace fields per sec, then it will produce 50 de-interlaced frames in a sec and the display should also be expecting to run at 50 fps. If your algorithm is taking 30 ms, then it is kind of slowing down entire pipeline. The algorithm needs to be running at the speed of producer (vpe) and consumer (display)
  • Hi,manisha
    Thanks for your reply.
    I think I know what you say.
    Vpe will output 50 frames with de-interlaced in PAL(50 fields).
    But there will be about 20ms that we can use.Right?
    Why did I add only 5ms (usleep(5000);) would disorganize the pipline?
  • I don't know what is going on with your application and what that algorithm is doing, so can't comment why inserting 2ms sleep is making any difference. All I can say is VPE doing de-interlacing is not dependent upon who is consuming the de-interlaced frames. VPE should be correctly fed the input and output buffers with correct parameter settings and it will do as instructed.
  • Hi,manisha

    Here is what I 've done in capturevpedisplay:

    line 327:

    index = vpe_output_dqbuf(vpe);

    //usleep(5000);

    display_buffer(vpe, index);

    As above I want to make usleep(5000) to take place our algo.

    I found if usleep is more than 2ms the vpe will disorganize the pipline after that test.

    1.In my opinion,50 frames will  remain about 20ms to do our algo,but why there is only about 2ms?

    2.In fact,we just need vpe to output 25 frames per second which remain more time to do our algo.I tried to set interlace field to 2 but it faild  

    https://e2e.ti.com/support/arm/sitara_arm/f/791/t/666961#pi316653=2

  • Can you try to increase the buffer depth of VIP and VPE?
  • Hi,manisha

    Thank you very much 

    It works!

    I changed the "NUMBUF" to 12 which vpe will work more stable.

    But sometims it still jitter

    I try to measure the time of capture-display loop.

    I found display is not stable sometimes.Below is what I debug in capturevpediaplay.c line 327 in my src code

    clock_gettime(CLOCK_MONOTONIC,&tp0);//tp0
    display_buffer(vpe, index);
    clock_gettime(CLOCK_MONOTONIC,&tp1);//tp1
    pre_time=tdiff_calc(&tp0, &tp1);
    printf ("total is tdiff=%lf ms \n", pre_time);

    [output]:

    total is tdiff=7.727317 ms
    total is tdiff=19.982787 ms
    total is tdiff=7.717232 ms
    total is tdiff=7.735614 ms
    total is tdiff=7.746837 ms
    total is tdiff=7.749277 ms
    total is tdiff=7.723738 ms
    total is tdiff=7.727480 ms
    total is tdiff=7.675589 ms
    total is tdiff=7.718696 ms
    total is tdiff=7.718370 ms
    total is tdiff=2.509784 ms
    total is tdiff=2.298317 ms
    total is tdiff=3.245363 ms
    total is tdiff=5.429814 ms
    total is tdiff=7.704218 ms
    total is tdiff=7.629555 ms
    total is tdiff=7.623373 ms
    total is tdiff=7.714792 ms
    total is tdiff=7.694133 ms
    total is tdiff=6.831024 ms
    total is tdiff=7.660624 ms
    total is tdiff=7.732197 ms
    total is tdiff=7.705032 ms
    total is tdiff=7.689090 ms
    total is tdiff=7.737403 ms
    total is tdiff=7.707635 ms
    total is tdiff=7.691856 ms
    total is tdiff=7.724389 ms
    total is tdiff=7.646798 ms
    total is tdiff=7.708286 ms
    total is tdiff=7.756109 ms
    total is tdiff=7.703243 ms
    total is tdiff=7.715280 ms
    total is tdiff=14.580302 ms
    total is tdiff=7.594094 ms
    total is tdiff=7.703243 ms
    total is tdiff=7.733987 ms
    total is tdiff=7.737240 ms
    total is tdiff=7.687790 ms
    total is tdiff=7.742608 ms
    total is tdiff=7.658509 ms
    total is tdiff=7.729595 ms
    total is tdiff=7.734963 ms
    total is tdiff=1.427237 ms
    total is tdiff=2.248216 ms
    total is tdiff=2.358829 ms
    total is tdiff=5.100251 ms
    total is tdiff=7.607107 ms
    total is tdiff=7.710725 ms
    total is tdiff=7.670710 ms
    total is tdiff=19.948464 ms
    total is tdiff=7.708448 ms
    total is tdiff=7.642242 ms
    total is tdiff=7.684210 ms

    It will occur about every 50 frames.(very rarely display will take about 15~16ms)

  • Hi,manisha
    VPE will output 50 frames in de-interlaced mode.
    I found our ALGO will take more than 20ms sometimes. I think that's why vpe pipline disorder .
    Can I config vpe output 25fps in de-interlace mode ?
  • bulabula_yan said:
    Can I config vpe output 25fps in de-interlace mode ?

    That's not supported. Today vpe driver only supports motion compensated de-interlacing which will produce de-interlace frame for every field it receives. You can try submitting alternate fields to vpe for de-interlacing in your application. I am not sure if this will work/will have effect on picture quality as it works on motion compensation. vpe IP supports spatial de-interalcing, that might have worked better with alternate field drop but the feature is not supported by the vpe driver.