linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Stevenson <dave.stevenson@raspberrypi.org>
To: Nicolas Dufresne <nicolas@ndufresne.ca>
Cc: Stefan Wahren <wahrenst@gmx.net>, Eric Anholt <eric@anholt.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	"moderated list:BROADCOM BCM2835 ARM ARCHITECTURE" 
	<linux-rpi-kernel@lists.infradead.org>,
	linux-arm-kernel@lists.infradead.org, devel@driverdev.osuosl.org,
	LMML <linux-media@vger.kernel.org>
Subject: Re: [PATCH 01/31] staging: bcm2835-camera: Ensure H264 header bytes get a sensible timestamp
Date: Fri, 28 Jun 2019 11:10:13 +0100	[thread overview]
Message-ID: <CAAoAYcOvnF55U0kPMFE4cOd=nUqjoidirbGP6AWN=5Rqp0RhbQ@mail.gmail.com> (raw)
In-Reply-To: <5e20b1d04b3c2f64173631ec2f0261a8a9597f0c.camel@ndufresne.ca>

Hi Nicolas

On Thu, 27 Jun 2019 at 20:55, Nicolas Dufresne <nicolas@ndufresne.ca> wrote:
>
> Hi Dave,
>
> Le jeudi 27 juin 2019 à 20:55 +0200, Stefan Wahren a écrit :
> > From: Dave Stevenson <dave.stevenson@raspberrypi.org>
> >
> > H264 header come from VC with 0 timestamps, which means they get a
> > strange timestamp when processed with VC/kernel start times,
> > particularly if used with the inline header option.
> > Remember the last frame timestamp and use that if set, or otherwise
> > use the kernel start time.
>
> Normally H264 headers are considered to be part of the following frame.
> Giving it the timestamp of the previous frame will likely confuse some
> userspace and cause an off-by-one in timestamp. I understand this is a
> workaround, but am wondering if this can be improved.

Sorry, slight ambiguity in how I'm reading your comment.

Are you saying that the header bytes want to be in the same buffer as
the following frame?
I thought this had also been discussed in the V4L2 stateful codec API
threads along with how many encoded frames were allowed in a single
V4L2 buffer. I certainly hadn't seen a statement about the header
bytes being combined with the next frame.
If the behaviour required by V4L2 is that header bytes and following
frame are in the same buffer, then that is relatively easy to achieve
in the firmware. This workaround can remain for older firmware as it
will never trigger if the firmware has combined the frames.


Or are you saying that the header bytes remain in their own buffer,
but the timestamp wants to be the same as the next frame? That is
harder to achieve in the firmware, but could probably be done in the
kernel driver by holding on to the header bytes frame until the next
buffer had been received, at which point the timestamp can be copied
across. Possible, but just needs slightly careful handling to ensure
we don't lose buffers accidentally.

  Dave

> >
> > Link: https://github.com/raspberrypi/linux/issues/1836
> > Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
> > ---
> >  .../staging/vc04_services/bcm2835-camera/bcm2835-camera.c  | 14 ++++++++++++--
> >  .../staging/vc04_services/bcm2835-camera/bcm2835-camera.h  |  2 ++
> >  2 files changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
> > index dce6e6d..0c04815 100644
> > --- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
> > +++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
> > @@ -359,7 +359,9 @@ static void buffer_cb(struct vchiq_mmal_instance *instance,
> >               }
> >       } else {
> >               if (dev->capture.frame_count) {
> > -                     if (dev->capture.vc_start_timestamp != -1 && pts) {
> > +                     if (dev->capture.vc_start_timestamp != -1) {
> > +                             buf->vb.vb2_buf.timestamp = ktime_get_ns();
> > +                     } else if (pts) {
> >                               ktime_t timestamp;
> >                               s64 runtime_us = pts -
> >                                   dev->capture.vc_start_timestamp;
> > @@ -372,8 +374,15 @@ static void buffer_cb(struct vchiq_mmal_instance *instance,
> >                                        ktime_to_ns(timestamp));
> >                               buf->vb.vb2_buf.timestamp = ktime_to_ns(timestamp);
> >                       } else {
> > -                             buf->vb.vb2_buf.timestamp = ktime_get_ns();
> > +                             if (dev->capture.last_timestamp) {
> > +                                     buf->vb.vb2_buf.timestamp =
> > +                                             dev->capture.last_timestamp;
> > +                             } else {
> > +                                     buf->vb.vb2_buf.timestamp =
> > +                                             ktime_to_ns(dev->capture.kernel_start_ts);
> > +                             }
> >                       }
> > +                     dev->capture.last_timestamp = buf->vb.vb2_buf.timestamp;
> >
> >                       vb2_set_plane_payload(&buf->vb.vb2_buf, 0, length);
> >                       vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_DONE);
> > @@ -541,6 +550,7 @@ static int start_streaming(struct vb2_queue *vq, unsigned int count)
> >                        dev->capture.vc_start_timestamp, parameter_size);
> >
> >       dev->capture.kernel_start_ts = ktime_get();
> > +     dev->capture.last_timestamp = 0;
> >
> >       /* enable the camera port */
> >       dev->capture.port->cb_ctx = dev;
> > diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.h b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.h
> > index 2b5679e..09273b0 100644
> > --- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.h
> > +++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.h
> > @@ -90,6 +90,8 @@ struct bm2835_mmal_dev {
> >               s64         vc_start_timestamp;
> >               /* Kernel start timestamp for streaming */
> >               ktime_t kernel_start_ts;
> > +             /* Timestamp of last frame */
> > +             u64             last_timestamp;
> >
> >               struct vchiq_mmal_port  *port; /* port being used for capture */
> >               /* camera port being used for capture */
> > --
> > 2.7.4
> >

  reply	other threads:[~2019-06-28 10:18 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-27 18:55 [PATCH 00/31] staging: bcm2835-camera: Improvements Stefan Wahren
2019-06-27 18:55 ` [PATCH 01/31] staging: bcm2835-camera: Ensure H264 header bytes get a sensible timestamp Stefan Wahren
2019-06-27 19:55   ` Nicolas Dufresne
2019-06-28 10:10     ` Dave Stevenson [this message]
2019-06-28 14:00       ` Nicolas Dufresne
2019-06-28 14:08         ` Hans Verkuil
2019-06-28 14:35           ` Nicolas Dufresne
2019-06-28  7:28   ` Dan Carpenter
2019-06-27 18:55 ` [PATCH 02/31] staging: bcm2835-camera: Check the error for REPEAT_SEQ_HEADER Stefan Wahren
2019-06-27 18:56 ` [PATCH 03/31] staging: bcm2835-camera: Replace spinlock protecting context_map with mutex Stefan Wahren
2019-06-27 18:56 ` [PATCH 04/31] staging: bcm2835-camera: Do not bulk receive from service thread Stefan Wahren
2019-06-27 18:56 ` [PATCH 05/31] staging: bcm2835-camera: Correctly denote key frames in encoded data Stefan Wahren
2019-06-27 18:56 ` [PATCH 06/31] staging: bcm2835-camera: Return early on errors Stefan Wahren
2019-06-28  7:38   ` Dan Carpenter
2019-06-27 18:56 ` [PATCH 07/31] staging: bcm2835-camera: Remove dead email addresses Stefan Wahren
2019-06-27 18:56 ` [PATCH 08/31] staging: bcm2835-camera: Fix comment style violations Stefan Wahren
2019-06-27 18:56 ` [PATCH 09/31] staging: bcm2835-camera: Fix spacing around operators Stefan Wahren
2019-06-27 18:56 ` [PATCH 10/31] staging: bcm2835-camera: Reduce length of enum names Stefan Wahren
2019-06-27 18:56 ` [PATCH 11/31] staging: bcm2835-camera: Fix multiple line dereference errors Stefan Wahren
2019-06-27 18:56 ` [PATCH 12/31] staging: bcm2835-camera: Fix brace style issues Stefan Wahren
2019-06-27 18:56 ` [PATCH 13/31] staging: bcm2835-camera: Fix missing lines between items Stefan Wahren
2019-06-27 18:56 ` [PATCH 14/31] staging: bcm2835-camera: Fix open parenthesis alignment Stefan Wahren
2019-06-27 18:56 ` [PATCH 15/31] staging: bcm2835-camera: Ensure all buffers are returned on disable Stefan Wahren
2019-06-27 18:56 ` [PATCH 16/31] staging: bcm2835-camera: Remove check of the number of buffers supplied Stefan Wahren
2019-06-27 18:56 ` [PATCH 17/31] staging: bcm2835-camera: Handle empty EOS buffers whilst streaming Stefan Wahren
2019-06-27 18:56 ` [PATCH 18/31] staging: bcm2835-camera: Set sequence number correctly Stefan Wahren
2019-06-27 18:56 ` [PATCH 19/31] staging: bcm2835-camera: Ensure timestamps never go backwards Stefan Wahren
2019-06-27 20:01   ` Nicolas Dufresne
2019-06-28  8:06 ` [PATCH 00/31] staging: bcm2835-camera: Improvements Hans Verkuil
2019-06-28 10:39   ` Dave Stevenson
2019-06-28 10:56     ` Hans Verkuil
2019-06-28 16:57   ` Stefan Wahren
2019-06-28 17:29     ` Dave Stevenson
2019-06-29 10:27       ` Stefan Wahren
2019-06-28 13:13 ` Hans Verkuil
2019-06-28 13: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='CAAoAYcOvnF55U0kPMFE4cOd=nUqjoidirbGP6AWN=5Rqp0RhbQ@mail.gmail.com' \
    --to=dave.stevenson@raspberrypi.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=eric@anholt.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=mchehab@kernel.org \
    --cc=nicolas@ndufresne.ca \
    --cc=wahrenst@gmx.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).