Improper frames in PAL

hello @JerryChang,
the output frames looks OK and with the correct colors.
I guess by “half frames” you mean the top-bottom interlaced-type, which when set is causing the output image to look half field above the other field. When the interlaced-type is set to interlaced then the frame looks OK - two interlaced fields.

Regards.

hello igal.kroyter,

let’s back to your original settings to check why you got half fps.
please add debug messages into below functions.
it’s nvhost_syncpt_wait_timeout_ext to use syncpt to communicate with sensor hardware. ​
for example,

static bool vi_notify_wait(struct tegra_channel *chan,
               ​struct tegra_channel_buffer *buf,
               ​struct timespec *ts)
...
       ​for (i = 0; i < chan->valid_ports; i++) {
           ​err = nvhost_syncpt_wait_timeout_ext(chan->vi->ndev,
                               ​chan->syncpt[i][SOF_SYNCPT_IDX], thresh[i],
                               ​chan->timeout, NULL, NULL);

please add some debug logs to examine the response time for each capture frames,
this function call should close to your sensor programming time, for example, if you had 25-fps, you should expect this function call return within 40ms.
thanks

hello @JerryChang,

I have added the dev_err print outs right after the vi4_check_status command and subtracted the the time that the log depicts:

  /* wait for vi notifier events */
	if (!vi_notify_wait(chan, buf, &ts)) {
		tegra_channel_error_recovery(chan);

		state = VB2_BUF_STATE_REQUEUEING;

		spin_lock_irqsave(&chan->capture_state_lock, flags);
		chan->capture_state = CAPTURE_TIMEOUT;
		spin_unlock_irqrestore(&chan->capture_state_lock,
								flags);
	}

	vi4_check_status(chan);

When the DT and driver were set to 576 lines I got the following:

  • field 1: 80 msec from previous (field 2)
  • field 2: 40 mesc from previous (field 1)

When the DT and driver were set to 288lines I got the following:

  • field 1: 23.3 msec from previous (field 2)
  • field 2: 3.36 mesc from previous (field 1)

Regards.

hello igal.kroyter,

this doesn’t look correct, please dig into your FPGA device to check the configurations.

hello @JerryChang,

Thanks for the distinction.

I just have to make sure that the definition of number of lines expected on the DT and driver have to be the number of line in a field (half the lines per frame), when dealing with interlaced video?
but on the user-space side the number of lines supposed to be the number of line in a frame?

Regards.

yes, please have a try, looking forward to your test results.

hi, @JerryChang,

sorry that I was not clearm but those were questions for you :) :

  1. Is the definition of number of lines expected on the DT and driver have to be the number of line in a field (half the lines per frame ), when dealing with interlaced video?
  2. but on the user-space side the number of lines supposed to be the number of line in a frame ?

hello igal.kroyter,

if you’re not interested in deinterlacing, two separate fields can be captured in a regular way by using the half size in device tree. it’s active_h in device tree, sensor mode settings. supporting interlaced captures essentially signifies that both fields TOP and BOTTOM will be captured in the same frame buffer;
for example,
in device tree, the capture height should be active_h=540 for 1920x1080i, and user-space command should still sending 1920x1080 capture request with interlaced flag.