DM36x Interlace Encoding FAQs
From Texas Instruments Embedded Processors Wiki
Does the DM36x H264 Encoder support interlace encoding?
Yes.
What all different interlace content encoding is supported?
Following different types of interlace encoding is supported.
- ARF: Adaptive Reference field, reference (either top or bottom field) is chosen by codec adaptively.
- SPF: Same Parity Field e.g. top/bottom field is referred when top/bottom field is encoded respectively.
- MRCF: Most Recent Coded Field e.g. if the current process call is to encode top/bottom field then reference for current call would be bottom/top field.
How to enable interlace encoding and interlace encoding type in application?
Following interface parameter needs to be set appropriately to enable interlace encoding
InterlacedVideo = 0 # 0 => Progressive, 1 => Interlaced interlaceRefMode = 0 # 0 => ARF (default mode),1 = SPF,2 = MRCF
What all feature set of encoder is disabled when interlace encoding is enabled?
Following are the limitations of the encoder:
- No Baseline Profile: Fatal error (IH264VENC_ERR_INTERLACE_IN_BP) is returned during algInit() instance creation stage if application tries to encode interlaced content in Baseline Profile mode.
- Airrate: This feature is not supported for interlaced content
- EncoderLevel: If interlace encoding is enabled for levels less than 2,1 or level more than level 4.1 encoder will return fatal error during instance creation.
- Rate Control Algorithms: CBR and Custom CBR1 Rate Control algorithms are not supported for interlaced encoding and will be automatically disabled by encoder.
- Buffering period SEI: Buffering period SEI insertion is not supported for interlaced content
- Picture Timing SEI: Picture Timing SEI insertion is not supported for interlaced content
Do we need to have two separate process call for 2 fields (top and bottom) of a frame?
Yes, in case of interlaced content, process call has to be invoked for each field separately.
Does the encoder expect the i/p to be interleaved or field separated ?
No, we support both through capture width. For interlaced sequence, encoder expects the start pointer of top or bottom field be given to it during the process call of the top or bottom fields, respectively. The pitch to move to the next line of the field is conveyed using captureWidth of DynamicParams. Refer below example for details.
/*This example tells how to set address of input buffer for 720x480 resolution.*/ /*Let us say complete frame is stored from the address: 0x81000000.*/ frameWidth = 720; /*0x2D0*/ frameHeight = 480; /*0x1E0*/ /*If the input frame is stored in the frame format.*/ captureWidth = frameWidth << 1; captureWidth = 1440 /*0x5A0*/ /*For even field process call.*/ inobj.bufDesc[0].buf = 0x81000000; inobj.bufDesc[1].buf = 0x81000000 + (frameWidth * frameheight * 1.5); inobj.bufDesc[0].buf = 0x81000000; inobj.bufDesc[1].buf = 0x81054600; /*For odd field process call.*/ inobj.bufDesc[0].buf = 0x81000000 + frameWidth; inobj.bufDesc[1].buf = 0x81000000 + (frameWidth * frameheight * 1.5) + frameWidth; inobj.bufDesc[0].buf += 0x810002D0; inobj.bufDesc[1].buf += 0x810548A0; /*If the input frame is stored in the field separated format.*/ captureWidth = frameWidth; captureWidth = 720; /*0x2D0*/ /*For even field process call.*/ inobj.bufDesc[0].buf = 0x81000000; inobj.bufDesc[1].buf = 0x81000000 + (frameWidth * (frameheight >> 1)); inobj.bufDesc[0].buf = 0x81000000; inobj.bufDesc[1].buf = 0x8102A300; /*For odd field process call.*/ inobj.bufDesc[0].buf = 0x81000000 + (frameWidth * (frameheight >> 1) * 1.5); inobj.bufDesc[1].buf = 0x81000000 + (frameWidth * (frameheight >> 1) * 1.5) + (frameWidth * (frameHeight >> 1)); inobj.bufDesc[0].buf = 0x8103F480; inobj.bufDesc[1].buf = 0x8113FC80;
What all encoder parameters are affected and needs to be taken care in interlace encoding?
Following parameters needs to be taken care appropriately during interlace encoding:
| Parameter | Type | Input/Output | Description |
| inputContentType | XDAS_Int32 | Input | Input content type. IVIDEO_PROGRESSIVE = Progressive video content; |
| interlaceRefMode | XDAS_Int32 | Input | Flag to control the reference picture selection(for inter prediction) in case of interlaced encoding 0: Automatic (Adaptive Reference field selection). |
| frameHeight | XDAS_Int32 | Input | Height of the video frame. Note: Progressive: It will be same as inputHeight for height multiple of 16.For inputHeight non-multiple of 16, application will set this field to next multiple of 16. Interlaced: It will be same as inputHeight for height multiple of 32.For inputHeight non-multiple of 32, application will set this field to next multiple of 32. |
| inputHeight | XDAS_Int32 | Input | For Interlaced: When the input height is a non-multiple of 32, the encoder expects the application to pad the input frame to the nearest multiple of 32 at the bottom of the frame. In this case, the application should set input height to actual height but should provide the padded input YUV data buffer to encoder. The encoder then sets the difference of the actual height and padded height as crop information in the bit-stream. |
| captureWidth | XDAS_Int32 | Input | Capture width parameter enables the application to provide input buffers with different line width (pitch) alignment than input width. For progressive content, if the parameter is set to:
|
| topFieldFirstFlag | XDAS_Int32 | IVIDENC1_InArgs | Flag to indicate the field order in interlaced content. Valid values are XDAS_TRUE and XDAS_FALSE. This field is only applicable to the input image buffer. This field is only applicable for interlaced content and not progressive. Currently, supported value is XDAS_TRUE. |
How does buffer requirement changes when interlace encoding is enabled?
In following cases memory footprint changes with interlace encoding:
- Size of memtab required for reference frame storage changes as additional space would be needed by codec when top and bottom fields are coded separately.
- Size of input buffer could have one of the following two values:
- If frame is captured in frame mode and captureWidth is set to twice the frameWidth (codec has to read every alternate lines to read top/bottom filed), size of input buffer would be
captureWidth = frameWidth << 1; frameHeight = inputHeight >> 1; inputBuffSizeY = (frameHeight * captureWidth); inputBuffSizeUV = (frameHeight * captureWidth)>>1;
- If frame is captured in field mode and captureWidth is set to the frameWidth, size of input buffer would be
captureWidth = frameWidth; frameHeight = inputHeight >> 1; inputBuffSizeY = (frameHeight * captureWidth); inputBuffSizeUV = (frameHeight * captureWidth)>>1;
- Size of the output buffer reduces to half as the frame is processes in the field mode i.e. top and bottom field are encoded separately.
captureWidth = frameWidth ; frameHeight = captureHeight >> 1 outputBuffSize = ((frameHeight * captureWidth)*3)>>1;
There is no restriction on output buffer size except that it should be enough to store one frame of encoded data. The output buffer size returned by the XDM_GETBUFINFO command assumes that the worst case output buffer size is (frameHeight*frameWidth)/2.





