H.264 encoder input buffer pitch

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 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