From: Jonas Karlman <[email protected]>
When decoding the second field in a complementary field pair the second
field is sharing the same frame_num with the first field.
Currently the frame_num for the first field is wrapped when it matches the
field being decoded, this cause issues to decode the second field in a
complementary field pair.
Fix this by using inclusive comparison, less than or equal.
Signed-off-by: Jonas Karlman <[email protected]>
Signed-off-by: Nicolas Dufresne <[email protected]>
Reviewed-by: Ezequiel Garcia <[email protected]>
Reviewed-by: Sebastian Fricke <[email protected]>
---
drivers/staging/media/rkvdec/rkvdec-h264.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/rkvdec/rkvdec-h264.c b/drivers/staging/media/rkvdec/rkvdec-h264.c
index f081b476340f..60eaf06b6e25 100644
--- a/drivers/staging/media/rkvdec/rkvdec-h264.c
+++ b/drivers/staging/media/rkvdec/rkvdec-h264.c
@@ -781,7 +781,7 @@ static void assemble_hw_rps(struct rkvdec_ctx *ctx,
continue;
if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM ||
- dpb[i].frame_num < dec_params->frame_num) {
+ dpb[i].frame_num <= dec_params->frame_num) {
p[i] = dpb[i].frame_num;
continue;
}
--
2.34.1
On 05/04/2022 22:44, Nicolas Dufresne wrote:
> From: Jonas Karlman <[email protected]>
>
> When decoding the second field in a complementary field pair the second
> field is sharing the same frame_num with the first field.
>
> Currently the frame_num for the first field is wrapped when it matches the
> field being decoded, this cause issues to decode the second field in a
cause issues to decode -> caused issues decoding
> complementary field pair.
>
> Fix this by using inclusive comparison, less than or equal.
I would change this last sentence to:
Fix this by using inclusive comparison: 'less than or equal'.
It makes it a bit easier to parse.
>
> Signed-off-by: Jonas Karlman <[email protected]>
> Signed-off-by: Nicolas Dufresne <[email protected]>
> Reviewed-by: Ezequiel Garcia <[email protected]>
> Reviewed-by: Sebastian Fricke <[email protected]>
> ---
> drivers/staging/media/rkvdec/rkvdec-h264.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/rkvdec/rkvdec-h264.c b/drivers/staging/media/rkvdec/rkvdec-h264.c
> index f081b476340f..60eaf06b6e25 100644
> --- a/drivers/staging/media/rkvdec/rkvdec-h264.c
> +++ b/drivers/staging/media/rkvdec/rkvdec-h264.c
> @@ -781,7 +781,7 @@ static void assemble_hw_rps(struct rkvdec_ctx *ctx,
> continue;
>
> if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM ||
> - dpb[i].frame_num < dec_params->frame_num) {
> + dpb[i].frame_num <= dec_params->frame_num) {
I wonder if a comment should be added here, explaining the reason for '<='.
It doesn't seem obvious to me. Up to you, though.
> p[i] = dpb[i].frame_num;
> continue;
> }
Regards,
Hans
Le vendredi 22 avril 2022 à 09:43 +0200, Hans Verkuil a écrit :
> On 05/04/2022 22:44, Nicolas Dufresne wrote:
> > From: Jonas Karlman <[email protected]>
> >
> > When decoding the second field in a complementary field pair the second
> > field is sharing the same frame_num with the first field.
> >
> > Currently the frame_num for the first field is wrapped when it matches the
> > field being decoded, this cause issues to decode the second field in a
>
> cause issues to decode -> caused issues decoding
>
> > complementary field pair.
> >
> > Fix this by using inclusive comparison, less than or equal.
>
> I would change this last sentence to:
>
> Fix this by using inclusive comparison: 'less than or equal'.
>
> It makes it a bit easier to parse.
>
> >
> > Signed-off-by: Jonas Karlman <[email protected]>
> > Signed-off-by: Nicolas Dufresne <[email protected]>
> > Reviewed-by: Ezequiel Garcia <[email protected]>
> > Reviewed-by: Sebastian Fricke <[email protected]>
> > ---
> > drivers/staging/media/rkvdec/rkvdec-h264.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/media/rkvdec/rkvdec-h264.c b/drivers/staging/media/rkvdec/rkvdec-h264.c
> > index f081b476340f..60eaf06b6e25 100644
> > --- a/drivers/staging/media/rkvdec/rkvdec-h264.c
> > +++ b/drivers/staging/media/rkvdec/rkvdec-h264.c
> > @@ -781,7 +781,7 @@ static void assemble_hw_rps(struct rkvdec_ctx *ctx,
> > continue;
> >
> > if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM ||
> > - dpb[i].frame_num < dec_params->frame_num) {
> > + dpb[i].frame_num <= dec_params->frame_num) {
>
> I wonder if a comment should be added here, explaining the reason for '<='.
>
> It doesn't seem obvious to me. Up to you, though.
I guess I could, the algo for wrapping in the spec is (formula 8-27):
if( FrameNum > frame_num )
FrameNumWrap = FrameNum − MaxFrameNum
else
FrameNumWrap = FrameNum
Our implementation has the branch condition flip over, and the flipped version of that is:
if( FrameNum <= frame_num )
FrameNumWrap = FrameNum
else
FrameNumWrap = FrameNum − MaxFrameNum
There is no deeper rationale since we simply follow the recipe described in the
spec. This is done so that we can share that condition with that long term
reference handling.
>
> > p[i] = dpb[i].frame_num;
> > continue;
> > }
>
> Regards,
>
> Hans
Le lundi 25 avril 2022 à 14:55 -0400, Nicolas Dufresne a écrit :
> Le vendredi 22 avril 2022 à 09:43 +0200, Hans Verkuil a écrit :
> > On 05/04/2022 22:44, Nicolas Dufresne wrote:
> > > From: Jonas Karlman <[email protected]>
> > >
> > > When decoding the second field in a complementary field pair the second
> > > field is sharing the same frame_num with the first field.
> > >
> > > Currently the frame_num for the first field is wrapped when it matches the
> > > field being decoded, this cause issues to decode the second field in a
> >
> > cause issues to decode -> caused issues decoding
> >
> > > complementary field pair.
> > >
> > > Fix this by using inclusive comparison, less than or equal.
> >
> > I would change this last sentence to:
> >
> > Fix this by using inclusive comparison: 'less than or equal'.
> >
> > It makes it a bit easier to parse.
> >
> > >
> > > Signed-off-by: Jonas Karlman <[email protected]>
> > > Signed-off-by: Nicolas Dufresne <[email protected]>
> > > Reviewed-by: Ezequiel Garcia <[email protected]>
> > > Reviewed-by: Sebastian Fricke <[email protected]>
> > > ---
> > > drivers/staging/media/rkvdec/rkvdec-h264.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/staging/media/rkvdec/rkvdec-h264.c b/drivers/staging/media/rkvdec/rkvdec-h264.c
> > > index f081b476340f..60eaf06b6e25 100644
> > > --- a/drivers/staging/media/rkvdec/rkvdec-h264.c
> > > +++ b/drivers/staging/media/rkvdec/rkvdec-h264.c
> > > @@ -781,7 +781,7 @@ static void assemble_hw_rps(struct rkvdec_ctx *ctx,
> > > continue;
> > >
> > > if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM ||
> > > - dpb[i].frame_num < dec_params->frame_num) {
> > > + dpb[i].frame_num <= dec_params->frame_num) {
> >
> > I wonder if a comment should be added here, explaining the reason for '<='.
> >
> > It doesn't seem obvious to me. Up to you, though.
>
> I guess I could, the algo for wrapping in the spec is (formula 8-27):
>
> if( FrameNum > frame_num )
> FrameNumWrap = FrameNum − MaxFrameNum
> else
> FrameNumWrap = FrameNum
>
> Our implementation has the branch condition flip over, and the flipped version of that is:
>
> if( FrameNum <= frame_num )
> FrameNumWrap = FrameNum
> else
> FrameNumWrap = FrameNum − MaxFrameNum
>
> There is no deeper rationale since we simply follow the recipe described in the
> spec. This is done so that we can share that condition with that long term
> reference handling.
Now I come to realize that in patch "[v3,19/24] media: rkvdec-h264: Add field
decoding support" all this code is removed. This is because the wrapping is
already done by the ref-builder, so while enabling field decoding, I now use the
wrapped value from the ref builder. I'm mostly keeping the patch so that this
fix is well documented. I will leave it like this then.
>
> >
> > > p[i] = dpb[i].frame_num;
> > > continue;
> > > }
> >
> > Regards,
> >
> > Hans
>