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.

H.264 encoder input buffer pitch

Hi,

I use C66x HP H.264 decoder and encoder. The decoder produces YUV buffers with pitch > width when width is not multiple of 16.

I want to use the buffers as input to the encoder. I tried to specify pitch in IVIDENC2_DynamicParams.captureWidth and IVIDEO2_BufDesc.imagePitch with no luck.

What parameters should I use to specify pitch for the encoder?

Regards,

Andrey Lisnevich

  • Hi Andrey,

    As per my understanding, for instance if you are decoding 1080P stream, width and Height is set to
    Width : 1920
    Height : 1088 (Rounding to multiple of 16).

    For Encoder can you please check by assigning the width and height parameters as
    Width : 1920
    Height : 1080

    Thanks and Regards,
    Palachandra M V

  • Hi Palachandra,

    In case of 1920x1080 pitch is equal to width because width (1920) is multiple of 16.
    Height 1080 or 1088 doesn't influence on pitch.

    Regards,
    Andrey Lisnevych
  • Hi Andrey,

    As per my understanding, encoder pitch should be equal to encoder width. If width is not a multiple of 16 crop information is enable in the encoded stream. Decoder will use the crop information in the stream and will reconstruct the YUV frame with pitch equal to width.

    Thanks and Regards,
    Palachandra M V
  • Hi Palachandra,

    I do not see "crop" keyword in H.264 encoder documentation. How can I configure this?

    For example H.264 decoder outputs YUV buffers with parameters width 700, height 600, pitch 704.

    How can I use such buffers with encoder to output H.264 elementary stream with 700x600 dimensions? It can be cropped but players should see and play it as 700x600.

    Regards,
    Andrey Lisnevich
  • Hi Andrey,

    If width is not a multiple of 16, crop information will be inserted in the encoded sequence and it is not a config parameter. As in the above example the decoder output pitch should be 700 instead of 704. It looks like issue is at decoder side.

    Thanks and Regards,

    Palachandra M V

  • Hi,

    I see problem on decoder's side also:

    It returns IVIDEO1_BufDesc with frameWitdth != framePitch. frameWitdth is not multiple of 16 but framePitch is rounded up to be multiple of 16. IVIDEO1_BufDesc.bufDesc contain wrong sizes of buffers. Sizes for Y, U and V are calculated based on frameWitdth (i.e. frameWitdth * frameHeight for Y component). But I checked real data and it is allocated according to framePitch so it should be framePitch * frameHeight for Y component. U and V buffers sizes are also wrong and based on frameWidth, not framePitch.

    >>> decoder output pitch should be 700 instead of 704. It looks like issue is at decoder side.

    I don't think this is an issue with decoder because this case is described in documentation in chapter 3.2 "FrameBuffer Management by Application"

    But I think it is issue with encoder because it can't use those buffers produced by decoder that is not good.


    Regards,

    Andrey Lisnevich

  • Hi Andrey,

    >>

    IVIDEO1_BufDesc.bufDesc contain wrong sizes of buffers. Sizes for Y, U and V are calculated based on frameWitdth (i.e. frameWitdth * frameHeight for Y component). But I checked real data and it is allocated according to framePitch so it should be framePitch * frameHeight for Y component. U and V buffers sizes are also wrong and based on frameWidth, not framePitch.

    >>

    I don't think IVIDEO1_BufDesc.bufDesc contain wrong sizes of buffers but I think the size is updated based on frameWitdth because that is the actual valid decoding frame size (i.e. frameWitdth * frameHeight for Y component) that should be displayed. Though the bufSize information is updated in IVIDEO1_BufDesc.bufDesc, it was not used when the pitch>width. Please refer to below code from testappdecoder.c file

    Also, when the buffer are allocated in the DPB they were allocated for  framePitch * frameHeight only.

    Please refer to below code in the testappdecoder.c  file to understand how the two cases(1.width == pitch, 2.width!=pitch) were handled

       if(width == pitch)
        {
            for(i = 0; i < displayBufs->numBufs; i++)
            {
                s = (XDAS_UInt8 *)displayBufs->bufDesc[i].buf;
                fwrite (s, sizeof (Byte), displayBufs->bufDesc[i].bufSize, fOutFile);
            }
        }
        else
        {
            for(i = 0; i < displayBufs->numBufs; i++)
            {
                for(ht = 0 ; ht < height; ht++)
                {
                    s = (XDAS_UInt8 *)displayBufs->bufDesc[i].buf + ht * pitch;
                    fwrite (s, sizeof (Byte), width, fOutFile);
                }
                if(!i)
                {
                    height = height >> 1;
                    width = width >> 1;
                    pitch = pitch >> 1;
                }
            }

    Please let me know for any questions

    Thanks,

    Praveen

     

  • Hi Praveen, Palachandra,

    > I don't think IVIDEO1_BufDesc.bufDesc contain wrong sizes of buffers but I think the size is updated based on frameWitdth because that is the actual valid decoding frame size

    Problem 1) Is that we are talking not about useful data size (i.e. frame size) but about buffer size where the useful data is stored. And using size of useful data in buffer as buffer size is wrong approach that leads to collisions:

    IVIDEO1_BufDesc.XDM1_SingleBufDesc.bufSize - Size of buf in 8-bit bytes.

    Problem 2) Actually I debugged and know how the buffers are stored and I can fix on the fly buffer size issue easily. Problem is that those buffers can't be used as input to H.264 encoder. I have to convert them before that to make width equal to pitch that results in unnecessary CPU cycles, DMA and DDR3 resources usage.

    Regards,
    Andrey Lisnevich
  • Hi Andrey,

    I assume there are no changes required for decoder for now. Is that correct ?

    Thanks,
    Praveen
  • Hi Praveen,

    I want decoder's output to be compatible with encoder's. For me it looks like problem is in encoder.

    Regards,

    Andrey Lisnevich

  • Hi Andrey,

    Currently H264 encoder supports captureWidth equal to 0 (that is image Pitch is equal to capture width). If capture width is greater than image pitch, encoding can be supported through modifications in host application.

    Thanks and Regards,
    Palachandra M V

  • Hi Palachandra,

    It will be great if you crate compatibility between encoders and decoders without need of converting YUV buffers.

    Regards,
    Andrey Lisnevich
  • Hi Andrey,

    Sorry for the inconvenience caused, Currently this feature is not supported in encoder. Therefore encoding can be supported through modifications in host application.

    Regards,
    Mashkur