Hello,
For our project, we are using the inline scaler of the TI81xx capture module for down-scaling.
We use 2 inputs of a capture card and for the same software and commands, we see a different behaviour between these 2 inputs when down-scaling: for the 1st input the video is correctly downscaled but for the 2nd input the image is shifted by an offset. Please see the attached file - the "shift" can be observed on the left of the picture.
Like I mentioned, we only see this for one of the inputs.
The difference between the inputs is that initially the data is captured in different formats.
1) My question is, would there be a limitation on the inline scaler in terms of formats it is capable to scale down?
The following printouts may tell you more about the captured data:
1st input - we see captured and scaled data correctly:
VPSS_CAPTURE: capture_create(2.1): ccparams->videoCaptureMode(0)(0x0), ccparams->videoIfMode(1)(0x1), ccparams->inDataFormat(6)(0x6)
2nd input - we see captured and scaled data incorrectly:
VPSS_CAPTURE: capture_create(2.1): ccparams->videoCaptureMode(6)(0x6), ccparams->videoIfMode(2)(0x2), ccparams->inDataFormat(4103)(0x1007)
2) Also, we later (after capture and scaling down) encode the video and the input to the encoder is NV12 data.
My second question is: what is the correct order of actions done to the data we are encoding?:
a) capture -> scale down -> convert to NV12 -> encode
or
b) capture -> convert to NV12 -> scale down -> encode
or mayby the scaler does the conversion as well as the scaling?
I am asking because if a) is true then it could "ring a bell" to the possible limitaion of the scaler in terms of formats it can / cannot scale... if there is such limitation(?). Please note that we see correctly captured and encoded 1-to-1 (not scaled) videos from both inputs. Also, I already checked for shifts and buffer addresses when queuing and dequeueing capture buffers and have not found anything suspicious there...
Thank you for your help,
Przemek Gajos
