• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 100 subscribers
  • Views 931 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.

DM365 - Video Capture - Resizer problem

Joseph Pulver
Prodigy 60 points

I am using DVSDK 4_02_00_06 to write a DMAI application that captures NTSC D1 composite video on a DM365 through the LI-VI365 board.   I set oper_mode=0 int eh boot args.  When I set my Capture_Attrs to give me UYVY frames, ontheFly=FALSE I get an image that looks like this (720x480 - I removed the color data): 

That image looks fine.  But I need 420PSEMI to feed the H264 encoder.  So I set my Capture_Attrs to ColorSpace_YUV420PSEMI, ontheFly=true, resolution left the same.  That gives me this image (again color data removed, this image ends up 736x480, after padding):

Notice how the slanted lines are jagged, and stair steppy?  It's almost as if the resizer is duplicating fields rather than deinterlacing the video properly.  Why is this?  How do I setup the Capture / Resizer to give me an image that looks like figure 1, but in YUV420PSEMI for the H264 encoder?  Is it possible to get a full frame of YUV420SP directly from the capture device (ontheFly=false?) and bypass the resizer, like I assume the UYVY capture is doing?

I've tried setting oper_mode=1 in the boot args, and using the Resizer in single shot mode.  Doing so appears to only give me 1 field of the interlaced video at a time.  This is not what I need either.  

Thank you for any help on this.  

Joe

  • 0
    Intellectual 435 points

    Hi,

    I am also interested in a solution to this problem, and am surprised nobody from TI will give information on it.  There are many open threads about this issue.  Here's hoping that bumping this thread to the top will help someone new see it.

    Thanks,

    Chris Richardson

  • 0
    Intellectual 960 points

    I am too VERY!!!!!!!!!! interested in the solution.

    I promised my customer the solution and am struggling for several weeks with this.

    Is there something I can do to promote the issue and the answer reception?

  • 0 in reply to Leon Pollak
    Guru 31670 points

    All,

    I'm not sure what exactly is happening in your case. But from a high-level, it looks to me like this. In the YUV420SP color conversion is done on interlaced data and after that de-interlacing is performed. In the other case there is no color conversion required and only de-interlacing is done. So, the solution would be to do the color conversion after de-interlacing is done. For this you might have to change the pipe line flow.

  • 0 in reply to Renjith Thomas
    Prodigy 60 points

    I eventually got an acceptable 420PSEMI image using single shot mode, not continuous (set oper_mode=1 in the bootargs to use the resizer in singleshot or onthefly mode).   In continuous mode the capture driver duplicates a field, so you lose half the vertical resolution.  This was documented in the driver document somewhere.  So in a sense you lose half the vertical resolution, but keep the full horizontal resolution, and get the stair step look on diagonal lines. There are two ways to fix this.

    Option 1, if continuous mode is needed (better performance)  modify the driver code to pass both fields into the resizer.  I've seen posts in these forums that mention what needs to be done, but I can't find them right now.  I did not go this route.  I got acceptable performance using option 2. 

    Option 2,  use the Resizer in "onthefly" or "singleshot" mode.  I capture the full resolution UYVY image, and send that into the resizer to get a 420PSEMI output.  The trick here was configuring the resizer properly (getting the correct image width, height, linelength values).   And I may or may not have had to change the Resizer.c file in the DMAI library.  I also may or may not have changed the driver code in the kernel.  I honestly can't remember.  I tried so many things, and finally got something that worked.  Here are a couple threads about capturing full resolution images that got me started.

    http://e2e.ti.com/support/embedded/linux/f/354/t/41298.aspx

    http://e2e.ti.com/support/embedded/multimedia_software_codecs/f/356/t/34546.aspx?pi239031349

    And some warnings.  Due to the nature of NTSC video, when I started using both fields I got very noticeable combing artifacts on objects in motion.   I believe this is why whomever wrote the driver decided to line double.  The half vertical res (line doubled) images may actually look better (and encode better) than video with combing.  

    I also had issues on the display side that needed to be resolved.  I capture, resize, h264encode, transmit, NETWORK, receive, h264decode, display.  The display was a mess when I got the capture side working.  It was as if the two fields of the interlaced video were being written to the display in reverse order, making the video very jittery.  This wouldn't be noticed if the fields were doubled (as top and bottom are the same), but when top and bottom differ it is very noticeable.   I am not sure which step caused the problem, but I fixed this by adjusting the decoder output buffer's dim.y value.  I subtracted 1 from the value the decoder gave me to force the display to output the fields in reverse order.   I think I had a color issue too, which I resolved by adjusting cbcrOffset calculated in Dispaly_v4l2.c. 

    Basically I kept randomly changing things, and suddenly it worked, and I moved on.  I hope something here helps.

  • 0 in reply to Joseph Pulver
    Intellectual 960 points

    Hello, Joseph.

    It is VERY interesting what you write here, very intriguing, but I do not know what to do with this...:-)

    I know that this is a bit impudent to ask, but if you could put, for example, your DVSDK tree "as is" to my FTP

    ftp://www.plris.com/pub/incoming,

    then we can diff it against the original tree, find all changes you made, extract, test and publish the relevant changes.

    Sorry again for my impudence...:-)

  • 0 in reply to Leon Pollak
    Prodigy 60 points

    I can't upload the whole tree, but I'll try to help if you have any specific questions.  I used the DMAI examples as a starting point and baby stepped my way from capture to display.

    1.  Capture UYVY images (oper_mode=0, cAttrs.ONTHEFLY=false).  Dumped these to a file to prove they looked right.  The image from the first post is an example output.

    2.  Added the Resizer step.  Set the rAttrs to what I wanted, and worked until the resizer output was acceptable.   I was shooting for a full vertical resolution 420PSEMI image. 

    3.  Then I added some Display code to display the Resizer output. (sanity  check that the display worked)

    4.  Finally I added the encode / decode steps.  There were some minor changes that needed to be made, but eventually it all clicked and I had what I wanted.

    Overall, there were not that many changes necessary in the DMAI library, or the kernel drivers.  It was just a matter of getting the right parameters set in my resizer / capture / display Attribute structures, and reworking how the buffers were passed around through the Fifo's with the manual resize step added in.