• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 331 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.

video shifts with resizer

chrisw957
Intellectual 480 points

Other Parts Discussed in Thread: OMAP3530

 

I have a pretty simple gstreamer pipeline that uses the resizer to downsample interlaced (bt656) video from 720x480 to 720x240.  I expected this operation to essentially "deinterlace" the video.  This works somewhat, but I have some consistent video "shifts" in the video output which looks like it might be the resizer switching from using "odd" lines to "even" lines.  I've tried several things to get rid of them, without any luck.  They are consistently in the same location.

Here is the gst pipeline:

$ gst-launch -v v4l2src num-buffers=200 always-copy=false ! dmaiaccel ! queue ! dmairesizer target-height=240 target-width=720 ! dmaienc_mpeg4 maxbitrate=6000000 targetbitrate=2000000 ! dmaiperf ! qtmux ! filesink location=newtest2.m4v

And here is a snapshot of the video when my arm is in motion (the aspect ratio has been corrected):

 

If the source is 720x480 and the output is 720x240, wouldn't you expect the resizer to just use every other line?

Lack of a deinterlacer on the omap3530 is becoming a problem for me.

Thanks,

Chris

  • 0
    TI__Mastermind 43875 points

    Chris,

    I don't think this is a de-interlacing issue. If it were you would likely see alternating lines showing the issue.

    This is more likely a buffer management issue, where the input and the output are using a single buffer but putting data in and reading out at completely different rates. The reading and writing overtake each other causing what is called 'tearing'

    The solution is to make sure that you are using triple buffering. (Double buffering will eliminate tearing but may introduce stuttering)

    I am not an expert on GStreamer, but if I remember correctly there are options somewhere to determine the number of buffers used.

    BR,

    Steve

  • 0 in reply to Steve Clynes
    Intellectual 480 points

     

    Thanks for the input.

    I originally thought it might be buffer related as well...  Each element in gstreamer seems to have its own buffer settings.  v4l2src defaults to 2 buffers, I changed that to 5 without any noticable change.  The dmairesizer has "number of output buffers", which defaults to 3, and I tried changing to 5 without any noticable change.  The dmaienc_mpeg4 element has an outputBufferSize as well, which claims to have a default of zero.  If I change that to anything else, I get an error from that element that "Not enough space free on the output buffer".  Maybe I would have to play with the cmem pools to get that to work.

    I guess I should also mention I tried adding a gstreamer "queue" element after the dmairesizer element, but that didn't change anything noticably either.

    -chris