[FFmpeg-devel] [PATCH] avcodec/dovi_rpudec - correctly read el_bit_depth_minus8 when ext_mapping_idc is non-zero

[FFmpeg-devel] [PATCH] avcodec/dovi_rpudec - correctly read el_bit_depth_minus8 when ext_mapping_idc is non-zero

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean <cosmin@cosmin.at>

It looks like the el_bitdepth_minus8 value in the header can also encode
ext_mapping_idc in the upper 8 bits.

Samples having a non-zero ext_mapping_idc fail validation currently because the
value returned is out of range. This bypasses this by currently ignoring the
ext_mapping_idc and using only the lower 8 bits for el_bitdepth_minus8.

---
 libavcodec/dovi_rpudec.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
index 7c7eda9d09..1b11ad3640 100644
--- a/libavcodec/dovi_rpudec.c
+++ b/libavcodec/dovi_rpudec.c
@@ -411,7 +411,9 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, size_t rpu_size,
 
         if ((hdr->rpu_format & 0x700) == 0) {
             int bl_bit_depth_minus8 = get_ue_golomb_31(gb);
-            int el_bit_depth_minus8 = get_ue_golomb_31(gb);
+            // this can encode a two byte value, with higher byte being ext_mapping_idc
+            // use only the lower byte for el_bit_depth_minus8
+            uint8_t el_bit_depth_minus8 = get_ue_golomb_long(gb) & 0xFF;
             int vdr_bit_depth_minus8 = get_ue_golomb_31(gb);
             VALIDATE(bl_bit_depth_minus8, 0, 8);
             VALIDATE(el_bit_depth_minus8, 0, 8);
-- 
2.42.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".

Re: [FFmpeg-devel] [PATCH] avcodec/dovi_rpudec - correctly read el_bit_depth_minus8 when ext_mapping_idc is non-zero

[Andreas Rheinhardt]

Cosmin Stejerean via ffmpeg-devel:
> From: Cosmin Stejerean <cosmin@cosmin.at>
> 
> It looks like the el_bitdepth_minus8 value in the header can also encode
> ext_mapping_idc in the upper 8 bits.
> 
> Samples having a non-zero ext_mapping_idc fail validation currently because the
> value returned is out of range. This bypasses this by currently ignoring the
> ext_mapping_idc and using only the lower 8 bits for el_bitdepth_minus8.
> 
> ---
>  libavcodec/dovi_rpudec.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
> index 7c7eda9d09..1b11ad3640 100644
> --- a/libavcodec/dovi_rpudec.c
> +++ b/libavcodec/dovi_rpudec.c
> @@ -411,7 +411,9 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, size_t rpu_size,
>  
>          if ((hdr->rpu_format & 0x700) == 0) {
>              int bl_bit_depth_minus8 = get_ue_golomb_31(gb);
> -            int el_bit_depth_minus8 = get_ue_golomb_31(gb);
> +            // this can encode a two byte value, with higher byte being ext_mapping_idc
> +            // use only the lower byte for el_bit_depth_minus8
> +            uint8_t el_bit_depth_minus8 = get_ue_golomb_long(gb) & 0xFF;
>              int vdr_bit_depth_minus8 = get_ue_golomb_31(gb);
>              VALIDATE(bl_bit_depth_minus8, 0, 8);
>              VALIDATE(el_bit_depth_minus8, 0, 8);

So there is a field (ext_mapping_idc) in RPU that neither rpudec nor
rpuenc (nor dovi_meta.h) know about? In this case, we should disable the
encoding parts.

- Andreas

_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] avcodec/dovi_rpudec - correctly read el_bit_depth_minus8 when ext_mapping_idc is non-zero

[Niklas Haas]

On Tue, 21 May 2024 01:17:32 +0000 Cosmin Stejerean via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> From: Cosmin Stejerean <cosmin@cosmin.at>
> 
> It looks like the el_bitdepth_minus8 value in the header can also encode
> ext_mapping_idc in the upper 8 bits.
> 
> Samples having a non-zero ext_mapping_idc fail validation currently because the
> value returned is out of range. This bypasses this by currently ignoring the
> ext_mapping_idc and using only the lower 8 bits for el_bitdepth_minus8.

What is ext_mapping_idc? If it's signalled data that can't be
reconstructed, we need to store it somewhere into AVDOVIMetadata and
then re-synthesize it during encoding. Otherwise the RPU transcode will
be lossy.

> 
> ---
>  libavcodec/dovi_rpudec.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
> index 7c7eda9d09..1b11ad3640 100644
> --- a/libavcodec/dovi_rpudec.c
> +++ b/libavcodec/dovi_rpudec.c
> @@ -411,7 +411,9 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, size_t rpu_size,
>  
>          if ((hdr->rpu_format & 0x700) == 0) {
>              int bl_bit_depth_minus8 = get_ue_golomb_31(gb);
> -            int el_bit_depth_minus8 = get_ue_golomb_31(gb);
> +            // this can encode a two byte value, with higher byte being ext_mapping_idc
> +            // use only the lower byte for el_bit_depth_minus8
> +            uint8_t el_bit_depth_minus8 = get_ue_golomb_long(gb) & 0xFF;
>              int vdr_bit_depth_minus8 = get_ue_golomb_31(gb);
>              VALIDATE(bl_bit_depth_minus8, 0, 8);
>              VALIDATE(el_bit_depth_minus8, 0, 8);
> -- 
> 2.42.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".

Re: [FFmpeg-devel] [PATCH] avcodec/dovi_rpudec - correctly read el_bit_depth_minus8 when ext_mapping_idc is non-zero

[Cosmin Stejerean via ffmpeg-devel]

> On May 21, 2024, at 3:21 AM, Niklas Haas <ffmpeg@haasn.xyz> wrote:
> 
> On Tue, 21 May 2024 01:17:32 +0000 Cosmin Stejerean via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
>> From: Cosmin Stejerean <cosmin@cosmin.at>
>> 
>> It looks like the el_bitdepth_minus8 value in the header can also encode
>> ext_mapping_idc in the upper 8 bits.
>> 
>> Samples having a non-zero ext_mapping_idc fail validation currently because the
>> value returned is out of range. This bypasses this by currently ignoring the
>> ext_mapping_idc and using only the lower 8 bits for el_bitdepth_minus8.
> 
> What is ext_mapping_idc? If it's signalled data that can't be
> reconstructed, we need to store it somewhere into AVDOVIMetadata and
> then re-synthesize it during encoding. Otherwise the RPU transcode will
> be lossy.

I'm not actually sure what it does, but from what I can tell on the current samples it doesn't matter if in the process of transcoding it ends up being set to 0. However it's not hard to save it and re-synthesize it so I can send a new patch that does that.

- Cosmin
_______________________________________________
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] [PATCH] avcodec/libsvtav1: send the EOS signal without a one frame delay to allow for the library to operate in a low-delay mode

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean <cosmin@cosmin.at>

Co-authored-by: Amir Naghdinezhad <amir.naghdinezhad@intel.com>
Signed-off-by: Cosmin Stejerean <cosmin@cosmin.at>
---
 libavcodec/libsvtav1.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 3b41f5a39e..1eda63200c 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -539,6 +539,14 @@ static int eb_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
     if (svt_ret == EB_NoErrorEmptyQueue)
         return AVERROR(EAGAIN);
 
+#if SVT_AV1_CHECK_VERSION(2, 0, 0)
+    if (headerPtr->flags & EB_BUFFERFLAG_EOS) {
+         svt_enc->eos_flag = EOS_RECEIVED;
+         svt_av1_enc_release_out_buffer(&headerPtr);
+         return AVERROR_EOF;
+    }
+#endif
+
     ref = get_output_ref(avctx, svt_enc, headerPtr->n_filled_len);
     if (!ref) {
         av_log(avctx, AV_LOG_ERROR, "Failed to allocate output packet.\n");
@@ -573,8 +581,10 @@ static int eb_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
     if (headerPtr->pic_type == EB_AV1_NON_REF_PICTURE)
         pkt->flags |= AV_PKT_FLAG_DISPOSABLE;
 
+#if !(SVT_AV1_CHECK_VERSION(2, 0, 0))
     if (headerPtr->flags & EB_BUFFERFLAG_EOS)
         svt_enc->eos_flag = EOS_RECEIVED;
+#endif
 
     ff_side_data_set_encoder_stats(pkt, headerPtr->qp * FF_QP2LAMBDA, NULL, 0, pict_type);
 
-- 
2.42.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".

Re: [FFmpeg-devel] [PATCH] avcodec/libsvtav1: send the EOS signal without a one frame delay to allow for the library to operate in a low-delay mode

[Cosmin Stejerean via ffmpeg-devel]

> On May 20, 2024, at 6:17 PM, Cosmin Stejerean via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> 
> From: Cosmin Stejerean <cosmin@cosmin.at>
> 
> Co-authored-by: Amir Naghdinezhad <amir.naghdinezhad@intel.com>
> Signed-off-by: Cosmin Stejerean <cosmin@cosmin.at>
> ---
> libavcodec/libsvtav1.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
> 

Disregard this one, it was previously applied. It was left over in my patches folder by mistake and git send-email picked it up again.

- Cosmin


_______________________________________________
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] [PATCH] avcodec/libsvtav1: send the EOS signal without a one frame delay to allow for the library to operate in a low-delay mode

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean <cosmin@cosmin.at>

Co-authored-by: Amir Naghdinezhad <amir.naghdinezhad@intel.com>
Signed-off-by: Cosmin Stejerean <cosmin@cosmin.at>
---
 libavcodec/libsvtav1.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 3b41f5a39e..1eda63200c 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -539,6 +539,14 @@ static int eb_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
     if (svt_ret == EB_NoErrorEmptyQueue)
         return AVERROR(EAGAIN);
 
+#if SVT_AV1_CHECK_VERSION(2, 0, 0)
+    if (headerPtr->flags & EB_BUFFERFLAG_EOS) {
+         svt_enc->eos_flag = EOS_RECEIVED;
+         svt_av1_enc_release_out_buffer(&headerPtr);
+         return AVERROR_EOF;
+    }
+#endif
+
     ref = get_output_ref(avctx, svt_enc, headerPtr->n_filled_len);
     if (!ref) {
         av_log(avctx, AV_LOG_ERROR, "Failed to allocate output packet.\n");
@@ -573,8 +581,10 @@ static int eb_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
     if (headerPtr->pic_type == EB_AV1_NON_REF_PICTURE)
         pkt->flags |= AV_PKT_FLAG_DISPOSABLE;
 
+#if !(SVT_AV1_CHECK_VERSION(2, 0, 0))
     if (headerPtr->flags & EB_BUFFERFLAG_EOS)
         svt_enc->eos_flag = EOS_RECEIVED;
+#endif
 
     ff_side_data_set_encoder_stats(pkt, headerPtr->qp * FF_QP2LAMBDA, NULL, 0, pict_type);
 
-- 
2.42.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".

Re: [FFmpeg-devel] [PATCH] avcodec/libsvtav1: send the EOS signal without a one frame delay to allow for the library to operate in a low-delay mode

[James Almer]

On 2/23/2024 8:21 PM, Cosmin Stejerean via ffmpeg-devel wrote:
> From: Cosmin Stejerean <cosmin@cosmin.at>
> 
> Co-authored-by: Amir Naghdinezhad <amir.naghdinezhad@intel.com>
> Signed-off-by: Cosmin Stejerean <cosmin@cosmin.at>
> ---
>   libavcodec/libsvtav1.c | 10 ++++++++++
>   1 file changed, 10 insertions(+)
> 
> diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
> index 3b41f5a39e..1eda63200c 100644
> --- a/libavcodec/libsvtav1.c
> +++ b/libavcodec/libsvtav1.c
> @@ -539,6 +539,14 @@ static int eb_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
>       if (svt_ret == EB_NoErrorEmptyQueue)
>           return AVERROR(EAGAIN);
>   
> +#if SVT_AV1_CHECK_VERSION(2, 0, 0)

SVT-AV1 1.8.0 has this value set to 1.8.0, same as in the current git 
head commit. Is this in preparation for an upcoming release?

> +    if (headerPtr->flags & EB_BUFFERFLAG_EOS) {
> +         svt_enc->eos_flag = EOS_RECEIVED;
> +         svt_av1_enc_release_out_buffer(&headerPtr);
> +         return AVERROR_EOF;
> +    }
> +#endif
> +
>       ref = get_output_ref(avctx, svt_enc, headerPtr->n_filled_len);
>       if (!ref) {
>           av_log(avctx, AV_LOG_ERROR, "Failed to allocate output packet.\n");
> @@ -573,8 +581,10 @@ static int eb_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
>       if (headerPtr->pic_type == EB_AV1_NON_REF_PICTURE)
>           pkt->flags |= AV_PKT_FLAG_DISPOSABLE;
>   
> +#if !(SVT_AV1_CHECK_VERSION(2, 0, 0))
>       if (headerPtr->flags & EB_BUFFERFLAG_EOS)
>           svt_enc->eos_flag = EOS_RECEIVED;
> +#endif
>   
>       ff_side_data_set_encoder_stats(pkt, headerPtr->qp * FF_QP2LAMBDA, NULL, 0, pict_type);
>   
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] avcodec/libsvtav1: send the EOS signal without a one frame delay to allow for the library to operate in a low-delay mode

[Cosmin Stejerean via ffmpeg-devel]

> On Feb 27, 2024, at 1:19 PM, James Almer <jamrial@gmail.com> wrote:
> 
> SVT-AV1 1.8.0 has this value set to 1.8.0, same as in the current git head commit. Is this in preparation for an upcoming release?

Yes, this is in preparation for release 2.0 which is targeted for next week. https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2155 is tracking the status, and this API change is one of the outstanding items.

- Cosmin
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] avcodec/libsvtav1: send the EOS signal without a one frame delay to allow for the library to operate in a low-delay mode

[James Almer]

On 2/27/2024 6:36 PM, Cosmin Stejerean via ffmpeg-devel wrote:
> 
> 
>> On Feb 27, 2024, at 1:19 PM, James Almer <jamrial@gmail.com> wrote:
>>
>> SVT-AV1 1.8.0 has this value set to 1.8.0, same as in the current git head commit. Is this in preparation for an upcoming release?
> 
> Yes, this is in preparation for release 2.0 which is targeted for next week. https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2155 is tracking the status, and this API change is one of the outstanding items.

Without this patch, the command "ffmpeg -lavfi testsrc,format=yuv420p 
-vframes 101 -c:v libsvtav1 -loglevel debug -f null -" gives this:

> Output stream #0:0 (video): 101 frames encoded; 101 packets muxed (17890 bytes);
> Total: 101 packets (17890 bytes) muxed
> frame=  101 fps=0.0 q=31.0 Lsize=N/A time=00:00:04.00 bitrate=N/A

Whereas with it applied, i get:

> Output stream #0:0 (video): 101 frames encoded; 100 packets muxed (17885 bytes);
> Total: 100 packets (17885 bytes) muxed
> frame=  100 fps=0.0 q=35.0 Lsize=N/A time=00:00:03.96 bitrate=N/A

If i pass it a single frame, i get no output at all. So the last frame 
is being lost.
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] avcodec/libsvtav1: send the EOS signal without a one frame delay to allow for the library to operate in a low-delay mode

[Cosmin Stejerean via ffmpeg-devel]

> On Feb 27, 2024, at 1:49 PM, James Almer <jamrial@gmail.com> wrote:
> 
>>> SVT-AV1 1.8.0 has this value set to 1.8.0, same as in the current git head commit. Is this in preparation for an upcoming release?
>> Yes, this is in preparation for release 2.0 which is targeted for next week. https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2155 is tracking the status, and this API change is one of the outstanding items.
> 
> Without this patch, the command "ffmpeg -lavfi testsrc,format=yuv420p -vframes 101 -c:v libsvtav1 -loglevel debug -f null -" gives this:
> 
>> Output stream #0:0 (video): 101 frames encoded; 101 packets muxed (17890 bytes);
>> Total: 101 packets (17890 bytes) muxed
>> frame=  101 fps=0.0 q=31.0 Lsize=N/A time=00:00:04.00 bitrate=N/A
> 
> Whereas with it applied, i get:
> 
>> Output stream #0:0 (video): 101 frames encoded; 100 packets muxed (17885 bytes);
>> Total: 100 packets (17885 bytes) muxed
>> frame=  100 fps=0.0 q=35.0 Lsize=N/A time=00:00:03.96 bitrate=N/A
> 
> If i pass it a single frame, i get no output at all. So the last frame is being lost.

This change depends on the API change on the SVT-AV1 side, which is in in https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2189

This will get merged in shortly as part of the 2.0 release. If I build this patch against the low-delay-api-change branch (from PR 2189) then I get 

> Output stream #0:0 (video): 101 frames encoded; 101 packets muxed (17970 bytes);
> Total: 101 packets (17970 bytes) muxed


- Cosmin
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] avcodec/libsvtav1: send the EOS signal without a one frame delay to allow for the library to operate in a low-delay mode

[James Almer]

On 2/27/2024 7:22 PM, Cosmin Stejerean via ffmpeg-devel wrote:
> 
> 
>> On Feb 27, 2024, at 1:49 PM, James Almer <jamrial@gmail.com> wrote:
>>
>>>> SVT-AV1 1.8.0 has this value set to 1.8.0, same as in the current git head commit. Is this in preparation for an upcoming release?
>>> Yes, this is in preparation for release 2.0 which is targeted for next week. https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2155 is tracking the status, and this API change is one of the outstanding items.
>>
>> Without this patch, the command "ffmpeg -lavfi testsrc,format=yuv420p -vframes 101 -c:v libsvtav1 -loglevel debug -f null -" gives this:
>>
>>> Output stream #0:0 (video): 101 frames encoded; 101 packets muxed (17890 bytes);
>>> Total: 101 packets (17890 bytes) muxed
>>> frame=  101 fps=0.0 q=31.0 Lsize=N/A time=00:00:04.00 bitrate=N/A
>>
>> Whereas with it applied, i get:
>>
>>> Output stream #0:0 (video): 101 frames encoded; 100 packets muxed (17885 bytes);
>>> Total: 100 packets (17885 bytes) muxed
>>> frame=  100 fps=0.0 q=35.0 Lsize=N/A time=00:00:03.96 bitrate=N/A
>>
>> If i pass it a single frame, i get no output at all. So the last frame is being lost.
> 
> This change depends on the API change on the SVT-AV1 side, which is in in https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2189
> 
> This will get merged in shortly as part of the 2.0 release. If I build this patch against the low-delay-api-change branch (from PR 2189) then I get
> 
>> Output stream #0:0 (video): 101 frames encoded; 101 packets muxed (17970 bytes);
>> Total: 101 packets (17970 bytes) muxed

Yes, i can confirm it works after applying !2189.

Will apply then. Thanks.
_______________________________________________
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".