* [FFmpeg-devel] [PATCH 2/6] avcodec/h264: Use FRAME_RECOVERED_HEURISTIC instead of IDR/SEI
2023-11-14 17:20 [FFmpeg-devel] [PATCH 1/6] avcodec/h264: Seperate SEI and IDR recovery handling Michael Niedermayer
@ 2023-11-14 17:20 ` Michael Niedermayer
2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 3/6] avcodec/h264dec: More elaborate documentation for frame_recovered Michael Niedermayer
` (3 subsequent siblings)
4 siblings, 0 replies; 14+ messages in thread
From: Michael Niedermayer @ 2023-11-14 17:20 UTC (permalink / raw)
To: FFmpeg development discussions and patches
This keeps IDR/SEI and heuristically detected recovery points cleaner seperated
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
libavcodec/h264_refs.c | 4 ++--
libavcodec/h264dec.h | 4 ++++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
index 25e521dafc0..92778e737a5 100644
--- a/libavcodec/h264_refs.c
+++ b/libavcodec/h264_refs.c
@@ -822,9 +822,9 @@ int ff_h264_execute_ref_pic_marking(H264Context *h)
|| pps_ref_count[0] <= 1 + (h->picture_structure != PICT_FRAME) && pps_ref_count[1] <= 1)
&& pps_ref_count[0]<=2 + (h->picture_structure != PICT_FRAME) + (2*!h->has_recovery_point)
&& h->cur_pic_ptr->f->pict_type == AV_PICTURE_TYPE_I){
- h->cur_pic_ptr->recovered |= FRAME_RECOVERED_IDR;
+ h->cur_pic_ptr->recovered |= FRAME_RECOVERED_HEURISTIC;
if(!h->avctx->has_b_frames)
- h->frame_recovered |= FRAME_RECOVERED_SEI;
+ h->frame_recovered |= FRAME_RECOVERED_HEURISTIC;
}
out:
diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
index 5ce3a6be735..b0c54ad82fb 100644
--- a/libavcodec/h264dec.h
+++ b/libavcodec/h264dec.h
@@ -519,6 +519,10 @@ typedef struct H264Context {
* so all the following frames in presentation order are correct.
*/
#define FRAME_RECOVERED_SEI (1 << 1)
+/**
+ * Recovery point detected by heuristic
+ */
+#define FRAME_RECOVERED_HEURISTIC (1 << 2)
int frame_recovered; ///< Initial frame has been completely recovered
--
2.17.1
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 14+ messages in thread
* [FFmpeg-devel] [PATCH 3/6] avcodec/h264dec: More elaborate documentation for frame_recovered
2023-11-14 17:20 [FFmpeg-devel] [PATCH 1/6] avcodec/h264: Seperate SEI and IDR recovery handling Michael Niedermayer
2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 2/6] avcodec/h264: Use FRAME_RECOVERED_HEURISTIC instead of IDR/SEI Michael Niedermayer
@ 2023-11-14 17:20 ` Michael Niedermayer
2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 4/6] avcodec/h264: keep track of which frames used gray references Michael Niedermayer
` (2 subsequent siblings)
4 siblings, 0 replies; 14+ messages in thread
From: Michael Niedermayer @ 2023-11-14 17:20 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
libavcodec/h264dec.h | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
index b0c54ad82fb..ede51951727 100644
--- a/libavcodec/h264dec.h
+++ b/libavcodec/h264dec.h
@@ -524,7 +524,17 @@ typedef struct H264Context {
*/
#define FRAME_RECOVERED_HEURISTIC (1 << 2)
- int frame_recovered; ///< Initial frame has been completely recovered
+ /**
+ * Initial frame has been completely recovered.
+ *
+ * Once this is set, all following decoded as well as displayed frames will be marked as recovered
+ * If a frame is marked as recovered frame_recovered will be set once this frame is output and thus
+ * all subsequently output fraames are also marked as recovered
+ *
+ * In effect, if you want all subsequent DECODED frames marked as recovered, set frame_recovered
+ * If you want all subsequent DISPAYED frames marked as recovered, set the frame->recovered
+ */
+ int frame_recovered;
int has_recovery_point;
--
2.17.1
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 14+ messages in thread
* [FFmpeg-devel] [PATCH 4/6] avcodec/h264: keep track of which frames used gray references
2023-11-14 17:20 [FFmpeg-devel] [PATCH 1/6] avcodec/h264: Seperate SEI and IDR recovery handling Michael Niedermayer
2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 2/6] avcodec/h264: Use FRAME_RECOVERED_HEURISTIC instead of IDR/SEI Michael Niedermayer
2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 3/6] avcodec/h264dec: More elaborate documentation for frame_recovered Michael Niedermayer
@ 2023-11-14 17:20 ` Michael Niedermayer
2023-11-14 17:32 ` Hendrik Leppkes
2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 5/6] avcodec/h264: Avoid using gray gap frames as references Michael Niedermayer
2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 6/6] avcodec/h264dec: Support skipping frames that used gray gap frames Michael Niedermayer
4 siblings, 1 reply; 14+ messages in thread
From: Michael Niedermayer @ 2023-11-14 17:20 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
libavcodec/h264_picture.c | 1 +
libavcodec/h264_slice.c | 19 ++++++++++++++++++-
libavcodec/h264dec.c | 1 +
libavcodec/h264dec.h | 4 ++++
4 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
index 691c61eea23..3234141dbd6 100644
--- a/libavcodec/h264_picture.c
+++ b/libavcodec/h264_picture.c
@@ -96,6 +96,7 @@ static void h264_copy_picture_params(H264Picture *dst, const H264Picture *src)
dst->field_picture = src->field_picture;
dst->reference = src->reference;
dst->recovered = src->recovered;
+ dst->gray = src->gray;
dst->invalid_gap = src->invalid_gap;
dst->sei_recovery_frame_cnt = src->sei_recovery_frame_cnt;
dst->mb_width = src->mb_width;
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 4861a2cabba..2c4ab89dae1 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -457,6 +457,7 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
h->poc.prev_frame_num = h->poc.frame_num;
h->recovery_frame = h1->recovery_frame;
+ h->non_gray = h1->non_gray;
return err;
}
@@ -1544,11 +1545,14 @@ static int h264_field_start(H264Context *h, const H264SliceContext *sl,
if (ret < 0)
return ret;
h->short_ref[0]->poc = prev->poc + 2U;
+ h->short_ref[0]->gray = prev->gray;
ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX, 0);
if (h->short_ref[0]->field_picture)
ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX, 1);
- } else if (!h->frame_recovered && !h->avctx->hwaccel)
+ } else if (!h->frame_recovered && !h->avctx->hwaccel) {
color_frame(h->short_ref[0]->f, c);
+ h->short_ref[0]->gray = 1;
+ }
h->short_ref[0]->frame_num = h->poc.prev_frame_num;
}
}
@@ -2007,6 +2011,19 @@ static int h264_slice_init(H264Context *h, H264SliceContext *sl,
(sl->ref_list[j][i].reference & 3);
}
+ if (sl->slice_type_nos == AV_PICTURE_TYPE_I) {
+ h->cur_pic_ptr->gray = 0;
+ h->non_gray = 1;
+ } else {
+ int gray = 0;
+ for (j = 0; j < sl->list_count; j++) {
+ for (i = 0; i < sl->ref_count[j]; i++) {
+ gray |= sl->ref_list[j][i].parent->gray;
+ }
+ }
+ h->cur_pic_ptr->gray = gray;
+ }
+
if (h->avctx->debug & FF_DEBUG_PICT_INFO) {
av_log(h->avctx, AV_LOG_DEBUG,
"slice:%d %c mb:%d %c%s%s frame:%d poc:%d/%d ref:%d/%d qp:%d loop:%d:%d:%d weight:%d%s %s\n",
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index ef9e60bbf33..7ea55db75dd 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -492,6 +492,7 @@ static void h264_decode_flush(AVCodecContext *avctx)
ff_h264_unref_picture(&h->cur_pic);
h->mb_y = 0;
+ h->non_gray = 0;
ff_h264_free_tables(h);
h->context_initialized = 0;
diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
index ede51951727..366626c056c 100644
--- a/libavcodec/h264dec.h
+++ b/libavcodec/h264dec.h
@@ -154,6 +154,8 @@ typedef struct H264Picture {
/// RefStruct reference; its pointee is shared between decoding threads.
atomic_int *decode_error_flags;
+
+ int gray;
} H264Picture;
typedef struct H264Ref {
@@ -567,6 +569,8 @@ typedef struct H264Context {
struct FFRefStructPool *ref_index_pool;
struct FFRefStructPool *decode_error_flags_pool;
int ref2frm[MAX_SLICES][2][64]; ///< reference to frame number lists, used in the loop filter, the first 2 are for -2,-1
+
+ int non_gray; ///< Did we encounter a intra frame after a gray gap frame
} H264Context;
extern const uint16_t ff_h264_mb_sizes[4];
--
2.17.1
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [FFmpeg-devel] [PATCH 4/6] avcodec/h264: keep track of which frames used gray references
2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 4/6] avcodec/h264: keep track of which frames used gray references Michael Niedermayer
@ 2023-11-14 17:32 ` Hendrik Leppkes
2023-11-14 18:46 ` Michael Niedermayer
0 siblings, 1 reply; 14+ messages in thread
From: Hendrik Leppkes @ 2023-11-14 17:32 UTC (permalink / raw)
To: FFmpeg development discussions and patches
On Tue, Nov 14, 2023 at 6:21 PM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
> libavcodec/h264_picture.c | 1 +
> libavcodec/h264_slice.c | 19 ++++++++++++++++++-
> libavcodec/h264dec.c | 1 +
> libavcodec/h264dec.h | 4 ++++
> 4 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
> index 691c61eea23..3234141dbd6 100644
> --- a/libavcodec/h264_picture.c
> +++ b/libavcodec/h264_picture.c
> @@ -96,6 +96,7 @@ static void h264_copy_picture_params(H264Picture *dst, const H264Picture *src)
> dst->field_picture = src->field_picture;
> dst->reference = src->reference;
> dst->recovered = src->recovered;
> + dst->gray = src->gray;
> dst->invalid_gap = src->invalid_gap;
> dst->sei_recovery_frame_cnt = src->sei_recovery_frame_cnt;
> dst->mb_width = src->mb_width;
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index 4861a2cabba..2c4ab89dae1 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -457,6 +457,7 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
> h->poc.prev_frame_num = h->poc.frame_num;
>
> h->recovery_frame = h1->recovery_frame;
> + h->non_gray = h1->non_gray;
>
> return err;
> }
> @@ -1544,11 +1545,14 @@ static int h264_field_start(H264Context *h, const H264SliceContext *sl,
> if (ret < 0)
> return ret;
> h->short_ref[0]->poc = prev->poc + 2U;
> + h->short_ref[0]->gray = prev->gray;
> ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX, 0);
> if (h->short_ref[0]->field_picture)
> ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX, 1);
> - } else if (!h->frame_recovered && !h->avctx->hwaccel)
> + } else if (!h->frame_recovered && !h->avctx->hwaccel) {
> color_frame(h->short_ref[0]->f, c);
> + h->short_ref[0]->gray = 1;
> + }
While we can't color invalid frames for hwaccels easily, the flag
should perhaps still be applied, as they are equally invalid.
Thinking about this, maybe the name should be less the color we
happened to use for it, and more like "placeholder" or "invalid" or
anything like that?
> h->short_ref[0]->frame_num = h->poc.prev_frame_num;
> }
> }
> @@ -2007,6 +2011,19 @@ static int h264_slice_init(H264Context *h, H264SliceContext *sl,
> (sl->ref_list[j][i].reference & 3);
> }
>
> + if (sl->slice_type_nos == AV_PICTURE_TYPE_I) {
> + h->cur_pic_ptr->gray = 0;
> + h->non_gray = 1;
> + } else {
> + int gray = 0;
> + for (j = 0; j < sl->list_count; j++) {
> + for (i = 0; i < sl->ref_count[j]; i++) {
> + gray |= sl->ref_list[j][i].parent->gray;
> + }
> + }
> + h->cur_pic_ptr->gray = gray;
> + }
> +
> if (h->avctx->debug & FF_DEBUG_PICT_INFO) {
> av_log(h->avctx, AV_LOG_DEBUG,
> "slice:%d %c mb:%d %c%s%s frame:%d poc:%d/%d ref:%d/%d qp:%d loop:%d:%d:%d weight:%d%s %s\n",
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index ef9e60bbf33..7ea55db75dd 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -492,6 +492,7 @@ static void h264_decode_flush(AVCodecContext *avctx)
> ff_h264_unref_picture(&h->cur_pic);
>
> h->mb_y = 0;
> + h->non_gray = 0;
>
> ff_h264_free_tables(h);
> h->context_initialized = 0;
> diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
> index ede51951727..366626c056c 100644
> --- a/libavcodec/h264dec.h
> +++ b/libavcodec/h264dec.h
> @@ -154,6 +154,8 @@ typedef struct H264Picture {
>
> /// RefStruct reference; its pointee is shared between decoding threads.
> atomic_int *decode_error_flags;
> +
> + int gray;
> } H264Picture;
>
> typedef struct H264Ref {
> @@ -567,6 +569,8 @@ typedef struct H264Context {
> struct FFRefStructPool *ref_index_pool;
> struct FFRefStructPool *decode_error_flags_pool;
> int ref2frm[MAX_SLICES][2][64]; ///< reference to frame number lists, used in the loop filter, the first 2 are for -2,-1
> +
> + int non_gray; ///< Did we encounter a intra frame after a gray gap frame
> } H264Context;
>
> extern const uint16_t ff_h264_mb_sizes[4];
> --
> 2.17.1
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [FFmpeg-devel] [PATCH 4/6] avcodec/h264: keep track of which frames used gray references
2023-11-14 17:32 ` Hendrik Leppkes
@ 2023-11-14 18:46 ` Michael Niedermayer
2023-11-20 0:11 ` Michael Niedermayer
0 siblings, 1 reply; 14+ messages in thread
From: Michael Niedermayer @ 2023-11-14 18:46 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 3124 bytes --]
On Tue, Nov 14, 2023 at 06:32:19PM +0100, Hendrik Leppkes wrote:
> On Tue, Nov 14, 2023 at 6:21 PM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> >
> > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > ---
> > libavcodec/h264_picture.c | 1 +
> > libavcodec/h264_slice.c | 19 ++++++++++++++++++-
> > libavcodec/h264dec.c | 1 +
> > libavcodec/h264dec.h | 4 ++++
> > 4 files changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
> > index 691c61eea23..3234141dbd6 100644
> > --- a/libavcodec/h264_picture.c
> > +++ b/libavcodec/h264_picture.c
> > @@ -96,6 +96,7 @@ static void h264_copy_picture_params(H264Picture *dst, const H264Picture *src)
> > dst->field_picture = src->field_picture;
> > dst->reference = src->reference;
> > dst->recovered = src->recovered;
> > + dst->gray = src->gray;
> > dst->invalid_gap = src->invalid_gap;
> > dst->sei_recovery_frame_cnt = src->sei_recovery_frame_cnt;
> > dst->mb_width = src->mb_width;
> > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> > index 4861a2cabba..2c4ab89dae1 100644
> > --- a/libavcodec/h264_slice.c
> > +++ b/libavcodec/h264_slice.c
> > @@ -457,6 +457,7 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
> > h->poc.prev_frame_num = h->poc.frame_num;
> >
> > h->recovery_frame = h1->recovery_frame;
> > + h->non_gray = h1->non_gray;
> >
> > return err;
> > }
> > @@ -1544,11 +1545,14 @@ static int h264_field_start(H264Context *h, const H264SliceContext *sl,
> > if (ret < 0)
> > return ret;
> > h->short_ref[0]->poc = prev->poc + 2U;
> > + h->short_ref[0]->gray = prev->gray;
> > ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX, 0);
> > if (h->short_ref[0]->field_picture)
> > ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX, 1);
> > - } else if (!h->frame_recovered && !h->avctx->hwaccel)
> > + } else if (!h->frame_recovered && !h->avctx->hwaccel) {
> > color_frame(h->short_ref[0]->f, c);
> > + h->short_ref[0]->gray = 1;
> > + }
>
> While we can't color invalid frames for hwaccels easily, the flag
> should perhaps still be applied, as they are equally invalid.
ok
> Thinking about this, maybe the name should be less the color we
> happened to use for it, and more like "placeholder" or "invalid" or
> anything like that?
"invalid" is a quite generic term that covers more than this case.
and iam not sure if "placeholder" is really good description of them.
I picked "gray" because i had no better idea and they are gray
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 251 bytes --]
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [FFmpeg-devel] [PATCH 4/6] avcodec/h264: keep track of which frames used gray references
2023-11-14 18:46 ` Michael Niedermayer
@ 2023-11-20 0:11 ` Michael Niedermayer
2023-11-20 3:01 ` Vittorio Giovara
0 siblings, 1 reply; 14+ messages in thread
From: Michael Niedermayer @ 2023-11-20 0:11 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 3452 bytes --]
On Tue, Nov 14, 2023 at 07:46:16PM +0100, Michael Niedermayer wrote:
> On Tue, Nov 14, 2023 at 06:32:19PM +0100, Hendrik Leppkes wrote:
> > On Tue, Nov 14, 2023 at 6:21 PM Michael Niedermayer
> > <michael@niedermayer.cc> wrote:
> > >
> > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > > ---
> > > libavcodec/h264_picture.c | 1 +
> > > libavcodec/h264_slice.c | 19 ++++++++++++++++++-
> > > libavcodec/h264dec.c | 1 +
> > > libavcodec/h264dec.h | 4 ++++
> > > 4 files changed, 24 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
> > > index 691c61eea23..3234141dbd6 100644
> > > --- a/libavcodec/h264_picture.c
> > > +++ b/libavcodec/h264_picture.c
> > > @@ -96,6 +96,7 @@ static void h264_copy_picture_params(H264Picture *dst, const H264Picture *src)
> > > dst->field_picture = src->field_picture;
> > > dst->reference = src->reference;
> > > dst->recovered = src->recovered;
> > > + dst->gray = src->gray;
> > > dst->invalid_gap = src->invalid_gap;
> > > dst->sei_recovery_frame_cnt = src->sei_recovery_frame_cnt;
> > > dst->mb_width = src->mb_width;
> > > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> > > index 4861a2cabba..2c4ab89dae1 100644
> > > --- a/libavcodec/h264_slice.c
> > > +++ b/libavcodec/h264_slice.c
> > > @@ -457,6 +457,7 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
> > > h->poc.prev_frame_num = h->poc.frame_num;
> > >
> > > h->recovery_frame = h1->recovery_frame;
> > > + h->non_gray = h1->non_gray;
> > >
> > > return err;
> > > }
> > > @@ -1544,11 +1545,14 @@ static int h264_field_start(H264Context *h, const H264SliceContext *sl,
> > > if (ret < 0)
> > > return ret;
> > > h->short_ref[0]->poc = prev->poc + 2U;
> > > + h->short_ref[0]->gray = prev->gray;
> > > ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX, 0);
> > > if (h->short_ref[0]->field_picture)
> > > ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX, 1);
> > > - } else if (!h->frame_recovered && !h->avctx->hwaccel)
> > > + } else if (!h->frame_recovered && !h->avctx->hwaccel) {
> > > color_frame(h->short_ref[0]->f, c);
> > > + h->short_ref[0]->gray = 1;
> > > + }
> >
> > While we can't color invalid frames for hwaccels easily, the flag
> > should perhaps still be applied, as they are equally invalid.
>
> ok
will apply with this changed
>
>
> > Thinking about this, maybe the name should be less the color we
> > happened to use for it, and more like "placeholder" or "invalid" or
> > anything like that?
>
> "invalid" is a quite generic term that covers more than this case.
> and iam not sure if "placeholder" is really good description of them.
> I picked "gray" because i had no better idea and they are gray
if someone comes up with a better name, we can rename it
but gray is kind of fitting
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 251 bytes --]
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [FFmpeg-devel] [PATCH 4/6] avcodec/h264: keep track of which frames used gray references
2023-11-20 0:11 ` Michael Niedermayer
@ 2023-11-20 3:01 ` Vittorio Giovara
2023-11-20 23:53 ` Michael Niedermayer
0 siblings, 1 reply; 14+ messages in thread
From: Vittorio Giovara @ 2023-11-20 3:01 UTC (permalink / raw)
To: FFmpeg development discussions and patches
On Sun, Nov 19, 2023 at 7:11 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:
> On Tue, Nov 14, 2023 at 07:46:16PM +0100, Michael Niedermayer wrote:
> > On Tue, Nov 14, 2023 at 06:32:19PM +0100, Hendrik Leppkes wrote:
> > > On Tue, Nov 14, 2023 at 6:21 PM Michael Niedermayer
> > > <michael@niedermayer.cc> wrote:
> > > >
> > > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > > > ---
> > > > libavcodec/h264_picture.c | 1 +
> > > > libavcodec/h264_slice.c | 19 ++++++++++++++++++-
> > > > libavcodec/h264dec.c | 1 +
> > > > libavcodec/h264dec.h | 4 ++++
> > > > 4 files changed, 24 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
> > > > index 691c61eea23..3234141dbd6 100644
> > > > --- a/libavcodec/h264_picture.c
> > > > +++ b/libavcodec/h264_picture.c
> > > > @@ -96,6 +96,7 @@ static void h264_copy_picture_params(H264Picture
> *dst, const H264Picture *src)
> > > > dst->field_picture = src->field_picture;
> > > > dst->reference = src->reference;
> > > > dst->recovered = src->recovered;
> > > > + dst->gray = src->gray;
> > > > dst->invalid_gap = src->invalid_gap;
> > > > dst->sei_recovery_frame_cnt = src->sei_recovery_frame_cnt;
> > > > dst->mb_width = src->mb_width;
> > > > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> > > > index 4861a2cabba..2c4ab89dae1 100644
> > > > --- a/libavcodec/h264_slice.c
> > > > +++ b/libavcodec/h264_slice.c
> > > > @@ -457,6 +457,7 @@ int ff_h264_update_thread_context(AVCodecContext
> *dst,
> > > > h->poc.prev_frame_num = h->poc.frame_num;
> > > >
> > > > h->recovery_frame = h1->recovery_frame;
> > > > + h->non_gray = h1->non_gray;
> > > >
> > > > return err;
> > > > }
> > > > @@ -1544,11 +1545,14 @@ static int h264_field_start(H264Context *h,
> const H264SliceContext *sl,
> > > > if (ret < 0)
> > > > return ret;
> > > > h->short_ref[0]->poc = prev->poc + 2U;
> > > > + h->short_ref[0]->gray = prev->gray;
> > > > ff_thread_report_progress(&h->short_ref[0]->tf,
> INT_MAX, 0);
> > > > if (h->short_ref[0]->field_picture)
> > > > ff_thread_report_progress(&h->short_ref[0]->tf,
> INT_MAX, 1);
> > > > - } else if (!h->frame_recovered && !h->avctx->hwaccel)
> > > > + } else if (!h->frame_recovered && !h->avctx->hwaccel) {
> > > > color_frame(h->short_ref[0]->f, c);
> > > > + h->short_ref[0]->gray = 1;
> > > > + }
> > >
> > > While we can't color invalid frames for hwaccels easily, the flag
> > > should perhaps still be applied, as they are equally invalid.
> >
> > ok
>
> will apply with this changed
>
> >
> >
> > > Thinking about this, maybe the name should be less the color we
> > > happened to use for it, and more like "placeholder" or "invalid" or
> > > anything like that?
> >
> > "invalid" is a quite generic term that covers more than this case.
> > and iam not sure if "placeholder" is really good description of them.
> > I picked "gray" because i had no better idea and they are gray
>
> if someone comes up with a better name, we can rename it
> but gray is kind of fitting
>
Sorry, what exactly are h264 gray frames?
Could you add some documentation to the new field in H264Picture too?
--
Vittorio
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [FFmpeg-devel] [PATCH 4/6] avcodec/h264: keep track of which frames used gray references
2023-11-20 3:01 ` Vittorio Giovara
@ 2023-11-20 23:53 ` Michael Niedermayer
0 siblings, 0 replies; 14+ messages in thread
From: Michael Niedermayer @ 2023-11-20 23:53 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 5340 bytes --]
On Sun, Nov 19, 2023 at 10:01:23PM -0500, Vittorio Giovara wrote:
> On Sun, Nov 19, 2023 at 7:11 PM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
>
> > On Tue, Nov 14, 2023 at 07:46:16PM +0100, Michael Niedermayer wrote:
> > > On Tue, Nov 14, 2023 at 06:32:19PM +0100, Hendrik Leppkes wrote:
> > > > On Tue, Nov 14, 2023 at 6:21 PM Michael Niedermayer
> > > > <michael@niedermayer.cc> wrote:
> > > > >
> > > > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > > > > ---
> > > > > libavcodec/h264_picture.c | 1 +
> > > > > libavcodec/h264_slice.c | 19 ++++++++++++++++++-
> > > > > libavcodec/h264dec.c | 1 +
> > > > > libavcodec/h264dec.h | 4 ++++
> > > > > 4 files changed, 24 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
> > > > > index 691c61eea23..3234141dbd6 100644
> > > > > --- a/libavcodec/h264_picture.c
> > > > > +++ b/libavcodec/h264_picture.c
> > > > > @@ -96,6 +96,7 @@ static void h264_copy_picture_params(H264Picture
> > *dst, const H264Picture *src)
> > > > > dst->field_picture = src->field_picture;
> > > > > dst->reference = src->reference;
> > > > > dst->recovered = src->recovered;
> > > > > + dst->gray = src->gray;
> > > > > dst->invalid_gap = src->invalid_gap;
> > > > > dst->sei_recovery_frame_cnt = src->sei_recovery_frame_cnt;
> > > > > dst->mb_width = src->mb_width;
> > > > > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> > > > > index 4861a2cabba..2c4ab89dae1 100644
> > > > > --- a/libavcodec/h264_slice.c
> > > > > +++ b/libavcodec/h264_slice.c
> > > > > @@ -457,6 +457,7 @@ int ff_h264_update_thread_context(AVCodecContext
> > *dst,
> > > > > h->poc.prev_frame_num = h->poc.frame_num;
> > > > >
> > > > > h->recovery_frame = h1->recovery_frame;
> > > > > + h->non_gray = h1->non_gray;
> > > > >
> > > > > return err;
> > > > > }
> > > > > @@ -1544,11 +1545,14 @@ static int h264_field_start(H264Context *h,
> > const H264SliceContext *sl,
> > > > > if (ret < 0)
> > > > > return ret;
> > > > > h->short_ref[0]->poc = prev->poc + 2U;
> > > > > + h->short_ref[0]->gray = prev->gray;
> > > > > ff_thread_report_progress(&h->short_ref[0]->tf,
> > INT_MAX, 0);
> > > > > if (h->short_ref[0]->field_picture)
> > > > > ff_thread_report_progress(&h->short_ref[0]->tf,
> > INT_MAX, 1);
> > > > > - } else if (!h->frame_recovered && !h->avctx->hwaccel)
> > > > > + } else if (!h->frame_recovered && !h->avctx->hwaccel) {
> > > > > color_frame(h->short_ref[0]->f, c);
> > > > > + h->short_ref[0]->gray = 1;
> > > > > + }
> > > >
> > > > While we can't color invalid frames for hwaccels easily, the flag
> > > > should perhaps still be applied, as they are equally invalid.
> > >
> > > ok
> >
> > will apply with this changed
> >
> > >
> > >
> > > > Thinking about this, maybe the name should be less the color we
> > > > happened to use for it, and more like "placeholder" or "invalid" or
> > > > anything like that?
> > >
> > > "invalid" is a quite generic term that covers more than this case.
> > > and iam not sure if "placeholder" is really good description of them.
> > > I picked "gray" because i had no better idea and they are gray
> >
> > if someone comes up with a better name, we can rename it
> > but gray is kind of fitting
> >
>
> Sorry, what exactly are h264 gray frames?
Bascically when we have "missing" frames we fill them by copying
a frame close by or if we have none then we fill them with gray.
(this can occur due to lost frames or at the stream start before
sei_recovery_frame_cnt)
These frames that we fill with gray are gray frames
Before this patchset we did not keep track of which frames where gray
so they could not be avoided as reference frames later. We only avoided
them during their creation.
After this patchset by default we avoid using gray frames as reference
which simply results in better looking frames.
Also i have a stream that is a classic IBBPBBP style stream but the
B frames use past B frames as references and accross intra frame so
that if gray frames are not avoided B frames will forever be corrupt
with gray blocks even after sei_recovery_frame_cnt.
Other H264 decoders do not show this behaviour that we have prior
to this patchset, they avoid these empty/gray frames.
Iam waiting for the owner of this stream to allow me to publish it
then ill make a fate test with it.
Basically this patchset makes things look better in every case where it
looks different than before that i found.
Also you can tune the options to get the old behavior or to drop
affected frames instead of adjusting references away from gray frames
>
> Could you add some documentation to the new field in H264Picture too?
ill post a patch documenting that
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are best at talking, realize last or never when they are wrong.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 251 bytes --]
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 14+ messages in thread
* [FFmpeg-devel] [PATCH 5/6] avcodec/h264: Avoid using gray gap frames as references
2023-11-14 17:20 [FFmpeg-devel] [PATCH 1/6] avcodec/h264: Seperate SEI and IDR recovery handling Michael Niedermayer
` (2 preceding siblings ...)
2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 4/6] avcodec/h264: keep track of which frames used gray references Michael Niedermayer
@ 2023-11-14 17:20 ` Michael Niedermayer
2023-11-21 12:27 ` James Almer
2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 6/6] avcodec/h264dec: Support skipping frames that used gray gap frames Michael Niedermayer
4 siblings, 1 reply; 14+ messages in thread
From: Michael Niedermayer @ 2023-11-14 17:20 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
libavcodec/h264_refs.c | 11 +++++++++++
libavcodec/h264dec.c | 1 +
libavcodec/h264dec.h | 1 +
3 files changed, 13 insertions(+)
diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
index 92778e737a5..9bc7b20988f 100644
--- a/libavcodec/h264_refs.c
+++ b/libavcodec/h264_refs.c
@@ -410,6 +410,17 @@ int ff_h264_build_ref_list(H264Context *h, H264SliceContext *sl)
else
return -1;
}
+ if (h->noref_gray>0 && sl->ref_list[list][index].parent->gray && h->non_gray) {
+ for (int j=0; j<sl->list_count; j++) {
+ int list2 = (list+j)&1;
+ if (h->default_ref[list2].parent && !h->default_ref[list2].parent->gray
+ && !(!FIELD_PICTURE(h) && (h->default_ref[list2].reference&3) != 3)) {
+ sl->ref_list[list][index] = h->default_ref[list2];
+ av_log(h, AV_LOG_DEBUG, "replacement of gray gap frame\n");
+ break;
+ }
+ }
+ }
av_assert0(av_buffer_get_ref_count(sl->ref_list[list][index].parent->f->buf[0]) > 0);
}
}
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 7ea55db75dd..b48821db244 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -1091,6 +1091,7 @@ static const AVOption h264_options[] = {
{ "nal_length_size", "nal_length_size", OFFSET(nal_length_size), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 4, VDX },
{ "enable_er", "Enable error resilience on damaged frames (unsafe)", OFFSET(enable_er), AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, VD },
{ "x264_build", "Assume this x264 version if no x264 version found in any SEI", OFFSET(x264_build), AV_OPT_TYPE_INT, {.i64 = -1}, -1, INT_MAX, VD },
+ { "noref_gray", "Avoid using gray gap frames as references", OFFSET(noref_gray), AV_OPT_TYPE_INT, {.i64 = 1}, -1, 1, VD },
{ NULL },
};
diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
index 366626c056c..591769ab258 100644
--- a/libavcodec/h264dec.h
+++ b/libavcodec/h264dec.h
@@ -571,6 +571,7 @@ typedef struct H264Context {
int ref2frm[MAX_SLICES][2][64]; ///< reference to frame number lists, used in the loop filter, the first 2 are for -2,-1
int non_gray; ///< Did we encounter a intra frame after a gray gap frame
+ int noref_gray;
} H264Context;
extern const uint16_t ff_h264_mb_sizes[4];
--
2.17.1
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [FFmpeg-devel] [PATCH 5/6] avcodec/h264: Avoid using gray gap frames as references
2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 5/6] avcodec/h264: Avoid using gray gap frames as references Michael Niedermayer
@ 2023-11-21 12:27 ` James Almer
2023-11-22 0:09 ` Michael Niedermayer
0 siblings, 1 reply; 14+ messages in thread
From: James Almer @ 2023-11-21 12:27 UTC (permalink / raw)
To: ffmpeg-devel
On 11/14/2023 2:20 PM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
> libavcodec/h264_refs.c | 11 +++++++++++
> libavcodec/h264dec.c | 1 +
> libavcodec/h264dec.h | 1 +
> 3 files changed, 13 insertions(+)
>
> diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
> index 92778e737a5..9bc7b20988f 100644
> --- a/libavcodec/h264_refs.c
> +++ b/libavcodec/h264_refs.c
> @@ -410,6 +410,17 @@ int ff_h264_build_ref_list(H264Context *h, H264SliceContext *sl)
> else
> return -1;
> }
> + if (h->noref_gray>0 && sl->ref_list[list][index].parent->gray && h->non_gray) {
> + for (int j=0; j<sl->list_count; j++) {
> + int list2 = (list+j)&1;
> + if (h->default_ref[list2].parent && !h->default_ref[list2].parent->gray
> + && !(!FIELD_PICTURE(h) && (h->default_ref[list2].reference&3) != 3)) {
> + sl->ref_list[list][index] = h->default_ref[list2];
> + av_log(h, AV_LOG_DEBUG, "replacement of gray gap frame\n");
> + break;
> + }
> + }
> + }
> av_assert0(av_buffer_get_ref_count(sl->ref_list[list][index].parent->f->buf[0]) > 0);
> }
> }
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index 7ea55db75dd..b48821db244 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -1091,6 +1091,7 @@ static const AVOption h264_options[] = {
> { "nal_length_size", "nal_length_size", OFFSET(nal_length_size), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 4, VDX },
> { "enable_er", "Enable error resilience on damaged frames (unsafe)", OFFSET(enable_er), AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, VD },
> { "x264_build", "Assume this x264 version if no x264 version found in any SEI", OFFSET(x264_build), AV_OPT_TYPE_INT, {.i64 = -1}, -1, INT_MAX, VD },
> + { "noref_gray", "Avoid using gray gap frames as references", OFFSET(noref_gray), AV_OPT_TYPE_INT, {.i64 = 1}, -1, 1, VD },
Should be AV_OPT_TYPE_BOOL, and there's no point allowing -1. That's
only useful for example when used with external modules as "use the
default from the external library".
> { NULL },
> };
>
> diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
> index 366626c056c..591769ab258 100644
> --- a/libavcodec/h264dec.h
> +++ b/libavcodec/h264dec.h
> @@ -571,6 +571,7 @@ typedef struct H264Context {
> int ref2frm[MAX_SLICES][2][64]; ///< reference to frame number lists, used in the loop filter, the first 2 are for -2,-1
>
> int non_gray; ///< Did we encounter a intra frame after a gray gap frame
> + int noref_gray;
> } H264Context;
>
> extern const uint16_t ff_h264_mb_sizes[4];
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [FFmpeg-devel] [PATCH 5/6] avcodec/h264: Avoid using gray gap frames as references
2023-11-21 12:27 ` James Almer
@ 2023-11-22 0:09 ` Michael Niedermayer
0 siblings, 0 replies; 14+ messages in thread
From: Michael Niedermayer @ 2023-11-22 0:09 UTC (permalink / raw)
To: FFmpeg development discussions and patches
[-- Attachment #1.1: Type: text/plain, Size: 2951 bytes --]
On Tue, Nov 21, 2023 at 09:27:59AM -0300, James Almer wrote:
> On 11/14/2023 2:20 PM, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > ---
> > libavcodec/h264_refs.c | 11 +++++++++++
> > libavcodec/h264dec.c | 1 +
> > libavcodec/h264dec.h | 1 +
> > 3 files changed, 13 insertions(+)
> >
> > diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
> > index 92778e737a5..9bc7b20988f 100644
> > --- a/libavcodec/h264_refs.c
> > +++ b/libavcodec/h264_refs.c
> > @@ -410,6 +410,17 @@ int ff_h264_build_ref_list(H264Context *h, H264SliceContext *sl)
> > else
> > return -1;
> > }
> > + if (h->noref_gray>0 && sl->ref_list[list][index].parent->gray && h->non_gray) {
> > + for (int j=0; j<sl->list_count; j++) {
> > + int list2 = (list+j)&1;
> > + if (h->default_ref[list2].parent && !h->default_ref[list2].parent->gray
> > + && !(!FIELD_PICTURE(h) && (h->default_ref[list2].reference&3) != 3)) {
> > + sl->ref_list[list][index] = h->default_ref[list2];
> > + av_log(h, AV_LOG_DEBUG, "replacement of gray gap frame\n");
> > + break;
> > + }
> > + }
> > + }
> > av_assert0(av_buffer_get_ref_count(sl->ref_list[list][index].parent->f->buf[0]) > 0);
> > }
> > }
> > diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> > index 7ea55db75dd..b48821db244 100644
> > --- a/libavcodec/h264dec.c
> > +++ b/libavcodec/h264dec.c
> > @@ -1091,6 +1091,7 @@ static const AVOption h264_options[] = {
> > { "nal_length_size", "nal_length_size", OFFSET(nal_length_size), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 4, VDX },
> > { "enable_er", "Enable error resilience on damaged frames (unsafe)", OFFSET(enable_er), AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, VD },
> > { "x264_build", "Assume this x264 version if no x264 version found in any SEI", OFFSET(x264_build), AV_OPT_TYPE_INT, {.i64 = -1}, -1, INT_MAX, VD },
> > + { "noref_gray", "Avoid using gray gap frames as references", OFFSET(noref_gray), AV_OPT_TYPE_INT, {.i64 = 1}, -1, 1, VD },
>
> Should be AV_OPT_TYPE_BOOL, and there's no point allowing -1. That's only
> useful for example when used with external modules as "use the default from
> the external library".
I was thinking that we may want to choose this depending on the detected
encoder when i wrote it. But as is, true it makes no sense ATM
I will change it
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 251 bytes --]
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 14+ messages in thread
* [FFmpeg-devel] [PATCH 6/6] avcodec/h264dec: Support skipping frames that used gray gap frames
2023-11-14 17:20 [FFmpeg-devel] [PATCH 1/6] avcodec/h264: Seperate SEI and IDR recovery handling Michael Niedermayer
` (3 preceding siblings ...)
2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 5/6] avcodec/h264: Avoid using gray gap frames as references Michael Niedermayer
@ 2023-11-14 17:20 ` Michael Niedermayer
2023-11-21 12:28 ` James Almer
4 siblings, 1 reply; 14+ messages in thread
From: Michael Niedermayer @ 2023-11-14 17:20 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
libavcodec/h264dec.c | 7 +++++++
libavcodec/h264dec.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index b48821db244..aa0022a3aba 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -939,6 +939,12 @@ static int finalize_frame(H264Context *h, AVFrame *dst, H264Picture *out, int *g
(h->avctx->flags2 & AV_CODEC_FLAG2_SHOW_ALL) ||
out->recovered)) {
+ if (h->skip_gray > 0 &&
+ h->non_gray && out->gray &&
+ !(h->avctx->flags2 & AV_CODEC_FLAG2_SHOW_ALL)
+ )
+ return 0;
+
if (!h->avctx->hwaccel &&
(out->field_poc[0] == INT_MAX ||
out->field_poc[1] == INT_MAX)
@@ -1091,6 +1097,7 @@ static const AVOption h264_options[] = {
{ "nal_length_size", "nal_length_size", OFFSET(nal_length_size), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 4, VDX },
{ "enable_er", "Enable error resilience on damaged frames (unsafe)", OFFSET(enable_er), AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, VD },
{ "x264_build", "Assume this x264 version if no x264 version found in any SEI", OFFSET(x264_build), AV_OPT_TYPE_INT, {.i64 = -1}, -1, INT_MAX, VD },
+ { "skip_gray", "Do not return gray gap frames", OFFSET(skip_gray), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1, VD },
{ "noref_gray", "Avoid using gray gap frames as references", OFFSET(noref_gray), AV_OPT_TYPE_INT, {.i64 = 1}, -1, 1, VD },
{ NULL },
};
diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
index 591769ab258..447c2499d97 100644
--- a/libavcodec/h264dec.h
+++ b/libavcodec/h264dec.h
@@ -572,6 +572,7 @@ typedef struct H264Context {
int non_gray; ///< Did we encounter a intra frame after a gray gap frame
int noref_gray;
+ int skip_gray;
} H264Context;
extern const uint16_t ff_h264_mb_sizes[4];
--
2.17.1
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [FFmpeg-devel] [PATCH 6/6] avcodec/h264dec: Support skipping frames that used gray gap frames
2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 6/6] avcodec/h264dec: Support skipping frames that used gray gap frames Michael Niedermayer
@ 2023-11-21 12:28 ` James Almer
0 siblings, 0 replies; 14+ messages in thread
From: James Almer @ 2023-11-21 12:28 UTC (permalink / raw)
To: ffmpeg-devel
On 11/14/2023 2:20 PM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
> libavcodec/h264dec.c | 7 +++++++
> libavcodec/h264dec.h | 1 +
> 2 files changed, 8 insertions(+)
>
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index b48821db244..aa0022a3aba 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -939,6 +939,12 @@ static int finalize_frame(H264Context *h, AVFrame *dst, H264Picture *out, int *g
> (h->avctx->flags2 & AV_CODEC_FLAG2_SHOW_ALL) ||
> out->recovered)) {
>
> + if (h->skip_gray > 0 &&
> + h->non_gray && out->gray &&
> + !(h->avctx->flags2 & AV_CODEC_FLAG2_SHOW_ALL)
> + )
> + return 0;
> +
> if (!h->avctx->hwaccel &&
> (out->field_poc[0] == INT_MAX ||
> out->field_poc[1] == INT_MAX)
> @@ -1091,6 +1097,7 @@ static const AVOption h264_options[] = {
> { "nal_length_size", "nal_length_size", OFFSET(nal_length_size), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 4, VDX },
> { "enable_er", "Enable error resilience on damaged frames (unsafe)", OFFSET(enable_er), AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, VD },
> { "x264_build", "Assume this x264 version if no x264 version found in any SEI", OFFSET(x264_build), AV_OPT_TYPE_INT, {.i64 = -1}, -1, INT_MAX, VD },
> + { "skip_gray", "Do not return gray gap frames", OFFSET(skip_gray), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1, VD },
Same here.
> { "noref_gray", "Avoid using gray gap frames as references", OFFSET(noref_gray), AV_OPT_TYPE_INT, {.i64 = 1}, -1, 1, VD },
> { NULL },
> };
> diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
> index 591769ab258..447c2499d97 100644
> --- a/libavcodec/h264dec.h
> +++ b/libavcodec/h264dec.h
> @@ -572,6 +572,7 @@ typedef struct H264Context {
>
> int non_gray; ///< Did we encounter a intra frame after a gray gap frame
> int noref_gray;
> + int skip_gray;
> } H264Context;
>
> extern const uint16_t ff_h264_mb_sizes[4];
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 14+ messages in thread