Sync a decode to a capture?

I am not sure what you mean by synchronizing the decode and capture stream, do you mean synchronization at a frame level (i.e. if you were just to display them both in a single display) or do you mean to have time stamps from each that you need to synchronize (i.e. they both are passed on with a relative synchronized time)? Assuming the former and you just need to display both the captured stream and the decoded stream on the same display (or parts of both) you would just have to create a buffer in the display thread that you could fill based on the availability of both the decode and capture sources and than pass it to the display only when both sources are complete.

Yes.. that's what I am doing now. a PIP with the ARM. But I am experiencing an odd behavior which results in the overlaid, extra data I have written to the buffer tearing or not showing up altogether.

Does the request for a buffer from the display wait for a vsync before returning a buffer?

Tearing normally happens when data is being written to a frame buffer currently being dispplayed; this is the reason solutions such as double (or tripple in some cases) buffering exist.  This could also affect data not showing up, depending on when relatively to the sync you write the data to the buffer.  Alternatively, data may not be displayed if only a single frame buffer is being displayed in a double buffer scheme (no ping-pong between the buffers) and data is written to the buffer that is not being displayed.

That said, do you know if you have a single or multiple buffering implementation?  Assuming a multiple buffer implementation (recommended), you should be able to use FBIO_WAITFORVSYNC and FBIOPAN_DISPLAY requests to sync ping-ponging of your frames.  As the name suggests, FBIO_WAITFORVSYNC is a requests which returns from the display driver when the frame has been fully rendered the end-of-frame vsync is encoutered.  This tells the application to pass the next frame (which the application should have filled with valid data, while the current frame was bing displayed); the application uses FBIOPAN_DISPLAY to advance memory pointer to next frame to be displayed, which means that the buffer for the current frame is now free and the application can start placing valid video data on it to get it ready for display in the future.  You can see our DVSDK demos (decode and encodedecode) for reference code that follow this approach.

I hope this helps.

my code is built on the encodedecode demo. I am using the Vdec2_GetDisplayBuf() call to get the buffer I am writing into. Then sending it off to the display..  this is the rough code for the p.i.p.  I am making.. I have to keep the pip tiny to maintain the 30fps frame rate.

  fifoRet = Fifo_get(hCapFifo, &hCapBuf); // Get the camera  buffer
    if (fifoRet < 0) {
           ...err
    }

    hOutBuf = Vdec2_getDisplayBuf(hVd2);
    while (hOutBuf)
     {
            cBuf = (Uint16 *)Buffer_getUserPtr(hCapBuf);
            oBuf = (Uint16 *)Buffer_getUserPtr(hOutBuf);
// PIP
.....

copy part of the cbuf into the obuf

......
        fifoRet = Fifo_put(hDispFifo, hOutBuf); 

.......

As to the FBIO_WAITFORSYNC and FBIOPAN_DISPLAY requests.  I have looked at the demos and I can see the FBIO_WAITFORSYNC call in the OSD code when an empty OSD buffer is requested. I have to gain a better understanding of when I can call ioctl and with which handles. It looks like only  Display_fbdev_get() waits for VSync.. ?

Display_v4l2_get resolves down to an ioctl (VIDIOC_DQBUF) call which , I assume  frees an empty buffer..   but it seems to just do it. Without any test for sync.

I haven't changed the buffer structure from the encodedecode demo yet so I believe the display thread has 3 input  buffers.

I will look more deeply into the demos.

Hi Jona,

Did you resolve the WAITFORVSYNC issue as I was using encodedecode demoa and now fbdev_loopback demo but have the same problem as I need to have synchronised data put into the video fields from a synchronised camera but the problem is it is not fixed between restarts of the apps and I think it has something to do with the buffering and probably the WAITFORVSYNC.  when I run the code I get an offset between when an event happens and is captured in the camera and the data that is coming from the other part of the system.  The offset I can explain due to the buffering but when I restart the offset changes- once running it is fixed but bewteen runs it differs by anything from 0 to 2 fields.  Any help on getting the buffering consitant would be much appreciated.

Thanks, Jinh T.