Re: [FFmpeg-devel] [PATCH v2] ffmpeg: allow full range of dts_delta_threshold

[Gyan Doshi]

On 15-04-2020 01:33 am, Michael Niedermayer wrote:

On Tue, Apr 14, 2020 at 02:48:47PM +0530, Gyan Doshi wrote:

For inputs from demuxers with AVFMT_TS_DISCONT flag,
the existing condition,

   delta < -1LL*dts_delta_threshold*AV_TIME_BASE

is rendered superflous due to the fixed threshold in

pkt_dts + AV_TIME_BASE/10 < FFMAX(ist->pts, ist->dts)

This prevents users from setting a high threshold to
avoid discontinuity correction due to errant timestamps.

Now, the maximum of the two thresholds is used.

fate-mpeg4-resolution-change call changed to preserve existing
timestamp correction by ffmpeg.c
---
Tested with multiple satellite MPEG-TS inputs.

  fftools/ffmpeg.c | 2 +-
  tests/fate/mpeg4.mak | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

breaks:
./ffmpeg -i 'concat:angels.mpg|angels.mpg'  -vsync 0  file.avi

...
frame=   24 fps=0.0 q=12.5 Lsize= 215kB time=00:00:07.50 bitrate= 
234.7kbits/s speed=75.5x
video:84kB audio:110kB subtitle:0kB other streams:0kB global headers:0kB muxing 
overhead: 10.697786%

vs.

...
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 219, 
current: 86; changing to 220. This may result in incorrect timestamps in the 
output file.
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 220, 
current: 87; changing to 221. This may result in incorrect timestamps in the 
output file.
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 221, 
current: 88; changing to 222. This may result in incorrect timestamps in the 
output file.
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 222, 
current: 89; changing to 223. This may result in incorrect timestamps in the 
output file.
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 223, 
current: 90; changing to 224. This may result in incorrect timestamps in the 
output file.
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 224, 
current: 91; changing to 225. This may result in incorrect timestamps in the 
output file.
[mpeg4 @ 0x5601cac87540] Invalid pts (72) <= last (83)
Video encoding failed


Yes, if the input includes a mid-stream dts reset of gap less than the 
default value of dts_delta_threshold then timestamps won't be made 
continuous. Default value is 10 seconds but till now it wasn't enforced 
for negative jumps, so your command worked. With this change, user will 
have to set it manually if they expect smaller jumps.


What can be done is to set the default value to 0, and then set separate 
values for positive and negative jumps inside the block to keep current 
behaviour. If user-set to non-zero, then the user's value is honoured.


Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3 5/9] lavc/libopenh264enc: set slice_mode option to deprecated

[Fu, Linjie]

> From: ffmpeg-devel  On Behalf Of
> Anton Khirnov
> Sent: Tuesday, April 14, 2020 19:11
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v3 5/9] lavc/libopenh264enc: set
> slice_mode option to deprecated
> 
> Quoting Linjie Fu (2020-04-11 12:03:35)
> > "slice mode" seems to be unnecessary since it could be determined by
> > -slices/max_nal_size.
> >
> > default:SM_FIXEDSLCNUM_SLICE mode with cpu-number slices.
> > -slices N:  SM_FIXEDSLCNUM_SLICE mode with N slices.
> > -max_nal_size:  SM_SIZELIMITED_SLICE mode with limited size slices.
> >
> > Add OPENH264_API_SLICE_MODE to remove this option after
> > LIBAVCODEC_VERSION_MAJOR = 59.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/libopenh264enc.c | 15 ---
> >  1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
> > index e556f03..3a642f0 100644
> > --- a/libavcodec/libopenh264enc.c
> > +++ b/libavcodec/libopenh264enc.c
> > @@ -33,6 +33,10 @@
> >  #include "internal.h"
> >  #include "libopenh264.h"
> >
> > +#ifndef OPENH264_API_SLICE_MODE
> > +#define OPENH264_API_SLICE_MODE
> (LIBAVCODEC_VERSION_MAJOR < 59)
> > +#endif
> 
> This should be moved to libavcodec/version.h with an FF_ prefix, so that
> it's not overlooked when we bump the version.

Moved the macro to version.h and resend the whole patch set as V4.
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1586926427-20170-6-git-send-email-linjie...@intel.com/
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1586926427-20170-10-git-send-email-linjie...@intel.com/

 
> Otherwise looks ok

Thanks for the review.

- Linjie
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 7/9] lavc/libopenh264enc: add profile high option support

[Linjie Fu]

Add support for PRO_HIGH/PRO_BASELINE in SVC Encoding extention mode,
which determined by iEntropyCodingModeFlag in ParamTranscode().



Signed-off-by: Linjie Fu 
---
 libavcodec/libopenh264enc.c | 32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index a7c389e..0fe8cf4 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -42,7 +42,7 @@ typedef struct SVCContext {
 ISVCEncoder *encoder;
 int slice_mode;
 int loopfilter;
-char *profile;
+int profile;
 int max_nal_size;
 int skip_frames;
 int skipped;
@@ -73,7 +73,11 @@ static const AVOption options[] = {
 #endif
 #endif
 { "loopfilter", "enable loop filter", OFFSET(loopfilter), AV_OPT_TYPE_INT, 
{ .i64 = 1 }, 0, 1, VE },
-{ "profile", "set profile restrictions", OFFSET(profile), 
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VE },
+{ "profile", "Set profile restrictions", OFFSET(profile), AV_OPT_TYPE_INT, 
{ .i64 = FF_PROFILE_UNKNOWN }, FF_PROFILE_UNKNOWN, 0x, VE, "profile" },
+#define PROFILE(name, value)  name, NULL, 0, AV_OPT_TYPE_CONST, { .i64 = value 
}, 0, 0, VE, "profile"
+{ PROFILE("constrained_baseline", 
FF_PROFILE_H264_CONSTRAINED_BASELINE) },
+{ PROFILE("high", FF_PROFILE_H264_HIGH) },
+#undef PROFILE
 { "max_nal_size", "set maximum NAL size in bytes", OFFSET(max_nal_size), 
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
 { "allow_skip_frames", "allow skipping frames to hit the target bitrate", 
OFFSET(skip_frames), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
 { "cabac", "Enable cabac", OFFSET(cabac), AV_OPT_TYPE_INT, { .i64 = 0 }, 
0, 1, VE },
@@ -109,12 +113,28 @@ static av_cold int svc_encode_init_profile(AVCodecContext 
*avctx, SEncParamExt *
 {
 SVCContext *s = avctx->priv_data;
 
-if (s->profile && !strcmp(s->profile, "main"))
-param->iEntropyCodingModeFlag = 1; //< 0:CAVLC  1:CABAC
-else if (!s->profile && s->cabac)
+if (s->profile == FF_PROFILE_UNKNOWN)
+s->profile = s->cabac ? FF_PROFILE_H264_HIGH :
+FF_PROFILE_H264_CONSTRAINED_BASELINE;
+
+switch (s->profile) {
+case FF_PROFILE_H264_HIGH:
 param->iEntropyCodingModeFlag = 1;
-else
+av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
+   "select EProfileIdc PRO_HIGH in libopenh264.\n");
+break;
+case FF_PROFILE_H264_CONSTRAINED_BASELINE:
+case FF_PROFILE_UNKNOWN:
+param->iEntropyCodingModeFlag = 0;
+av_log(avctx, AV_LOG_VERBOSE, "Using CAVLC, "
+   "select EProfileIdc PRO_BASELINE in libopenh264.\n");
+break;
+default:
 param->iEntropyCodingModeFlag = 0;
+av_log(avctx, AV_LOG_WARNING, "Unsupported profile, "
+   "select EProfileIdc PRO_BASELINE in libopenh264.\n");
+break;
+}
 
 return 0;
 }
-- 
2.7.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-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 4/9] lavc/libopenh264enc: prompt slice number changing inside libopenh264

[Linjie Fu]

Libopenh264enc would set the slice according to the number of cpu cores
if uiSliceNum equals to 0 (auto) in SM_FIXEDSLCNUM_SLICE mode.

Prompt a warning for user to catch this.

Signed-off-by: Linjie Fu 
---
 libavcodec/libopenh264enc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index f994f95..e556f03 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -237,6 +237,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
 param.sSpatialLayers[0].sSliceCfg.uiSliceMode   = 
s->slice_mode;
 param.sSpatialLayers[0].sSliceCfg.sSliceArgument.uiSliceNum = 
avctx->slices;
 #endif
+if (avctx->slices == 0 && s->slice_mode == SM_FIXEDSLCNUM_SLICE)
+av_log(avctx, AV_LOG_WARNING, "Slice count will be set 
automatically\n");
 
 if (s->slice_mode == SM_SIZELIMITED_SLICE) {
 if (s->max_nal_size) {
-- 
2.7.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-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 3/9] lavc/libopenh264enc: add bit rate control select support

[Linjie Fu]

RC_BITRATE_MODE:
set BITS_EXCEEDED to iCurrentBitsLevel and allows QP adjust
in RcCalculatePictureQp().

RC_BUFFERBASED_MODE:
use buffer status to adjust the video quality.

RC_TIMESTAMP_MODE:
bit rate control based on timestamp.

Default to use RC_QUALITY_MODE.

Signed-off-by: Linjie Fu 
---
 libavcodec/libopenh264enc.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 57313b1..f994f95 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -47,6 +47,9 @@ typedef struct SVCContext {
 int skip_frames;
 int skipped;
 int cabac;
+
+// rate control mode
+int rc_mode;
 } SVCContext;
 
 #define OFFSET(x) offsetof(SVCContext, x)
@@ -71,6 +74,13 @@ static const AVOption options[] = {
 { "max_nal_size", "set maximum NAL size in bytes", OFFSET(max_nal_size), 
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
 { "allow_skip_frames", "allow skipping frames to hit the target bitrate", 
OFFSET(skip_frames), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
 { "cabac", "Enable cabac", OFFSET(cabac), AV_OPT_TYPE_INT, { .i64 = 0 }, 
0, 1, VE },
+
+{ "rc_mode", "Select rate control mode", OFFSET(rc_mode), AV_OPT_TYPE_INT, 
{ .i64 = RC_QUALITY_MODE }, RC_OFF_MODE, RC_TIMESTAMP_MODE, VE, "rc_mode" },
+{ "off",   "bit rate control off", 
0, AV_OPT_TYPE_CONST, { .i64 = RC_OFF_MODE }, 0, 0, VE, 
"rc_mode" },
+{ "quality",   "quality mode", 
0, AV_OPT_TYPE_CONST, { .i64 = RC_QUALITY_MODE }, 0, 0, VE, 
"rc_mode" },
+{ "bitrate",   "bitrate mode", 
0, AV_OPT_TYPE_CONST, { .i64 = RC_BITRATE_MODE }, 0, 0, VE, 
"rc_mode" },
+{ "buffer","using buffer status to adjust the video quality (no 
bitrate control)", 0, AV_OPT_TYPE_CONST, { .i64 = RC_BUFFERBASED_MODE }, 0, 0, 
VE, "rc_mode" },
+{ "timestamp", "bit rate control based on timestamp",  
0, AV_OPT_TYPE_CONST, { .i64 = RC_TIMESTAMP_MODE },   0, 0, VE, 
"rc_mode" },
 { NULL }
 };
 
@@ -134,7 +144,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 param.iPicHeight = avctx->height;
 param.iTargetBitrate = avctx->bit_rate > 0 ? avctx->bit_rate : 
2*1000*1000;
 param.iMaxBitrate= FFMAX(avctx->rc_max_rate, 
avctx->bit_rate);
-param.iRCMode= RC_QUALITY_MODE;
+param.iRCMode= s->rc_mode;
 // QP = 0 is not well supported, so default to (1, 51)
 param.iMaxQp = avctx->qmax >= 0 ? av_clip(avctx->qmax, 
1, 51) : 51;
 param.iMinQp = avctx->qmin >= 0 ? av_clip(avctx->qmin, 
1, param.iMaxQp) : 1;
-- 
2.7.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-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 6/9] lavc/libopenh264enc: separate svc_encode_init() into several functions

[Linjie Fu]

Separate the initialization procedure into different functions.

Make it more readable and easier to be extended.

Signed-off-by: Linjie Fu 
---
 libavcodec/libopenh264enc.c | 283 +++-
 1 file changed, 174 insertions(+), 109 deletions(-)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 89f3cc0..a7c389e 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -105,120 +105,51 @@ static av_cold int svc_encode_close(AVCodecContext 
*avctx)
 return 0;
 }
 
-static av_cold int svc_encode_init(AVCodecContext *avctx)
+static av_cold int svc_encode_init_profile(AVCodecContext *avctx, SEncParamExt 
*param)
 {
 SVCContext *s = avctx->priv_data;
-SEncParamExt param = { 0 };
-int err;
-int log_level;
-WelsTraceCallback callback_function;
-AVCPBProperties *props;
 
-if ((err = ff_libopenh264_check_version(avctx)) < 0)
-return err;
+if (s->profile && !strcmp(s->profile, "main"))
+param->iEntropyCodingModeFlag = 1; //< 0:CAVLC  1:CABAC
+else if (!s->profile && s->cabac)
+param->iEntropyCodingModeFlag = 1;
+else
+param->iEntropyCodingModeFlag = 0;
 
-if (WelsCreateSVCEncoder(>encoder)) {
-av_log(avctx, AV_LOG_ERROR, "Unable to create encoder\n");
-return AVERROR_UNKNOWN;
-}
+return 0;
+}
 
-// Pass all libopenh264 messages to our callback, to allow ourselves to 
filter them.
-log_level = WELS_LOG_DETAIL;
-(*s->encoder)->SetOption(s->encoder, ENCODER_OPTION_TRACE_LEVEL, 
_level);
+static av_cold int svc_encode_init_rate_control(AVCodecContext *avctx, 
SEncParamExt *param)
+{
+SVCContext *s = avctx->priv_data;
 
-// Set the logging callback function to one that uses av_log() (see 
implementation above).
-callback_function = (WelsTraceCallback) ff_libopenh264_trace_callback;
-(*s->encoder)->SetOption(s->encoder, ENCODER_OPTION_TRACE_CALLBACK, 
_function);
+/* Rate Control */
+param->iRCMode= s->rc_mode;
 
-// Set the AVCodecContext as the libopenh264 callback context so that it 
can be passed to av_log().
-(*s->encoder)->SetOption(s->encoder, 
ENCODER_OPTION_TRACE_CALLBACK_CONTEXT, );
+param->iTargetBitrate = avctx->bit_rate > 0 ? avctx->bit_rate 
: 2*1000*1000;
+param->iMaxBitrate= FFMAX(avctx->rc_max_rate, 
avctx->bit_rate);
+param->bEnableFrameSkip   = s->skip_frames;
 
-(*s->encoder)->GetDefaultParams(s->encoder, );
+// QP = 0 is not well supported, so default to (1, 51)
+param->iMaxQp = avctx->qmax >= 0 ? 
av_clip(avctx->qmax, 1, 51) : 51;
+param->iMinQp = avctx->qmin >= 0 ? 
av_clip(avctx->qmin, 1, param->iMaxQp) : 1;
+param->bEnableAdaptiveQuant   = 1;
 
-#if FF_API_CODER_TYPE
-FF_DISABLE_DEPRECATION_WARNINGS
-if (!s->cabac)
-s->cabac = avctx->coder_type == FF_CODER_TYPE_AC;
-FF_ENABLE_DEPRECATION_WARNINGS
-#endif
+param->iSpatialLayerNum   = 1;  // Number of 
dependency(Spatial/CGS) layers used to be encoded
+param->iTemporalLayerNum  = 1;  // Number of temporal layer 
specified
 
-param.fMaxFrameRate  = 1/av_q2d(avctx->time_base);
-param.iPicWidth  = avctx->width;
-param.iPicHeight = avctx->height;
-param.iTargetBitrate = avctx->bit_rate > 0 ? avctx->bit_rate : 
2*1000*1000;
-param.iMaxBitrate= FFMAX(avctx->rc_max_rate, 
avctx->bit_rate);
-param.iRCMode= s->rc_mode;
-// QP = 0 is not well supported, so default to (1, 51)
-param.iMaxQp = avctx->qmax >= 0 ? av_clip(avctx->qmax, 
1, 51) : 51;
-param.iMinQp = avctx->qmin >= 0 ? av_clip(avctx->qmin, 
1, param.iMaxQp) : 1;
-param.iTemporalLayerNum  = 1;
-param.iSpatialLayerNum   = 1;
-param.bEnableDenoise = 0;
-param.bEnableBackgroundDetection = 1;
-param.bEnableAdaptiveQuant   = 1;
-param.bEnableFrameSkip   = s->skip_frames;
-param.bEnableLongTermReference   = 0;
-param.iLtrMarkPeriod = 30;
-param.uiIntraPeriod  = avctx->gop_size;
-#if OPENH264_VER_AT_LEAST(1, 4)
-param.eSpsPpsIdStrategy  = CONSTANT_ID;
-#else
-param.bEnableSpsPpsIdAddition= 0;
-#endif
-param.bPrefixNalAddingCtrl   = 0;
-param.iLoopFilterDisableIdc  = !s->loopfilter;
-param.iEntropyCodingModeFlag = 0;
-param.iMultipleThreadIdc = avctx->thread_count;
-if (s->profile && !strcmp(s->profile, "main"))
-param.iEntropyCodingModeFlag = 1;
-else if (!s->profile && s->cabac)
-param.iEntropyCodingModeFlag = 1;
+param->bEnableDenoise = 0;  // Denoise control
+param->bEnableBackgroundDetection = 1;  // Background detection control
 
-

[FFmpeg-devel] [PATCH v4 8/9] lavc/libopenh264enc: allow specifying the profile through AVCodecContext

[Linjie Fu]

Signed-off-by: Linjie Fu 
---
 libavcodec/libopenh264enc.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 0fe8cf4..4d337d2 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -113,6 +113,22 @@ static av_cold int svc_encode_init_profile(AVCodecContext 
*avctx, SEncParamExt *
 {
 SVCContext *s = avctx->priv_data;
 
+/* Allow specifying the libopenh264 profile through AVCodecContext. */
+if (FF_PROFILE_UNKNOWN == s->profile &&
+FF_PROFILE_UNKNOWN != avctx->profile)
+switch (avctx->profile) {
+case FF_PROFILE_H264_CONSTRAINED_BASELINE:
+s->profile = FF_PROFILE_H264_CONSTRAINED_BASELINE;
+break;
+case FF_PROFILE_H264_HIGH:
+s->profile = FF_PROFILE_H264_HIGH;
+break;
+default:
+av_log(avctx, AV_LOG_WARNING,
+   "Unsupported avctx->profile: %d.\n", avctx->profile);
+break;
+}
+
 if (s->profile == FF_PROFILE_UNKNOWN)
 s->profile = s->cabac ? FF_PROFILE_H264_HIGH :
 FF_PROFILE_H264_CONSTRAINED_BASELINE;
-- 
2.7.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-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 5/9] lavc/libopenh264enc: set slice_mode option to deprecated

[Linjie Fu]

"slice mode" option seems to be unnecessary since it could be
determined by -slices/max_nal_size.

default:SM_FIXEDSLCNUM_SLICE mode with cpu-number slices.
-slices N:  SM_FIXEDSLCNUM_SLICE mode with N slices.
-max_nal_size:  SM_SIZELIMITED_SLICE mode with limited size slices.

Add FF_API_OPENH264_SLICE_MODE macro to remove this option after
LIBAVCODEC_VERSION_MAJOR = 59.

Signed-off-by: Linjie Fu 
---
 libavcodec/libopenh264enc.c | 7 +--
 libavcodec/version.h| 3 +++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index e556f03..89f3cc0 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -54,11 +54,13 @@ typedef struct SVCContext {
 
 #define OFFSET(x) offsetof(SVCContext, x)
 #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
+#define DEPRECATED AV_OPT_FLAG_DEPRECATED
 static const AVOption options[] = {
+#if FF_API_OPENH264_SLICE_MODE
 #if OPENH264_VER_AT_LEAST(1, 6)
-{ "slice_mode", "set slice mode", OFFSET(slice_mode), AV_OPT_TYPE_INT, { 
.i64 = SM_FIXEDSLCNUM_SLICE }, SM_SINGLE_SLICE, SM_RESERVED, VE, "slice_mode" },
+{ "slice_mode", "set slice mode, use slices/max_nal_size", 
OFFSET(slice_mode), AV_OPT_TYPE_INT, { .i64 = SM_FIXEDSLCNUM_SLICE }, 
SM_SINGLE_SLICE, SM_RESERVED, VE|DEPRECATED, "slice_mode" },
 #else
-{ "slice_mode", "set slice mode", OFFSET(slice_mode), AV_OPT_TYPE_INT, { 
.i64 = SM_AUTO_SLICE }, SM_SINGLE_SLICE, SM_RESERVED, VE, "slice_mode" },
+{ "slice_mode", "set slice mode, use slices/max_nal_size", 
OFFSET(slice_mode), AV_OPT_TYPE_INT, { .i64 = SM_AUTO_SLICE }, SM_SINGLE_SLICE, 
SM_RESERVED, VE|DEPRECATED, "slice_mode" },
 #endif
 { "fixed", "a fixed number of slices", 0, AV_OPT_TYPE_CONST, { .i64 = 
SM_FIXEDSLCNUM_SLICE }, 0, 0, VE, "slice_mode" },
 #if OPENH264_VER_AT_LEAST(1, 6)
@@ -69,6 +71,7 @@ static const AVOption options[] = {
 { "auto", "automatic number of slices according to number of threads", 
0, AV_OPT_TYPE_CONST, { .i64 = SM_AUTO_SLICE }, 0, 0, VE, "slice_mode" },
 { "dyn", "Dynamic slicing", 0, AV_OPT_TYPE_CONST, { .i64 = 
SM_DYN_SLICE }, 0, 0, VE, "slice_mode" },
 #endif
+#endif
 { "loopfilter", "enable loop filter", OFFSET(loopfilter), AV_OPT_TYPE_INT, 
{ .i64 = 1 }, 0, 1, VE },
 { "profile", "set profile restrictions", OFFSET(profile), 
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VE },
 { "max_nal_size", "set maximum NAL size in bytes", OFFSET(max_nal_size), 
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 278f6be..83075e4 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -135,6 +135,9 @@
 #ifndef FF_API_UNSANITIZED_BITRATES
 #define FF_API_UNSANITIZED_BITRATES (LIBAVCODEC_VERSION_MAJOR < 59)
 #endif
+#ifndef FF_API_OPENH264_SLICE_MODE
+#define FF_API_OPENH264_SLICE_MODE (LIBAVCODEC_VERSION_MAJOR < 59)
+#endif
 
 
 #endif /* AVCODEC_VERSION_H */
-- 
2.7.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-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 9/9] lavc/libopenh264enc: Add coder option to replace cabac

[Linjie Fu]

Set DEPRECATED flag to option cabac, replace with coder.

Change the default option to -1 and allow the default cabac to be
determined by profile.

Add FF_API_OPENH264_CABAC macro for cabac to remove this option after
LIBAVCODEC_VERSION_MAJOR = 59.

Signed-off-by: Linjie Fu 
---
 libavcodec/libopenh264enc.c | 35 ---
 libavcodec/version.h|  3 +++
 2 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 4d337d2..6b7aa87 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -46,7 +46,10 @@ typedef struct SVCContext {
 int max_nal_size;
 int skip_frames;
 int skipped;
-int cabac;
+#if FF_API_OPENH264_CABAC
+int cabac;  // deprecated
+#endif
+int coder;
 
 // rate control mode
 int rc_mode;
@@ -80,7 +83,15 @@ static const AVOption options[] = {
 #undef PROFILE
 { "max_nal_size", "set maximum NAL size in bytes", OFFSET(max_nal_size), 
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
 { "allow_skip_frames", "allow skipping frames to hit the target bitrate", 
OFFSET(skip_frames), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
-{ "cabac", "Enable cabac", OFFSET(cabac), AV_OPT_TYPE_INT, { .i64 = 0 }, 
0, 1, VE },
+#if FF_API_OPENH264_CABAC
+{ "cabac", "Enable cabac(deprecated, use coder)", OFFSET(cabac), 
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE|DEPRECATED },
+#endif
+{ "coder", "Coder type",  OFFSET(coder), AV_OPT_TYPE_INT, { .i64 = -1 }, 
-1, 1, VE, "coder" },
+{ "default",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = -1 }, 
INT_MIN, INT_MAX, VE, "coder" },
+{ "cavlc",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 0 },  
INT_MIN, INT_MAX, VE, "coder" },
+{ "cabac",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 },  
INT_MIN, INT_MAX, VE, "coder" },
+{ "vlc",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 0 },  
INT_MIN, INT_MAX, VE, "coder" },
+{ "ac",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 },  
INT_MIN, INT_MAX, VE, "coder" },
 
 { "rc_mode", "Select rate control mode", OFFSET(rc_mode), AV_OPT_TYPE_INT, 
{ .i64 = RC_QUALITY_MODE }, RC_OFF_MODE, RC_TIMESTAMP_MODE, VE, "rc_mode" },
 { "off",   "bit rate control off", 
0, AV_OPT_TYPE_CONST, { .i64 = RC_OFF_MODE }, 0, 0, VE, 
"rc_mode" },
@@ -129,8 +140,17 @@ static av_cold int svc_encode_init_profile(AVCodecContext 
*avctx, SEncParamExt *
 break;
 }
 
-if (s->profile == FF_PROFILE_UNKNOWN)
-s->profile = s->cabac ? FF_PROFILE_H264_HIGH :
+#if FF_API_CODER_TYPE && FF_API_OPENH264_CABAC
+FF_DISABLE_DEPRECATION_WARNINGS
+if (s->coder < 0 && avctx->coder_type == FF_CODER_TYPE_AC)
+s->coder = 1;
+else
+s->coder = s->cabac;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+
+if (s->profile == FF_PROFILE_UNKNOWN && s->coder >= 0)
+s->profile = s->coder ? FF_PROFILE_H264_HIGH :
 FF_PROFILE_H264_CONSTRAINED_BASELINE;
 
 switch (s->profile) {
@@ -349,13 +369,6 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
 
 (*s->encoder)->GetDefaultParams(s->encoder, );
 
-#if FF_API_CODER_TYPE
-FF_DISABLE_DEPRECATION_WARNINGS
-if (!s->cabac)
-s->cabac = avctx->coder_type == FF_CODER_TYPE_AC;
-FF_ENABLE_DEPRECATION_WARNINGS
-#endif
-
 if (err = svc_encode_init_params(avctx, ) < 0)
 return err;
 
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 83075e4..7765bc7 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -138,6 +138,9 @@
 #ifndef FF_API_OPENH264_SLICE_MODE
 #define FF_API_OPENH264_SLICE_MODE (LIBAVCODEC_VERSION_MAJOR < 59)
 #endif
+#ifndef FF_API_OPENH264_CABAC
+#define FF_API_OPENH264_CABAC  (LIBAVCODEC_VERSION_MAJOR < 59)
+#endif
 
 
 #endif /* AVCODEC_VERSION_H */
-- 
2.7.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-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 1/9] lavc/libopenh264enc: Add default qmin/qmax support

[Linjie Fu]

Set default QP range to (1, 51) instead of (2, 32).

QP = 0 is not well supported currently in libopenh264. If iMaxQp/iMinQp
equals 0, the QP range would be changed unexpectedly inside libopenh264
with a warning:

Warning:Change QP Range from(0,51) to (12,42)

[1] 

[2] 

Signed-off-by: Linjie Fu 
---
 libavcodec/libopenh264enc.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index dd5d4ee..c7ae5b1 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -135,6 +135,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
 param.iTargetBitrate = avctx->bit_rate;
 param.iMaxBitrate= FFMAX(avctx->rc_max_rate, 
avctx->bit_rate);
 param.iRCMode= RC_QUALITY_MODE;
+// QP = 0 is not well supported, so default to (1, 51)
+param.iMaxQp = avctx->qmax >= 0 ? av_clip(avctx->qmax, 
1, 51) : 51;
+param.iMinQp = avctx->qmin >= 0 ? av_clip(avctx->qmin, 
1, param.iMaxQp) : 1;
 param.iTemporalLayerNum  = 1;
 param.iSpatialLayerNum   = 1;
 param.bEnableDenoise = 0;
@@ -331,6 +334,12 @@ static int svc_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 return 0;
 }
 
+static const AVCodecDefault svc_enc_defaults[] = {
+{ "qmin",  "-1"},
+{ "qmax",  "-1"},
+{ NULL },
+};
+
 AVCodec ff_libopenh264_encoder = {
 .name   = "libopenh264",
 .long_name  = NULL_IF_CONFIG_SMALL("OpenH264 H.264 / AVC / MPEG-4 AVC 
/ MPEG-4 part 10"),
@@ -344,6 +353,7 @@ AVCodec ff_libopenh264_encoder = {
 .caps_internal  = FF_CODEC_CAP_INIT_THREADSAFE | FF_CODEC_CAP_INIT_CLEANUP,
 .pix_fmts   = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P,
 AV_PIX_FMT_NONE },
+.defaults   = svc_enc_defaults,
 .priv_class = ,
 .wrapper_name   = "libopenh264",
 };
-- 
2.7.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-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 2/9] lavc/libopenh264enc: add default gop size and bit rate

[Linjie Fu]

It would be 200kbps bitrate with gop size = 12 by default
which generated too many IDR frames in rather low bit rate.
The quality would be poor.

Set these default values according to vaapi encoder, and
use 2Mbps bitrate if user doesn't set it explicitly as
nvenc sugguested.

Signed-off-by: Linjie Fu 
---
 libavcodec/libopenh264enc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index c7ae5b1..57313b1 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -132,7 +132,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 param.fMaxFrameRate  = 1/av_q2d(avctx->time_base);
 param.iPicWidth  = avctx->width;
 param.iPicHeight = avctx->height;
-param.iTargetBitrate = avctx->bit_rate;
+param.iTargetBitrate = avctx->bit_rate > 0 ? avctx->bit_rate : 
2*1000*1000;
 param.iMaxBitrate= FFMAX(avctx->rc_max_rate, 
avctx->bit_rate);
 param.iRCMode= RC_QUALITY_MODE;
 // QP = 0 is not well supported, so default to (1, 51)
@@ -335,6 +335,8 @@ static int svc_encode_frame(AVCodecContext *avctx, AVPacket 
*avpkt,
 }
 
 static const AVCodecDefault svc_enc_defaults[] = {
+{ "b", "0" },
+{ "g", "120"   },
 { "qmin",  "-1"},
 { "qmax",  "-1"},
 { NULL },
-- 
2.7.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-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 0/9] Enhancement for libopenh264 encoder

[Linjie Fu]

Docs would be provided later.

Linjie Fu (9):
  lavc/libopenh264enc: Add default qmin/qmax support
  lavc/libopenh264enc: add default gop size and bit rate
  lavc/libopenh264enc: add bit rate control select support
  lavc/libopenh264enc: prompt slice number changing inside libopenh264
  lavc/libopenh264enc: set slice_mode option to deprecated
[v4]: move FF_API_OPENH264_SLICE_MODE to libavcodec/version.h
  lavc/libopenh264enc: separate svc_encode_init() into several functions
  lavc/libopenh264enc: add profile high option support
  lavc/libopenh264enc: allow specifying the profile through
AVCodecContext
  lavc/libopenh264enc: Add coder option to replace cabac
[v4]: move FF_API_OPENH264_CABAC to libavcodec/version.h

 libavcodec/libopenh264enc.c | 365 ++--
 libavcodec/version.h|   6 +
 2 files changed, 259 insertions(+), 112 deletions(-)

-- 
2.7.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-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3] avformat/hlsenc: add hls_fmp4_init_resend option

[Steven Liu]

> 2020年4月12日 下午9:38，Steven Liu  写道：
> 
> 
> 
>> 2020年4月7日 下午5:31，Steven Liu  写道：
>> 
>> add option for resend init file after m3u8 refresh everytime.
>> 
>> Signed-off-by: Steven Liu 
>> ---
>> doc/muxers.texi  |  3 +++
>> libavformat/hlsenc.c | 41 -
>> 2 files changed, 39 insertions(+), 5 deletions(-)
>> 
>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>> index d304181671..4ae9d2cda9 100644
>> --- a/doc/muxers.texi
>> +++ b/doc/muxers.texi
>> @@ -836,6 +836,9 @@ fmp4 files may be used in HLS version 7 and above.
>> @item hls_fmp4_init_filename @var{filename}
>> Set filename to the fragment files header file, default filename is 
>> @file{init.mp4}.
>> 
>> +@item hls_fmp4_init_resend @var{filename}
>> +Resend init file after m3u8 file refresh every time, default is @var{0}.
>> +
>> When @code{var_stream_map} is set with two or more variant streams, the
>> @var{filename} pattern must contain the string "%v", this string specifies
>> the position of variant stream index in the generated init file names.
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index b4c72b6e54..668439440c 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -119,6 +119,7 @@ typedef struct VariantStream {
>>int packets_written;
>>int init_range_length;
>>uint8_t *temp_buffer;
>> +uint8_t *init_buffer;
>> 
>>AVFormatContext *avf;
>>AVFormatContext *vtt_avf;
>> @@ -192,6 +193,7 @@ typedef struct HLSContext {
>>char *segment_filename;
>>char *fmp4_init_filename;
>>int segment_type;
>> +int resend_init_file;  ///< resend init file into disk after refresh 
>> m3u8
>> 
>>int use_localtime;  ///< flag to expand filename with localtime
>>int use_localtime_mkdir;///< flag to mkdir dirname in timebased filename
>> @@ -2234,6 +2236,23 @@ static int hls_write_header(AVFormatContext *s)
>>return ret;
>> }
>> 
>> +static int hls_init_file_resend(AVFormatContext *s, VariantStream *vs)
>> +{
>> +HLSContext *hls = s->priv_data;
>> +AVDictionary *options = NULL;
>> +int ret = 0;
>> +
>> +set_http_options(s, , hls);
>> +ret = hlsenc_io_open(s, >out, hls->fmp4_init_filename, );
>> +av_dict_free();
>> +if (ret < 0)
>> +return ret;
>> +avio_write(vs->out, vs->init_buffer, vs->init_range_length);
>> +hlsenc_io_close(s, >out, hls->fmp4_init_filename);
>> +
>> +return ret;
>> +}
>> +
>> static int hls_write_packet(AVFormatContext *s, AVPacket *pkt)
>> {
>>HLSContext *hls = s->priv_data;
>> @@ -2246,7 +2265,6 @@ static int hls_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>>int range_length = 0;
>>const char *proto = NULL;
>>int use_temp_file = 0;
>> -uint8_t *buffer = NULL;
>>VariantStream *vs = NULL;
>>char *old_filename = NULL;
>> 
>> @@ -2332,9 +2350,12 @@ static int hls_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>>avio_flush(oc->pb);
>>if (hls->segment_type == SEGMENT_TYPE_FMP4) {
>>if (!vs->init_range_length) {
>> -range_length = avio_close_dyn_buf(oc->pb, );
>> -avio_write(vs->out, buffer, range_length);
>> -av_freep();
>> +range_length = avio_close_dyn_buf(oc->pb, >init_buffer);
>> +if (range_length <= 0)
>> +return AVERROR(EINVAL);
>> +avio_write(vs->out, vs->init_buffer, range_length);
>> +if (!hls->resend_init_file)
>> +av_freep(>init_buffer);
>>vs->init_range_length = range_length;
>>avio_open_dyn_buf(>pb);
>>vs->packets_written = 0;
>> @@ -2446,6 +2467,14 @@ static int hls_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>>}
>>}
>> 
>> +if (hls->resend_init_file && hls->segment_type == 
>> SEGMENT_TYPE_FMP4) {
>> +ret = hls_init_file_resend(s, vs);
>> +if (ret < 0) {
>> +av_freep(_filename);
>> +return ret;
>> +}
>> +}
>> +
>>if (hls->flags & HLS_SINGLE_FILE) {
>>vs->number++;
>>vs->start_pos += vs->size;
>> @@ -2510,7 +2539,8 @@ static void hls_free_variant_streams(struct HLSContext 
>> *hls)
>>}
>> 
>>avformat_free_context(vs->avf);
>> -
>> +if (hls->resend_init_file)
>> +av_freep(>init_buffer);
>>hls_free_segments(vs->segments);
>>hls_free_segments(vs->old_segments);
>>av_freep(>m3u8_name);
>> @@ -3010,6 +3040,7 @@ static const AVOption options[] = {
>>{"mpegts",   "make segment file to mpegts files in m3u8", 0, 
>> AV_OPT_TYPE_CONST, {.i64 = SEGMENT_TYPE_MPEGTS }, 0, UINT_MAX,   E, 
>> "segment_type"},
>>{"fmp4",   "make segment file to fragment mp4 files in m3u8", 0, 
>> AV_OPT_TYPE_CONST, {.i64 = SEGMENT_TYPE_FMP4 }, 0, UINT_MAX,   E, 
>> "segment_type"},
>>{"hls_fmp4_init_filename", 

Re: [FFmpeg-devel] [PATCH v2] avformat/dashdec: add attribute lang for audio and subtitle streams

[Steven Liu]

> 2020年4月11日 上午9:55，Steven Liu  写道：
> 
> 
> 
>> 2020年4月8日 下午10:39，Steven Liu  写道：
>> 
>> 
>> 
>>> 2020年3月31日 下午8:20，Steven Liu  写道：
>>> 
>>> There should have language in the metadata of streams which show to user
>>> 
>>> Signed-off-by: Steven Liu 
>>> ---
>>> libavformat/dashdec.c | 49 +++
>>> 1 file changed, 45 insertions(+), 4 deletions(-)
>>> 
>>> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
>>> index 271202b0a5..5ba7feb245 100644
>>> --- a/libavformat/dashdec.c
>>> +++ b/libavformat/dashdec.c
>>> @@ -85,6 +85,7 @@ struct representation {
>>> 
>>>   enum AVMediaType type;
>>>   char id[20];
>>> +char *lang;
>>>   int bandwidth;
>>>   AVRational framerate;
>>>   AVStream *assoc_stream; /* demuxer stream associated with this 
>>> representation */
>>> @@ -144,6 +145,9 @@ typedef struct DASHContext {
>>>   uint64_t period_duration;
>>>   uint64_t period_start;
>>> 
>>> +/* AdaptationSet Attribute */
>>> +char *adaptionset_lang;
>>> +
>>>   int is_live;
>>>   AVIOInterruptCB *interrupt_callback;
>>>   char *allowed_extensions;
>>> @@ -872,6 +876,15 @@ static int 
>>> parse_manifest_representation(AVFormatContext *s, const char *url,
>>>   ret = AVERROR(ENOMEM);
>>>   goto end;
>>>   }
>>> +if (c->adaptionset_lang) {
>>> +rep->lang = av_strdup(c->adaptionset_lang);
>>> +if (!rep->lang) {
>>> +av_log(s, AV_LOG_ERROR, "alloc language memory failure\n");
>>> +av_freep();
>>> +ret = AVERROR(ENOMEM);
>>> +goto end;
>>> +}
>>> +}
>>>   rep->parent = s;
>>>   representation_segmenttemplate_node = 
>>> find_child_node_by_name(representation_node, "SegmentTemplate");
>>>   representation_baseurl_node = 
>>> find_child_node_by_name(representation_node, "BaseURL");
>>> @@ -1103,6 +1116,19 @@ end:
>>>   return ret;
>>> }
>>> 
>>> +static int parse_manifest_adaptationset_attr(AVFormatContext *s, 
>>> xmlNodePtr adaptionset_node)
>>> +{
>>> +DASHContext *c = s->priv_data;
>>> +
>>> +if (!adaptionset_node) {
>>> +av_log(s, AV_LOG_WARNING, "Cannot get AdaptionSet\n");
>>> +return AVERROR(EINVAL);
>>> +}
>>> +c->adaptionset_lang = xmlGetProp(adaptionset_node, "lang");
>>> +
>>> +return 0;
>>> +}
>>> +
>>> static int parse_manifest_adaptationset(AVFormatContext *s, const char *url,
>>>   xmlNodePtr adaptionset_node,
>>>   xmlNodePtr mpd_baseurl_node,
>>> @@ -,6 +1137,7 @@ static int 
>>> parse_manifest_adaptationset(AVFormatContext *s, const char *url,
>>>   xmlNodePtr period_segmentlist_node)
>>> {
>>>   int ret = 0;
>>> +DASHContext *c = s->priv_data;
>>>   xmlNodePtr fragment_template_node = NULL;
>>>   xmlNodePtr content_component_node = NULL;
>>>   xmlNodePtr adaptionset_baseurl_node = NULL;
>>> @@ -1118,6 +1145,10 @@ static int 
>>> parse_manifest_adaptationset(AVFormatContext *s, const char *url,
>>>   xmlNodePtr adaptionset_supplementalproperty_node = NULL;
>>>   xmlNodePtr node = NULL;
>>> 
>>> +ret = parse_manifest_adaptationset_attr(s, adaptionset_node);
>>> +if (ret < 0)
>>> +return ret;
>>> +
>>>   node = xmlFirstElementChild(adaptionset_node);
>>>   while (node) {
>>>   if (!av_strcasecmp(node->name, (const char *)"SegmentTemplate")) {
>>> @@ -1142,13 +1173,15 @@ static int 
>>> parse_manifest_adaptationset(AVFormatContext *s, const char *url,
>>>   adaptionset_baseurl_node,
>>>   adaptionset_segmentlist_node,
>>>   
>>> adaptionset_supplementalproperty_node);
>>> -if (ret < 0) {
>>> -return ret;
>>> -}
>>> +if (ret < 0)
>>> +goto err;
>>>   }
>>>   node = xmlNextElementSibling(node);
>>>   }
>>> -return 0;
>>> +
>>> +err:
>>> +av_freep(>adaptionset_lang);
>>> +return ret;
>>> }
>>> 
>>> static int parse_programinformation(AVFormatContext *s, xmlNodePtr node)
>>> @@ -2121,6 +2154,10 @@ static int dash_read_header(AVFormatContext *s)
>>>   av_dict_set_int(>assoc_stream->metadata, 
>>> "variant_bitrate", rep->bandwidth, 0);
>>>   if (rep->id[0])
>>>   av_dict_set(>assoc_stream->metadata, "id", rep->id, 0);
>>> +if (rep->lang) {
>>> +av_dict_set(>assoc_stream->metadata, "language", 
>>> rep->lang, 0);
>>> +av_freep(>lang);
>>> +}
>>>   }
>>>   for (i = 0; i < c->n_subtitles; i++) {
>>>   rep = c->subtitles[i];
>>> @@ -2128,6 +2165,10 @@ static int dash_read_header(AVFormatContext *s)
>>>   rep->assoc_stream = s->streams[rep->stream_index];
>>>   if (rep->id[0])
>>>   

Re: [FFmpeg-devel] [PATCH v4] avcodec/v4l2_m2m: handle the v4l2 eos event

[Andriy Gelman]

On Wed, 08. Apr 20:51, Andriy Gelman wrote:
> On Wed, 01. Apr 10:38, Ming Qian wrote:
> > when the last frame of capture is dequeueed,
> > driver may send this V4L2_EVENT_EOS event,
> > If this event is received, then the capture buffers have been flushed and
> > avcodec_receive_packet()/avcodec_receive_frame() can return AVERROR_EOF.
> > Otherwise, the draining continues until all the capture buffers have been 
> > dequeued or VIDIOC_DQBUF ioctl returns an EPIPE error.
> > 
> > Some devices may not support V4L2_EVENT_EOS.
> > This is logged as a warning message and not treated as a fatal error during 
> > initialization.
> > 
> > Without this patch imx8qm often hangs at the end of encoding/decoding when
> > flushing the capture buffers
> > 
> > Signed-off-by: Ming Qian 
> > ---
> >  libavcodec/v4l2_context.c |  6 ++
> >  libavcodec/v4l2_m2m_dec.c |  8 
> >  libavcodec/v4l2_m2m_enc.c | 19 +++
> >  3 files changed, 33 insertions(+)
> > 
> > diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
> > index 8110bbb555..6b1f65fe4c 100644
> > --- a/libavcodec/v4l2_context.c
> > +++ b/libavcodec/v4l2_context.c
> > @@ -154,6 +154,7 @@ static inline void v4l2_save_to_context(V4L2Context* 
> > ctx, struct v4l2_format_upd
> >  }
> >  
> >  /**
> > + * handle resolution change event and end of stream event
> >   * returns 1 if reinit was successful, negative if it failed
> >   * returns 0 if reinit was not executed
> >   */
> > @@ -171,6 +172,11 @@ static int v4l2_handle_event(V4L2Context *ctx)
> >  return 0;
> >  }
> >  
> > +if (evt.type == V4L2_EVENT_EOS) {
> > +ctx->done = 1;
> > +return 0;
> > +}
> > +
> >  if (evt.type != V4L2_EVENT_SOURCE_CHANGE)
> >  return 0;
> >  
> > diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
> > index d666edffe4..9989649784 100644
> > --- a/libavcodec/v4l2_m2m_dec.c
> > +++ b/libavcodec/v4l2_m2m_dec.c
> > @@ -123,6 +123,14 @@ static int v4l2_prepare_decoder(V4L2m2mContext *s)
> >  }
> >  }
> >  
> > +memset(, 0, sizeof(sub));
> > +sub.type = V4L2_EVENT_EOS;
> > +ret = ioctl(s->fd, VIDIOC_SUBSCRIBE_EVENT, );
> > +if (ret < 0) {
> > +av_log(s->avctx, AV_LOG_WARNING,
> > +"the v4l2 driver does not support end of stream 
> > VIDIOC_SUBSCRIBE_EVENT\n");
> > +}
> > +
> >  return 0;
> >  }
> >  
> > diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c
> > index 84de63ec9d..78cf9ba47a 100644
> > --- a/libavcodec/v4l2_m2m_enc.c
> > +++ b/libavcodec/v4l2_m2m_enc.c
> > @@ -155,6 +155,23 @@ static int v4l2_check_b_frame_support(V4L2m2mContext 
> > *s)
> >  return AVERROR_PATCHWELCOME;
> >  }
> >  
> > +static int v4l2_subscribe_eos_event(V4L2m2mContext *s)
> > +{
> > +struct v4l2_event_subscription sub;
> > +int ret;
> > +
> > +memset(, 0, sizeof(sub));
> > +sub.type = V4L2_EVENT_EOS;
> > +ret = ioctl(s->fd, VIDIOC_SUBSCRIBE_EVENT, );
> > +if (ret < 0) {
> > +av_log(s->avctx, AV_LOG_WARNING,
> > +"the v4l2 driver does not support end of stream 
> > VIDIOC_SUBSCRIBE_EVENT\n");
> > +return ret;
> > +}
> > +
> > +return 0;
> > +}
> > +
> >  static int v4l2_prepare_encoder(V4L2m2mContext *s)
> >  {
> >  AVCodecContext *avctx = s->avctx;
> > @@ -164,6 +181,8 @@ static int v4l2_prepare_encoder(V4L2m2mContext *s)
> >  /**
> >   * requirements
> >   */
> > +v4l2_subscribe_eos_event(s);
> > +
> >  ret = v4l2_check_b_frame_support(s);
> >  if (ret)
> >  return ret;
> > -- 
> > 2.26.0
> > 
> 
> lgtm
> Tested on RPi4 and Odroid XU4. 
> 

Applied. 

Thanks,
-- 
Andriy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH, v2 1/2] lavc/qsvdec: add decode support for HEVC 4:2:2 8-bit and 10-bit

[Fu, Linjie]

> From: Zhong Li 
> Sent: Wednesday, April 15, 2020 09:58
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: Re: [FFmpeg-devel] [PATCH, v2 1/2] lavc/qsvdec: add decode
> support for HEVC 4:2:2 8-bit and 10-bit
> 
> Linjie Fu  于2020年2月26日周三 下午4:43写道：
> >
> > Enables HEVC Range Extension decoding support (Linux) for 4:2:2 8/10 bit
> > on ICL+ (gen11 +) platform.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> > [v2]: restrict to support on Linux.
> >
> >  libavcodec/qsv.c  | 16 
> >  libavutil/hwcontext_qsv.c | 24 
> >  2 files changed, 40 insertions(+)
> >
> > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> > index db98c75..171a8d6 100644
> > --- a/libavcodec/qsv.c
> > +++ b/libavcodec/qsv.c
> > @@ -195,6 +195,12 @@ enum AVPixelFormat ff_qsv_map_fourcc(uint32_t
> fourcc)
> >  case MFX_FOURCC_NV12: return AV_PIX_FMT_NV12;
> >  case MFX_FOURCC_P010: return AV_PIX_FMT_P010;
> >  case MFX_FOURCC_P8:   return AV_PIX_FMT_PAL8;
> > +#if CONFIG_VAAPI
> > +case MFX_FOURCC_YUY2: return AV_PIX_FMT_YUYV422;
> 
> There is no VAAPI structures here, so should not use CONFIG_VAAPI to
> disable them.
> 

This is pointed out in [1] that D3D code doesn't support YUYV format, and indeed
It leads to unexpected crash in windows.(instead of working or reporting 
unsupported
On ICL- platform)

Hence this patch restricted to add support on linux only.

And I admit the best solution should be get this fully supported on both linux 
and windows.
(I believe Max and Artem is helping on windows side)

Thanks for the review,
Linjie

[1] 
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1582596080-1035-1-git-send-email-linjie...@intel.com/


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v1 1/2] avcodec/nvenc_h264: add spatial_aq and temporal_aq option to consistent with nvenc_hevc

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavcodec/nvenc_h264.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/nvenc_h264.c b/libavcodec/nvenc_h264.c
index 479155fe15..a2e77e67d0 100644
--- a/libavcodec/nvenc_h264.c
+++ b/libavcodec/nvenc_h264.c
@@ -99,7 +99,9 @@ static const AVOption options[] = {
 { "b_adapt",  "When lookahead is enabled, set this to 0 to disable 
adaptive B-frame decision",
 OFFSET(b_adapt),   
   AV_OPT_TYPE_BOOL,  { .i64 = 1 }, 0,  1, VE },
 { "spatial-aq",   "set to 1 to enable Spatial AQ",  OFFSET(aq),
   AV_OPT_TYPE_BOOL,  { .i64 = 0 }, 0,  1, VE },
+{ "spatial_aq",   "set to 1 to enable Spatial AQ",  OFFSET(aq),
   AV_OPT_TYPE_BOOL,  { .i64 = 0 }, 0,  1, VE },
 { "temporal-aq",  "set to 1 to enable Temporal AQ", 
OFFSET(temporal_aq),  AV_OPT_TYPE_BOOL,  { .i64 = 0 }, 0,  1, VE },
+{ "temporal_aq",  "set to 1 to enable Temporal AQ", 
OFFSET(temporal_aq),  AV_OPT_TYPE_BOOL,  { .i64 = 0 }, 0,  1, VE },
 { "zerolatency",  "Set 1 to indicate zero latency operation (no reordering 
delay)",
 
OFFSET(zerolatency),  AV_OPT_TYPE_BOOL,  { .i64 = 0 }, 0,  1, VE },
 { "nonref_p", "Set this to 1 to enable automatic insertion of 
non-reference P-frames",
-- 
2.21.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v1 2/2] avcodec/nvenc_hevc: add spatial-aq and temporal-aq option to consistent with nvenc_h264

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavcodec/nvenc_hevc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/nvenc_hevc.c b/libavcodec/nvenc_hevc.c
index 7c9b3848f1..d06cb0d6b0 100644
--- a/libavcodec/nvenc_hevc.c
+++ b/libavcodec/nvenc_hevc.c
@@ -96,7 +96,9 @@ static const AVOption options[] = {
 { "forced-idr",   "If forcing keyframes, force them as IDR frames.",
 
OFFSET(forced_idr),   AV_OPT_TYPE_BOOL,  { .i64 = 0 }, -1, 1, VE },
 { "spatial_aq",   "set to 1 to enable Spatial AQ",  OFFSET(aq),
   AV_OPT_TYPE_BOOL,  { .i64 = 0 }, 0, 1, VE },
+{ "spatial-aq",   "set to 1 to enable Spatial AQ",  OFFSET(aq),
   AV_OPT_TYPE_BOOL,  { .i64 = 0 }, 0, 1, VE },
 { "temporal_aq",  "set to 1 to enable Temporal AQ", 
OFFSET(temporal_aq),  AV_OPT_TYPE_BOOL,  { .i64 = 0 }, 0, 1, VE },
+{ "temporal-aq",  "set to 1 to enable Temporal AQ", 
OFFSET(temporal_aq),  AV_OPT_TYPE_BOOL,  { .i64 = 0 }, 0, 1, VE },
 { "zerolatency",  "Set 1 to indicate zero latency operation (no reordering 
delay)",
 
OFFSET(zerolatency),  AV_OPT_TYPE_BOOL,  { .i64 = 0 }, 0, 1, VE },
 { "nonref_p", "Set this to 1 to enable automatic insertion of 
non-reference P-frames",
-- 
2.21.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH, v2 1/2] lavc/qsvdec: add decode support for HEVC 4:2:2 8-bit and 10-bit

[Zhong Li]

Linjie Fu  于2020年2月26日周三 下午4:43写道：
>
> Enables HEVC Range Extension decoding support (Linux) for 4:2:2 8/10 bit
> on ICL+ (gen11 +) platform.
>
> Signed-off-by: Linjie Fu 
> ---
> [v2]: restrict to support on Linux.
>
>  libavcodec/qsv.c  | 16 
>  libavutil/hwcontext_qsv.c | 24 
>  2 files changed, 40 insertions(+)
>
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index db98c75..171a8d6 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -195,6 +195,12 @@ enum AVPixelFormat ff_qsv_map_fourcc(uint32_t fourcc)
>  case MFX_FOURCC_NV12: return AV_PIX_FMT_NV12;
>  case MFX_FOURCC_P010: return AV_PIX_FMT_P010;
>  case MFX_FOURCC_P8:   return AV_PIX_FMT_PAL8;
> +#if CONFIG_VAAPI
> +case MFX_FOURCC_YUY2: return AV_PIX_FMT_YUYV422;

There is no VAAPI structures here, so should not use CONFIG_VAAPI to
disable them.

> +#if QSV_VERSION_ATLEAST(1, 27)
> +case MFX_FOURCC_Y210: return AV_PIX_FMT_Y210;
> +#endif
> +#endif
>  }
>  return AV_PIX_FMT_NONE;
>  }
> @@ -211,6 +217,16 @@ int ff_qsv_map_pixfmt(enum AVPixelFormat format, 
> uint32_t *fourcc)
>  case AV_PIX_FMT_P010:
>  *fourcc = MFX_FOURCC_P010;
>  return AV_PIX_FMT_P010;
> +#if CONFIG_VAAPI
> +case AV_PIX_FMT_YUV422P:
> +*fourcc = MFX_FOURCC_YUY2;
> +return AV_PIX_FMT_YUYV422;
> +#if QSV_VERSION_ATLEAST(1, 27)
> +case AV_PIX_FMT_YUV422P10:
> +*fourcc = MFX_FOURCC_Y210;
> +return AV_PIX_FMT_Y210;
> +#endif
> +#endif
>  default:
>  return AVERROR(ENOSYS);
>  }
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index b1b6740..4306c6e3 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -44,6 +44,10 @@
>  #include "pixdesc.h"
>  #include "time.h"
>
> +#define QSV_VERSION_ATLEAST(MAJOR, MINOR)   \
> +(MFX_VERSION_MAJOR > (MAJOR) || \
> + MFX_VERSION_MAJOR == (MAJOR) && MFX_VERSION_MINOR >= (MINOR))
> +
>  typedef struct QSVDevicePriv {
>  AVBufferRef *child_device_ctx;
>  } QSVDevicePriv;
> @@ -103,6 +107,14 @@ static const struct {
>  { AV_PIX_FMT_BGRA, MFX_FOURCC_RGB4 },
>  { AV_PIX_FMT_P010, MFX_FOURCC_P010 },
>  { AV_PIX_FMT_PAL8, MFX_FOURCC_P8   },
> +#if CONFIG_VAAPI
> +{ AV_PIX_FMT_YUYV422,
> +   MFX_FOURCC_YUY2 },
> +#if QSV_VERSION_ATLEAST(1, 27)
> +{ AV_PIX_FMT_Y210,
> +   MFX_FOURCC_Y210 },
> +#endif
> +#endif
>  };
>
>  static uint32_t qsv_fourcc_from_pix_fmt(enum AVPixelFormat pix_fmt)
> @@ -773,7 +785,19 @@ static int map_frame_to_surface(const AVFrame *frame, 
> mfxFrameSurface1 *surface)
>  surface->Data.R = frame->data[0] + 2;
>  surface->Data.A = frame->data[0] + 3;
>  break;
> +#if CONFIG_VAAPI
> +case AV_PIX_FMT_YUYV422:
> +surface->Data.Y = frame->data[0];
> +surface->Data.U = frame->data[0] + 1;
> +surface->Data.V = frame->data[0] + 3;
> +break;
>
> +case AV_PIX_FMT_Y210:
> +surface->Data.Y16 = (mfxU16 *)frame->data[0];
> +surface->Data.U16 = (mfxU16 *)frame->data[0] + 1;
> +surface->Data.V16 = (mfxU16 *)frame->data[0] + 3;
> +break;
> +#endif
>  default:
>  return MFX_ERR_UNSUPPORTED;
>  }
> --
> 2.7.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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 2/2] libavcodec/libaomenc.c: Support lossless encoding

[James Zern]

On Tue, Apr 7, 2020 at 5:14 PM Ryo Hirafuji  wrote:
>
> From: Ryo Hirafuji 
>
> AV1 support lossless encoding.
> In this patch, I added a command line flag to enable it.
>
> Fixes ticket #7600
> ---
>  libavcodec/libaomenc.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
>
> [...]
> @@ -574,7 +577,9 @@ static av_cold int aom_init(AVCodecContext *avctx,
>  if (avctx->rc_min_rate == avctx->rc_max_rate &&
>  avctx->rc_min_rate == avctx->bit_rate && avctx->bit_rate) {
>  enccfg.rc_end_usage = AOM_CBR;
> -} else if (ctx->crf >= 0) {
> +} else if (ctx->crf == 0) {
> +enccfg.rc_end_usage = AOM_Q;

I saw the earlier comments around using crf=0 as the trigger for this.
libaom will behave differently with q vs cq mode. This also differs
from the -lossless in libvpxenc where this feature originated; mostly
we've been mapping options one to one with vpx/aomenc. Let me ask
around about the preference for lossless usage in libaom.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 1/2] libavcodec/libaomenc.c: Support gray input

[James Zern]

On Tue, Apr 14, 2020 at 3:57 AM Ryo Hirafuji  wrote:
>
> Thanks for the review!
>
> This should bump the micro version number in libavcodec/version.h.
>
>
> OK, I will bump up the version when the problem below is solved.
>

If we want to go for compatibility with different versions of the
library we could move forward with the patch as is, though it would be
simpler to just treat this as a bug fix in libaom.

>
> > That's annoying. I filed a bug to track [1]. The monochrome flag
> > itself seems unnecessary for the library rather than just an image
> > format, but that's another discussion.
> >
>
>  Thanks for creating the issue.
>
> You might be right.
> I just need this line to set  the monochrome flag to 1 in Sequence Header
> OBU:
> > enccfg->monochrome = 1u;
>
> This reads a little strangely to me, maybe something like: U and V
> > information is ignored, but must point to valid buffers...?
> > [1] https://crbug.com/aomedia/2639
>
>
> I pasted the stack trace when V plane and U plane are NULL and ffmpeg
> crashes:
> https://bugs.chromium.org/p/aomedia/issues/detail?id=2639#c1
> (ryoh@... is also my account)
>

Thanks for adding the detail.

> If we allocate aom_image with aom_img_alloc function, allocated V plane and
> U plane are filled with 0 (not 128, 512 or 2048).
> And I don't have to fill them to 128 to obtain a gray image.
> (I tried it in https://github.com/link-u/cavif )
> So I think these planes are just ignored (but not sure).
>

They should be. From the stack trace it looks like a simple fix when
dealing with border extension, though that may uncover other issues.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 7/7] get_bits: use immediate in skip_remaining

[Michael Niedermayer]

On Tue, Apr 14, 2020 at 10:25:03AM +, Christophe Gisquet wrote:
> When the entry informs to continue reading, this means the current read
> will be entirely skipped. Small object size reduction, depending on
> inlining.
> ---
>  libavcodec/get_bits.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

interresting we all missed this before, should be ok

thx


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/7] get_bits: support 32bits cache

[Carl Eugen Hoyos]

Am Di., 14. Apr. 2020 um 12:25 Uhr schrieb Christophe Gisquet
:
>
> Therefore, also activate it under ARCH_X86 (testing for more archs welcome)
> for the only codecs supporting said cache reader.
> For UTVideo, on 8 bits samples and ARCH_X86_32 (X86_64 being unaffected),
> timings for one line do ~19.4k -> 15.1k and 16.5k

> (roughly 17% speedup).

I cannot reproduce - I see around 30% speedup on x86_32 decoding utvideo =-)

Will test on ppc32 over the weekend.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/movenc: remove call to av_copy_packet_side_data() when concatenatic eac3 syncframes

[Andreas Rheinhardt]

James Almer:
> This generates a potential memory leak if info->pkt already contains side data
> elements, and may mix side data from the last packet with other properties 
> from
> the first.

Now that you mention it: Yes, there is a potential memleak.* So remove this.
> 
> Keep all the properties from the first packet only in the output packet
> instead.
> 
> Signed-off-by: James Almer 
> ---
> The alternative is to keep all the properties of the last packet instead of 
> the
> first, or merge the side data from all packets into the output packet, giving
> priority to the either the first or the last in case of duplicate side data
> types.
> 
> I have no idea what would be ideal since i don't have a sample that triggers
> this code, and i don't know what kind of side data these eac3 packets could
> contain that one would need to choose between them.
> 
Right now any side data these packets might contain is ignored (with the
potential exception of AVProducerReferenceTime stuff). Relevant side
data would be AV_PKT_DATA_SKIP_SAMPLES (which the mov muxer ignores) or
maybe AV_PKT_DATA_PARAM_CHANGE.

>  libavformat/movenc.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index bc8d08044e..bf3e4fa2ce 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -520,8 +520,6 @@ concatenate:
>  memcpy(info->pkt.data + info->pkt.size - pkt->size, pkt->data, 
> pkt->size);
>  info->num_blocks += num_blocks;
>  info->pkt.duration += pkt->duration;
> -if ((ret = av_copy_packet_side_data(>pkt, pkt)) < 0)
> -goto end;
>  if (info->num_blocks != 6)
>  goto end;
>  av_packet_unref(pkt);
> 

- Andreas

*: And anyway, av_copy_packet_side_data() is even more broken: It
allocates a new side-data-array and only then checks for whether dst and
src coincide. Was the intention behind this to enable a packet's side
data to be made independently allocated in a scenario like AVPacket
pkt1, pkt2; ... pkt1 = pkt2; av_copy_packet_side_data(, );? If
so that is very dangerous given the av_packet_unref() of the destination
packet in case of failure.
(And if src != dst, then the already allocated side data leaks in case
of allocation failure because dst->side_data_elems does not accurately
reflect how many side data elements there are right now.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/movenc: remove call to av_copy_packet_side_data() when concatenatic eac3 syncframes

[James Almer]

This generates a potential memory leak if info->pkt already contains side data
elements, and may mix side data from the last packet with other properties from
the first.

Keep all the properties from the first packet only in the output packet
instead.

Signed-off-by: James Almer 
---
The alternative is to keep all the properties of the last packet instead of the
first, or merge the side data from all packets into the output packet, giving
priority to the either the first or the last in case of duplicate side data
types.

I have no idea what would be ideal since i don't have a sample that triggers
this code, and i don't know what kind of side data these eac3 packets could
contain that one would need to choose between them.

 libavformat/movenc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index bc8d08044e..bf3e4fa2ce 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -520,8 +520,6 @@ concatenate:
 memcpy(info->pkt.data + info->pkt.size - pkt->size, pkt->data, 
pkt->size);
 info->num_blocks += num_blocks;
 info->pkt.duration += pkt->duration;
-if ((ret = av_copy_packet_side_data(>pkt, pkt)) < 0)
-goto end;
 if (info->num_blocks != 6)
 goto end;
 av_packet_unref(pkt);
-- 
2.26.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 5/7] get_bits: improve and fix get_bits_long for 32b

[Michael Niedermayer]

On Tue, Apr 14, 2020 at 10:25:01AM +, Christophe Gisquet wrote:
> The new code is guaranteed to read at least 32bits, which is likely ok with
> the usual case that get_bits without cache can read up to 25.
> ---
>  libavcodec/get_bits.h | 29 ++---
>  1 file changed, 26 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
> index 4f75f9dd84..da054ebfcb 100644
> --- a/libavcodec/get_bits.h
> +++ b/libavcodec/get_bits.h
> @@ -608,21 +608,44 @@ static inline void skip_bits1(GetBitContext *s)
>   */
>  static inline unsigned int get_bits_long(GetBitContext *s, int n)
>  {
> +unsigned ret = 0;

Dead assignment if CACHED_BITSTREAM_READER is not used


>  av_assert2(n>=0 && n<=32);
>  if (!n) {
>  return 0;
>  #if CACHED_BITSTREAM_READER
>  }
> -return get_bits(s, n);
> +
> +# ifdef BITSTREAM_READER_LE
> +unsigned left = 0;
> +# endif
> +if (n > s->bits_left) {
> +n -= s->bits_left;

> +# ifdef BITSTREAM_READER_LE
> +left = s->bits_left;
> +ret = get_val(s, s->bits_left, 1);
> +refill_all(s, 1);
> +# else
> +ret = get_val(s, s->bits_left, 0);
> +refill_all(s, 0);
> +# endif

Its a pitty one cannot write the following

+# ifdef BITSTREAM_READER_LE
+left = s->bits_left;
+# endif
+ret = get_val(s, s->bits_left, BITSTREAM_READER_LE);
+refill_all(s, BITSTREAM_READER_LE);

that would be nicer looking if it worked


[...]
-- 
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


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] configure: fix clang on macOS 10.15

[Carl Eugen Hoyos]

Am Di., 14. Apr. 2020 um 20:49 Uhr schrieb Jan Ekström :
>
> On Tue, Apr 14, 2020 at 8:45 PM Josh de Kock  wrote:
> >
> > Works around a bug in the newer Xcode 11's clang with -fstack-check
> > emitting bad code with misaligned call instructions.
> > ---
> >  configure | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/configure b/configure
> > index 4d4c429be9..c872a2932d 100755
> > --- a/configure
> > +++ b/configure
> > @@ -5358,6 +5358,11 @@ case $target_os in
> >  fi
> >  version_script='-exported_symbols_list'
> >  VERSION_SCRIPT_POSTPROCESS_CMD='tr " " "\n" | sed -n 
> > /global:/,/local:/p | grep ";" | tr ";" "\n" | sed -E "s/(.+)/_\1/g" | sed 
> > -E "s/(.+[^*])/\1*/"'
> > +# Workaround for Xcode 11 -fstack-check bug
> > +if enabled clang; then
> > +clang_version=$($cc -dumpversion)
> > +test ${clang_version%%.*} -ge 11 && add_cflags -fno-stack-check
>
> I would match what dav1d does so far, and check for equality against
> 11.

> Not greater-or-equal, if I'm reading this correctly.

+1

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] ffmpeg: allow full range of dts_delta_threshold

[Michael Niedermayer]

On Tue, Apr 14, 2020 at 02:48:47PM +0530, Gyan Doshi wrote:
> For inputs from demuxers with AVFMT_TS_DISCONT flag,
> the existing condition,
> 
>   delta < -1LL*dts_delta_threshold*AV_TIME_BASE
> 
> is rendered superflous due to the fixed threshold in
> 
> pkt_dts + AV_TIME_BASE/10 < FFMAX(ist->pts, ist->dts)
> 
> This prevents users from setting a high threshold to
> avoid discontinuity correction due to errant timestamps.
> 
> Now, the maximum of the two thresholds is used.
> 
> fate-mpeg4-resolution-change call changed to preserve existing
> timestamp correction by ffmpeg.c
> ---
> Tested with multiple satellite MPEG-TS inputs.
> 
>  fftools/ffmpeg.c | 2 +-
>  tests/fate/mpeg4.mak | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

breaks:
./ffmpeg -i 'concat:angels.mpg|angels.mpg'  -vsync 0  file.avi

...
frame=   24 fps=0.0 q=12.5 Lsize= 215kB time=00:00:07.50 bitrate= 
234.7kbits/s speed=75.5x
video:84kB audio:110kB subtitle:0kB other streams:0kB global headers:0kB muxing 
overhead: 10.697786%

vs.

...
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 219, 
current: 86; changing to 220. This may result in incorrect timestamps in the 
output file.
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 220, 
current: 87; changing to 221. This may result in incorrect timestamps in the 
output file.
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 221, 
current: 88; changing to 222. This may result in incorrect timestamps in the 
output file.
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 222, 
current: 89; changing to 223. This may result in incorrect timestamps in the 
output file.
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 223, 
current: 90; changing to 224. This may result in incorrect timestamps in the 
output file.
[avi @ 0x5601caccc180] Non-monotonous DTS in output stream 0:1; previous: 224, 
current: 91; changing to 225. This may result in incorrect timestamps in the 
output file.
[mpeg4 @ 0x5601cac87540] Invalid pts (72) <= last (83)
Video encoding failed

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] [GSOC] libavfilter/vf_colorconstancy.c : Adding weighted greyedge

[YATENDRA SINGH]

Signed-off-by: Yatendra Singh 
---
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_colorconstancy.c | 265 +++-
 3 files changed, 232 insertions(+), 35 deletions(-)

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e6cfcd9487..c90aadae98 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -447,6 +447,7 @@ OBJS-$(CONFIG_VSTACK_FILTER) +=
vf_stack.o framesync.o
 OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
 OBJS-$(CONFIG_WAVEFORM_FILTER)   += vf_waveform.o
 OBJS-$(CONFIG_WEAVE_FILTER)  += vf_weave.o
+OBJS-$(CONFIG_WEIGHTED_GREYEDGE_FILTER)  += vf_colorconstancy.o
 OBJS-$(CONFIG_XBR_FILTER)+= vf_xbr.o
 OBJS-$(CONFIG_XFADE_FILTER)  += vf_xfade.o
 OBJS-$(CONFIG_XFADE_OPENCL_FILTER)   += vf_xfade_opencl.o opencl.o
opencl/xfade.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 501e5d041b..594b497f0b 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -426,6 +426,7 @@ extern AVFilter ff_vf_vstack;
 extern AVFilter ff_vf_w3fdif;
 extern AVFilter ff_vf_waveform;
 extern AVFilter ff_vf_weave;
+extern AVFilter ff_vf_weighted_greyedge;
 extern AVFilter ff_vf_xbr;
 extern AVFilter ff_vf_xfade;
 extern AVFilter ff_vf_xfade_opencl;
diff --git a/libavfilter/vf_colorconstancy.c
b/libavfilter/vf_colorconstancy.c
index eae62204b5..49508ae65e 100644
--- a/libavfilter/vf_colorconstancy.c
+++ b/libavfilter/vf_colorconstancy.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2018 Mina Sami
+ * Copyright (c) 2020 Yatendra Singh
  *
  * This file is part of FFmpeg.
  *
@@ -26,6 +27,14 @@
  *
  * @cite
  * J. van de Weijer, Th. Gevers, A. Gijsenij "Edge-Based Color Constancy".
+ *
+ * @cite
+ * J. van de Weijer, Th. Gevers, and J. Geusebroek,
+ * “Edge and corner detection by photometric quasi-invariants”.
+ *
+ * @cite
+ * A. Gijsenij, Th. Gevers, J. van de Weijer,
+ * "Improving Color Constancy by Photometric Edge Weighting".
  */

 #include "libavutil/imgutils.h"
@@ -40,8 +49,10 @@
 #include 

 #define GREY_EDGE "greyedge"
+#define WEIGHTED_GREY_EDGE "weighted_greyedge"

 #define SQRT3 1.73205080757
+#define NORAMAL_WHITE 1/SQRT3

 #define NUM_PLANES3
 #define MAX_DIFF_ORD  2
@@ -83,6 +94,11 @@ typedef struct ColorConstancyContext {
 int planeheight[4];
 int planewidth[4];

+double min_err;
+int max_iters;
+
+double *weight_info[2];
+
 int filtersize;
 double *gauss[MAX_DIFF_ORD+1];

@@ -552,32 +568,6 @@ static void normalize_light(double *light)
 }
 }

-/**
- * Redirects to corresponding algorithm estimation function and performs
normalization
- * after estimation.
- *
- * @param ctx the filter context.
- * @param in frame to perfrom estimation on.
- *
- * @return 0 in case of success, a negative value corresponding to an
- * AVERROR code in case of failure.
- */
-static int illumination_estimation(AVFilterContext *ctx, AVFrame *in)
-{
-ColorConstancyContext *s = ctx->priv;
-int ret;
-
-ret = filter_grey_edge(ctx, in);
-
-av_log(ctx, AV_LOG_DEBUG, "Estimated illumination= %f %f %f\n",
-   s->white[0], s->white[1], s->white[2]);
-normalize_light(s->white);
-av_log(ctx, AV_LOG_DEBUG, "Estimated illumination after normalization=
%f %f %f\n",
-   s->white[0], s->white[1], s->white[2]);
-
-return ret;
-}
-
 /**
  * Performs simple correction via diagonal transformation model.
  *
@@ -634,6 +624,162 @@ static void chromatic_adaptation(AVFilterContext
*ctx, AVFrame *in, AVFrame *out
 ctx->internal->execute(ctx, diagonal_transformation, , NULL,
nb_jobs);
 }

+/**
+ * Slice function for weighted grey edge algorithm that does partial
summing/maximizing
+ * of gaussian derivatives.
+ *
+ * @param ctx the filter context.
+ * @param arg data to be passed between threads.
+ * @param jobnr current job nubmer.
+ * @param nb_jobs total number of jobs.
+ *
+ * @return 0.
+ */
+static int filter_slice_weighted_greyedge(AVFilterContext* ctx, void* arg,
int jobnr, int nb_jobs)
+{
+ColorConstancyContext *s = ctx->priv;
+ThreadData *td = arg;
+AVFrame *in= td->in;
+int minknorm   = s->minknorm;
+const uint8_t thresh = 255;
+int plane;
+
+int height_max  = FFMAX3(s->planeheight[0], s->planeheight[1],
s->planeheight[2]);
+int width_max   = FFMAX3(s->planewidth[0], s->planewidth[1],
s->planewidth[2]);
+
+memset(s->weight_info[0], 0, height_max * width_max * sizeof(double));
+memset(s->weight_info[1], 0, height_max * width_max * sizeof(double));
+
+for (plane = 0; plane < NUM_PLANES; plane++)
+{
+const int height= s->planeheight[plane];
+const int width = s->planewidth[plane];
+const int in_linesize   = in->linesize[plane];
+const int slice_start   = (height * jobnr) / nb_jobs;
+const int slice_end = (height * (jobnr+1)) / 

Re: [FFmpeg-devel] [PATCH] configure: fix clang on macOS 10.15

[Jan Ekström]

On Tue, Apr 14, 2020 at 8:45 PM Josh de Kock  wrote:
>
> Works around a bug in the newer Xcode 11's clang with -fstack-check
> emitting bad code with misaligned call instructions.
> ---
>  configure | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/configure b/configure
> index 4d4c429be9..c872a2932d 100755
> --- a/configure
> +++ b/configure
> @@ -5358,6 +5358,11 @@ case $target_os in
>  fi
>  version_script='-exported_symbols_list'
>  VERSION_SCRIPT_POSTPROCESS_CMD='tr " " "\n" | sed -n 
> /global:/,/local:/p | grep ";" | tr ";" "\n" | sed -E "s/(.+)/_\1/g" | sed -E 
> "s/(.+[^*])/\1*/"'
> +# Workaround for Xcode 11 -fstack-check bug
> +if enabled clang; then
> +clang_version=$($cc -dumpversion)
> +test ${clang_version%%.*} -ge 11 && add_cflags -fno-stack-check

I would match what dav1d does so far, and check for equality against
11. Not greater-or-equal, if I'm reading this correctly.

> +fi
>  ;;
>  msys*)
>  die "Native MSYS builds are discouraged, please use the MINGW 
> environment."
> --
> 2.24.1 (Apple Git-126)

Can verify this fixes running newly built binaries on macOS 10.15.
Without this, the binary crashes immediately.

Please mention that this also fixes ticket #8073 .

For context for others, it seems like Apple has been distributing a
broken clang binary with their development tool kit for quite a while.
People have reported it, but things go as usual (
https://forums.developer.apple.com/thread/121887 ).

Other projects, such as dav1d, have taken the same approach. Check for
clang major version under darwin, and if 11 -> disable stack checking.

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 02/10] configure, libavformat/Makefile: Fix webm_chunk dependencies

[Andreas Rheinhardt]

Andreas Rheinhardt:
> Andreas Rheinhardt:
>> The webm_chunk muxer requires the WebM muxer, yet it does not directly
>> require anything from libavformat/matroska.c (it does not even include
>> the corresponding header). So remove the dependency from the Makefile
>> and add a _select to configure.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  configure| 1 +
>>  libavformat/Makefile | 2 +-
>>  2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index 09bda9b408..2f08d06af7 100755
>> --- a/configure
>> +++ b/configure
>> @@ -3335,6 +3335,7 @@ w64_demuxer_select="wav_demuxer"
>>  w64_muxer_select="wav_muxer"
>>  wav_demuxer_select="riffdec"
>>  wav_muxer_select="riffenc"
>> +webm_chunk_muxer_select="webm_muxer"
>>  webm_muxer_select="iso_media riffenc"
>>  webm_dash_manifest_demuxer_select="matroska_demuxer"
>>  wtv_demuxer_select="mpegts_demuxer riffdec"
>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>> index 9d4c230bcf..f72fa6fb1a 100644
>> --- a/libavformat/Makefile
>> +++ b/libavformat/Makefile
>> @@ -555,7 +555,7 @@ OBJS-$(CONFIG_WEBM_MUXER)+= 
>> matroskaenc.o matroska.o \
>>  wv.o vorbiscomment.o \
>>  webmdashenc.o webm_chunk.o
>>  OBJS-$(CONFIG_WEBM_DASH_MANIFEST_MUXER)  += webmdashenc.o matroska.o
>> -OBJS-$(CONFIG_WEBM_CHUNK_MUXER)  += webm_chunk.o matroska.o
>> +OBJS-$(CONFIG_WEBM_CHUNK_MUXER)  += webm_chunk.o
>>  OBJS-$(CONFIG_WEBP_MUXER)+= webpenc.o
>>  OBJS-$(CONFIG_WEBVTT_DEMUXER)+= webvttdec.o subtitles.o
>>  OBJS-$(CONFIG_WEBVTT_MUXER)  += webvttenc.o
>>
> If no one objects, I'll apply the rest of this patchset tomorrow.
> 
> - Andreas
> 
Applied.

- 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-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] configure: fix clang on macOS 10.15

[Josh de Kock]

Works around a bug in the newer Xcode 11's clang with -fstack-check
emitting bad code with misaligned call instructions.
---
 configure | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configure b/configure
index 4d4c429be9..c872a2932d 100755
--- a/configure
+++ b/configure
@@ -5358,6 +5358,11 @@ case $target_os in
 fi
 version_script='-exported_symbols_list'
 VERSION_SCRIPT_POSTPROCESS_CMD='tr " " "\n" | sed -n 
/global:/,/local:/p | grep ";" | tr ";" "\n" | sed -E "s/(.+)/_\1/g" | sed -E 
"s/(.+[^*])/\1*/"'
+# Workaround for Xcode 11 -fstack-check bug
+if enabled clang; then
+clang_version=$($cc -dumpversion)
+test ${clang_version%%.*} -ge 11 && add_cflags -fno-stack-check
+fi
 ;;
 msys*)
 die "Native MSYS builds are discouraged, please use the MINGW 
environment."
-- 
2.24.1 (Apple Git-126)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter/af_amix: use av_strtod() for weights

[Nicolas George]

Martin Storsjö (12020-04-14):
> This broke fate - on the last iteration, weight_sum is accumulated but we
> break before incrementing i, thus one weight is counted twice.

It should not have been pushed without review in the first place. But
the fact it was pushed without running FATE makes it inexcusable.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter/af_amix: use av_strtod() for weights

[Martin Storsjö]

On Tue, 14 Apr 2020, Paul B Mahol wrote:


ffmpeg | branch: master | Paul B Mahol  | Tue Apr 14 12:38:47 
2020 +0200| [10a68ccd58318c00c7872081a0518acec7ebe6c3] | committer: Paul B Mahol

avfilter/af_amix: use av_strtod() for weights


http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=10a68ccd58318c00c7872081a0518acec7ebe6c3

---

libavfilter/af_amix.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/libavfilter/af_amix.c b/libavfilter/af_amix.c
index af8ad58262..78b7a7c83d 100644
--- a/libavfilter/af_amix.c
+++ b/libavfilter/af_amix.c
@@ -34,6 +34,7 @@
#include "libavutil/avstring.h"
#include "libavutil/channel_layout.h"
#include "libavutil/common.h"
+#include "libavutil/eval.h"
#include "libavutil/float_dsp.h"
#include "libavutil/mathematics.h"
#include "libavutil/opt.h"
@@ -506,9 +507,9 @@ static int activate(AVFilterContext *ctx)
static av_cold int init(AVFilterContext *ctx)
{
MixContext *s = ctx->priv;
-char *p, *arg, *saveptr = NULL;
float last_weight = 1.f;
int i, ret;
+char *p;

for (i = 0; i < s->nb_inputs; i++) {
AVFilterPad pad = { 0 };
@@ -534,13 +535,13 @@ static av_cold int init(AVFilterContext *ctx)

p = s->weights_str;
for (i = 0; i < s->nb_inputs; i++) {
-if (!(arg = av_strtok(p, " ", )))
-break;
-
-p = NULL;
-sscanf(arg, "%f", _weight);
+last_weight = av_strtod(p, );
s->weights[i] = last_weight;
s->weight_sum += FFABS(last_weight);
+if (p && *p)
+p++;
+else
+break;


This broke fate - on the last iteration, weight_sum is accumulated but we 
break before incrementing i, thus one weight is counted twice.


// Martin


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH, v2 1/2] lavc/qsvdec: add decode support for HEVC 4:2:2 8-bit and 10-bit

[Fu, Linjie]

> From: Fu, Linjie 
> Sent: Wednesday, February 26, 2020 16:39
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [PATCH,v2 1/2] lavc/qsvdec: add decode support for HEVC 4:2:2 8-bit
> and 10-bit
> 
> Enables HEVC Range Extension decoding support (Linux) for 4:2:2 8/10 bit
> on ICL+ (gen11 +) platform.
> 
> Signed-off-by: Linjie Fu 
> ---
> [v2]: restrict to support on Linux.
> 
>  libavcodec/qsv.c  | 16 
>  libavutil/hwcontext_qsv.c | 24 
>  2 files changed, 40 insertions(+)
> 
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index db98c75..171a8d6 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -195,6 +195,12 @@ enum AVPixelFormat ff_qsv_map_fourcc(uint32_t
> fourcc)
>  case MFX_FOURCC_NV12: return AV_PIX_FMT_NV12;
>  case MFX_FOURCC_P010: return AV_PIX_FMT_P010;
>  case MFX_FOURCC_P8:   return AV_PIX_FMT_PAL8;
> +#if CONFIG_VAAPI
> +case MFX_FOURCC_YUY2: return AV_PIX_FMT_YUYV422;
> +#if QSV_VERSION_ATLEAST(1, 27)
> +case MFX_FOURCC_Y210: return AV_PIX_FMT_Y210;
> +#endif
> +#endif
>  }
>  return AV_PIX_FMT_NONE;
>  }
> @@ -211,6 +217,16 @@ int ff_qsv_map_pixfmt(enum AVPixelFormat format,
> uint32_t *fourcc)
>  case AV_PIX_FMT_P010:
>  *fourcc = MFX_FOURCC_P010;
>  return AV_PIX_FMT_P010;
> +#if CONFIG_VAAPI
> +case AV_PIX_FMT_YUV422P:
> +*fourcc = MFX_FOURCC_YUY2;
> +return AV_PIX_FMT_YUYV422;
> +#if QSV_VERSION_ATLEAST(1, 27)
> +case AV_PIX_FMT_YUV422P10:
> +*fourcc = MFX_FOURCC_Y210;
> +return AV_PIX_FMT_Y210;
> +#endif
> +#endif
>  default:
>  return AVERROR(ENOSYS);
>  }
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index b1b6740..4306c6e3 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -44,6 +44,10 @@
>  #include "pixdesc.h"
>  #include "time.h"
> 
> +#define QSV_VERSION_ATLEAST(MAJOR, MINOR)   \
> +(MFX_VERSION_MAJOR > (MAJOR) || \
> + MFX_VERSION_MAJOR == (MAJOR) && MFX_VERSION_MINOR >=
> (MINOR))
> +
>  typedef struct QSVDevicePriv {
>  AVBufferRef *child_device_ctx;
>  } QSVDevicePriv;
> @@ -103,6 +107,14 @@ static const struct {
>  { AV_PIX_FMT_BGRA, MFX_FOURCC_RGB4 },
>  { AV_PIX_FMT_P010, MFX_FOURCC_P010 },
>  { AV_PIX_FMT_PAL8, MFX_FOURCC_P8   },
> +#if CONFIG_VAAPI
> +{ AV_PIX_FMT_YUYV422,
> +   MFX_FOURCC_YUY2 },
> +#if QSV_VERSION_ATLEAST(1, 27)
> +{ AV_PIX_FMT_Y210,
> +   MFX_FOURCC_Y210 },
> +#endif
> +#endif
>  };
> 
>  static uint32_t qsv_fourcc_from_pix_fmt(enum AVPixelFormat pix_fmt)
> @@ -773,7 +785,19 @@ static int map_frame_to_surface(const AVFrame
> *frame, mfxFrameSurface1 *surface)
>  surface->Data.R = frame->data[0] + 2;
>  surface->Data.A = frame->data[0] + 3;
>  break;
> +#if CONFIG_VAAPI
> +case AV_PIX_FMT_YUYV422:
> +surface->Data.Y = frame->data[0];
> +surface->Data.U = frame->data[0] + 1;
> +surface->Data.V = frame->data[0] + 3;
> +break;
> 
> +case AV_PIX_FMT_Y210:
> +surface->Data.Y16 = (mfxU16 *)frame->data[0];
> +surface->Data.U16 = (mfxU16 *)frame->data[0] + 1;
> +surface->Data.V16 = (mfxU16 *)frame->data[0] + 3;
> +break;
> +#endif
>  default:
>  return MFX_ERR_UNSUPPORTED;
>  }
> --
Ping for the patch set for 422 8/10 bit:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1582706369-32704-1-git-send-email-linjie...@intel.com/
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1582706402-439-1-git-send-email-linjie...@intel.com/


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-devel, v2] dvbsub.c, change segment order to be in line with spec

[John Stebbins]

On Tue, 2020-04-14 at 10:29 +0200, Paul B Mahol wrote:
> On 4/14/20, Alen Vrečko  wrote:
> > Hello, everyone.
> > 
> > Looks like this patch got forgotten. I'd very much like to see it
> > applied.
> > 
> > In our testing. This patch doesn't break any existing players. But
> > it does
> > allow for older STBs to play subtitles.
> > 
> > If you don't like the patch, feel free to change the order
> > yourself. The
> > current dvb structure order in dvbsub.c is not in line with ETSI EN
> > 300 743
> > (any version).
> > 
> > Spec order: display definition segment > page composition segment >
> > region
> > composition segment > CLUT
> > Your order: display definition segment > page composition segment >
> > *CLUT* >
> > region composition segment
> 
> Is specification freely available?
> 
> > 

I can answer that since I've been poking around in that code lately...
https://www.etsi.org/deliver/etsi_en/300700_300799/300743/01.03.01_60/en_300743v010301p.pdf

The relevant information is in section 4.3

Within a display set the sequence of segments (when present) is:
•display definition segment; 
•page composition; 
•region composition; 
•CLUT definition; 
•object data; 
•end of display set segment. 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 2/3] avdevice/opengl: add support of wrapped avframe codec

[Nicolas George]

Marton Balint (12020-04-11):
> Also change the default to that.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavdevice/opengl_enc.c | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)

No objection. Thanks.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 1/3] avdevice/xv: add support of wrapped avframe codec

[Nicolas George]

Marton Balint (12020-04-11):
> Also change the default to that.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavdevice/xv.c | 22 ++
>  1 file changed, 14 insertions(+), 8 deletions(-)

No objection. Thanks.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3] avformat/mux: Make uncoded frames av_packet_unref() compatible

[Nicolas George]

Andreas Rheinhardt (12020-04-12):
> Currently uncoded frames (i.e. packets whose data actually points to an
> AVFrame) are not refcounted. As a consequence, calling av_packet_unref()
> on them will not free them, but may simply make sure that they leak by
> losing the pointer to the frame.
> 
> This commit changes this by actually making uncoded frames refcounted.
> In order not to rely on sizeof(AVFrame) (which is not part of the public
> API and so must not be used here in libavformat) the packet's data is
> changed to a (padded) buffer containing just a pointer to an AVFrame.
> Said buffer is owned by an AVBuffer with a custom free function that
> frees the frame as well as the buffer. Thereby the pointer/the AVBuffer
> owns the AVFrame.
> 
> Said ownership can actually be transferred by copying and resetting
> the pointer, as might happen when actually writing the uncoded frames
> in AVOutputFormat.write_uncoded_frame() (although currently no muxer
> makes use of this possibility).
> 
> This makes packets containing uncoded frames compatible with
> av_packet_unref(). This already has three advantages in interleaved mode:
> 1. If an error happens at the preparatory steps (before the packet is
> put into the interleavement queue), the frame is properly freed.
> 2. If the trailer is never written, the frames still in the
> interleavement queue will now be properly freed by
> ff_packet_list_free().
> 3. The custom code for moving the packet to the packet list in
> ff_interleave_add_packet() can be removed.
> 
> It will also simplify fixing further memleaks in future commits.
> 
> Suggested-by: Marton Balint 
> Signed-off-by: Andreas Rheinhardt 
> ---
> How embarrassing! The earlier version forgot to check the allocation.

I am confused: does it not make unwrapped frames behave exactly the same
as wrapped frames?

AFAIU, Marton intends to remove all this code, and I think he is right,
because it was a hack.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/3] avformat: deprecate muxing uncoded frames

[Nicolas George]

Marton Balint (12020-04-11):
> The extra allocations and deallocations are barely measurable. So far
> uncoded_frame was used for realtime outputs. So you get, I don't know 100
> packets/frames per second? Allocating those is peanuts, and I have to stress
> that you are not allocating the data, just the AVFrame struct.

Dynamic allocations are expensive. A hundred per second, multiplied by
maybe ten or a thousand for a project that handles several clients
simultaneously, that may make the difference.

But I grant you, there are already a lot of allocations, especially if
interleaving of streams is in action.

> I'd also argue if it is simple for the application. Might be for some
> specific use cases, certainly not for e.g. ffmpeg.c or any other application
> which tries to support multiple output formats. Maybe it is no accident that
> I am not aware of any project on the internet who picked up using this API.
> Are you?

I use it in a few of my projects, at least.

> Maintenance for *us* is significant, see the mux.c patches Andreas sent to
> patch the various bugs caused by exceptions in the muxing code. And his
> preferred solution is to wrap the frame in an AVPacket where the destructor
> frees the AVFrame. Just like AVCODEC_ID_WRAPPED_FRAME does it.

Yes, I remembered these issues had to be fixed when designed uncoded
frames.

> Sorry, I don't see the benefits of keeping the API, I only see the huge
> maintenance burden our our part. I'd just drop it at the next bump.

After a closer look, I say this:

For the maintenance burden of mux.c, go ahead, remove everything related
to uncoded frame. In this part of code, uncoded frames and wrapped
frames are the same thing, just implemented differently. The wrapped
frame implementation is cleaner, so let us choose this one.

But in that case, av_write_uncoded_frame() just becomes an utility
function that does wrapped_avframe_encode() and av_write_frame(). It
makes writing applications easier: let us keep it that way. Utility
functions are not maintenance burden.

And at the other end, when calling output format callbacks, the handling
for write_uncoded_frame() is six lines of leaf code. We can keep it if
it makes decoders simpler.

Which leads me to an actual proposition:

Rework your patch to clean up wrapped frames, but leave alone the bits
about uncoded frames that are not in the way: they will be broken, let
them be. When you post your patch, I will try to fix them without
getting in the way. And then we cans discuss with something practical
under our eyes.

> IMHO writing uncoded frame for pulse/alsa audio is pointless. It does not
> support planar, and the performance gain (especially for realtime output) is
> so insignificant, it does not worth maintaining such a feature.

Our ALSA code does not, but ALSA itself supports planar formats, and
adding it to our code is quite easy.

Also, please remember that real-time device exist on machines with very
constrained hardware too.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Moving ffprobe's writers to lavu

[Nicolas George]

Jan Ekström (12020-04-11):
> I think this all depends on how much of a use there is for this sort of thing.
> 
> Just looking at the case of wanting to output data from a filter, I
> would default to the opinion that it would make sense to have these
> writers (or at least some of them) common to the fftools tooling. Then
> common code in the API clients could be written that would utilize the
> metadata or side data that these filters generate.

The way I see it, code common to fftools should be specific to the kind
of applications the fftools are: command-line applications with a lot of
options.

Writing JSON is not specific to command-line applications with a lot of
options. Therefore, it belongs in lavu rather than fftools. That also
means it should be designed more cleanly, which is a good thing.

> Of course, (unfortunately and without actually looking) I would bet
> right now there would be not so much normalization with these filters'
> output, but it would make much more sense to have a common way of
> pushing data out with the frames (be it side data or metadata), which
> then could be pushed out in a required format by the API client. And
> then an example could be added under doc/examples to show API users
> how to output data produced by filters.

What I didn't write in my first mail is that I have a plan. And what you
just described is more or less the third step in it.

The first step is to have clean code to produce formatted output. This
is what I am discussing now.

The second step, see below.

> If you have a feeling there's a specific need for this to be available
> through the library to all components, I would like to hear the
> reasoning. My default would be that the API client should handle
> dumping the data exported by filters into wherever the API client
> requires (memory, file, JSON, XML).

My reasoning is that some formatters are common enough that its logical
to have them in lavu. Just an example: using lavf's HTTP client to POST
a JSON request; if lavu does not have a JSON formatter, new code or
another library is needed. Which is a waste, since there already is
JSON code in FFmpeg.

Note that, on a closer look, not all writers code from ffprobe deserves
to be imported to lavu. The flat/compact/default outputs are way too
specific to ffprobe, and the structure in sections too.

But at the very least JSON and XML serialization APIs would make a lot
of sense.

Also worth noting: writing a low-level JSON or XML serialization API is
actually very easy. It is just a matter of escaping special characters
and printing delimiters. And the bit about where the output should go, I
already solved it with my AVWriter proposition.

What is more work is to write a parser. I had started on a limited XML
parser, but it was too early, it was not ripe in my mind, and I ended up
bikeshedding myself on the actual design.

The other thing that is harder is to write a good high-level API for
serializing structure data to JSON or XML. And the thing is, the reason
I am proposing it now is: I have cracked it, I have a good solution for
our kind of use.

This is the second step of my plan: a lightweight polymorphic
introspection system.

It sounds scary, but it is not. What it means is that you write a small
bit of code that describes a structure: “there is a field quantizer
which is an integer; there is a field noise which is a float; there is a
field name which is a string”. And then you pass around a pointer to
that description, and the JSON or XML code uses it to serialize the
structure.

The first benefit of this system is that if you have n kinds of
structures and m different serialization formats, you only need n+m
code, not n×m.

The next benefit is that it will allow type-safe introspection. Like
what we do with av_opt_set_something(), but not limited to a few types
and more extensible.

And later, it could allow for reliable de-serialization, with limited
need for escaping.

I know this may seem like a castle on the sand, but we have to realize:
incremental changes lead us to local potential pits: suboptimal, not
really convenient APIs that we keep because it would be a lot of work to
redesign them.

Some times, we need annealing.

The move to refcounted frames was one. The move to use AVFrame in
libavfilter, Anton's “evil plan” was another. My rewrite of lavfi's
internals to be non-recursive was yet another.

Well, I say we need annealing for the way we handle structured data.

And I say I can do it, in a way that does not disrupt the project much.
You can trust me on this or ask for details.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/3] lavf/utils: stop using deprecated av_codec_next()

[Josh de Kock]

Signed-off-by: Josh de Kock 
---
 libavformat/utils.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index a58e47fabc..4f777ba849 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -222,7 +222,8 @@ static const AVCodec *find_probe_decoder(AVFormatContext 
*s, const AVStream *st,
 
 if (codec->capabilities & AV_CODEC_CAP_AVOID_PROBING) {
 const AVCodec *probe_codec = NULL;
-while (probe_codec = av_codec_next(probe_codec)) {
+void *iter = NULL;
+while ((probe_codec = av_codec_iterate())) {
 if (probe_codec->id == codec_id &&
 av_codec_is_decoder(probe_codec) &&
 !(probe_codec->capabilities & (AV_CODEC_CAP_AVOID_PROBING 
| AV_CODEC_CAP_EXPERIMENTAL))) {
-- 
2.24.1 (Apple Git-126)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/3] tools: stop using deprecated av_codec_next()

[Josh de Kock]

Signed-off-by: Josh de Kock 
---
 tools/enum_options.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/enum_options.c b/tools/enum_options.c
index 28631d1a6b..548e427b7a 100644
--- a/tools/enum_options.c
+++ b/tools/enum_options.c
@@ -113,13 +113,14 @@ static void show_format_opts(void)
 
 static void show_codec_opts(void)
 {
+void *iter = NULL;
 AVCodec *c = NULL;
 
 printf("@section Generic codec AVOptions\n");
 show_opts(avcodec_get_class());
 
 printf("@section Codec-specific AVOptions\n");
-while ((c = av_codec_next(c))) {
+while ((c = av_codec_iterate())) {
 if (!c->priv_class)
 continue;
 printf("@subsection %s AVOptions\n", c->priv_class->class_name);
-- 
2.24.1 (Apple Git-126)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/3] lavc: stop using deprecated av_codec_next()

[Josh de Kock]

Signed-off-by: Josh de Kock 
---
 libavcodec/options.c | 5 +++--
 libavcodec/tests/utils.c | 3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavcodec/options.c b/libavcodec/options.c
index 35e8ac9313..babab599fc 100644
--- a/libavcodec/options.c
+++ b/libavcodec/options.c
@@ -55,15 +55,16 @@ static void *codec_child_next(void *obj, void *prev)
 
 static const AVClass *codec_child_class_next(const AVClass *prev)
 {
+void *iter = NULL;
 AVCodec *c = NULL;
 
 /* find the codec that corresponds to prev */
-while (prev && (c = av_codec_next(c)))
+while (prev && (c = av_codec_iterate()))
 if (c->priv_class == prev)
 break;
 
 /* find next codec with priv options */
-while (c = av_codec_next(c))
+while (c = av_codec_iterate())
 if (c->priv_class)
 return c->priv_class;
 return NULL;
diff --git a/libavcodec/tests/utils.c b/libavcodec/tests/utils.c
index f6ba7fe66e..5041a4085e 100644
--- a/libavcodec/tests/utils.c
+++ b/libavcodec/tests/utils.c
@@ -19,10 +19,11 @@
 #include "libavcodec/avcodec.h"
 
 int main(void){
+void *iter = NULL;
 AVCodec *codec = NULL;
 int ret = 0;
 
-while (codec = av_codec_next(codec)) {
+while (codec = av_codec_iterate()) {
 if (av_codec_is_encoder(codec)) {
 if (codec->type == AVMEDIA_TYPE_AUDIO) {
 if (!codec->sample_fmts) {
-- 
2.24.1 (Apple Git-126)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] cmdutils: stop using deprecated av_codec_next()

[Josh de Kock]

On Tue, Apr 14, 2020, at 9:09 AM, Anton Khirnov wrote:
> ---
>  fftools/cmdutils.c | 33 +++--
>  1 file changed, 19 insertions(+), 14 deletions(-)
> 
> [...]

LGTM, thanks. I will apply this a bit later after my set (or you can if you 
want it sooner).

-- 
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3 5/9] lavc/libopenh264enc: set slice_mode option to deprecated

[Anton Khirnov]

Quoting Linjie Fu (2020-04-11 12:03:35)
> "slice mode" seems to be unnecessary since it could be determined by
> -slices/max_nal_size.
> 
> default:SM_FIXEDSLCNUM_SLICE mode with cpu-number slices.
> -slices N:  SM_FIXEDSLCNUM_SLICE mode with N slices.
> -max_nal_size:  SM_SIZELIMITED_SLICE mode with limited size slices.
> 
> Add OPENH264_API_SLICE_MODE to remove this option after
> LIBAVCODEC_VERSION_MAJOR = 59.
> 
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/libopenh264enc.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
> index e556f03..3a642f0 100644
> --- a/libavcodec/libopenh264enc.c
> +++ b/libavcodec/libopenh264enc.c
> @@ -33,6 +33,10 @@
>  #include "internal.h"
>  #include "libopenh264.h"
>  
> +#ifndef OPENH264_API_SLICE_MODE
> +#define OPENH264_API_SLICE_MODE(LIBAVCODEC_VERSION_MAJOR < 59)
> +#endif

This should be moved to libavcodec/version.h with an FF_ prefix, so that
it's not overlooked when we bump the version.

Otherwise looks ok

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3 4/9] lavc/libopenh264enc: prompt slice number changing inside libopenh264

[Anton Khirnov]

Quoting Linjie Fu (2020-04-11 12:03:34)
> Libopenh264enc would set the slice according to the number of cpu cores
> if uiSliceNum equals to 0 (auto) in SM_FIXEDSLCNUM_SLICE mode.
> 
> Prompt a warning for user to catch this.
> 
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/libopenh264enc.c | 2 ++
>  1 file changed, 2 insertions(+)

Ok

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3 1/9] lavc/libopenh264enc: Add default qmin/qmax support

[Anton Khirnov]

Quoting Linjie Fu (2020-04-11 12:03:31)
> Set default QP range to (1, 51) instead of (2, 32).
> 
> QP = 0 is not well supported currently in libopenh264. If iMaxQp/iMinQp
> equals 0, the QP range would be changed unexpectedly inside libopenh264
> with a warning:
> 
> Warning:Change QP Range from(0,51) to (12,42)
> 
> [1] 
> 
> [2] 
> 
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/libopenh264enc.c | 10 ++
>  1 file changed, 10 insertions(+)

Looks ok

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 01/10] lavc/libopenh264enc: Add default qmin/qmax support

[Anton Khirnov]

Quoting Fu, Linjie (2020-04-10 15:27:02)
> > From: ffmpeg-devel  On Behalf Of
> > Anton Khirnov
> > Sent: Friday, April 10, 2020 18:12
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 01/10] lavc/libopenh264enc: Add
> > default qmin/qmax support
> > 
> > Quoting Linjie Fu (2020-04-06 13:14:44)
> > > Set default QP range to (1, 51) instead of (2, 32).
> > >
> > > QP = 0 is not well supported currently in libopenh264. If iMaxQp/iMinQp
> > > equals 0, the QP range would be changed unexpectedly inside libopenh264
> > > with a warning:
> > >
> > > Warning:Change QP Range from(0,51) to (12,42)
> > >
> > > [1]
> >  > encoder_ext.cpp#L375>
> > > [2] 
> > >
> > > Signed-off-by: Linjie Fu 
> > > ---
> > >  libavcodec/libopenh264enc.c | 10 ++
> > >  1 file changed, 10 insertions(+)
> > >
> > > diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
> > > index ae6d17c..364926f 100644
> > > --- a/libavcodec/libopenh264enc.c
> > > +++ b/libavcodec/libopenh264enc.c
> > > @@ -135,6 +135,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > >  param.iTargetBitrate = avctx->bit_rate;
> > >  param.iMaxBitrate= FFMAX(avctx->rc_max_rate, avctx-
> > >bit_rate);
> > >  param.iRCMode= RC_QUALITY_MODE;
> > > +// QP = 0 is not well supported, so default to (1, 51)
> > > +param.iMaxQp = avctx->qmax >= 0 ? 
> > > av_clip(avctx->qmax, 1,
> > 51) : 51;
> > > +param.iMinQp = avctx->qmin >= 0 ? 
> > > av_clip(avctx->qmin, 1,
> > param.iMaxQp) : 1;
> > 
> > Should we set them at all if they are not specified by the user?
> 
> The answer is no and that's why I set qmin/qmax to -1 by default, otherwise
> they would be set to (2, 31) by default [1] in VBR mode in FFmpeg.
> 
> > Wouldn't it be better to leave the unset, as is done now?
> 
> Most encoders would prefer to get a default QP range specifically if it's not
> explicitly set by user, either choosing a default value inside ffmpeg or 
> leave it
> unset to be determined in core library/driver, like libx264, vaapi, qsv, 
> nvenc.
> 
> For libopenh264enc specifically, the supported range is (1, 51), qp = 0 is 
> not well
> Supported yet in libopenh264 library [2]. If either of qmin or qmax equals 0, 
> the
> qp range would be reduced to (12, 42) inside libopenh264 library.
> 
> The default QP range is supposed to be as wide as enough IMHO, so set it to 
> (1, 51)
> and avoid the warning inside the library. (and MaxQp =51 is the recommended 
> value
> in the demo config file in /openh264/testbin/welsenc.cfg)
> 
> Thanks for the review.

ok then

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 1/2] libavcodec/libaomenc.c: Support gray input

[Ryo Hirafuji]

Thanks for the review!

This should bump the micro version number in libavcodec/version.h.


OK, I will bump up the version when the problem below is solved.


> That's annoying. I filed a bug to track [1]. The monochrome flag
> itself seems unnecessary for the library rather than just an image
> format, but that's another discussion.
>

 Thanks for creating the issue.

You might be right.
I just need this line to set  the monochrome flag to 1 in Sequence Header
OBU:
> enccfg->monochrome = 1u;

This reads a little strangely to me, maybe something like: U and V
> information is ignored, but must point to valid buffers...?
> [1] https://crbug.com/aomedia/2639


I pasted the stack trace when V plane and U plane are NULL and ffmpeg
crashes:
https://bugs.chromium.org/p/aomedia/issues/detail?id=2639#c1
(ryoh@... is also my account)

If we allocate aom_image with aom_img_alloc function, allocated V plane and
U plane are filled with 0 (not 128, 512 or 2048).
And I don't have to fill them to 128 to obtain a gray image.
(I tried it in https://github.com/link-u/cavif )
So I think these planes are just ignored (but not sure).

2020年4月14日(火) 6:25 James Zern :

> Hi,
>
> On Tue, Apr 7, 2020 at 5:14 PM Ryo Hirafuji 
> wrote:
> >
> > From: Ryo Hirafuji 
> >
> > AV1 decoders, libaomdec and libdav1d, both support grayscale image.
> > However, libaomenc does not support it yet.
> > In this patch, I add a grayscale image support also to libaomenc.
> >
> > Fixes ticket #7599
> > ---
> >  libavcodec/libaomenc.c | 40 +---
> >  1 file changed, 33 insertions(+), 7 deletions(-)
> >
>
> This should bump the micro version number in libavcodec/version.h.
>
> > [...]
> > @@ -979,12 +986,27 @@ static int aom_encode(AVCodecContext *avctx,
> AVPacket *pkt,
> >
> >  if (frame) {
> >  rawimg  = >rawimg;
> > -rawimg->planes[AOM_PLANE_Y] = frame->data[0];
> > -rawimg->planes[AOM_PLANE_U] = frame->data[1];
> > -rawimg->planes[AOM_PLANE_V] = frame->data[2];
> > -rawimg->stride[AOM_PLANE_Y] = frame->linesize[0];
> > -rawimg->stride[AOM_PLANE_U] = frame->linesize[1];
> > -rawimg->stride[AOM_PLANE_V] = frame->linesize[2];
> > +if (frame->format == AV_PIX_FMT_GRAY8 ||
> > +frame->format == AV_PIX_FMT_GRAY10 ||
> > +frame->format == AV_PIX_FMT_GRAY12) {
> > +rawimg->monochrome = 1;
> > +// Information of U and V planes are ignored,
> > +// but must point some valid pointer to avoid SIGSEGV of
> libaom.
>
> That's annoying. I filed a bug to track [1]. The monochrome flag
> itself seems unnecessary for the library rather than just an image
> format, but that's another discussion.
> This reads a little strangely to me, maybe something like: U and V
> information is ignored, but must point to valid buffers...?
>
> [1] https://crbug.com/aomedia/2639
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 6/7] get_bits: change refill to RAD pattern

[Christophe Gisquet]

Described as variant 4 in the linked article.
Results in faster and smaller code. Also, cases for the "refill_all" cases
(usually when we want to empty/fill it) have been inlined.
---
 libavcodec/get_bits.h | 103 +-
 1 file changed, 41 insertions(+), 62 deletions(-)

diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index da054ebfcb..baff86ecf6 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -153,11 +153,7 @@ static inline unsigned int show_bits(GetBitContext *s, int 
n);
  */
 
 #if CACHED_BITSTREAM_READER
-# if BITSTREAM_BITS == 32
-#   define MIN_CACHE_BITS (32-7)
-# else
-#   define MIN_CACHE_BITS  32
-# endif
+#   define MIN_CACHE_BITS (BITSTREAM_BITS-7)
 #elif defined LONG_BITSTREAM_READER
 #   define MIN_CACHE_BITS 32
 #else
@@ -262,46 +258,21 @@ static inline int get_bits_count(const GetBitContext *s)
 }
 
 #if CACHED_BITSTREAM_READER
-static inline void refill_half(GetBitContext *s, int is_le)
+// See variant 4 in the following article:
+// 
https://fgiesen.wordpress.com/2018/02/20/reading-bits-in-far-too-many-ways-part-2/
+static inline void refill_gb(GetBitContext *s, int is_le)
 {
 #if !UNCHECKED_BITSTREAM_READER
 if (s->ptr >= s->buffer_end)
 return;
 #endif
 
-#if BITSTREAM_BITS == 32
-if (s->bits_left > 16) {
-if (is_le)
-s->cache |= (uint32_t)s->ptr[0] << s->bits_left;
-else
-s->cache |= (uint32_t)s->ptr[0] << (32 - s->bits_left);
-s->ptr++;
-s->bits_left += 8;
-return;
-}
-#endif
-
 if (is_le)
-s->cache |= (cache_type)AV_RL_HALF(s->ptr) << s->bits_left;
+s->cache |= (cache_type)AV_RL_ALL(s->ptr) << s->bits_left;
 else
-s->cache |= (cache_type)AV_RB_HALF(s->ptr) << (BITSTREAM_HBITS - 
s->bits_left);
-s->ptr   += sizeof(s->cache)/2;
-s->bits_left += BITSTREAM_HBITS;
-}
-
-static inline void refill_all(GetBitContext *s, int is_le)
-{
-#if !UNCHECKED_BITSTREAM_READER
-if (s->ptr >= s->buffer_end)
-return;
-#endif
-
-if (is_le)
-s->cache = AV_RL_ALL(s->ptr);
-else
-s->cache = AV_RB_ALL(s->ptr);
-s->ptr += sizeof(s->cache);
-s->bits_left = BITSTREAM_BITS;
+s->cache |= (cache_type)AV_RB_ALL(s->ptr) >> s->bits_left;
+s->ptr   += (BITSTREAM_BITS-1 - s->bits_left) >> 3;
+s->bits_left |= BITSTREAM_BITS-8;
 }
 
 static inline cache_type get_val(GetBitContext *s, unsigned n, int is_le)
@@ -374,9 +345,9 @@ static inline int get_xbits(GetBitContext *s, int n)
 
 if (n > s->bits_left)
 #ifdef BITSTREAM_READER_LE
-refill_half(s, 1);
+refill_gb(s, 1);
 #else
-refill_half(s, 0);
+refill_gb(s, 0);
 #endif
 
 #if BITSTREAM_BITS == 32
@@ -448,9 +419,9 @@ static inline unsigned int get_bits(GetBitContext *s, int n)
 av_assert2(n>0 && n<=32);
 if (n > s->bits_left) {
 #ifdef BITSTREAM_READER_LE
-refill_half(s, 1);
+refill_gb(s, 1);
 #else
-refill_half(s, 0);
+refill_gb(s, 0);
 #endif
 if (s->bits_left < BITSTREAM_HBITS)
 s->bits_left = n;
@@ -486,7 +457,7 @@ static inline unsigned int get_bits_le(GetBitContext *s, 
int n)
 #if CACHED_BITSTREAM_READER
 av_assert2(n>0 && n<=32);
 if (n > s->bits_left) {
-refill_half(s, 1);
+refill_gb(s, 1);
 if (s->bits_left < BITSTREAM_HBITS)
 s->bits_left = n;
 }
@@ -513,9 +484,9 @@ static inline unsigned int show_bits(GetBitContext *s, int 
n)
 #if CACHED_BITSTREAM_READER
 if (n > s->bits_left)
 #ifdef BITSTREAM_READER_LE
-refill_half(s, 1);
+refill_gb(s, 1);
 #else
-refill_half(s, 0);
+refill_gb(s, 0);
 #endif
 
 tmp = show_val(s, n);
@@ -535,7 +506,6 @@ static inline void skip_bits(GetBitContext *s, int n)
 skip_remaining(s, n);
 else {
 n -= s->bits_left;
-s->cache = 0;
 
 if (n >= BITSTREAM_BITS) {
 unsigned skip = n / 8;
@@ -543,11 +513,14 @@ static inline void skip_bits(GetBitContext *s, int n)
 n -= 8*skip;
 s->ptr += skip;
 }
+
 #ifdef BITSTREAM_READER_LE
-refill_all(s, 1);
+s->cache = AV_RL_ALL(s->ptr);
 #else
-refill_all(s, 0);
+s->cache = AV_RB_ALL(s->ptr);
 #endif
+s->ptr  += sizeof(cache_type);
+s->bits_left = BITSTREAM_BITS;
 if (n)
 skip_remaining(s, n);
 }
@@ -561,12 +534,15 @@ static inline void skip_bits(GetBitContext *s, int n)
 static inline unsigned int get_bits1(GetBitContext *s)
 {
 #if CACHED_BITSTREAM_READER
-if (!s->bits_left)
+if (!s->bits_left) {
 #ifdef BITSTREAM_READER_LE
-refill_all(s, 1);
+s->cache = AV_RL_ALL(s->ptr);
 #else
-refill_all(s, 0);
+s->cache = AV_RB_ALL(s->ptr);
 #endif
+s->ptr  += sizeof(cache_type);
+s->bits_left = BITSTREAM_BITS;
+}
 
 #ifdef BITSTREAM_READER_LE
 

[FFmpeg-devel] [PATCH 4/7] get_bits: replace index by an incremented pointer

[Christophe Gisquet]

The main effect is actually code size reduction, due to the smaller
refill code (or difference in inlining decision), e.g. on Win32 of
{magicyuv,huffyuvdec,utvideodec}.o as follows:
19068/41460/16512  ->  18892/40760/16448

It should also be a small speedup (because it simplifies the address
computation), but no change was measured.
---
 libavcodec/get_bits.h | 43 +--
 1 file changed, 25 insertions(+), 18 deletions(-)

diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index 59bfbdd88b..4f75f9dd84 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -91,10 +91,12 @@ typedef uint32_t cache_type;
 typedef struct GetBitContext {
 const uint8_t *buffer, *buffer_end;
 #if CACHED_BITSTREAM_READER
+const uint8_t *ptr;
 cache_type cache;
 unsigned bits_left;
+#else
+int index; // Cached version advances ptr instead
 #endif
-int index;
 int size_in_bits;
 int size_in_bits_plus8;
 } GetBitContext;
@@ -253,7 +255,7 @@ static inline unsigned int show_bits(GetBitContext *s, int 
n);
 static inline int get_bits_count(const GetBitContext *s)
 {
 #if CACHED_BITSTREAM_READER
-return s->index - s->bits_left;
+return 8*(s->ptr - s->buffer) - s->bits_left;
 #else
 return s->index;
 #endif
@@ -263,42 +265,42 @@ static inline int get_bits_count(const GetBitContext *s)
 static inline void refill_half(GetBitContext *s, int is_le)
 {
 #if !UNCHECKED_BITSTREAM_READER
-if (s->index >> 3 >= s->buffer_end - s->buffer)
+if (s->ptr >= s->buffer_end)
 return;
 #endif
 
 #if BITSTREAM_BITS == 32
 if (s->bits_left > 16) {
 if (is_le)
-s->cache |= (uint32_t)s->buffer[s->index >> 3] << s->bits_left;
+s->cache |= (uint32_t)s->ptr[0] << s->bits_left;
 else
-s->cache |= (uint32_t)s->buffer[s->index >> 3] << (32 - s->bits_left);
-s->index += 8;
+s->cache |= (uint32_t)s->ptr[0] << (32 - s->bits_left);
+s->ptr++;
 s->bits_left += 8;
 return;
 }
 #endif
 
 if (is_le)
-s->cache |= (cache_type)AV_RL_HALF(s->buffer + (s->index >> 3)) << 
s->bits_left;
+s->cache |= (cache_type)AV_RL_HALF(s->ptr) << s->bits_left;
 else
-s->cache |= (cache_type)AV_RB_HALF(s->buffer + (s->index >> 3)) << 
(BITSTREAM_HBITS - s->bits_left);
-s->index += BITSTREAM_HBITS;
+s->cache |= (cache_type)AV_RB_HALF(s->ptr) << (BITSTREAM_HBITS - 
s->bits_left);
+s->ptr   += sizeof(s->cache)/2;
 s->bits_left += BITSTREAM_HBITS;
 }
 
 static inline void refill_all(GetBitContext *s, int is_le)
 {
 #if !UNCHECKED_BITSTREAM_READER
-if (s->index >> 3 >= s->buffer_end - s->buffer)
+if (s->ptr >= s->buffer_end)
 return;
 #endif
 
 if (is_le)
-s->cache = AV_RL_ALL(s->buffer + (s->index >> 3));
+s->cache = AV_RL_ALL(s->ptr);
 else
-s->cache = AV_RB_ALL(s->buffer + (s->index >> 3));
-s->index += BITSTREAM_BITS;
+s->cache = AV_RB_ALL(s->ptr);
+s->ptr += sizeof(s->cache);
 s->bits_left = BITSTREAM_BITS;
 }
 
@@ -534,13 +536,12 @@ static inline void skip_bits(GetBitContext *s, int n)
 else {
 n -= s->bits_left;
 s->cache = 0;
-s->bits_left = 0;
 
 if (n >= BITSTREAM_BITS) {
-unsigned skip = (n / 8) * 8;
+unsigned skip = n / 8;
 
-n -= skip;
-s->index += skip;
+n -= 8*skip;
+s->ptr += skip;
 }
 #ifdef BITSTREAM_READER_LE
 refill_all(s, 1);
@@ -699,12 +700,14 @@ static inline int init_get_bits_xe(GetBitContext *s, 
const uint8_t *buffer,
 s->size_in_bits   = bit_size;
 s->size_in_bits_plus8 = bit_size + 8;
 s->buffer_end = buffer + buffer_size;
-s->index  = 0;
 
 #if CACHED_BITSTREAM_READER
+s->ptr= buffer;
 s->cache  = 0;
 s->bits_left  = 0;
 refill_all(s, is_le);
+#else
+s->index  = 0;
 #endif
 
 return ret;
@@ -757,7 +760,11 @@ static inline const uint8_t *align_get_bits(GetBitContext 
*s)
 int n = -get_bits_count(s) & 7;
 if (n)
 skip_bits(s, n);
+#if CACHED_BITSTREAM_READER
+return s->ptr;
+#else
 return s->buffer + (s->index >> 3);
+#endif
 }
 
 /**
-- 
2.26.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 7/7] get_bits: use immediate in skip_remaining

[Christophe Gisquet]

When the entry informs to continue reading, this means the current read
will be entirely skipped. Small object size reduction, depending on
inlining.
---
 libavcodec/get_bits.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index baff86ecf6..d1e29b9917 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -793,7 +793,7 @@ static inline const uint8_t *align_get_bits(GetBitContext 
*s)
 code  = table[index][0];\
 n = table[index][1];\
 if (max_depth > 2 && n < 0) {   \
-LAST_SKIP_BITS(name, gb, nb_bits);  \
+LAST_SKIP_BITS(name, gb, bits); \
 UPDATE_CACHE(name, gb); \
 \
 nb_bits = -n;   \
@@ -878,7 +878,7 @@ static av_always_inline int get_vlc2(GetBitContext *s, 
VLC_TYPE (*table)[2],
 skip_remaining(s, bits);
 code = set_idx(s, code, , _bits, table);
 if (max_depth > 2 && n < 0) {
-skip_remaining(s, nb_bits);
+skip_remaining(s, bits);
 code = set_idx(s, code, , _bits, table);
 }
 }
-- 
2.26.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 5/7] get_bits: improve and fix get_bits_long for 32b

[Christophe Gisquet]

The new code is guaranteed to read at least 32bits, which is likely ok with
the usual case that get_bits without cache can read up to 25.
---
 libavcodec/get_bits.h | 29 ++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index 4f75f9dd84..da054ebfcb 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -608,21 +608,44 @@ static inline void skip_bits1(GetBitContext *s)
  */
 static inline unsigned int get_bits_long(GetBitContext *s, int n)
 {
+unsigned ret = 0;
 av_assert2(n>=0 && n<=32);
 if (!n) {
 return 0;
 #if CACHED_BITSTREAM_READER
 }
-return get_bits(s, n);
+
+# ifdef BITSTREAM_READER_LE
+unsigned left = 0;
+# endif
+if (n > s->bits_left) {
+n -= s->bits_left;
+# ifdef BITSTREAM_READER_LE
+left = s->bits_left;
+ret = get_val(s, s->bits_left, 1);
+refill_all(s, 1);
+# else
+ret = get_val(s, s->bits_left, 0);
+refill_all(s, 0);
+# endif
+}
+
+#ifdef BITSTREAM_READER_LE
+ret = get_val(s, n, 1) << left | ret;
+#else
+ret = get_val(s, n, 0) | ret << n;
+#endif
+
+return ret;
 #else
 } else if (n <= MIN_CACHE_BITS) {
 return get_bits(s, n);
 } else {
 #ifdef BITSTREAM_READER_LE
-unsigned ret = get_bits(s, 16);
+ret = get_bits(s, 16);
 return ret | (get_bits(s, n - 16) << 16);
 #else
-unsigned ret = get_bits(s, 16) << (n - 16);
+ret = get_bits(s, 16) << (n - 16);
 return ret | get_bits(s, n - 16);
 #endif
 }
-- 
2.26.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 0/7] Port cache bitstream reader to 32bits, and improve

[Christophe Gisquet]

This patch series gathers all changes affecting the cached reader and
the file get_bits.h.
The largest consists in modifying the cached reader so that the cache
can be selected to be (native) 32 bits large. Then, due to some corner
cases from various codecs, reducing some reads or fixing functions that
can not guarantee the usual number of bits, are needed.

Note: the MVHA sample was generated using the pattern generation from
VirtualDub2 (Tools->Create test video->zone plates) and the MVHA codec,
and is 235186 bytes.

Christophe Gisquet (7):
  fate: add a MVHA test
  get_bits: support 32bits cache
  get_xbits: request fewer bits
  get_bits: replace index by an incremented pointer
  get_bits: improve and fix get_bits_long for 32b
  get_bits: change refill to RAD pattern
  get_bits: use immediate in skip_remaining

 libavcodec/get_bits.h   | 193 +++-
 libavcodec/mvha.c   |   2 +-
 libavcodec/utvideodec.c |   2 +-
 tests/fate/video.mak|   3 +
 tests/ref/fate/mvha |   6 ++
 5 files changed, 143 insertions(+), 63 deletions(-)
 create mode 100644 tests/ref/fate/mvha

-- 
2.26.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/7] fate: add a MVHA test

[Christophe Gisquet]

---
 tests/fate/video.mak | 3 +++
 tests/ref/fate/mvha  | 6 ++
 2 files changed, 9 insertions(+)
 create mode 100644 tests/ref/fate/mvha

diff --git a/tests/fate/video.mak b/tests/fate/video.mak
index d2d43e518d..8e54718c16 100644
--- a/tests/fate/video.mak
+++ b/tests/fate/video.mak
@@ -364,6 +364,9 @@ fate-xxan-wc4: CMD = framecrc -i 
$(TARGET_SAMPLES)/wc4-xan/wc4trailer-partial.av
 FATE_VIDEO-$(call DEMDEC, WAV, SMVJPEG) += fate-smvjpeg
 fate-smvjpeg: CMD = framecrc -idct simple -flags +bitexact -i 
$(TARGET_SAMPLES)/smv/clock.smv -an
 
+FATE_VIDEO-$(call DEMDEC, AVI, MVHA) += fate-mvha
+fate-mvha: CMD = framecrc -i $(TARGET_SAMPLES)/mvha/mvha.avi -an
+
 FATE_VIDEO += $(FATE_VIDEO-yes)
 
 FATE_SAMPLES_FFMPEG += $(FATE_VIDEO)
diff --git a/tests/ref/fate/mvha b/tests/ref/fate/mvha
new file mode 100644
index 00..3635f97730
--- /dev/null
+++ b/tests/ref/fate/mvha
@@ -0,0 +1,6 @@
+#tb 0: 1001/3
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 640x480
+#sar 0: 0/1
+0,  0,  0,1,   614400, 0xff8fb84b
-- 
2.26.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/7] get_bits: support 32bits cache

[Christophe Gisquet]

Therefore, also activate it under ARCH_X86 (testing for more archs welcome)
for the only codecs supporting said cache reader.
For UTVideo, on 8 bits samples and ARCH_X86_32 (X86_64 being unaffected),
timings for one line do ~19.4k -> 15.1k and 16.5k (roughly 17% speedup).
---
 libavcodec/get_bits.h   | 110 
 libavcodec/mvha.c   |   2 +-
 libavcodec/utvideodec.c |   2 +-
 3 files changed, 80 insertions(+), 34 deletions(-)

diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index 66fb877599..cb4df98e54 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -58,10 +58,40 @@
 #define CACHED_BITSTREAM_READER 0
 #endif
 
+#if CACHED_BITSTREAM_READER
+
+# ifndef BITSTREAM_BITS
+#   if HAVE_FAST_64BIT || defined(LONG_BITSTREAM_READER)
+# define BITSTREAM_BITS   64
+#   else
+# define BITSTREAM_BITS   32
+#   endif
+# endif
+
+# if BITSTREAM_BITS == 64
+#   define BITSTREAM_HBITS  32
+typedef uint64_t cache_type;
+#   define AV_RB_ALL  AV_RB64
+#   define AV_RL_ALL  AV_RL64
+#   define AV_RB_HALF AV_RB32
+#   define AV_RL_HALF AV_RL32
+#   define CACHE_TYPE(a) UINT64_C(a)
+# else
+#   define BITSTREAM_HBITS  16
+typedef uint32_t cache_type;
+#   define AV_RB_ALL  AV_RB32
+#   define AV_RL_ALL  AV_RL32
+#   define AV_RB_HALF AV_RB16
+#   define AV_RL_HALF AV_RL16
+#   define CACHE_TYPE(a) UINT32_C(a)
+#endif
+
+#endif
+
 typedef struct GetBitContext {
 const uint8_t *buffer, *buffer_end;
 #if CACHED_BITSTREAM_READER
-uint64_t cache;
+cache_type cache;
 unsigned bits_left;
 #endif
 int index;
@@ -121,7 +151,11 @@ static inline unsigned int show_bits(GetBitContext *s, int 
n);
  */
 
 #if CACHED_BITSTREAM_READER
-#   define MIN_CACHE_BITS 64
+# if BITSTREAM_BITS == 32
+#   define MIN_CACHE_BITS (32-7)
+# else
+#   define MIN_CACHE_BITS  32
+# endif
 #elif defined LONG_BITSTREAM_READER
 #   define MIN_CACHE_BITS 32
 #else
@@ -226,22 +260,34 @@ static inline int get_bits_count(const GetBitContext *s)
 }
 
 #if CACHED_BITSTREAM_READER
-static inline void refill_32(GetBitContext *s, int is_le)
+static inline void refill_half(GetBitContext *s, int is_le)
 {
 #if !UNCHECKED_BITSTREAM_READER
 if (s->index >> 3 >= s->buffer_end - s->buffer)
 return;
 #endif
 
+#if BITSTREAM_BITS == 32
+if (s->bits_left > 16) {
+if (is_le)
+s->cache |= (uint32_t)s->buffer[s->index >> 3] << s->bits_left;
+else
+s->cache |= (uint32_t)s->buffer[s->index >> 3] << (32 - s->bits_left);
+s->index += 8;
+s->bits_left += 8;
+return;
+}
+#endif
+
 if (is_le)
-s->cache = (uint64_t)AV_RL32(s->buffer + (s->index >> 3)) << 
s->bits_left | s->cache;
+s->cache |= (cache_type)AV_RL_HALF(s->buffer + (s->index >> 3)) << 
s->bits_left;
 else
-s->cache = s->cache | (uint64_t)AV_RB32(s->buffer + (s->index >> 3)) 
<< (32 - s->bits_left);
-s->index += 32;
-s->bits_left += 32;
+s->cache |= (cache_type)AV_RB_HALF(s->buffer + (s->index >> 3)) << 
(BITSTREAM_HBITS - s->bits_left);
+s->index += BITSTREAM_HBITS;
+s->bits_left += BITSTREAM_HBITS;
 }
 
-static inline void refill_64(GetBitContext *s, int is_le)
+static inline void refill_all(GetBitContext *s, int is_le)
 {
 #if !UNCHECKED_BITSTREAM_READER
 if (s->index >> 3 >= s->buffer_end - s->buffer)
@@ -249,22 +295,22 @@ static inline void refill_64(GetBitContext *s, int is_le)
 #endif
 
 if (is_le)
-s->cache = AV_RL64(s->buffer + (s->index >> 3));
+s->cache = AV_RL_ALL(s->buffer + (s->index >> 3));
 else
-s->cache = AV_RB64(s->buffer + (s->index >> 3));
-s->index += 64;
-s->bits_left = 64;
+s->cache = AV_RB_ALL(s->buffer + (s->index >> 3));
+s->index += BITSTREAM_BITS;
+s->bits_left = BITSTREAM_BITS;
 }
 
-static inline uint64_t get_val(GetBitContext *s, unsigned n, int is_le)
+static inline cache_type get_val(GetBitContext *s, unsigned n, int is_le)
 {
-uint64_t ret;
+cache_type ret;
 av_assert2(n>0 && n<=63);
 if (is_le) {
-ret = s->cache & ((UINT64_C(1) << n) - 1);
+ret = s->cache & ((CACHE_TYPE(1) << n) - 1);
 s->cache >>= n;
 } else {
-ret = s->cache >> (64 - n);
+ret = s->cache >> (BITSTREAM_BITS - n);
 s->cache <<= n;
 }
 s->bits_left -= n;
@@ -274,12 +320,12 @@ static inline uint64_t get_val(GetBitContext *s, unsigned 
n, int is_le)
 static inline unsigned show_val(const GetBitContext *s, unsigned n)
 {
 #ifdef BITSTREAM_READER_LE
-return s->cache & ((UINT64_C(1) << n) - 1);
+return s->cache & ((CACHE_TYPE(1) << n) - 1);
 #else
-return s->cache >> (64 - n);
+return s->cache >> (BITSTREAM_BITS - n);
 #endif
 }
-#endif
+#endif // ~CACHED_BITSTREAM_READER
 
 /**
  * Skips the specified number of bits.
@@ -384,11 +430,11 @@ static inline unsigned int get_bits(GetBitContext *s, int 
n)
 av_assert2(n>0 && n<=32);
 if (n > 

[FFmpeg-devel] [PATCH 3/7] get_xbits: request fewer bits

[Christophe Gisquet]

Also allows it to not break 32bits readers.
---
 libavcodec/get_bits.h | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index cb4df98e54..59bfbdd88b 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -367,8 +367,24 @@ static inline void skip_remaining(GetBitContext *s, 
unsigned n)
 static inline int get_xbits(GetBitContext *s, int n)
 {
 #if CACHED_BITSTREAM_READER
-int32_t cache = show_bits(s, 32);
-int sign = ~cache >> 31;
+int32_t cache;
+int sign;
+
+if (n > s->bits_left)
+#ifdef BITSTREAM_READER_LE
+refill_half(s, 1);
+#else
+refill_half(s, 0);
+#endif
+
+#if BITSTREAM_BITS == 32
+cache = s->cache;
+#elif defined(BITSTREAM_READER_LE)
+cache = s->cache & 0x;
+#else
+cache = s->cache >> 32;
+#endif
+sign = ~cache >> 31;
 skip_remaining(s, n);
 
 return uint32_t)(sign ^ cache)) >> (32 - n)) ^ sign) - sign;
-- 
2.26.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3] lavfi: add new iteration API

[Lynne]

Apr 14, 2020, 09:52 by j...@itanimul.li:

> Hi,
>
> On Mon, Apr 13, 2020, at 10:32 PM, Josh Allmann wrote:
>
>> Hi,
>>
>> On Sat, 24 Mar 2018 at 14:40, Josh de Kock  wrote:
>> >
>> > Signed-off-by: Josh de Kock 
>> > ---
>> >  configure|  29 +-
>> >  doc/APIchanges   |   4 +
>> >  doc/writing_filters.txt  |   6 +-
>> >  libavfilter/allfilters.c | 823 
>> > +--
>> >  libavfilter/avfilter.c   |  50 +--
>> >  libavfilter/avfilter.h   |  29 +-
>> >  libavfilter/version.h|   3 +
>> >  7 files changed, 489 insertions(+), 455 deletions(-)
>> >
>>
>> This is a couple years too late, but wanted to drop a note that this
>> particular API change was breaking : it made avfilter_register a
>> no-op. The consequence is that it's much more difficult to maintain
>> filters out-of-tree; preserving the old behavior without changes to
>> user code requires a special build of ffmpeg that has the filter
>> configured/compiled in. The recommended workaround of using
>> avfilter_graph_alloc_filter requires more effort to wire the filter in
>> explicitly. It also doesn't allow for conveniences such as using
>> avfilter_graph_parse, since there doesn't seem to be a way to make
>> filters accessible via avfilter_get_by_name outside of ffmpeg compile
>> time.
>>
>> If there is another workaround that I'm missing, please let me know,
>> or if there's some deeper rationale for the decision to disable this
>> feature.
>>
>
> This was actually an intentional change, there was some trouble with how
> external codecs/filters/etc should be handled.
>
> Since this was an unsupported use-case which was quite sensitive to ABI the
> change was there to explicitly prevent people (ab)using the API like this.  It
> was also to prepare for potentially a new API to implement this in a proper
> fashion (but as you can see this was never completed).
>
> I did begin working on this again a little while back but due to an 
> unfortunate
> data-loss I will have to start from scratch to continue working on it (yes, 
> yes
> 'where's your backup?' I know). It's likely to be something I will be working
> on in the future since I will be doing FFmpeg stuff again soon.
>
> There is also the discussion of 'do we want this?' from a more ideological
> perspective which we will have to re-discuss, maybe something like gstreamer 
> is
> more suited for the majority of the use-cases (?).
>

Nope, we definitely don't want to do this. NAK. Have you seen the trashfire of 
random
outdated proprietary (and free) plugins for gstreamer?
Removing the option of abusing the API like that was also somewhat motivated by
preventing that scenario from happening, at the cost of making fuzzing take 
longer.
This was answered in the original discussion, there's no reason to bring this 
up now,
nothing has changed.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2] ffmpeg: allow full range of dts_delta_threshold

[Gyan Doshi]

For inputs from demuxers with AVFMT_TS_DISCONT flag,
the existing condition,

  delta < -1LL*dts_delta_threshold*AV_TIME_BASE

is rendered superflous due to the fixed threshold in

pkt_dts + AV_TIME_BASE/10 < FFMAX(ist->pts, ist->dts)

This prevents users from setting a high threshold to
avoid discontinuity correction due to errant timestamps.

Now, the maximum of the two thresholds is used.

fate-mpeg4-resolution-change call changed to preserve existing
timestamp correction by ffmpeg.c
---
Tested with multiple satellite MPEG-TS inputs.

 fftools/ffmpeg.c | 2 +-
 tests/fate/mpeg4.mak | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 0578265c1e..505fef5bdc 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4480,7 +4480,7 @@ static int process_input(int file_index)
 if (is->iformat->flags & AVFMT_TS_DISCONT) {
 if (delta < -1LL*dts_delta_threshold*AV_TIME_BASE ||
 delta >  1LL*dts_delta_threshold*AV_TIME_BASE ||
-pkt_dts + AV_TIME_BASE/10 < FFMAX(ist->pts, ist->dts)) {
+pkt_dts + FFMAX(AV_TIME_BASE/10, 
dts_delta_threshold*AV_TIME_BASE) < FFMAX(ist->pts, ist->dts)) {
 ifile->ts_offset -= delta;
 av_log(NULL, AV_LOG_DEBUG,
"timestamp discontinuity for stream #%d:%d "
diff --git a/tests/fate/mpeg4.mak b/tests/fate/mpeg4.mak
index ed6a2fac20..d7a9c62d7e 100644
--- a/tests/fate/mpeg4.mak
+++ b/tests/fate/mpeg4.mak
@@ -1,7 +1,7 @@
 
 MPEG4_RESOLUTION_CHANGE = down-down down-up up-down up-up
 
-fate-mpeg4-resolution-change-%: CMD = framemd5 -flags +bitexact -idct simple 
-i $(TARGET_SAMPLES)/mpeg4/resize_$(@:fate-mpeg4-resolution-change-%=%).h263 
-sws_flags +bitexact
+fate-mpeg4-resolution-change-%: CMD = framemd5 -dts_delta_threshold 1.99 
-flags +bitexact -idct simple -i 
$(TARGET_SAMPLES)/mpeg4/resize_$(@:fate-mpeg4-resolution-change-%=%).h263 
-sws_flags +bitexact
 
 FATE_MPEG4-$(call DEMDEC, H263, H263) := $(addprefix 
fate-mpeg4-resolution-change-, $(MPEG4_RESOLUTION_CHANGE))
 
-- 
2.26.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: add low_delay_b option for HEVC

[Fu, Linjie]

> From: ffmpeg-devel  On Behalf Of
> Mark Thompson
> Sent: Monday, April 13, 2020 20:20
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: add
> low_delay_b option for HEVC
> 
> On 13/04/2020 05:32, Linjie Fu wrote:
> > Low delay B-frame is supported on ICL+ platform.
> >
> > For low power encoding, low_delay_b should be enabled by default.
> >
> > Low delay B:
> >  Video-Coding-HEVC-288.html>
> >
> > There is an on-going work in libva and media-driver to add querys
> > support for low delay b, would add it once it's ready:
> > https://github.com/intel/libva/pull/220
> > https://github.com/intel/libva/pull/364
> > https://github.com/intel/media-driver/issues/721
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  doc/encoders.texi  |  8 
> >  libavcodec/vaapi_encode_h265.c | 19 +--
> >  2 files changed, 25 insertions(+), 2 deletions(-)
> 
> My understanding was that the only reason for this stuff existing was to work
> around broken hardware which didn't support P frames.  Is this no longer
> true?
> 
> >
> > diff --git a/doc/encoders.texi b/doc/encoders.texi
> > index e23b6b3..b0812be 100644
> > --- a/doc/encoders.texi
> > +++ b/doc/encoders.texi
> > @@ -3089,6 +3089,14 @@ Some combination of the following values:
> >  Include HDR metadata if the input frames have it
> >  (@emph{mastering_display_colour_volume} and
> @emph{content_light_level}
> >  messages).
> > +
> > +@item low_delay_b
> > +Use low delay B-frames instead of P frames. Reordering of pictures is
> > +not allowed. The first picture is encoded as an I picture and subsequent
> > +pictures are encoded as B pictures. Moreover, since past B pictures are
> > +used for prediction, a low coding delay but with higher coding efficiency
> > +(because of bi-prediction) is achieved.
> 
> This sounds like a marketing blurb.
> 
> Not for the manual, but can you explain in detail what might actually make
> this better, with actual numbers if possible?  Intuitively the coding 
> efficiency
> will be worse, because a number of the B-picture syntax elements are just
> redundant but still have to be coded (picking between two options which are
> actually identical).  The gain of allowing biprediction between two identical
> pictures doesn't seem like a useful feature.
> 
The story is, this is kind of the hardware limitation for VDENC as we've 
discussed
on IRC.

As to the performance/efficiency, I'm curious too and would take some 
experiments.

This patch is kind of insufficient, updated a new version, to distinguish 
low_delay_b
and reference B frames, thx.

- Linjie
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavu/mem: Make alloc array functions more similar to av_malloc

[Nicolas George]

Anton Khirnov (12020-04-14):
> IIUC some platforms had problems with malloc(0)
> Plus I don't think any valid code should ever malloc zero bytes, so my
> suggestion would be for all malloc wrappers to:
> - av_assert2(size > 0)
> - return NULL otherwise

I think this is a very good idea.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] kmsgrab: Drop DRM master if running as root

[Anton Khirnov]

Quoting Mark Thompson (2020-04-12 16:46:25)
> If we have both root and DRM master then drop the latter because we
> don't need both and holding onto it can interfere with running other
> programs.
> 
> From a discussion with deltasquared on IRC.
> ---
> It would be marginally better to check whether we have CAP_SYS_ADMIN rather 
> than just whether we are effectively root, but the capabilities interface is 
> a lot more complex to query and this is already sufficient to cover the 
> reported case.
> 
>  libavdevice/kmsgrab.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/libavdevice/kmsgrab.c b/libavdevice/kmsgrab.c
> index d0de774871..53280da0f5 100644
> --- a/libavdevice/kmsgrab.c
> +++ b/libavdevice/kmsgrab.c
> @@ -263,6 +263,13 @@ static av_cold int kmsgrab_read_header(AVFormatContext 
> *avctx)
>  ctx->device = (AVHWDeviceContext*) ctx->device_ref->data;
>  ctx->hwctx  = (AVDRMDeviceContext*)ctx->device->hwctx;
>  
> +if (geteuid() == 0 && drmIsMaster(ctx->hwctx->fd)) {
> +// If we have both root and DRM master then drop the latter
> +// because we don't need both and holding onto it can interfere
> +// with running other programs.
> +drmDropMaster(ctx->hwctx->fd);
> +}

Any idea how would this interact with user namespaces?

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavu/mem: Make alloc array functions more similar to av_malloc

[Anton Khirnov]

Quoting James Almer (2020-04-12 22:47:55)
> On 4/11/2020 8:53 PM, Carl Eugen Hoyos wrote:
> > Am So., 12. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> > :
> >>
> >> Am So., 5. Apr. 2020 um 14:03 Uhr schrieb Michael Niedermayer
> >> :
> >>>
> >>> On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
>  Hi!
> 
>  Attached patch makes the alloc array functions more similar to
>  av_malloc, depending on max_alloc_size instead of INT_MAX.
> 
>  Allows a work-around for ticket #7140
> 
>  Please comment, Carl Eugen
> >>>
>   mem.c |8 
>   1 file changed, 4 insertions(+), 4 deletions(-)
>  507531ed6f0932834d005bc1dd7d18e762f158b2  
>  0001-lavu-mem-Make-alloc-array-functions-more-similar-to-.patch
>  From 7ae240a9f7885130251031aba5d0764b11947fec Mon Sep 17 00:00:00 2001
>  From: Carl Eugen Hoyos 
>  Date: Sat, 4 Apr 2020 00:37:03 +0200
>  Subject: [PATCH] lavu/mem: Make alloc array functions more similar to
>   av_malloc().
> 
>  Do not limit the array allocation functions to allocations of INT_MAX,
>  instead depend on max_alloc_size like av_malloc().
> 
>  Allows a workaround for ticket #7140.
>  ---
>   libavutil/mem.c | 8 
>   1 file changed, 4 insertions(+), 4 deletions(-)
> >>>
> >>> av_size_mult() may be faster
> >>
> >> New patch attached.
> > 
> > And an actually working variant.
> > 
> > Please comment, Carl Eugen
> 
> > From 643c501d6698d7d17e47a9f907165649f1446fa6 Mon Sep 17 00:00:00 2001
> > From: Carl Eugen Hoyos 
> > Date: Sun, 12 Apr 2020 00:36:30 +0200
> > Subject: [PATCH] lavu/mem: Make other alloc functions more similar to 
> > av_malloc().
> > 
> > Do not limit the array allocation functions and av_calloc() to allocations
> > of INT_MAX, instead depend on max_alloc_size like av_malloc().
> > 
> > Allows a workaround for ticket #7140.
> > ---
> >  libavutil/mem.c | 20 
> >  1 file changed, 12 insertions(+), 8 deletions(-)
> > 
> > diff --git a/libavutil/mem.c b/libavutil/mem.c
> > index 88fe09b179..e044374c62 100644
> > --- a/libavutil/mem.c
> > +++ b/libavutil/mem.c
> > @@ -183,23 +183,26 @@ int av_reallocp(void *ptr, size_t size)
> >  
> >  void *av_malloc_array(size_t nmemb, size_t size)
> >  {
> > -if (!size || nmemb >= INT_MAX / size)
> > +size_t result;
> > +if (av_size_mult(nmemb, size, ) < 0)
> >  return NULL;
> > -return av_malloc(nmemb * size);
> > +return av_malloc(result);
> 
> If I'm reading this right, when size is 0, instead of NULL this will now
> return av_malloc(0), which looks like it may end up being a pointer to a
> 1 byte big buffer. Is that intended?

IIUC some platforms had problems with malloc(0)
Plus I don't think any valid code should ever malloc zero bytes, so my
suggestion would be for all malloc wrappers to:
- av_assert2(size > 0)
- return NULL otherwise

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3] lavfi: add new iteration API

[Josh de Kock]

Hi,

On Mon, Apr 13, 2020, at 10:32 PM, Josh Allmann wrote:
> Hi,
> 
> On Sat, 24 Mar 2018 at 14:40, Josh de Kock  wrote:
> >
> > Signed-off-by: Josh de Kock 
> > ---
> >  configure|  29 +-
> >  doc/APIchanges   |   4 +
> >  doc/writing_filters.txt  |   6 +-
> >  libavfilter/allfilters.c | 823 
> > +--
> >  libavfilter/avfilter.c   |  50 +--
> >  libavfilter/avfilter.h   |  29 +-
> >  libavfilter/version.h|   3 +
> >  7 files changed, 489 insertions(+), 455 deletions(-)
> >
> 
> This is a couple years too late, but wanted to drop a note that this
> particular API change was breaking : it made avfilter_register a
> no-op. The consequence is that it's much more difficult to maintain
> filters out-of-tree; preserving the old behavior without changes to
> user code requires a special build of ffmpeg that has the filter
> configured/compiled in. The recommended workaround of using
> avfilter_graph_alloc_filter requires more effort to wire the filter in
> explicitly. It also doesn't allow for conveniences such as using
> avfilter_graph_parse, since there doesn't seem to be a way to make
> filters accessible via avfilter_get_by_name outside of ffmpeg compile
> time.
> 
> If there is another workaround that I'm missing, please let me know,
> or if there's some deeper rationale for the decision to disable this
> feature.

This was actually an intentional change, there was some trouble with how
external codecs/filters/etc should be handled.

Since this was an unsupported use-case which was quite sensitive to ABI the
change was there to explicitly prevent people (ab)using the API like this.  It
was also to prepare for potentially a new API to implement this in a proper
fashion (but as you can see this was never completed).

I did begin working on this again a little while back but due to an unfortunate
data-loss I will have to start from scratch to continue working on it (yes, yes
'where's your backup?' I know). It's likely to be something I will be working
on in the future since I will be doing FFmpeg stuff again soon.

There is also the discussion of 'do we want this?' from a more ideological
perspective which we will have to re-discuss, maybe something like gstreamer is
more suited for the majority of the use-cases (?).

-- 
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode_h265: add private b_strategy option for hevc_vaapi

[Linjie Fu]

Allow user to choose between I/P/B frames:

- normal
Ordinary IB..BPB..B GOP structure.
- low delay B-frames:
Allows forward-predict only for all B frames, L0 == L1, supported
on ICL+ platforms, required by VDENC(low_power).
- reference B-frames:
Convert P-frames to low delay B-frames, normal B frames still have
2 different ref_lists and allow bi-prediction.

Low delay B:


There is an on-going work in libva and media-driver to add querys
support for low delay b, would add it once it's ready:
https://github.com/intel/libva/pull/220
https://github.com/intel/libva/pull/364
https://github.com/intel/media-driver/issues/721

Signed-off-by: Linjie Fu 
---
Further step for low delay B would be refining the reference management
to enable support for more forward-references in same ref_list.

 doc/encoders.texi  | 16 
 libavcodec/vaapi_encode.c  | 20 +++-
 libavcodec/vaapi_encode.h  |  1 +
 libavcodec/vaapi_encode_h265.c | 32 +++-
 4 files changed, 63 insertions(+), 6 deletions(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index e23b6b3..1fb5ecf 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -3089,6 +3089,22 @@ Some combination of the following values:
 Include HDR metadata if the input frames have it
 (@emph{mastering_display_colour_volume} and @emph{content_light_level}
 messages).
+
+@item b_strategy
+Allow user to choose between I/P/B frames and specify the type of B-frames.
+@table @samp
+@item normal
+Normal IBBPBB strategy.
+
+@item low_delay_b
+Allows forward-predict only for all B frames, ref_list0 equals to ref_list1,
+supported on ICL+ platforms, required by VDENC(low_power).
+
+@item ref_b
+Convert P-frames to low delay B-frames as references, while normal B frames
+still have 2 different ref_lists and allow bi-prediction.
+@end table
+
 @end table
 
 @end table
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 8ff720e..ea7efb6 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1792,15 +1792,25 @@ static av_cold int 
vaapi_encode_init_gop_structure(AVCodecContext *avctx)
"reference frames.\n");
 return AVERROR(EINVAL);
 } else if (!(ctx->codec->flags & FLAG_B_PICTURES) ||
-   ref_l1 < 1 || avctx->max_b_frames < 1) {
-av_log(avctx, AV_LOG_VERBOSE, "Using intra and P-frames "
-   "(supported references: %d / %d).\n", ref_l0, ref_l1);
+   ref_l1 < 1 || avctx->max_b_frames < 1 ||
+   ctx->b_frame_strategy == 1) {
+if (ctx->b_frame_strategy == 1)
+av_log(avctx, AV_LOG_VERBOSE, "Using intra and B -frames "
+   "(low delay) (supported references: %d / %d).\n",
+   ref_l0, ref_l1);
+else
+av_log(avctx, AV_LOG_VERBOSE, "Using intra and P-frames "
+   "(supported references: %d / %d).\n", ref_l0, ref_l1);
 ctx->gop_size = avctx->gop_size;
 ctx->p_per_i  = INT_MAX;
 ctx->b_per_p  = 0;
 } else {
-av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-frames "
-   "(supported references: %d / %d).\n", ref_l0, ref_l1);
+if (ctx->b_frame_strategy == 2)
+av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-frames "
+   "(supported references: %d / %d).\n", ref_l0, ref_l1);
+else
+av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-frames "
+   "(supported references: %d / %d).\n", ref_l0, ref_l1);
 ctx->gop_size = avctx->gop_size;
 ctx->p_per_i  = INT_MAX;
 ctx->b_per_p  = avctx->max_b_frames;
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index b9a3def..1feca6c 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -310,6 +310,7 @@ typedef struct VAAPIEncodeContext {
 int idr_counter;
 int gop_counter;
 int end_of_stream;
+int b_frame_strategy;
 
 // Whether the driver supports ROI at all.
 int roi_allowed;
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 97dc5a7..cecde73 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -62,6 +62,7 @@ typedef struct VAAPIEncodeH265Context {
 int tier;
 int level;
 int sei;
+int b_frame_strategy;
 
 // Derived settings.
 int fixed_qp_idr;
@@ -894,6 +895,9 @@ static int 
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
 
 sh->slice_type = hpic->slice_type;
 
+if (sh->slice_type == HEVC_SLICE_P && priv->b_frame_strategy)
+sh->slice_type = HEVC_SLICE_B;
+
 sh->slice_pic_order_cnt_lsb = hpic->pic_order_cnt &
 (1 << (sps->log2_max_pic_order_cnt_lsb_minus4 + 4)) - 1;
 
@@ -1052,10 +1056,13 @@ static int 

Re: [FFmpeg-devel] [PATCH v3] lavfi: add new iteration API

[Paul B Mahol]

On 4/13/20, Josh Allmann  wrote:
> Hi,
>
> On Sat, 24 Mar 2018 at 14:40, Josh de Kock  wrote:
>>
>> Signed-off-by: Josh de Kock 
>> ---
>>  configure|  29 +-
>>  doc/APIchanges   |   4 +
>>  doc/writing_filters.txt  |   6 +-
>>  libavfilter/allfilters.c | 823
>> +--
>>  libavfilter/avfilter.c   |  50 +--
>>  libavfilter/avfilter.h   |  29 +-
>>  libavfilter/version.h|   3 +
>>  7 files changed, 489 insertions(+), 455 deletions(-)
>>
>
> This is a couple years too late, but wanted to drop a note that this
> particular API change was breaking : it made avfilter_register a
> no-op. The consequence is that it's much more difficult to maintain
> filters out-of-tree; preserving the old behavior without changes to
> user code requires a special build of ffmpeg that has the filter
> configured/compiled in. The recommended workaround of using
> avfilter_graph_alloc_filter requires more effort to wire the filter in
> explicitly. It also doesn't allow for conveniences such as using
> avfilter_graph_parse, since there doesn't seem to be a way to make
> filters accessible via avfilter_get_by_name outside of ffmpeg compile
> time.
>
> If there is another workaround that I'm missing, please let me know,
> or if there's some deeper rationale for the decision to disable this
> feature.

Out of tree filters are not supported.

>
> Josh
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-devel, v2] dvbsub.c, change segment order to be in line with spec

[Paul B Mahol]

On 4/14/20, Alen Vrečko  wrote:
> Hello, everyone.
>
> Looks like this patch got forgotten. I'd very much like to see it applied.
>
> In our testing. This patch doesn't break any existing players. But it does
> allow for older STBs to play subtitles.
>
> If you don't like the patch, feel free to change the order yourself. The
> current dvb structure order in dvbsub.c is not in line with ETSI EN 300 743
> (any version).
>
> Spec order: display definition segment > page composition segment > region
> composition segment > CLUT
> Your order: display definition segment > page composition segment > *CLUT* >
> region composition segment

Is specification freely available?

>
> Alen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [FFmpeg-devel, v2] dvbsub.c, change segment order to be in line with spec

[Alen Vrečko]

Hello, everyone.

Looks like this patch got forgotten. I'd very much like to see it applied. 

In our testing. This patch doesn't break any existing players. But it does 
allow for older STBs to play subtitles. 

If you don't like the patch, feel free to change the order yourself. The 
current dvb structure order in dvbsub.c is not in line with ETSI EN 300 743 
(any version). 

Spec order: display definition segment > page composition segment > region 
composition segment > CLUT
Your order: display definition segment > page composition segment > *CLUT* > 
region composition segment

Alen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] cmdutils: stop using deprecated av_codec_next()

[Anton Khirnov]

---
 fftools/cmdutils.c | 33 +++--
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index f0f2b4fde4..7f5a5ca664 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -1500,13 +1500,14 @@ static char get_media_type_char(enum AVMediaType type)
 }
 }
 
-static const AVCodec *next_codec_for_id(enum AVCodecID id, const AVCodec *prev,
+static const AVCodec *next_codec_for_id(enum AVCodecID id, void **iter,
 int encoder)
 {
-while ((prev = av_codec_next(prev))) {
-if (prev->id == id &&
-(encoder ? av_codec_is_encoder(prev) : av_codec_is_decoder(prev)))
-return prev;
+const AVCodec *c;
+while ((c = av_codec_iterate(iter))) {
+if (c->id == id &&
+(encoder ? av_codec_is_encoder(c) : av_codec_is_decoder(c)))
+return c;
 }
 return NULL;
 }
@@ -1543,11 +1544,12 @@ static unsigned get_codecs_sorted(const 
AVCodecDescriptor ***rcodecs)
 
 static void print_codecs_for_id(enum AVCodecID id, int encoder)
 {
-const AVCodec *codec = NULL;
+void *iter = NULL;
+const AVCodec *codec;
 
 printf(" (%s: ", encoder ? "encoders" : "decoders");
 
-while ((codec = next_codec_for_id(id, codec, encoder)))
+while ((codec = next_codec_for_id(id, , encoder)))
 printf("%s ", codec->name);
 
 printf(")");
@@ -1570,7 +1572,8 @@ int show_codecs(void *optctx, const char *opt, const char 
*arg)
" ---\n");
 for (i = 0; i < nb_codecs; i++) {
 const AVCodecDescriptor *desc = codecs[i];
-const AVCodec *codec = NULL;
+const AVCodec *codec;
+void *iter = NULL;
 
 if (strstr(desc->name, "_deprecated"))
 continue;
@@ -1588,14 +1591,14 @@ int show_codecs(void *optctx, const char *opt, const 
char *arg)
 
 /* print decoders/encoders when there's more than one or their
  * names are different from codec name */
-while ((codec = next_codec_for_id(desc->id, codec, 0))) {
+while ((codec = next_codec_for_id(desc->id, , 0))) {
 if (strcmp(codec->name, desc->name)) {
 print_codecs_for_id(desc->id, 0);
 break;
 }
 }
-codec = NULL;
-while ((codec = next_codec_for_id(desc->id, codec, 1))) {
+iter = NULL;
+while ((codec = next_codec_for_id(desc->id, , 1))) {
 if (strcmp(codec->name, desc->name)) {
 print_codecs_for_id(desc->id, 1);
 break;
@@ -1626,9 +1629,10 @@ static void print_codecs(int encoder)
encoder ? "Encoders" : "Decoders");
 for (i = 0; i < nb_codecs; i++) {
 const AVCodecDescriptor *desc = codecs[i];
-const AVCodec *codec = NULL;
+const AVCodec *codec;
+void *iter = NULL;
 
-while ((codec = next_codec_for_id(desc->id, codec, encoder))) {
+while ((codec = next_codec_for_id(desc->id, , encoder))) {
 printf(" %c", get_media_type_char(desc->type));
 printf((codec->capabilities & AV_CODEC_CAP_FRAME_THREADS) ? "F" : 
".");
 printf((codec->capabilities & AV_CODEC_CAP_SLICE_THREADS) ? "S" : 
".");
@@ -1833,9 +1837,10 @@ static void show_help_codec(const char *name, int 
encoder)
 if (codec)
 print_codec(codec);
 else if ((desc = avcodec_descriptor_get_by_name(name))) {
+void *iter = NULL;
 int printed = 0;
 
-while ((codec = next_codec_for_id(desc->id, codec, encoder))) {
+while ((codec = next_codec_for_id(desc->id, , encoder))) {
 printed = 1;
 print_codec(codec);
 }
-- 
2.25.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-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/mediacodec_wrapper: fix {input, output}_buffers global reference leak

[Matthieu Bouron]

On Thu, Apr 09, 2020 at 05:06:05PM +0200, Matthieu Bouron wrote:
> Fixes ticket #8607.
> ---
>  libavcodec/mediacodec_wrapper.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
> index 5213cf640a7..79abc8b6aa9 100644
> --- a/libavcodec/mediacodec_wrapper.c
> +++ b/libavcodec/mediacodec_wrapper.c
> @@ -1303,6 +1303,12 @@ int ff_AMediaCodec_delete(FFAMediaCodec* codec)
>  ret = AVERROR_EXTERNAL;
>  }
>  
> +(*env)->DeleteGlobalRef(env, codec->input_buffers);
> +codec->input_buffers = NULL;
> +
> +(*env)->DeleteGlobalRef(env, codec->output_buffers);
> +codec->output_buffers = NULL;
> +
>  (*env)->DeleteGlobalRef(env, codec->object);
>  codec->object = NULL;
>  
> -- 
> 2.26.0
> 

The user confirmed the patch fixes the issue. I will apply this patch
tomorrow if there is no objection.

-- 
Matthieu B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] ffmpeg: allow full range of dts_delta_threshold

[Gyan Doshi]

For inputs from demuxers with AVFMT_TS_DISCONT flag,
the existing condition,

  delta < -1LL*dts_delta_threshold*AV_TIME_BASE

is rendered superflous due to the fixed threshold in

pkt_dts + AV_TIME_BASE/10 < FFMAX(ist->pts, ist->dts)

This prevents users from setting a high threshold to
avoid discontinuity correction due to errant timestamps.

Now, the maximum of the two thresholds is used.
---
Tested with multiple satellite MPEG-TS inputs.

 fftools/ffmpeg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 0578265c1e..505fef5bdc 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4480,7 +4480,7 @@ static int process_input(int file_index)
 if (is->iformat->flags & AVFMT_TS_DISCONT) {
 if (delta < -1LL*dts_delta_threshold*AV_TIME_BASE ||
 delta >  1LL*dts_delta_threshold*AV_TIME_BASE ||
-pkt_dts + AV_TIME_BASE/10 < FFMAX(ist->pts, ist->dts)) {
+pkt_dts + FFMAX(AV_TIME_BASE/10, 
dts_delta_threshold*AV_TIME_BASE) < FFMAX(ist->pts, ist->dts)) {
 ifile->ts_offset -= delta;
 av_log(NULL, AV_LOG_DEBUG,
"timestamp discontinuity for stream #%d:%d "
-- 
2.26.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".