Change the field in NTSC (480i)

Hello,

If you have the overlay package check _OMX_VFCCSetOmxBufHdrInfo () function in omx_vfcc_drvif.c file.

BR
Margarita

Hi Margartia,

Thanks for the response. But can we configure the capture driver from application layer?

While looking into the code I found a variable used to define "inputContentType" in ilclients_utils.c.

tStaticParam.videoStaticParams.h264EncStaticParams.videnc2Params.inputContentType = IVIDEO_INTERLACED;

Can this be used to change the order of the field captured?

Also changing of the top/bottom field should be configured while capturing or encoding?

Please let me know if there are any queries regarding the same.

Thanks,

Krunal

Hi Krunal,

I am not sure of capture driver has any configuration to reverse the field.

But IVAHD encoder has one field "topFieldFirstFlag" which can be set FALSE to indicate top field is not first.

If you have set this to TRUE for interlaced, can you try setting it to FALSe and check if bottom field is encoded first?

Ram

Hi Ram,

Can you please help in setting "topFieldFirstFlag" from my application?

Thanks,
Krunal

HI Krunal,
In omx_h264enc.c and omx_mpeg4ve.c this flag is set to 1. Try setting this to 0.
Please also post this query on this topfieldFirstflag on Multimedia forum also.

Ram

Hi Ram,

I tried setting topfieldFirstflag = 0 in "omx_h264ve.c" file. But still I don't observe any changes.

Can you please help us further?
The issue I think is on the capture side. So can you please help me debug how to configure capture to reverse the field order ?

The issue we are facing is with NTSC(480i) only. According to the standard while capturing the order should be bottom-top but what we observe is, it is top-bottom.

Normal NTSC sequence should be like:
(Frame#23 bottom, Frame#23 top), (Frame#24 bottom, Frame#24 top), (Frame#25 bottom, Frame#25 top)…

But what we observed here is the capture get for each output frame N, the top from frame N and bottom from next frame N+1
(Frame#23 top, Frame#24 bottom), (Frame#24 top, Frame#25 bottom), Frame#25 top…

Question: Why we get top field first?

Please let me know if there are any queries.

Thanks,
Krunal

Hi Kunal,

 

Why do you require to invert the fields? For NTSC, it is always top field which comes first. Is there any specific reason to invert field id.

Also Capture driver captures from the external decoder, so whatever extern decoder provides, it captures and gives it to the user. So you need to invert this in external decoder driver, then driver will capture inverted fields.

 

Regards,

Brijesh

Hi Brijesh,

According to the NTSC standard the bottom field should be first. But what I observed with our application is opposite. So in order to correct it I want to change the field order and compare the results.

Question: So can you please guide me how can this be achieved?

Also as you said Capture driver captures from external decoder. So for deinterlaced video it must have been configured to capture top-field first or the bottom-field first.

Question: So can you please let me know what will be our current mode in capture driver?

In "omx_vfcc_drvif.c" there is a function _OMX_VFCCSetOmxBufHdrInfo() which has a variable sOutBufHeaderPtr->nFrameType which is been assigned different values "OMX_Video_Interlaced_Topfield, OMX_Video_Interlaced_Bottomfield or OMX_Video_Progressive".

Question: How do we decide the value to be assigned?

Please correct me if I am wrong with my understanding.

Thanks,

Krunal

Hi Krunal,
As i said, capture driver does not care, it just gives out the fields with the correct field id. You could process them in the order you want. May be at the higher level, OMX layer, you will need to process them correctly. I am not sure how this can be done from OMX.
Rgds,Brijesh

Hi Brijesh,

Thanks for the response.

Ram,
Can you please let me know how are these fields processed at OMX layer?

Regards,
Krunal

Hello,

Please find the attached video with the post which might help in pointing out the issue. I am using EleCard StreamEye to verify the different fields captured. When I use the View->Interlace->Solid Fields we can observe the different fields.

sample.h

Kindly change the extension from sample.h to sample.h264

Please let me know if there are any queries with the video.

Thanks,

Krunal

Hi Krunal,
The function OMX_VFCCSetOmxBufHdrInfo just does the translation from FVID2 type to OMX types.
Here you may add a hack to invert the field and then give a try

switch ( pFrame->fid ) {
case FVID2_FID_TOP:
//sOutBufHeaderPtr->nFrameType = OMX_Video_Interlaced_Topfield;
sOutBufHeaderPtr->nFrameType = OMX_Video_Interlaced_Bottomfield;
sOutBufHeaderPtr->nFlags = OMX_TI_BUFFERFLAG_VIDEO_FRAME_TYPE_INTERLACE;
break;

/**< Top field. */
case FVID2_FID_BOTTOM:
// sOutBufHeaderPtr->nFrameType = OMX_Video_Interlaced_Bottomfield;
sOutBufHeaderPtr->nFrameType = OMX_Video_Interlaced_Topfield;
sOutBufHeaderPtr->nFlags = OMX_TI_BUFFERFLAG_VIDEO_FRAME_TYPE_INTERLACE;
sOutBufHeaderPtr->nFlags |= OMX_TI_BUFFERFLAG_VIDEO_FRAME_TYPE_INTERLACE_BOTTOM;
break;

Hi Ram,

Tried this but didn't got any success.

While looking into the issue what I observed is bottom(even) field and top(odd) field are from two different frames. Probably it looks like it takes the top field of next frame and places it into the bottom of the present frame.

Any other ideas which you think might be the issue or can help in further debugging?

Thanks,
Krunal

Hi Krunal,
If I remember correctly, I had supproted you on similar issue. You were trying to configure capture and encoder in field-merged mode and it worked well. If you use field merge mode are you seeing the issue?

Hi Ram

Are you pointing to the below issue in the link:
e2e.ti.com/.../999043;pi317334scroll=false&pi317334=6

Yes Krunal,
It is the jumping issue when you are using DEI for field-merged mode.

What is your new applciation uses? Does it use DEI?
Are you capturing and encoding in field separated mode?

To invert the fields while encoding there is one solution I guess.
You need to set secondFieldOffsetHeight[x] values with negative values , if your buffer address points to bottom-field.

Yes Ram,
I am working with the same application. Also we are using the same setup as it was previously used.

But now we are facing the issue of wrong field order for NTSC videos and thats why need to change the field order.
I will try changing secondFieldOffsetHeight[x] values and will let you know the results.

Do you recommend any other changes along with the above or just secondFieldOffsetHeight[x] should be enough?

Thanks,
Krunal

Hi Krunal,
If it is same application, then you will be doing field-merge capture and encode. Encoder will not interpret secondFieldOffsetHeight[x].

Can you check the output of capture driver? You can dump YUV output from capture from FillBufferDone call. It may result in frame drops, but you can identify, if you are observing fields mixing up or not.

Hi Ram,

Yes we have captured the YUV output of the capture buffer and it is also having the same effect.

Thanks,
Krunal

Hi Krunal,
Since it is not possible for captrue driver to invert the field, you can use encoder to invert the fields.
For this, the fields should be available in field-separated format from capture driver.
and now

inBufs->planeDesc[0].buf = Address of Luma of bottom field
inBufs->planeDesc[1].buf = Address of chroma of bottom field

and set secondFieldOffsets to get the luma and chroma address. These will be negative values in this case as you have give bottom field
as base address.
inBufs->secondFieldOffsetWidth[0] = offset from inBufs->planeDesc[0].buf to get topfiled Luma. this will be 0.
inBufs->secondFieldOffsetHeight[0] = offset from inBufs->planeDesc[0].buf to get topfiled Luma . This will be -height;
inBufs->secondFieldOffsetWidth[1] = offset from inBufs->planeDesc[0].buf to get topfiled chroma. this will be 0.;
inBufs->secondFieldOffsetHeight[1] = offset from inBufs->planeDesc[0].buf to get topfiled chroma. this will be -height/2;

This feature has been tested with encoder.

thanks
Ram

Hi Ram,

Thanks for the response. I will try this and will let you know the results.

Thanks,
Krunal

Hello Krunal,

I would suggest that you change the field order to the desired value at the external decoder.

Fields have to be processed in the way they arrive, since they are temporally ordered that way. Any attempt to change the processing order, would result in errors.

Thanks,
Prashant.

Hi Prashant,

We have gone through the datasheet of external decoder, but we didn't find any registers where we can change the field order.
We are now looking into the capture driver in HDVPSS and trying to change the field order, but we didn't got any success.

There is a variable vipPortConfig->invertFieldPol = FALSE in file component-sources/hdvpss_01_00_01_37/packages/ti/psp/vps/drivers/capture/src/vpsdrv_captureVip.c.

What is the use of this variable? What are the expected results if we change it to TRUE?

Thanks,
Krunal

Hello TI,

We didn't get any solution yet. Any updates on above issue?

Thanks,
Krunal

Can you check my last reply on below link?

e2e.ti.com/.../440195

Rgds,
Brijesh