• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 320 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.

Buffer issue when encoding on DM365

Tom Hanson
Intellectual 920 points

I'm running a modified version of the encode demo.

Scenario 1: If I allocate the capture buffers in the application, the image is correct, but there is an apparent buffer contention/overwrite/?? issue.  After a period of a few seconds to a minute the capture thread gets an error on the capture_put() call trying to give a buffer back to the capture device. I've verified all arguments to the Capture_put() call.

Scenario 2: If I allocation the capture buffers in the driver, the image has color bars across it (see attached image), but the application will run continuously with no buffer problems as in scenario 1.

I'm assuming that the color bars are buffer size/offset issues related to the chroma buffer.

Any suggestions as to how to fix either of these problems?

TIA!

ColorBars.zip
  • 0
    Genius 5240 points

    Tom, I can't answer your question, but...   I've created an application that streams H.264 video to the network using cut and paste code from the encode demo.  It runs day in and day out without any failures.  I'm using DVSDK_2_10_00_13.

    I'm fixing to re-architect the code to suit my needs because I used much of the code in it's existing state.  Perhaps you modified something that's causing your problem.  I would go back and review the differences between the original and new code.

  • 0 in reply to John Anderson
    Intellectual 920 points

    John Anderson said:
    Perhaps you modified something...

    That's for sure.  Had to tweak several things to get it running on a legacy board.  That included restructuring the buffering scheme which is a mess (IMHO of course.)  That uncovred/caused other problems including this one.  I'm now going back and actually fixing/finding the problems, instead of working around them.

  • 0
    Intellectual 920 points

    Tom Hanson said:
    Scenario 1: ...After a period of a few seconds to a minute the capture thread gets an error on the capture_put() call..

    I've got a partial answer: for VIDIOC_QBUF, the video driver (specifically vpfe_doioctl() ) runs through a different code path if the buffer queue is empty than if it is just putting the returned buffer on the end of the queue.  All well and good, but in this path it validates the buffer length, which it doesn't do in the normal path.  Thus, if the length is wrong you don't get an error until you hit a condition which causes the buffer queue to empty. 

    So, WHY would the length only be validated if the queue is empty???  Can't expain that one, but off the cuff it sounds like a bad idea.  If the length is invalid when the queue is empty, isn't it invalid when there are still buffers in the queue?

    I'm still working on why the length is wrong.  It appears that the calculation in the demo doesn't match what the driver actaully uses.