mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Hans Verkuil <hverkuil@xs4all.nl>,
	Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: kernel@collabora.com, linux-kernel@vger.kernel.org,
	Sebastian Fricke <sebastian.fricke@collabora.com>,
	linux-media@vger.kernel.org
Subject: Re: [PATCH v3 09/24] media: v4l2: Trace calculated p/b0/b1 initial reflist
Date: Fri, 22 Apr 2022 10:58:39 -0400	[thread overview]
Message-ID: <04819e457ee0135e5d0b337dccfaba69b2d46610.camel@collabora.com> (raw)
In-Reply-To: <d7451087-45f1-9691-2289-999eb16ca8a0@xs4all.nl>

Le vendredi 22 avril 2022 à 09:26 +0200, Hans Verkuil a écrit :
> On 05/04/2022 22:44, Nicolas Dufresne wrote:
> > Add debug print statements to print the content of P & B reference
> > lists, to verify that the ordering of the generated reference lists is
> > correct. This is especially important for the field decoding mode,
> > where sorting is more complex.
> > 
> > Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> > Tested-by: Sebastian Fricke <sebastian.fricke@collabora.com>
> > Reviewed-by: Sebastian Fricke <sebastian.fricke@collabora.com>
> > ---
> >  drivers/media/v4l2-core/v4l2-h264.c | 86 +++++++++++++++++++++++++++++
> >  1 file changed, 86 insertions(+)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-h264.c b/drivers/media/v4l2-core/v4l2-h264.c
> > index 38d8dbda0045..bcf9b7774560 100644
> > --- a/drivers/media/v4l2-core/v4l2-h264.c
> > +++ b/drivers/media/v4l2-core/v4l2-h264.c
> > @@ -241,6 +241,87 @@ static int v4l2_h264_b1_ref_list_cmp(const void *ptra, const void *ptrb,
> >  	return poca < pocb ? -1 : 1;
> >  }
> >  
> > +static char ref_type_to_char (u8 ref_type)
> 
> Spurious space before (.
> 
> Odd that checkpatch didn't catch that.
> 
> > +{
> > +	switch (ref_type) {
> > +	case V4L2_H264_FRAME_REF:
> > +		return 'f';
> > +	case V4L2_H264_TOP_FIELD_REF:
> > +		return 't';
> > +	case V4L2_H264_BOTTOM_FIELD_REF:
> > +		return 'b';
> > +	}
> > +
> > +	return '?';
> > +}
> > +
> > +static const char *format_ref_list_p(const struct v4l2_h264_reflist_builder *builder,
> > +				     struct v4l2_h264_reference *reflist,
> > +				     char *out_str, const int len)
> > +{
> > +	int n = 0, i;
> > +
> > +	n += snprintf(out_str + n, len - n, "|");
> > +
> > +	for (i = 0; i < builder->num_valid; i++) {
> > +		/* this is pic_num for frame and frame_num (wrapped) for field,
> > +		 * but for frame pic_num is equal to frame_num (wrapped).
> > +		 */
> > +		int frame_num = builder->refs[reflist[i].index].frame_num;
> > +		bool longterm = builder->refs[reflist[i].index].longterm;
> > +
> > +		n += scnprintf(out_str + n, len - n, "%i%c%c|",
> > +			       frame_num, longterm ? 'l' : 's',
> > +			       ref_type_to_char (reflist[i].fields));
> > +	}
> > +
> > +	return out_str;
> > +}
> > +
> > +static void print_ref_list_p(const struct v4l2_h264_reflist_builder *builder,
> > +			     struct v4l2_h264_reference *reflist)
> > +{
> > +	char buf[1024];
> > +
> > +	pr_debug("ref_pic_list_p (cur_poc %u%c) %s\n",
> > +		 builder->cur_pic_order_count,
> > +		 ref_type_to_char(builder->cur_pic_fields),
> > +		 format_ref_list_p(builder, reflist, buf, sizeof(buf)));
> > +}
> > +
> > +static const char *format_ref_list_b(const struct v4l2_h264_reflist_builder *builder,
> > +				     struct v4l2_h264_reference *reflist,
> > +				     char *out_str, const int len)
> > +{
> > +	int n = 0, i;
> > +
> > +	n += snprintf(out_str + n, len - n, "|");
> > +
> > +	for (i = 0; i < builder->num_valid; i++) {
> > +		int frame_num = builder->refs[reflist[i].index].frame_num;
> > +		u32 poc = v4l2_h264_get_poc(builder, reflist + i);
> > +		bool longterm = builder->refs[reflist[i].index].longterm;
> > +
> > +		n += scnprintf(out_str + n, len - n, "%i%c%c|",
> > +			       longterm ? frame_num : poc,
> > +			       longterm ? 'l' : 's',
> > +			       ref_type_to_char(reflist[i].fields));
> > +	}
> > +
> > +	return out_str;
> > +}
> > +
> > +static void print_ref_list_b(const struct v4l2_h264_reflist_builder *builder,
> > +			     struct v4l2_h264_reference *reflist, u8 list_num)
> > +{
> > +	char buf[1024];
> 
> I really don't like placing 1024 bytes on the stack. Can you find another way
> of doing this? Perhaps using pr_cont or writing each format_ref_list item
> on a separate line.

Thanks, I was strongly discourage of using pr_cont (which was my first
approach). Rationales are well covered on LKLM and in the pr_cont documentation,
so I won't say more then its not visually thread safe.

I would like to decline the second proposition, as having the lists spread out
on up to 32 lines will make the trace very hard to use. What I may suggest, as I
would really prefer keeping this trace useful, is to use an allocation instead.
The performance does not matter, and I explicitly call this function inside the
pr_debug call so it can be compiled out.

My last resort otherwise would be to use 32 %s formaters, and pass each of the
possible 32 entry (or empty string "") manually.

let me know what you believe is acceptable for you,
Nicolas

> 
> Regards,
> 
> 	Hans
> 
> > +
> > +	pr_debug("ref_pic_list_b%u (cur_poc %u%c) %s",
> > +		 list_num, builder->cur_pic_order_count,
> > +		 ref_type_to_char (builder->cur_pic_fields),
> > +		 format_ref_list_b(builder, reflist, buf, sizeof(buf)));
> > +}
> > +
> >  /**
> >   * v4l2_h264_build_p_ref_list() - Build the P reference list
> >   *
> > @@ -261,6 +342,8 @@ v4l2_h264_build_p_ref_list(const struct v4l2_h264_reflist_builder *builder,
> >  	       sizeof(builder->unordered_reflist[0]) * builder->num_valid);
> >  	sort_r(reflist, builder->num_valid, sizeof(*reflist),
> >  	       v4l2_h264_p_ref_list_cmp, NULL, builder);
> > +
> > +	print_ref_list_p(builder, reflist);
> >  }
> >  EXPORT_SYMBOL_GPL(v4l2_h264_build_p_ref_list);
> >  
> > @@ -296,6 +379,9 @@ v4l2_h264_build_b_ref_lists(const struct v4l2_h264_reflist_builder *builder,
> >  	if (builder->num_valid > 1 &&
> >  	    !memcmp(b1_reflist, b0_reflist, builder->num_valid))
> >  		swap(b1_reflist[0], b1_reflist[1]);
> > +
> > +	print_ref_list_b(builder, b0_reflist, 0);
> > +	print_ref_list_b(builder, b1_reflist, 1);
> >  }
> >  EXPORT_SYMBOL_GPL(v4l2_h264_build_b_ref_lists);
> >  
> 


  reply	other threads:[~2022-04-22 14:59 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-05 20:44 [PATCH v3 00/24] H.264 Field Decoding Support for Frame-based Decoders Nicolas Dufresne
2022-04-05 20:44 ` [PATCH v3 01/24] media: doc: Document dual use of H.264 pic_num/frame_num Nicolas Dufresne
2022-04-22  6:31   ` Hans Verkuil
2022-04-05 20:44 ` [PATCH v3 02/24] media: v4l2-mem2mem: Trace on implicit un-hold Nicolas Dufresne
2022-04-05 20:44 ` [PATCH v3 03/24] media: videobuf2-v4l2: Warn on holding buffers without support Nicolas Dufresne
2022-04-05 20:44 ` [PATCH v3 04/24] media: h264: Avoid wrapping long_term_frame_idx Nicolas Dufresne
2022-04-05 20:44 ` [PATCH v3 05/24] media: h264: Use v4l2_h264_reference for reflist Nicolas Dufresne
2022-04-22  5:42   ` Hans Verkuil
2022-04-22 15:23     ` Nicolas Dufresne
2022-04-22  6:59   ` Hans Verkuil
2022-04-22 14:44     ` Nicolas Dufresne
2022-04-05 20:44 ` [PATCH v3 06/24] media: h264: Increase reference lists size to 32 Nicolas Dufresne
2022-04-05 20:44 ` [PATCH v3 07/24] media: h264: Store current picture fields Nicolas Dufresne
2022-04-05 20:44 ` [PATCH v3 08/24] media: h264: Store all fields into the unordered list Nicolas Dufresne
2022-04-05 20:44 ` [PATCH v3 09/24] media: v4l2: Trace calculated p/b0/b1 initial reflist Nicolas Dufresne
2022-04-22  7:26   ` Hans Verkuil
2022-04-22 14:58     ` Nicolas Dufresne [this message]
2022-04-22 16:33       ` Hans Verkuil
2022-04-05 20:44 ` [PATCH v3 10/24] media: h264: Sort p/b reflist using frame_num Nicolas Dufresne
2022-04-22  7:29   ` Hans Verkuil
2022-04-05 20:44 ` [PATCH v3 11/24] media: v4l2: Reorder field reflist Nicolas Dufresne
2022-04-22  7:31   ` Hans Verkuil
2022-04-05 20:44 ` [PATCH v3 12/24] media: rkvdec: Stop overclocking the decoder Nicolas Dufresne
2022-04-22  7:33   ` Hans Verkuil
2022-04-05 20:44 ` [PATCH v3 13/24] media: rkvdec: h264: Fix dpb_valid implementation Nicolas Dufresne
2022-04-05 20:44 ` [PATCH v3 14/24] media: rkvdec: h264: Fix bit depth wrap in pps packet Nicolas Dufresne
2022-04-05 20:44 ` [PATCH v3 15/24] media: rkvdec: Move H264 SPS validation in rkvdec-h264 Nicolas Dufresne
2022-04-06  5:17   ` Ezequiel Garcia
2022-04-22  7:36   ` Hans Verkuil
2022-04-05 20:44 ` [PATCH v3 16/24] media: rkvdec: h264: Validate and use pic width and height in mbs Nicolas Dufresne
2022-04-06 13:10   ` Nicolas Dufresne
2022-04-06 13:12   ` Ezequiel Garcia
2022-04-22  7:39   ` Hans Verkuil
2022-04-05 20:44 ` [PATCH v3 17/24] media: rkvdec: h264: Fix reference frame_num wrap for second field Nicolas Dufresne
2022-04-22  7:43   ` Hans Verkuil
2022-04-25 18:55     ` Nicolas Dufresne
2022-04-25 19:00       ` Nicolas Dufresne
2022-04-05 20:44 ` [PATCH v3 18/24] media: rkvdec: Ensure decoded resolution fit coded resolution Nicolas Dufresne
2022-04-05 20:44 ` [PATCH v3 19/24] media: rkvdec-h264: Add field decoding support Nicolas Dufresne
2022-04-05 20:44 ` [PATCH v3 20/24] media: rkvdec: Enable capture buffer holding for H264 Nicolas Dufresne
2022-04-05 20:44 ` [PATCH v3 21/24] media: hantro: Stop using H.264 parameter pic_num Nicolas Dufresne
2022-04-05 20:44 ` [PATCH v3 22/24] media: hantro: h264: Make dpb entry management more robust Nicolas Dufresne
2022-04-05 20:44 ` [PATCH v3 23/24] media: hantro: Add H.264 field decoding support Nicolas Dufresne
2022-04-22  7:49   ` Hans Verkuil
2022-04-05 20:44 ` [PATCH v3 24/24] media: hantro: Enable HOLD_CAPTURE_BUF for H.264 Nicolas Dufresne
2022-04-06 17:58 ` [PATCH v3 00/24] H.264 Field Decoding Support for Frame-based Decoders Nicolas Dufresne

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=04819e457ee0135e5d0b337dccfaba69b2d46610.camel@collabora.com \
    --to=nicolas.dufresne@collabora.com \
    --cc=hverkuil@xs4all.nl \
    --cc=kernel@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=sebastian.fricke@collabora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®