[v4l2 demo] Issue in displaying the output

If you are doing any type of encoding or decoding, you will need to run loadmodules.sh as that sets up communication between ARM and MJCP used for video/image compression.  If you are simply capturing and displaying, you may be able to get away without running loadmodules.sh.

Please note that the source code for the encode, decode, and encodedecode examples are included.  I agree that this is likely due to some call made in on of these demos that initializes the hardware; you must ensure that you are making similar calls in your example.   If after looking at the demo source code, you cannot figure things out, let us know and we will point you in the right direction.  Hint:  Loook for interactions with Video drivers (normally call to open functions, followed by calls to ioctl function).

Hi Juan,

I'm running the v4l2 example in the dvsdk folder which should be an easy starting code to develop applications using the dm355. In this demo there is no encoding/decoding procedure.

The encodedecode demo is not useful to me because this is my first experience in the dm355 field and i can't understand lot of code portion of the example.

The v4l2 is a suitable example so i prefer to start with it. I suppose that the initialization to be added should be the Initialize Codec Engine run time "CERuntime_init();". Is it correct?I have tryed to add this code to the example but i have some errore including the header file which contains the definition of CERuntime_init() because this method is defined as extern.

Any idea?Is there someone which can execute correctly the v4l2 example?

Thank you for any suggestion or comment!

please note that you do not need to call any of the CE (Codec Engine) functions such as CERuntime_init() unless you are doing encoding.decoding. 

All you need is calls to the Linux drivers for capture and display; we provide standardized Linux video drivers (APIs are defined via Linux V4L2 and FBDev Standards); both of these are character type drivers, which mean that you communicate with these drivers via function calls such as: open, read, write, mmap, close, and ioctl.  Look for calls to these functions in the encode demos, my guess would be that some of the ioctl calls in the demos are passing different initialization paramaters than what the V4L2 example is passing, and hence initializing the hardware differently.

Hi Juan,

I think my issue concerns only the display initialization because the program run correctly except for the displaying task.

This is my init routine. Where do you think i'm wrong?

Thank you very much for your great help!

/******************************************************************************
 * initDisplayDevice
 ******************************************************************************/
int initDisplayDevice(char *displays[])
{
    struct fb_var_screeninfo varInfo;
    struct fb_fix_screeninfo finfo;
    unsigned int            *buf;
    int                      fd;
    int                      i;
    int                      screen_pitch = 0;
    int std;

    /* Open video display device */
    fd = open(FBVID_DEVICE, O_RDWR);

    if (fd == -1) {
        printf("Failed to open fb device %s (%s)\n", FBVID_DEVICE,
                                                  strerror(errno));
        return FAILURE;
    }

    if (ioctl(fd, FBIOGET_FSCREENINFO, &finfo)) {

        printf("Failed FBIOGET_FSCREENINFO on %s (%s)\n", FBVID_DEVICE,
                                                       strerror(errno));
        return FAILURE;
    }
    screen_pitch = finfo.line_length;


    varInfo.xres = RES_WIDTH;
    varInfo.yres = RES_HEIGHT;
    varInfo.bits_per_pixel = SCREEN_BPP;

    /* Set video display format */
    if (ioctl(fd, FBIOPUT_VSCREENINFO, &varInfo) == -1) {
        printf("Failed FBIOPUT_VSCREENINFO on %s (%s)\n", FBVID_DEVICE,
                                                       strerror(errno));
        return FAILURE;
    }

    if (varInfo.xres != RES_WIDTH ||
        varInfo.yres != RES_HEIGHT ||
        varInfo.bits_per_pixel != SCREEN_BPP) {
        printf("Failed to get the requested screen size: %dx%d at %d bpp\n",
            RES_WIDTH, RES_HEIGHT, SCREEN_BPP);
        return FAILURE;
    }

    /* Map the video buffers to user space */
    displays[0] = (char *) mmap (NULL,
                 screen_pitch * varInfo.yres_virtual,
                                 PROT_READ | PROT_WRITE,
                                 MAP_SHARED,
                                 fd, 0);

    if (displays[0] == MAP_FAILED) {
        printf("Failed mmap on %s (%s)\n", FBVID_DEVICE, strerror(errno));
        return FAILURE;
    }

    /* Clear the video buffers */
    buf = (unsigned int *) displays[0];

    for (i=0; i<FRAME_SIZE * NUM_DISP / sizeof(unsigned int); i++) {
        buf[i] = UYVY_BLACK;
    }

    printf("Display buffer %d mapped to address %#lx\n", 0,
        (unsigned long) displays[0]);

    for (i=0; i<NUM_DISP-1; i++) {
        displays[i+1] = displays[i] + FRAME_SIZE;
        printf("Display buffer %d mapped to address %#lx\n", i+1,
            (unsigned long) displays[i+1]);
    }

    return fd;

Two things I would like to point out.

1) Based on your initial e-mails and title of the post, I thought your goal was to use V4L2 driver; the source code above is using FBDev (for display only) driver.  Just wanted you to be aware of that ...

2) The code above looks ok from an FBDev point of view, however, without knowing the values of RES_WIDTH, RES_HEGHT, SCREEN_BPP.... and what your goal is for displaying, it just looks like very generic code.  FYI, the encodedecode demos assume NTSC or PAL by default, hence if running these initialize your hardware correctly, you should be using similar values to configure your program.  Also, as I pointed out, FBDEV is only used for display of video, you may also need to ensure proper initialization of the capture side (V4L2 driver).