From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Seongyong Park <euphoriccatface@gmail.com>
Cc: linux-media <linux-media@vger.kernel.org>,
Matt Ranostay <matt.ranostay@konsulko.com>
Subject: Re: [PATCH 1/2] media: video-i2c: frame delay based on last frame's end time
Date: Sun, 6 Jun 2021 13:00:43 +0200 [thread overview]
Message-ID: <20210606130043.382d3450@coco.lan> (raw)
In-Reply-To: <CAJp=mWRihf_AiLXojoeeY6JTqA=-mD11+aWZToRcw2ozWoB5zw@mail.gmail.com>
Em Sun, 6 Jun 2021 16:20:53 +0900
Seongyong Park <euphoriccatface@gmail.com> escreveu:
> 2021년 6월 5일 (토) 오후 11:53, Mauro Carvalho Chehab <mchehab@kernel.org>님이 작성:
> > you would need to use:
> >
> > usleep_range(min_delay_us, max_delay_us);
> >
> > instead of:
> >
> > schedule_timeout_interruptible(schedule_delay);
> >
> > in order to tell the realtime clock about a dead line for
> > sleeping.
> >
> > Thanks,
> > Mauro
>
> Okay, I have tried `usleep_range()` instead, and it indeed shows
> improvement in the frame rate.
> Now it's basically the same as before my patch, except for
> `jiffies_to_usecs()` and then `usleep_range()`.
>
> ...
> int schedule_delay;
> + uint64_t schedule_delay_us;
>
> try_to_freeze();
> ...
> if (time_after(jiffies, start_jiffies + delay))
> schedule_delay = delay;
>
> - schedule_timeout_interruptible(schedule_delay);
> + schedule_delay_us = jiffies_to_usecs(schedule_delay);
> + usleep_range(schedule_delay_us * 3/4, schedule_delay_us);
> } while (!kthread_should_stop());
>
> return 0;
> ...
>
> I decided to keep the `if (...) schedule_delay = delay;` part.
Yeah, you would need something like that.
> The concern was that my RPi Zero was having quite a bit of constant
> drift, like showing 3FPS when set to 4FPS, 6FPS when 8FPS, 10FPS when
> 16FPS, and so on.
> Now that I've confirmed the timing's good enough (usually ~0.5 FPS
> faster than the frame rate given), there's no need for me to bother
> anymore.
In other to avoid the drift, the logic needs to calculate the delay based
on something like this (pseudo-C) code:
start_jiffies = jiffies;
frame_count = 0;
i = 0;
do {
i++;
delay = jiffies - (start_jiffies * i * <interval>);
...
}
The actual logic should probably avoid multiplying stuff there, as this
could go sideways easily due to overflows.
Perhaps something like this would work better, keeping a more precise
average fps rate:
next_jiffies = jiffies + delay;
do {
...
schedule_delay_us = jiffies_to_usecs(next_jiffies - jiffies);
usleep_range(schedule_delay_us * 3/4, schedule_delay_us); ...
next_jiffies += delay;
}
>
> I'll send another patchset if it doesn't look too bad.
>
> Thank you very much.
> Seongyong Park
Thanks,
Mauro
next prev parent reply other threads:[~2021-06-06 11:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-05 11:54 [PATCH V2 0/2] media: video-i2c: additional support for Melexis MLX90640 Seongyong Park
2021-05-16 11:09 ` [PATCH 1/2] media: video-i2c: frame delay based on last frame's end time Seongyong Park
2021-05-16 11:09 ` [PATCH 2/2] media: video-i2c: append register data on MLX90640's frame Seongyong Park
2021-05-16 20:48 ` Matt Ranostay
2021-05-17 1:39 ` Seongyong Park
2021-05-17 23:40 ` Matt Ranostay
2021-05-16 20:13 ` [PATCH 1/2] media: video-i2c: frame delay based on last frame's end time Matt Ranostay
2021-05-19 3:45 ` [PATCH V2 2/2] media: video-i2c: append register data on MLX90640's frame Seongyong Park
2021-06-05 11:54 ` Seongyong Park
2021-06-05 11:54 ` [PATCH 1/2] media: video-i2c: frame delay based on last frame's end time Seongyong Park
2021-06-05 14:00 ` Mauro Carvalho Chehab
2021-06-05 14:53 ` Mauro Carvalho Chehab
2021-06-06 7:20 ` Seongyong Park
2021-06-06 11:00 ` Mauro Carvalho Chehab [this message]
2021-06-06 15:06 ` Seongyong Park
2021-06-06 19:18 ` Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210606130043.382d3450@coco.lan \
--to=mchehab@kernel.org \
--cc=euphoriccatface@gmail.com \
--cc=linux-media@vger.kernel.org \
--cc=matt.ranostay@konsulko.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.