• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 100 subscribers
  • Views 349 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.

Encoding partial frame width on DM365

Keith Nicholson
Prodigy 80 points

Hi,

I've been trying to find a way to encode < full input frame using the H.264 encoder of the DM365, and I'm struggling!

To explain the problem, I'm using the resizer device (chained with capture device) to convert the colour space of an input PAL D1 (720x576) image into 4:2:0SP so it can be fed into the H.264 encoder. The resizer output buffer has to be 32 byte aligned, so the resulting captured frame is 736x576 (last 16 pixels on each line are padding).

So, what I'd like to be able to do is pass the input 736 wide image into the H.264 encoder but tell it to only encode the first 720. I've been through the encoder user guide and have played with many of the input parameters but to no avail. The best result is setting 'captureWidth' to 736 and other width values to 720. Based on the user guide this suggests it will compensate for the input buffer being wider than the image. In fact, the resulting output is correct, apart from the last 12 lines which are not written to by the encoder and left uninitialised. It is as if the encoder knows to process an input buffer of 736x576, but stops encoding after 720x576 pixels. The difference between the 2 sizes being approximately 12x736 pixel wide lines! Doesn't seem like a coincidence.

Just wondering if anyone has had any success trying to do something similar? I realise I could perform a framecopy operation to remove the padding, but I was hoping to avoid what seemed like an unnecessary step.

regards,

Keith Nicholson

  • 0
    Prodigy 80 points

    If anybody involved with the codec development in TI could provide any insight into how the 'captureWidth' setting affects the encoder process, and how the encoder determines that it has finished the frame.

    It's really the relationship between captureWidth and inputWidth that I'm not sure is working correctly.

    regards,

    Keith

     

  • 0
    TI__Mastermind 37340 points

    Keith Nicholson said:

    To explain the problem, I'm using the resizer device (chained with capture device) to convert the colour space of an input PAL D1 (720x576) image into 4:2:0SP so it can be fed into the H.264 encoder. The resizer output buffer has to be 32 byte aligned, so the resulting captured frame is 736x576 (last 16 pixels on each line are padding).

    Are you using 8-bit pixels in resizer; normally the video pipeline uses 16-bit YCbCr pixels as do the codecs.  Which means each pixel is 2-bytes long.  When using default 16-bit pixels, a 720 pixel line is 32-byte aligned and no 16 additional pixels of padding are necessary.  I am not an expert on how the codecs work, but just wanted to make sure you are not doing any unnecessary padding.

  • 0 in reply to Juan Gonzales
    Prodigy 80 points

    In the case of the DM365, the H.264 encoder only takes 4:2:0 semi-planar format, so unfortunately it has to be 8-bit pixels coming out of the colorspace conversion in the resizer. I'm not sure why the H.264 encoder doesn't support 16-bit pixels, but I guess it's due to optimisations required for this particular device.

     

  • 0 in reply to Keith Nicholson
    Intellectual 650 points

    We've actually been successful at taking in 720x480 input video, conversion to SP and still getting the encoder to produce 720x480 output H.264 video - the trick is that in addition to setting captureWidth = 736, imageWidth = 720 to also ensure during your encodeBuffer call to pass in parameters in bufDesc[x].bufSize (since the bufSize is now 736x480 for Y, and 736x480*0.5 for UV)

    I also 'tricked' the resizer into doing 720x480 -> 720x480 (so no scaling); just pass in 720x480 as the desired width,height and just know in the back of your head that it actually deposits 720 valid data, 16 more useless pixels, so that pitch = 736, valid = 720

    Jerry Johns
    Nuvation Research Corporation 

  • 0 in reply to JerryJohns
    Prodigy 80 points

    Thanks for the suggestions Jerry, much appreciated.

    On your second point, this is also the way I'm using the resizer, so the 'real' data is just 720 with 16 useless pixels just there for the resizer padding.

    This is interesting, reading through your description would seem to match how I'm passing the data in. I wonder where the difference is. Certainly the bufDesc sizes are 353280 and 176640 bytes for the Y and UV respectively.

    I'll keep investigating.

    Keith

     

  • 0 in reply to Keith Nicholson
    Intellectual 650 points

    Oh i forgot to mention (and this might be the trick for you): inBufDesc.frameWidth has to be set to 720 in your encodeVideoBuffer call.

    :)

  • 0 in reply to JerryJohns
    Prodigy 80 points

    As it turns out the encoder is working fine, though thanks for the pointers Jerry, that helped me greatly in narrowing down my search. What was actually happening was I'd fixed up the parameters for the encoder ok, but in the process mangled the numbers going to an intermediate framecopy.

    Apologies for the misdirection! :-)

    Keith

     

  • 0 in reply to Keith Nicholson
    Prodigy 170 points

    hi all

    i am working on dm365/dm368

    when capture D1 PAL or NTSC resolution , the input buf to encoder resolution is 736x576 or 736x480 , how to set to make the encoder working at 720x576 or 720x480 resolution ?

    i tried to set as follow but the encoder create failed :

    maxWidth = 736

    inputWidth = 720

    captureWidth = 736