NTSC filed order is opposite to standard

Hi TI Team,

Can you please help us to resolve this issue ?

Regards,
Devang

Are you using V4L2 or VIP driver on M3?

Regards,
Brijesh

Hi Brijesh,

We are using VIP driver on M3 .

Regards,
Devang

Well, if you are using VIP driver on M3, driver just captures as the field comes, it does not care about the order. You will need to reorder them in the open max layer.

Rgds,
Brijesh

Hi Brijesh,

We are looking into the source code of capture drive: /hdvpss_01_00_01_37/packages/ti/psp/vps/drivers/capture/src

We have done some experiments related to field order, but didn't get any success.  Here in the source code a parameter is there,

pChObj->invertFid = FALSE

We make it TRUE , but we are not able to see any effect of it.

Can you please let us know What is this parameter for ?

If we change vipPortConfig->invertFidPol = TRUE; in file component-sources/hdvpss_01_00_01_37/packages/ti/psp/vps/drivers/capture/src/vpsdrv_captureVip.c then both filed are appearing together when displayed. We didn't get the reason for this yet.

Any idea, what is happening here ?

As you have suggested that we need to do changes in OMX layer, Can you please let us know in which files the changes are required ?

Regards,

Devang

invertFid field is not getting used anywhere, so will not mater at all. invertFidPol is used for the discrete sync capture, so also will not mater for your case.
it should be somewhere in your vfcc..

Rgds,
Brijesh

Hi Brijesh,

I am not much aware of EZSDK framework. I have gone through some documents I could find which are provided with SDK, But I could not find any usefull information related to our usecase.

Can you please guide us to reverse the field order and to make it as per NTSC standard ?

Regards,
Devang

Devang,

I will not be able help in ezsdk, i can help from driver side.

Rgds,

Brijesh

Hi Brijesh,

Thanks for the response. Will it be possible to reverse the filed order from the capture driver itself ?

Regards,

Devang

Yes, You could invert the field when you dequeue the frame. You could add an field invertFid, if this is set to true, invert the field id in the dequeue function for all the frames..

Rgds,
Brijesh

Hi Brijesh,

We have inverted the field inside function  Vps_captDequeue ()  by adding a line 

frameList->frames[frameList->numFrames]->fid = 1 - frameList->frames[frameList->numFrames]->fid;

What we observed by debug print is, every time the FID is 0 and we are inverting it to 1.

Here we are not getting the FID in alternative format (0 --1--0--1...).

Are you able to make the field order for NTSC as per standard ? Can you provide us the patch ?

 

Regards,

Devang

Hi Brijesh,

Any update on this issue ?

Regards,
Devang

Devang,

This is not correct way. You should run a for loop like below

for (i = 0; i < frameList->numFrames; i ++)
{
frameList->frames[i]->fid = !frameList->frames[i]->fid;
}

Hi Brijesh,

If we use debug print to see value of frameList->numFrames, it is showing value 0. That means it will never go inside the loop.

Some more update :

We have tried to swap pointers of YUV data for field 0 and field 1.(pChObj->dataFormat is showing value 7 => FVID2_DF_YUV420SP_UV)

/* Swaping of Y plane*/

/*temp is void pointer*/


temp = pChObj->pPrevFrame->addr[0][0];
(pChObj->pPrevFrame->addr[0][0]) = (pChObj->pPrevFrame->addr[1][0]);
(pChObj->pPrevFrame->addr[1][0]) = temp;

/* Swaping of UV plane*/
temp = pChObj->pPrevFrame->addr[0][1];
(pChObj->pPrevFrame->addr[0][1]) = (pChObj->pPrevFrame->addr[1][1]);
(pChObj->pPrevFrame->addr[1][1]) = temp;


But this also didn't help us. Are we doing anything wrong here ?

Regards,

Devang

Devang,

frameList->numFrames will not be 0 always, when you get a frame in the application or when you get the callback from the driver, this field will not be 0.

Rgds,
Brijesh

Brijesh.

frameList->numFrames  should not be zero but in debug print we are getting its value 0 even though the captured and encoded video is fine.

Questions:

1. The addresses we swapped as mentioned in previous reply should work, right   ?

2. Is there any user guide, which we can go though and can understand  the flow ? We have HDVPSS user guide, but it is not helping us to understand the flow. It just describe the structures etc.

3.  What are the other things that we can do to achieve reverse field order ?

4. Are you able to make field order as per standard ?

Regards,

Devang

1, no
2, no
3, only change the fid in dequeue function, by the way, where are you changing the code? i see numFrames getting incremented in the code, so you should get correct numFrames in the application. This is the variable telling app how many frames are captured, otherwise there is no way to know it.
4, i wont be able to try it out.

Rgds,
Brijesh

I am changing the code in below file .

component-sources/hdvpss_01_00_01_37/packages/ti/psp/vps/drivers/capture/src/vpsdrv_captureApi.c  in function Vps_captDequeue()

Here is the part of code :

if ( dequeStatus == FVID2_SOK )
                    {
                        /*
                         * deque is successful, add to frame list
                         */
                        frameList->frames[frameList->numFrames] =
                            ( FVID2_Frame * ) pData;
          
#if 1 /* Added to reverse the field */
                        Vps_printf("frameList->numFrames = %d\n", frameList->numFrames);
                        for (i = 0; i <= frameList->numFrames; i++)
                        {
                                frameList->frames[i]->fid = !frameList->frames[i]->fid;
                        }
#endif
                        frameList->numFrames++;
                        if (pObj->oneCallBackPerFrm)
                        {
                            break;
                        }
                    }

Regards,

Devang

Devang,

There is a mistake in your code, numFrames is incremented after your changes, it should be something like below

if ( dequeStatus == FVID2_SOK )
                    {
                        /*
                         * deque is successful, add to frame list
                         */
                        frameList->frames[frameList->numFrames] =
                            ( FVID2_Frame * ) pData;
          
                        frameList->numFrames++;

#if 1 /* Added to reverse the field */
                        Vps_printf("frameList->numFrames = %d\n", frameList->numFrames);
                        for (i = 0; i <= frameList->numFrames; i++)
                        {
                                frameList->frames[i]->fid = !frameList->frames[i]->fid;
                        }
#endif
                        if (pObj->oneCallBackPerFrm)
                        {
                            break;
                        }
                    }

Rgds,

Brijesh

Hi Brijesh,

I have taken the frameList->numFrames++ above the reversal logic as per your suggestion. With this changes frameList->numFrames = 1, so loop is executing one time only and we are getting frameList->frames[0]->fid = 0   every time it get executed and we are not  getting any improvement in field order.

Regards,

Devang

Can you try below?

frameList->frames[i]->fid = 1 - frameList->frames[i]->fid;


Rgds,
Brijesh

No effect.

In file "component-sources/hdvpss_01_00_01_37/packages/ti/psp/vps/drivers/capture/src/vpsdrv_captureList.c", function Vps_CaptTskPutCaptFrm(), a logic is there which first capture both odd/bottom and even/top fields (even first and then wait for odd to be captured) then and then it put the frame in Queue.

if ((NULL != pChObj->pPrevFrame) &&

                           (TRUE == pChObj->evenFieldCaptured) &&

                            (pChObj->pPrevFrame->channelNum !=

                               VPS_CAPT_DROP_FRAME_CH_ID))

                       {

 frameCaptured = TRUE;

  VpsUtils_quePut(
                                &pObj->fullQue[Vps_captGetStreamId(parseDescInfo->lChannel)],
                                pChObj->pPrevFrame,
                                BIOS_WAIT_FOREVER);
      pChObj->pPrevFrame = NULL;

     }


Based on this logic many parameters like  expected fid, programmed fid, fieldTobeProgrammed are getting updated in many functions for the next field, which appearing to be depended.

 How can we invert this logic to capture odd/bottom field first and then top/even field ? or if there is any other method to do this then it will also fine.

Regards,

Devang

Devang,

From the driver side, there is no other change required, We are reverting field id to the output frame, driver does not depend on this output frame. If earlier you were getting both fields, may be inverted, you will still get both the fields in the right order now, 

Now still if this is not working, there could be something in the application. Could you start looking into your application?

Rgds,

Brijesh

Hi Brijesh.

Thank you for the response.

1. In Dequeue function we are reversing the frame Id, not the field. Right ?

2. Why swapping the addresses of fields before putting the frame in out queue (swapping of Y and UV plane as per in previous reply) doesn't  work?

3. Isn't it possible to invert the field Id of incoming fields itself as soon as they have been received at VIP ?

We have made an application to capture and dump the video file. In that file also we are getting the wrong field order. So it is appearing that something wrong is happening at capture side only.

4. The capture driver is making frames in Top field first format. So we need to make it bottom field first format. Please confirm the same.

Regards,

Devang

Answers below

1, no, we are reverting field id, fid is field id

2, capture always work in fields, it outputs one field at a time. unless you have enabled field merge mode, i asked you earlier, you said it is not enabled.

3, No, VIP just captures what it gets.

4, Capture driver does not do this, it captures what it gets it from outside..

Rgds,

Brijesh

Please find answers as per numbers.

1. Ok

2. field merge mode is enable in our application. I am not able to find any discussion on field merge mode in our communication thread.

3.  Ok. SO once we get video data from VIP same as it received , can we change/modify it or its metadata ?

4. I still have doubt on this point.

Regards,

Devang

Once you get buffer in the application, you are free to modify them, driver does not care..

How are you checking field inversion in simple capture + dump application?

Hi Brijesh,

For simple capture + dump application, we are checking field inversion using YUV tools.

We have disable the field merge mode from the application. With this change,  we are getting the alternate value (1-0-1-0...) of fid  in dequeue function of capture driver. We have inverted that fid, but it has no effect on final encoded video. Still there is no effect in field order of the video.

Inverting the fid is only parameter we need to change or any other parameter or meta data also require to be changed ?

Regards,

Devang

No other change required, there is no other meta data.

May be, the change is required in your decoder, it might not accepting frame starting with the odd field, could you check in your decoder?

Rgds,
Brijesh

Hello,

You could check the omx_venc_utils.h file in the overlay package for datacontent type.
This type could be set in the app as tStaticParam.videoStaticParams.h264EncStaticParams.videnc2Params.inputContentType = ...



BR
Margarita

Hello,

@ Brijesh,

We have already checked at the decoder side and I am sure there is no change require in decoder.

@ Margarita,

The  videoStaticParams.h264EncStaticParams.videnc2Params.inputContentType is set to IVIDEO_INTERLACED. If i try to change it to either IVIDEO_INTERLACED_TOPFIELD or IVIDEO_INTERLACED_BOTTOMFIELD, I am getting an run time error related to encoder.

We are getting wrong field order for NTSC in our capture_encode application as well as in simple capture_dump (irrespective of value of field merge flag). So I think this problem is related to capture side only and it has nothing to do with encoder.

This issue is now getting critical. So I request you to reproduce this is issue at your end, so that you can get exact idea for the solution.

Regards,

Devang

Devang,

If you invert fid bit in the dequeue, you will start getting fields with the inverted field id in the application, now i dont understand how you are saying that it does not work in simple capture dump.. How do you check it out here? It really depends on how do you interpret it. If you treat invert fid as again inverted, you will see the same problem..

Rgds,
Brijesh

Hi Brijesh,

See the video attached at below link :

If you will play this sample.h264 (sample.h)video of a decrementing counter in elecard streamEye application. You will be able to see the both fields of the video simultaneously and it will be easy for you to identify which field is ahead compare to other with reference to the time.I have attached a picture of a frame from the same video.

Initially both fields were showing value 02:39:860 as shown in image below. (Upper side Top field)

When I pressed the button to see next field, I got below image in which value changed from 02:39:860 to 02:39:760 in bottom field first, while top field is still showing value 02:39:860. [Expected result : value should be change in top field first]

When i again press the button to see next field, I got below image in which top field's value is changed from 02:39:860 to value 02:39:760.

 

What we want is  when both fields show a value 02:39:860 and if we press button to see next field , we should get value changed in top fields first, means in top filed the value should be changed first to 02:39:760 and after that again when we press button to see next field, at that time value in bottom field should be changed from 02:39:860 to 02:39:760.

This is what we want to achieve by inverting field ID. If we simply capture and dump the video, we are getting the same field order as I have mentioned in above case of decrementing counter.

Let me know if you have any query or if we are going in wrong direction or doing something wrong.

Regards,

Devang

Hello TI team,

Any update or suggestion on above issue ?

Regards,
Devang

Hi Devang,

Did you check your source? It might be coming from the source itself. I had seen this earlier that the source was not giving the field in the correct order.

I am doubting this because you are seeing this issue in both the cases, original field id and reverted field id..

Rgds,

Brijesh

Hi Brijesh,

It may possible that the source itself is providing wrong field order for NTSC. We will check and confirm.

But in our use case , we may not be able to control/access the source, so considering that if we have to change the fields from the firmware only (even if the source is providing wrong field order) how can we achieve it ? Reversing field id in dequeue function we already had tried without success.

Regards,
Devang

Devang,

If you dont know if the field is reversed from the source itself, you should not revert it in the firmware/driver blindly. Also there is no way for the firmware to know if the source is sending field id in the wrong way. This has to be handled correctly in the application.

Regards,
Brijesh

Brijesh,

I have discussed with the team and i got to know that source is providing the correct field order. However when the video data get processed (cap_enc_dump) through EZSDK,  the problem get started.

Sometimes it looks like the frames we are seeing is made by fields of two different frames. I mean if we have,

F1B-F1T,  F2B-F2T,  F3B-F3T,  F4B-F4T,  F5B-F5T,  F6B-F6T,  F7B-F7T ....  ; F = Field,  B = Bottom, T = Top then ,

when we see the video frame it looks like Current Frame = Top Field of Current frame + Bottom field of next frame

Frame1 = F1T +  F2B,  

Frame2 = F2T +  F3B

Frame3 = F3T +  F4B

Frame4 = F4T +  F5B and so on....

Regards,

Devang

Devang,

How did you concluded source is providing correct field order?

Rgds,
Brijesh

Hi Brijesh,

1. NTSC camera: The NTSC camera with our custom board is giving reversal field order while the same NTSC camera with other proprietary products are giving field order as per standard.

2. Black magic media express

    We have used black magic media as source and we have played a standard NTSC video in it. When we capture and encode  the same video using our custom board the, the output video is not same as input video in terms of field order when played in ELECARD.

Let me know if you have any doubt.

The problem is appearing in the firmware not in the source. It would be appreciated If you could spare some time to reproduce this at your end because that would give you the clear idea and we can approach towards solution.

Regards,

Devang

Devang,

All i can say is, there is no metadata that driver uses to get the field id, it gets field id your sources and if you invert this field id in the dequeue, you will start getting fields with the correct field id. If you are still not getting it working. it must be something to do with your source.

I am just trying to help you, will not be able to try it out.

Regards,
Brijesh

Hi Brijesh,

1. Any input from your side on below mentioned  observation (third last reply)?

2. Can we change the way two fields get merged ?

3. We have disabled the field merge flag and tried to revert the field id from OMX layer after FVID2_deque. However it has no effect.

Regards,

Devang

Hello TI team,

We are waiting for your response.

Regards,
Devang