Re: [FFmpeg-devel] [PATCH v1] fftools/ffmpeg: Add support for per frame rotation and flip

[Jun Li]

On Mon, May 13, 2019 at 2:58 AM Michael Niedermayer 
wrote:

> On Sat, May 11, 2019 at 10:57:01PM -0700, Jun Li wrote:
> > On Sat, May 11, 2019 at 10:47 PM Jun Li  wrote:
> >
> > > Fix #6945
> > > Current implementaion for autorotate works fine for stream
> > > level rotataion but no support for frame level operation
> > > and frame flip. This patch is for adding flip support and
> > > per frame operations.
> > > ---
> > >  fftools/cmdutils.c|  9 ++---
> > >  fftools/cmdutils.h|  2 +-
> > >  fftools/ffmpeg.c  | 21 +-
> > >  fftools/ffmpeg.h  |  2 +
> > >  fftools/ffmpeg_filter.c   | 81 ---
> > >  fftools/ffplay.c  | 28 +++---
> > >  libavutil/display.c   | 14 +++
> > >  libavutil/display.h   | 14 +++
> > >  libavutil/tests/display.c |  8 
> > >  tests/ref/fate/display|  4 ++
> > >  10 files changed, 166 insertions(+), 17 deletions(-)
> [...]
>
> > > \ No newline at end of file
>
> > > diff --git a/libavutil/display.h b/libavutil/display.h
> > > index 515adad795..23d71a0bc5 100644
> > > --- a/libavutil/display.h
> > > +++ b/libavutil/display.h
> > > @@ -106,6 +106,20 @@ void av_display_rotation_set(int32_t matrix[9],
> > > double angle);
> > >   */
> > >  void av_display_matrix_flip(int32_t matrix[9], int hflip, int vflip);
> > >
> > > +/**
> > > + * Extract the rotation component and hflip status of the
> transformation
> > > matrix.
> > > + *
> > > + * @param matrix the transformation matrix
> > > + * @param hflip wille be set to 1 if the matrix need horizontal
> flipped
> > > + * @return the angle (in degrees) by which the transformation rotates
> the
> > > frame
> > > + * counterclockwise. The angle will be in range [-180.0,
> 180.0],
> > > + * or NaN if the matrix is singular.
> > > + *
> > > + * @note floating point numbers are inherently inexact, so callers are
> > > + *   recommended to round the return value to nearest integer
> before
> > > use.
> > > + */
> > > +double av_display_rotation_hflip_get(const int32_t matrix[9], int*
> hflip);
> > > +
> > >  /**
> > >   * @}
> > >   * @}
> > > diff --git a/libavutil/tests/display.c b/libavutil/tests/display.c
> > > index 893ebb5543..65a0971e7b 100644
> > > --- a/libavutil/tests/display.c
> > > +++ b/libavutil/tests/display.c
> > > @@ -35,6 +35,8 @@ static void print_matrix(int32_t matrix[9])
> > >  int main(void)
> > >  {
> > >  int32_t matrix[9];
> > > +int hflip = 0;
> > > +double degree;
> > >
> > >  // Set the matrix to 90 degrees
> > >  av_display_rotation_set(matrix, 90);
> > > @@ -56,6 +58,12 @@ int main(void)
> > >  print_matrix(matrix);
> > >  printf("degrees: %f\n", av_display_rotation_get(matrix));
> > >
> > > +// flip vertical
> > > +av_display_matrix_flip(matrix, 0, 1);
> > > +print_matrix(matrix);
> > > +degree = av_display_rotation_hflip_get(matrix, );
> > > +printf("degrees: %f, hflip: %i\n", degree, hflip);
> > > +
> > >  return 0;
> > >
> > >  }
>
> [...]
>
> > This change is to address the feedback of last patch using 1st frame's
> > orientation as stream rotation.
> > Thanks again for review. I added the support for per frame rotation.
> >
> > (I know it involves too many file changes and not easy to read. Sorry
> about
> > that I tried to
> >  separate them but failed since due to some dependencies).
>
> The libavutil changes should be in a seperate patch and need a version
> and APIChanges update
>

Thanks Michael for the review. I updated the version to address the
feedback:
https://patchwork.ffmpeg.org/patch/13120/
https://patchwork.ffmpeg.org/patch/13119/
Thanks!

-Jun


> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If a bugfix only changes things apparently unrelated to the bug with no
> further explanation, that is a good sign that the bugfix is wrong.
> ___
> 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 v2 1/2] lavu/display: add av_display_rotation_hflip_get and bump version

[Jun Li]

Add av_display_rotation_hflip_get to get information whether the
matrix indicates horizontal flip.
---
 doc/APIchanges|  3 +++
 libavutil/display.c   | 14 ++
 libavutil/display.h   | 14 ++
 libavutil/tests/display.c |  8 
 libavutil/version.h   |  2 +-
 tests/ref/fate/display|  4 
 6 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index e75c4044ce..73c6809563 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2019-05-13 - XX - lavu 56.28.100 - display.h
+  Add av_display_rotation_hflip_get
+
 2019-04-20 - 3153a6502a - lavc 58.52.100 - avcodec.h
   Add AV_CODEC_FLAG_DROPCHANGED to allow avcodec_receive_frame to drop
   frames whose parameters differ from first decoded frame in stream.
diff --git a/libavutil/display.c b/libavutil/display.c
index a0076e067b..f5a6a4a08d 100644
--- a/libavutil/display.c
+++ b/libavutil/display.c
@@ -71,3 +71,17 @@ void av_display_matrix_flip(int32_t matrix[9], int hflip, 
int vflip)
 for (i = 0; i < 9; i++)
 matrix[i] *= flip[i % 3];
 }
+
+double av_display_rotation_hflip_get(const int32_t matrix[9], int *hflip)
+{
+int32_t m[9];
+*hflip = 0;
+memcpy(m, matrix, sizeof(m));
+
+if (m[0] > 0 && m[4] < 0 || m[0] < 0 && m[4] > 0 ||
+m[1] > 0 && m[3] > 0 || m[1] < 0 && m[3] < 0) {
+*hflip = 1;
+av_display_matrix_flip(m, 1, 0);
+}
+return av_display_rotation_get(m);
+}
diff --git a/libavutil/display.h b/libavutil/display.h
index 515adad795..c37d10c741 100644
--- a/libavutil/display.h
+++ b/libavutil/display.h
@@ -106,6 +106,20 @@ void av_display_rotation_set(int32_t matrix[9], double 
angle);
  */
 void av_display_matrix_flip(int32_t matrix[9], int hflip, int vflip);
 
+/**
+ * Extract the rotation component and hflip status of the transformation 
matrix.
+ *
+ * @param matrix the transformation matrix
+ * @param hflip will be set to 1 if the matrix indicates horizontal flip
+ * @return the angle (in degrees) by which the transformation rotates the frame
+ * counterclockwise. The angle will be in range [-180.0, 180.0],
+ * or NaN if the matrix is singular.
+ * 
+ * @note floating point numbers are inherently inexact, so callers are
+ *   recommended to round the return value to nearest integer before use.
+ */
+double av_display_rotation_hflip_get(const int32_t matrix[9], int* hflip);
+
 /**
  * @}
  * @}
diff --git a/libavutil/tests/display.c b/libavutil/tests/display.c
index 893ebb5543..65a0971e7b 100644
--- a/libavutil/tests/display.c
+++ b/libavutil/tests/display.c
@@ -35,6 +35,8 @@ static void print_matrix(int32_t matrix[9])
 int main(void)
 {
 int32_t matrix[9];
+int hflip = 0;
+double degree;
 
 // Set the matrix to 90 degrees
 av_display_rotation_set(matrix, 90);
@@ -56,6 +58,12 @@ int main(void)
 print_matrix(matrix);
 printf("degrees: %f\n", av_display_rotation_get(matrix));
 
+// flip vertical
+av_display_matrix_flip(matrix, 0, 1);
+print_matrix(matrix);
+degree = av_display_rotation_hflip_get(matrix, );
+printf("degrees: %f, hflip: %i\n", degree, hflip);
+
 return 0;
 
 }
diff --git a/libavutil/version.h b/libavutil/version.h
index 12b4f9fc3a..91ab71604b 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  56
-#define LIBAVUTIL_VERSION_MINOR  27
+#define LIBAVUTIL_VERSION_MINOR  28
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
diff --git a/tests/ref/fate/display b/tests/ref/fate/display
index 251e7e0cdf..14b4c7db7c 100644
--- a/tests/ref/fate/display
+++ b/tests/ref/fate/display
@@ -14,3 +14,7 @@ degrees: 135.00
 -46340 -46340 0
 0 0 1073741824
 degrees: -135.00
+-46340 -46340 0
+-46340 46340 0
+0 0 1073741824
+degrees: 45.00, hflip: 1
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH v2 2/2] fftools/ffmpeg: add support for per frame rotation and flip

[Jun Li]

Fix #6945
Current implementaion for autorotate works fine for stream
level rotataion but no support for frame level operation
and frame flip. This patch is for adding flip support and
per frame operations.
---
 fftools/cmdutils.c  |  9 ++---
 fftools/cmdutils.h  |  2 +-
 fftools/ffmpeg.c| 21 ++-
 fftools/ffmpeg.h|  2 +
 fftools/ffmpeg_filter.c | 81 ++---
 fftools/ffplay.c| 28 +++---
 6 files changed, 126 insertions(+), 17 deletions(-)

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 9cfbc45c2b..b8bb904419 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -2172,13 +2172,12 @@ void *grow_array(void *array, int elem_size, int *size, 
int new_size)
 return array;
 }
 
-double get_rotation(AVStream *st)
+double get_rotation_hflip(int32_t display_matrix[9], int* hflip)
 {
-uint8_t* displaymatrix = av_stream_get_side_data(st,
- 
AV_PKT_DATA_DISPLAYMATRIX, NULL);
 double theta = 0;
-if (displaymatrix)
-theta = -av_display_rotation_get((int32_t*) displaymatrix);
+
+if (display_matrix)
+theta = -av_display_rotation_hflip_get(display_matrix, hflip);
 
 theta -= 360*floor(theta/360 + 0.9/360);
 
diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index 6e2e0a2acb..dce44ed6e1 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -643,6 +643,6 @@ void *grow_array(void *array, int elem_size, int *size, int 
new_size);
 char name[128];\
 av_get_channel_layout_string(name, sizeof(name), 0, ch_layout);
 
-double get_rotation(AVStream *st);
+double get_rotation_hflip(int32_t display_matrix[9], int* hflip);
 
 #endif /* FFTOOLS_CMDUTILS_H */
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 01f04103cf..9ea1aaa930 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2126,6 +2126,24 @@ static int ifilter_has_all_input_formats(FilterGraph *fg)
 return 1;
 }
 
+static int ifilter_display_matrix_need_from_frame(InputFilter *ifilter, 
AVFrame* frame)
+{
+int32_t* stream_matrix = 
(int32_t*)av_stream_get_side_data(ifilter->ist->st, 
+AV_PKT_DATA_DISPLAYMATRIX, 
NULL);
+// if we already have display matrix from stream, use it instead of 
extracting
+// from frame.
+if (stream_matrix) {
+memcpy(ifilter->display_matrix, stream_matrix, 4 * 9);
+return 0;
+}
+
+// cleanup the display matrix, may be from last frame
+memset(ifilter->display_matrix, 0, 4 * 9);
+av_display_rotation_set(ifilter->display_matrix, 0);
+
+return !!av_dict_get(frame->metadata, "Orientation", NULL, 0);
+}
+
 static int ifilter_send_frame(InputFilter *ifilter, AVFrame *frame)
 {
 FilterGraph *fg = ifilter->graph;
@@ -2141,7 +2159,8 @@ static int ifilter_send_frame(InputFilter *ifilter, 
AVFrame *frame)
ifilter->channel_layout != frame->channel_layout;
 break;
 case AVMEDIA_TYPE_VIDEO:
-need_reinit |= ifilter->width  != frame->width ||
+need_reinit |= ifilter_display_matrix_need_from_frame(ifilter, frame) 
||
+   ifilter->width  != frame->width ||
ifilter->height != frame->height;
 break;
 }
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index eb1eaf6363..8331720663 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -251,6 +251,8 @@ typedef struct InputFilter {
 int channels;
 uint64_t channel_layout;
 
+int32_t display_matrix[9];
+
 AVBufferRef *hw_frames_ctx;
 
 int eof;
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 72838de1e2..1894f30561 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -328,6 +328,7 @@ static void init_input_filter(FilterGraph *fg, 
AVFilterInOut *in)
 fg->inputs[fg->nb_inputs - 1]->format = -1;
 fg->inputs[fg->nb_inputs - 1]->type = ist->st->codecpar->codec_type;
 fg->inputs[fg->nb_inputs - 1]->name = describe_filter_link(fg, in, 1);
+av_display_rotation_set(fg->inputs[fg->nb_inputs - 1]->display_matrix, 0);
 
 fg->inputs[fg->nb_inputs - 1]->frame_queue = av_fifo_alloc(8 * 
sizeof(AVFrame*));
 if (!fg->inputs[fg->nb_inputs - 1]->frame_queue)
@@ -807,22 +808,43 @@ static int configure_input_video_filter(FilterGraph *fg, 
InputFilter *ifilter,
 last_filter = ifilter->filter;
 
 if (ist->autorotate) {
-double theta = get_rotation(ist->st);
+int hflip = 0;
+double theta = get_rotation_hflip(ifilter->display_matrix, );
 
-if (fabs(theta - 90) < 1.0) {
+if (fabs(theta) < 1.0) {
+if (hflip)
+ret = insert_filter(_filter, _idx, "hflip", NULL);
+} else if (fabs(theta - 90) < 1.0) {
 ret = insert_filter(_filter, _idx, "transpose", "clock");
-} else if (fabs(theta - 180) < 1.0) {
-ret = insert_filter(_filter, _idx, 

Re: [FFmpeg-devel] [PATCH v2] Add multiple padding method in dnn native

[Steven Liu]

Xuewei Meng  于2019年5月11日周六 上午11:11写道：
>
> ---
>  libavfilter/dnn_backend_native.c | 52 
>  libavfilter/dnn_backend_native.h |  3 ++
>  2 files changed, 43 insertions(+), 12 deletions(-)
>
> diff --git a/libavfilter/dnn_backend_native.c 
> b/libavfilter/dnn_backend_native.c
> index 06fbdf368b..171a756385 100644
> --- a/libavfilter/dnn_backend_native.c
> +++ b/libavfilter/dnn_backend_native.c
> @@ -61,6 +61,12 @@ static DNNReturnType set_input_output_native(void *model, 
> DNNInputData *input, c
>  return DNN_ERROR;
>  }
>  cur_channels = conv_params->output_num;
> +
> +if(conv_params->padding_method == VALID){
> +int pad_size = conv_params->kernel_size - 1;
> +cur_height -= pad_size;
> +cur_width -= pad_size;
> +}
>  break;
>  case DEPTH_TO_SPACE:
>  depth_to_space_params = (DepthToSpaceParams 
> *)network->layers[layer].params;
> @@ -77,6 +83,10 @@ static DNNReturnType set_input_output_native(void *model, 
> DNNInputData *input, c
>  if (network->layers[layer].output){
>  av_freep(>layers[layer].output);
>  }
> +
> +if(cur_height <= 0 || cur_width <= 0)
> +return DNN_ERROR;
> +
>  network->layers[layer].output = av_malloc(cur_height * cur_width * 
> cur_channels * sizeof(float));
>  if (!network->layers[layer].output){
>  return DNN_ERROR;
> @@ -154,13 +164,14 @@ DNNModel *ff_dnn_load_model_native(const char 
> *model_filename)
>  ff_dnn_free_model_native();
>  return NULL;
>  }
> +conv_params->padding_method = 
> (int32_t)avio_rl32(model_file_context);
>  conv_params->activation = (int32_t)avio_rl32(model_file_context);
>  conv_params->input_num = (int32_t)avio_rl32(model_file_context);
>  conv_params->output_num = (int32_t)avio_rl32(model_file_context);
>  conv_params->kernel_size = 
> (int32_t)avio_rl32(model_file_context);
>  kernel_size = conv_params->input_num * conv_params->output_num *
>conv_params->kernel_size * 
> conv_params->kernel_size;
> -dnn_size += 16 + (kernel_size + conv_params->output_num << 2);
> +dnn_size += 20 + (kernel_size + conv_params->output_num << 2);
>  if (dnn_size > file_size || conv_params->input_num <= 0 ||
>  conv_params->output_num <= 0 || conv_params->kernel_size <= 
> 0){
>  avio_closep(_file_context);
> @@ -218,23 +229,35 @@ DNNModel *ff_dnn_load_model_native(const char 
> *model_filename)
>
>  static void convolve(const float *input, float *output, const 
> ConvolutionalParams *conv_params, int width, int height)
>  {
> -int y, x, n_filter, ch, kernel_y, kernel_x;
>  int radius = conv_params->kernel_size >> 1;
>  int src_linesize = width * conv_params->input_num;
>  int filter_linesize = conv_params->kernel_size * conv_params->input_num;
>  int filter_size = conv_params->kernel_size * filter_linesize;
> +int pad_size = (conv_params->padding_method == VALID) ? 
> (conv_params->kernel_size - 1) / 2 : 0;
>
> -for (y = 0; y < height; ++y){
> -for (x = 0; x < width; ++x){
> -for (n_filter = 0; n_filter < conv_params->output_num; 
> ++n_filter){
> +for (int y = pad_size; y < height - pad_size; ++y){
> +for (int x = pad_size; x < width - pad_size; ++x){
> +for (int n_filter = 0; n_filter < conv_params->output_num; 
> ++n_filter){
>  output[n_filter] = conv_params->biases[n_filter];
> -for (ch = 0; ch < conv_params->input_num; ++ch){
> -for (kernel_y = 0; kernel_y < conv_params->kernel_size; 
> ++kernel_y){
> -for (kernel_x = 0; kernel_x < 
> conv_params->kernel_size; ++kernel_x){
> -output[n_filter] += input[CLAMP_TO_EDGE(y + 
> kernel_y - radius, height) * src_linesize +
> -  CLAMP_TO_EDGE(x + 
> kernel_x - radius, width) * conv_params->input_num + ch] *
> -conv_params->kernel[n_filter 
> * filter_size + kernel_y * filter_linesize +
> -kernel_x 
> * conv_params->input_num + ch];
> +
> +for (int ch = 0; ch < conv_params->input_num; ++ch){
> +for (int kernel_y = 0; kernel_y < 
> conv_params->kernel_size; ++kernel_y){
> +for (int kernel_x = 0; kernel_x < 
> conv_params->kernel_size; ++kernel_x){
> +float input_pel;
> +if(conv_params->padding_method == 
> SAME_CLAMP_TO_EDGE){
> +int y_pos = CLAMP_TO_EDGE(y + kernel_y - 
> radius, height);

[FFmpeg-devel] [PATCH] lavc/vaapi_hevc: extend parameter buffer to ParameterBufferHEVCExtension

[Fu Linjie]

Extend ParameterBufferHEVC to ParameterBufferHEVCExtension for both
VAPicture and VASlice.

Pass Range Extension flags to support the decode for HEVC REXT.

Separate the behaviour of ff_vaapi_decode_make_slice_buffer for base and
rext to avoid potential regression.

Signed-off-by: Fu Linjie 
---
 libavcodec/vaapi_hevc.c | 134 
 1 file changed, 112 insertions(+), 22 deletions(-)

diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
index c69d63d..f0b6f8e 100644
--- a/libavcodec/vaapi_hevc.c
+++ b/libavcodec/vaapi_hevc.c
@@ -29,8 +29,13 @@
 #include "vaapi_decode.h"
 
 typedef struct VAAPIDecodePictureHEVC {
+#if VA_CHECK_VERSION(1, 2, 0)
+VAPictureParameterBufferHEVCExtension pic_param;
+VASliceParameterBufferHEVCExtension last_slice_param;
+#else
 VAPictureParameterBufferHEVC pic_param;
 VASliceParameterBufferHEVC last_slice_param;
+#endif
 const uint8_t *last_buffer;
 size_t last_size;
 
@@ -116,12 +121,17 @@ static int vaapi_hevc_start_frame(AVCodecContext  
*avctx,
 const HEVCSPS  *sps = h->ps.sps;
 const HEVCPPS  *pps = h->ps.pps;
 
+#if VA_CHECK_VERSION(1, 2, 0)
+VAPictureParameterBufferHEVC *pic_param = >pic_param.base;
+#else
+VAPictureParameterBufferHEVC *pic_param = >pic_param;
+#endif
+
 const ScalingList *scaling_list = NULL;
 int err, i;
 
 pic->pic.output_surface = ff_vaapi_get_surface_id(h->ref->frame);
-
-pic->pic_param = (VAPictureParameterBufferHEVC) {
+*pic_param = (VAPictureParameterBufferHEVC) {
 .pic_width_in_luma_samples= sps->width,
 .pic_height_in_luma_samples   = sps->height,
 .log2_min_luma_coding_block_size_minus3   = sps->log2_min_cb_size 
- 3,
@@ -188,26 +198,54 @@ static int vaapi_hevc_start_frame(AVCodecContext  
*avctx,
 },
 };
 
-fill_vaapi_pic(>pic_param.CurrPic, h->ref, 0);
-fill_vaapi_reference_frames(h, >pic_param);
+fill_vaapi_pic(_param->CurrPic, h->ref, 0);
+fill_vaapi_reference_frames(h, pic_param);
 
 if (pps->tiles_enabled_flag) {
-pic->pic_param.num_tile_columns_minus1 = pps->num_tile_columns - 1;
-pic->pic_param.num_tile_rows_minus1= pps->num_tile_rows - 1;
+pic_param->num_tile_columns_minus1 = pps->num_tile_columns - 1;
+pic_param->num_tile_rows_minus1= pps->num_tile_rows - 1;
 
 for (i = 0; i < pps->num_tile_columns; i++)
-pic->pic_param.column_width_minus1[i] = pps->column_width[i] - 1;
-
+pic_param->column_width_minus1[i] = pps->column_width[i] - 1;
 for (i = 0; i < pps->num_tile_rows; i++)
-pic->pic_param.row_height_minus1[i] = pps->row_height[i] - 1;
+pic_param->row_height_minus1[i] = pps->row_height[i] - 1;
 }
 
 if (h->sh.short_term_ref_pic_set_sps_flag == 0 && h->sh.short_term_rps) {
-pic->pic_param.st_rps_bits = h->sh.short_term_ref_pic_set_size;
+pic_param->st_rps_bits = h->sh.short_term_ref_pic_set_size;
 } else {
-pic->pic_param.st_rps_bits = 0;
+pic_param->st_rps_bits = 0;
 }
 
+#if VA_CHECK_VERSION(1, 2, 0)
+if (sps->sps_range_extension_flag) {
+pic->pic_param.rext = (VAPictureParameterBufferHEVCRext) {
+.range_extension_pic_fields.bits  = {
+.transform_skip_rotation_enabled_flag   = 
sps->transform_skip_rotation_enabled_flag,
+.transform_skip_context_enabled_flag= 
sps->transform_skip_context_enabled_flag,
+.implicit_rdpcm_enabled_flag= 
sps->implicit_rdpcm_enabled_flag,
+.explicit_rdpcm_enabled_flag= 
sps->explicit_rdpcm_enabled_flag,
+.extended_precision_processing_flag = 
sps->extended_precision_processing_flag,
+.intra_smoothing_disabled_flag  = 
sps->intra_smoothing_disabled_flag,
+.high_precision_offsets_enabled_flag= 
sps->high_precision_offsets_enabled_flag,
+.persistent_rice_adaptation_enabled_flag= 
sps->persistent_rice_adaptation_enabled_flag,
+.cabac_bypass_alignment_enabled_flag= 
sps->cabac_bypass_alignment_enabled_flag,
+.cross_component_prediction_enabled_flag= 
pps->cross_component_prediction_enabled_flag,
+.chroma_qp_offset_list_enabled_flag = 
pps->chroma_qp_offset_list_enabled_flag,
+},
+.diff_cu_chroma_qp_offset_depth = 
pps->diff_cu_chroma_qp_offset_depth,
+.chroma_qp_offset_list_len_minus1   = 
pps->chroma_qp_offset_list_len_minus1,
+.log2_sao_offset_scale_luma = 
pps->log2_sao_offset_scale_luma,
+.log2_sao_offset_scale_chroma   = 
pps->log2_sao_offset_scale_chroma,
+

Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_scale_cuda: Simplify output plane addressing

[Yogender Gupta]

Yes, this looks better and should have been this way.

Thanks,
Yogender

-Original Message-
From: Philip Langdale  
Sent: Tuesday, May 14, 2019 8:42 AM
To: ffmpeg-devel@ffmpeg.org
Cc: Yogender Gupta ; Philip Langdale 
Subject: [PATCH 3/3] avfilter/vf_scale_cuda: Simplify output plane addressing

I'm not sure why this was written the way it was originally. We initialise the 
plane addresses correctly in hwcontext_cuda so why try and play games to 
calculate the plane offsets directly in this code?
---
 libavfilter/vf_scale_cuda.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c index 
a833dcd1a4..b7cdb81081 100644
--- a/libavfilter/vf_scale_cuda.c
+++ b/libavfilter/vf_scale_cuda.c
@@ -390,12 +390,12 @@ static int scalecuda_resize(AVFilterContext *ctx,
out->data[0], out->width, out->height, 
out->linesize[0],
1);
 call_resize_kernel(ctx, s->cu_func_uchar, 1,
-   in->data[0]+in->linesize[0]*in->height, 
in->width/2, in->height/2, in->linesize[0]/2,
-   out->data[0]+out->linesize[0]*out->height, 
out->width/2, out->height/2, out->linesize[0]/2,
+   in->data[1], in->width/2, in->height/2, 
in->linesize[0]/2,
+   out->data[1], out->width/2, out->height/2, 
+ out->linesize[0]/2,
1);
 call_resize_kernel(ctx, s->cu_func_uchar, 1,
-   in->data[0]+ 
ALIGN_UP((in->linesize[0]*in->height*5)/4, s->tex_alignment), in->width/2, 
in->height/2, in->linesize[0]/2,
-   out->data[0]+(out->linesize[0]*out->height*5)/4, 
out->width/2, out->height/2, out->linesize[0]/2,
+   in->data[2], in->width/2, in->height/2, 
in->linesize[0]/2,
+   out->data[2], out->width/2, out->height/2, 
+ out->linesize[0]/2,
1);
 break;
 case AV_PIX_FMT_YUV444P:
@@ -404,12 +404,12 @@ static int scalecuda_resize(AVFilterContext *ctx,
out->data[0], out->width, out->height, 
out->linesize[0],
1);
 call_resize_kernel(ctx, s->cu_func_uchar, 1,
-   in->data[0]+in->linesize[0]*in->height, in->width, 
in->height, in->linesize[0],
-   out->data[0]+out->linesize[0]*out->height, 
out->width, out->height, out->linesize[0],
+   in->data[1], in->width, in->height, in->linesize[0],
+   out->data[1], out->width, out->height, 
+ out->linesize[0],
1);
 call_resize_kernel(ctx, s->cu_func_uchar, 1,
-   in->data[0]+in->linesize[0]*in->height*2, 
in->width, in->height, in->linesize[0],
-   out->data[0]+out->linesize[0]*out->height*2, 
out->width, out->height, out->linesize[0],
+   in->data[2], in->width, in->height, in->linesize[0],
+   out->data[2], out->width, out->height, 
+ out->linesize[0],
1);
 break;
 case AV_PIX_FMT_YUV444P16:
@@ -433,7 +433,7 @@ static int scalecuda_resize(AVFilterContext *ctx,
1);
 call_resize_kernel(ctx, s->cu_func_uchar2, 2,
in->data[1], in->width/2, in->height/2, 
in->linesize[1],
-   out->data[0] + out->linesize[0] * ((out->height + 
31) & ~0x1f), out->width/2, out->height/2, out->linesize[1]/2,
+   out->data[1], out->width/2, out->height/2, 
+ out->linesize[1]/2,
1);
 break;
 case AV_PIX_FMT_P010LE:
@@ -443,7 +443,7 @@ static int scalecuda_resize(AVFilterContext *ctx,
2);
 call_resize_kernel(ctx, s->cu_func_ushort2, 2,
in->data[1], in->width / 2, in->height / 2, 
in->linesize[1]/2,
-   out->data[0] + out->linesize[0] * ((out->height + 
31) & ~0x1f), out->width / 2, out->height / 2, out->linesize[1] / 4,
+   out->data[1], out->width / 2, out->height / 
+ 2, out->linesize[1] / 4,
2);
 break;
 case AV_PIX_FMT_P016LE:
@@ -453,7 +453,7 @@ static int scalecuda_resize(AVFilterContext *ctx,
2);
 call_resize_kernel(ctx, s->cu_func_ushort2, 2,
in->data[1], in->width / 2, in->height / 2, 
in->linesize[1] / 2,
-   out->data[0] + out->linesize[0] * ((out->height + 
31) & ~0x1f), out->width / 2, out->height / 2, out->linesize[1] / 4,
+   out->data[1], out->width / 2, out->height / 
+ 2, out->linesize[1] / 4,
2);
 break;
 default:
--
2.20.1

Re: [FFmpeg-devel] [PATCH] "assert(a && b)" --> "assert(a); assert(b)" for more precise diagnostics, except for libformat

[myp...@gmail.com]

On Wed, May 15, 2019 at 7:01 AM Hendrik Leppkes  wrote:
>
> On Tue, May 14, 2019 at 11:25 PM Adam Richter  wrote:
> >
> > Consider, for example, if you agree that columnization makes this range 
> > check
> > more recognizable in a glance and makes it easier to spot what the bounds 
> > are
> > (the sixteen space indentation is taken from the code in which it appeared):
> >
> > av_assert0(par->bits_per_coded_sample >= 0 &&
> > par->bits_per_coded_sample <= 8);
> >
> > ...vs...
> >
> > av_assert0(par->bits_per_coded_sample >= 0);
> > av_assert0(par->bits_per_coded_sample <= 8);
> >
> > A possible counter-argument to this might be that, in a long sequence
> > of assertions, can be informative to group related assertions
> > together, which I think is true, but it is possible to get this other
> > means, such as by using blank lines to separate express such grouping.
> >
> > So, Mark, if you decide you are OK with my complete patches, I encourage
> > you to let me know.  Otherwise, if there are any of those changes which you
> > are OK with, I would like to just to to get those merged.  Finally, if you 
> > would
> > rather see none of those changes merged (one one to split the assertions in
> > libavformat and one was for everywhere else in ffmpeg), please let me know
> > about that too, in which case, if no one advocates for their
> > inclusion, I'll drop
> > my proposal to merge these changes.
> >
>
> Unfortunately I have to agree with Mark. asserst that check the same
> value or extremely closely related values should stay combined.
>
I agree this part
> >
> > Also after this, I may take a look at adding a branch hint to the av_assertN
> > macros if nobody objects.
> >
>
> Please don't, we don't do branch hints anywhere, and this is a bad
> place to start.
> If an assert is truely performance sensitive (as in, it makes a
> measurable difference), it should probably be moved from assert0 to
> assert1, and as such is only enabled in testing builds.
>
If assert0 or assert1 lead to performance drop, we need some profiling
data, then try to fix it.
> - Hendrik
___
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 1/2] VP4 video decoder

[Reimar Döffinger]

On Tue, May 14, 2019 at 10:37:03PM +1000, Peter Ross wrote:
> On Sun, May 12, 2019 at 01:24:56PM +0200, Reimar Döffinger wrote:
> > On 12.05.2019, at 08:12, Peter Ross  wrote:
> > > +static int read_mb_value(GetBitContext *gb)
> > > +{
> > > +int v = 1;
> > > +int size;
> > > +
> > > +do {
> > > +size = 0;
> > > +if (!get_bits1(gb))
> > > +break;
> > > +v++;
> > > +do {
> > > +if (!get_bits1(gb))
> > > +break;
> > > +v += 1 << size++;
> > > +} while (size < 8);
> > > +} while (size == 8);
> > > +
> > > +if (size)
> > > +v += get_bits(gb, size);
> > > +
> > > +return v;
> > > +}
> >
> > Maybe not worth it performance wise, but did you check if this could be 
> > simplified?
> > For example the get_bits1 cases that end up with size 0 could return 
> > directly.
> > Or it could peek ahead 9 bits in the bitstream and count the leading 1s to 
> > get v and size without looping (i.e. loop only for the 9 bits of 1s 
> > specifically).
> > Alternatively add a comment to clarify the encoding scheme it implements 
> > (like 9 consecutive 1s is a prefix encoding an offset of 257 etc).
>
> thanks for these suggestions.
>
> replacing get_bits() with OPEN_READER/UPDATE_CACHE/SHOW_UBITS/etc results in a
> consistent 0.50 % speedup.

Not sure how readable that gets, I actually just meant taking
advantage of show_bits()
While nice, I am not sure speed is much of a consideration for vp4
really.
___
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] "assert(a && b)" --> "assert(a); assert(b)" for more precise diagnostics, except for libformat

[Hendrik Leppkes]

On Tue, May 14, 2019 at 11:25 PM Adam Richter  wrote:
>
> Consider, for example, if you agree that columnization makes this range check
> more recognizable in a glance and makes it easier to spot what the bounds are
> (the sixteen space indentation is taken from the code in which it appeared):
>
> av_assert0(par->bits_per_coded_sample >= 0 &&
> par->bits_per_coded_sample <= 8);
>
> ...vs...
>
> av_assert0(par->bits_per_coded_sample >= 0);
> av_assert0(par->bits_per_coded_sample <= 8);
>
> A possible counter-argument to this might be that, in a long sequence
> of assertions, can be informative to group related assertions
> together, which I think is true, but it is possible to get this other
> means, such as by using blank lines to separate express such grouping.
>
> So, Mark, if you decide you are OK with my complete patches, I encourage
> you to let me know.  Otherwise, if there are any of those changes which you
> are OK with, I would like to just to to get those merged.  Finally, if you 
> would
> rather see none of those changes merged (one one to split the assertions in
> libavformat and one was for everywhere else in ffmpeg), please let me know
> about that too, in which case, if no one advocates for their
> inclusion, I'll drop
> my proposal to merge these changes.
>

Unfortunately I have to agree with Mark. asserst that check the same
value or extremely closely related values should stay combined.

>
> Also after this, I may take a look at adding a branch hint to the av_assertN
> macros if nobody objects.
>

Please don't, we don't do branch hints anywhere, and this is a bad
place to start.
If an assert is truely performance sensitive (as in, it makes a
measurable difference), it should probably be moved from assert0 to
assert1, and as such is only enabled in testing builds.

- Hendrik
___
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/2] tests/fate: Add fate test for timestamp interpolation

[Andriy Gelman]

Hello,

On Tue, 14. May 17:54, Andriy Gelman wrote:
> From: Andriy Gelman 
> 
> This test verifies that missing timestamps from mpegts are interpolated
> for a HEVC stream.
> ---
>  tests/fate/mpegts.mak  |   7 ++
>  tests/ref/fate/mpegts-probe-interptime | 154 +
>  2 files changed, 161 insertions(+)
>  create mode 100644 tests/ref/fate/mpegts-probe-interptime
> 
> diff --git a/tests/fate/mpegts.mak b/tests/fate/mpegts.mak
> index bbcbfc47b2..71e40ef26f 100644
> --- a/tests/fate/mpegts.mak
> +++ b/tests/fate/mpegts.mak
> @@ -5,6 +5,10 @@ PROBE_CODEC_NAME_COMMAND = \
>  ffprobe$(PROGSSUF)$(EXESUF) -show_entries stream=codec_name \
>  -print_format default -bitexact -v 0
>  
> +PROBE_INTERP_TIME_COMMAND = \
> +ffprobe$(PROGSSUF)$(EXESUF) -show_entries packet=pts,dts \
> +-print_format default -bitexact -v 0
> +
>  FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC, AAC_LATM) += 
> fate-mpegts-probe-latm
>  fate-mpegts-probe-latm: SRC = $(TARGET_SAMPLES)/mpegts/loewe.ts
>  fate-mpegts-probe-latm: CMD = run $(PROBE_CODEC_NAME_COMMAND) -i "$(SRC)"
> @@ -19,6 +23,9 @@ FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS) += 
> fate-mpegts-probe-pmt-merge
>  fate-mpegts-probe-pmt-merge: SRC = $(TARGET_SAMPLES)/mpegts/pmtchange.ts
>  fate-mpegts-probe-pmt-merge: CMD = run $(PROBE_CODEC_NAME_COMMAND) 
> -merge_pmt_versions 1 -i "$(SRC)"
>  
> +FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC) += 
> fate-mpegts-probe-interptime

> +fate-mpegts-probe-interptime: SRC = $(TARGET_SAMPLES)/mpegts/foreman.ts

I attach a file foreman.ts that is required for this fate test. 

Thanks, 
Andriy


G}¾Ì—®÷]톢ƟD‹À0ºæ;ˆ”4úàý5‡¾Ôcf:½\{!b*Û

Ñ(ŸýÄ@ rÏW¬ý£F)J¬[#¸h|°Bûڋ¡…ÜV†Žñ÷TRl­ºa2ôGv1ç2µÞÌ'v-N{ðϪHP47‡TÏXwž×Ò½rå_Ìo¿Tc>PôÏD†q;˜œ¦³©P¹/¸Óن`ܯG
4-½‹¡u’GA­ܶíÙAɼïqdŒ)lB‡Àdf¾	M•*‚IÕZй_@{´Í3¢R2çiH
ž6£R}>~xý‹lÞ7§eW¼£äçÎ[â}߅Áž2Â¥g‡Èâ,Ù©Î1K±ýÛaÝ4-mÜ0Ìvbi&ÑÓ
ؤKŸõ„ÌU°|E;œGA
à€€%ÃÛC«
F
P

Ñ0ŸýÄ03çÙŬIŒíßâaþ2,P±÷›¬|@w`J‹g!b€=ÆZp‰yzi+UY;Ï
–æ4³£
	DxÇ8™ˆnXÖKB—{-%™uÖU>´<1Ëï?'Bhº©¶ØŽ£|ɍŸ?±»'$®Ö:n#
áÅ°\~gB·ßÂb/ÂßëähïÅåaG´°¿N	W(íàG
Ð,ק(
D¢ð¾
Þ¥¼â…¤Îùá903€ck¹8ã¹EªlJ†¤	ªì¹¨¾¦
"Ý
´t½‹X|9áOú¾1óC:&}HEªéÀÎM*—¸¶Žkyü­­é,9a

Ñ8ŸýÄ03ʅ1JÁÓ#­ÒTŸ—=iŽN#|Râч;A‚=¯òÅFë¢Á¦^X±L?ԖnÏFäƸMQtPF¶êÔ}÷o¡r—G
7Bÿ¢ãU²‰
3& b.ØïûQû1G
Zå"_d>é‹Èµã“ã.>¿@uY¤ÆHT7öƒ@ªÍÂ3á¡÷NlœD”fÉ÷E™OhNÅþºejó®½êl&…¬Œ—½ÍâtC²ddž¯¥Ý¹T‚Ðo¶$ GA
à€€%ÃÛó“
F
P
@

ÿÿ
`’€
B


`  $Yd©$Êà€€
D
Ár´b@
*
¬ M\%b|™8À¡gî>-H›œÇٞÏiöic
U—M0X°F²p+å—)Cø/Ú5
fOÖ^Ÿ `zžu-ø¤†Zz˜º†­þ ÍG
eÕB¥Û
íD1*h§Pì½±· ý‰Ïô ÍÁ'™ý¤¤c	¿Ï»wš¼øgÛÝê__óuÁ™^_2Ÿ:‚Iïß×®gÝÅ®­³K&
¥\­Xüê=+Ý»ôH–ŒûÛ¿èbËù[j4({ޖ’EýŸøÄ<ýVR©¡}sÔ[6Ï@«½×#¨§ŠÇ¤aç-?ë?øÀÙK¾wîîjKª^•.A,G„vM
B.m ÌǗæÅG
zcÖµ;YÐu÷7"L|!6 +Êè륓{zÃv:ÿ*jG‘8ø[Õ¬êJÙØÄþÿóízÞbÇr})"iú¾Κ’šlø8ÓC?§ö2E2ëó\Ÿ¢K8(“·…ƒNxmÿ¥ÎŽJƒ[æþd+8¼Ñhù‹²Œ«,¼Ðñ”•ÝžÈGӋò$ÚÃü¸”ðÑÉ[ÿ¬<=x¡¿çà-of¹Þ/ƒ,®mFÅ*xâ
¶’«œê/­ÿ<ñ=G
Ûoxà,¶/߉j¡³¬»WòÝ©üj>”ÁV>NüT	zfØìš.¡.#“ÁKË´Á×£è¬äÌéÇDzRw•ž›:;-M&=”R
½¹ì–˜¦êYÔ'è%xW¸¿о‰ëâí¦‚éG]
PªKer—Û0ý^î•ý>ìƒ×ºüÿ­2aÞyÎGHÇ*ÑaÔ!¦·m®â¾SÒkÿqm(֗ÍK݋*qæ^Q(EÜÍF‹0»G
TUþÇÚÍOw»+ÈÄ
«³Ìøšn–|ڕc+ñò`ƒ”W³ù*£ô´ÆìÛYoâÛOŽ[0
H'Ã
;êCÌwxŽá)f…Xùž¦í%ë%åë¹íÕѪÇS&šôêÝLuè¦4¡p¸<–F»»»6wë;O霎¯Ì€N—’bÛåS-(|pە~2ÿ2Ô™ x´•×L¨eûSEO>¦Ù¨.ÁÔ㾚yBçêÔG
a+«c˜·Ñ‰×B訁gãµcï
Xû‹÷Ñä0—"A|K „»[óN-ž¶¼ÜAÂÚh½ˆüÞRî×ã4B.Õ¢¦êï6ƒDÅÌ:·÷Kmǐty_ñ÷„<€¬šO¼xJG&|«P*Rù#Hçè¬P#|,~ÆÖ$ûöÒüp™l𡟧t¾Ù?'1L³ë<Š‡ò鈧Œì}f¹‹Œž)逴q¢’¸¡»WmÁÐCôo
¥ƒG
>CÿÿɂÒÑW됰OPޛP‹U÷ÕэËk4¤Õ°Þ¶,mh8v[òµø¼(}®z´‘—Dc<þöƒz$f쾞,‹˜Á®fBNe.p\áXŸÖ©FÊÃxš˜½í@ɍ¸É²°~üEÓ8“óVšѪƒ÷ÈЌÈüré¥34Ú;ùb! ²PyæÆ@÷¬%w’“>¹.Y8Ki](ƒPì2‹Ó”"ºNHglp¹‡u7{Ûn-#äÀ

Ñ`ŸýÄ03á½³}øº w	M˜Ö+Cð0Áb²Jªç„h͟‰:Y¼…_»½#ÑPkÈ]_¤³³bÐçîIœËÃXs'æœè„(0G
Qœ"ˆçÖ;àzˆW…ê\Ü\䫅ÏQ 4ÀÑý³ùà—oCÁb¹ÀðOº éªhÔF‚KÓúЙ½¡Ò=Ør Œ?•¨}æZ4IR܌¡¸†Z]R×
Bòó"?Ú)WüD+÷"!fŒ+ àÈÁ8À—¼)™iŸbÕ6Íõs~©.u'÷ÂOøÔÀÒ›AÒ‡0þDÁÿN:çÁ+§ñ¾lM‘øßG
é^Xá€

ÑhŸýÄ0³Èg³}°¯Ž…“~îªë%Œ¼ß'.ÖéÙ,Å¡ýNÂ4K™,ŠþfO´ßù»VŒ>‹TºRh³nMώ7(×@ÿÞÿ­ÌãoQŠ@떸´æèþ[ê’]硵d°­ûÊ1B“Õ¡š`]‹ÝàþûK„£™à^ø®“éG¬ê%›y@à¸ìs/‘r4FþÊßÓ+wM2÷§èÔw*zqƒˆÀÌ&ÙòG
Œ4fš”çêŠ

ÑpŸýÄ03ÅÃ)~A¾wØYñMƪÁÙNMðLã‰
MTV;º9A5’gRgnc†Í“OÞ§ð›TÂÄJ	ñ®rètå4
"‘ˆž8­oB'Z¯sJ2½JßJl
ªõoš/›Bû¾)ŽW1ãZx•àZd&	`UMÛËÌt¾|N›š¸¦=»ñLéPôSºÒ2–ÒâÒ

[FFmpeg-devel] [PATCH v2 1/2] libavformat/utils: Interpolate missing timestamps in H264 and HEVC when no b-frames observed

[Andriy Gelman]

From: Andriy Gelman 

Fixes Ticket #7895.

Currently, timestamp interpolation is disabled by default in H264 and
HEVC.  This creates playback issues when the demuxer does not output a
valid timestamp. This patch allows interpolation when no b-frames have
been observed during decoding, which fixes playback issues for some
missing timestamp cases.
---
 libavformat/utils.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index a63d71b0f4..3dd0bf0d66 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1233,7 +1233,9 @@ static void compute_pkt_fields(AVFormatContext *s, 
AVStream *st,
 int64_t offset;
 AVRational duration;
 int onein_oneout = st->codecpar->codec_id != AV_CODEC_ID_H264 &&
-   st->codecpar->codec_id != AV_CODEC_ID_HEVC;
+   st->codecpar->codec_id != AV_CODEC_ID_HEVC ||
+   (!st->internal->avctx->max_b_frames &&
+st->cur_dts != RELATIVE_TS_BASE); /*skip when no 
timing info from demuxer */
 
 if (s->flags & AVFMT_FLAG_NOFILLIN)
 return;
@@ -1272,6 +1274,10 @@ static void compute_pkt_fields(AVFormatContext *s, 
AVStream *st,
 delay = st->internal->avctx->has_b_frames;
 presentation_delayed = 0;
 
+/*update max_b_frames if delay is larger */
+if (delay > st->internal->avctx->max_b_frames)
+  st->internal->avctx->max_b_frames = delay;
+
 /* XXX: need has_b_frame, but cannot get it if the codec is
  *  not initialized */
 if (delay &&
@@ -1337,7 +1343,8 @@ static void compute_pkt_fields(AVFormatContext *s, 
AVStream *st,
 presentation_delayed, av_ts2str(pkt->pts), av_ts2str(pkt->dts), 
av_ts2str(st->cur_dts),
 pkt->stream_index, pc, pkt->duration, delay, onein_oneout);
 
-/* Interpolate PTS and DTS if they are not present. We skip H264
+/* Interpolate PTS and DTS if they are not present. H264/HEVC timestamps 
are
+ * interpolated only if no b-frames have been observed. Otherwise, we skip 
H264/HEVC
  * currently because delay and has_b_frames are not reliably set. */
 if ((delay == 0 || (delay == 1 && pc)) &&
 onein_oneout) {
-- 
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 v2 2/2] tests/fate: Add fate test for timestamp interpolation

[Andriy Gelman]

From: Andriy Gelman 

This test verifies that missing timestamps from mpegts are interpolated
for a HEVC stream.
---
 tests/fate/mpegts.mak  |   7 ++
 tests/ref/fate/mpegts-probe-interptime | 154 +
 2 files changed, 161 insertions(+)
 create mode 100644 tests/ref/fate/mpegts-probe-interptime

diff --git a/tests/fate/mpegts.mak b/tests/fate/mpegts.mak
index bbcbfc47b2..71e40ef26f 100644
--- a/tests/fate/mpegts.mak
+++ b/tests/fate/mpegts.mak
@@ -5,6 +5,10 @@ PROBE_CODEC_NAME_COMMAND = \
 ffprobe$(PROGSSUF)$(EXESUF) -show_entries stream=codec_name \
 -print_format default -bitexact -v 0
 
+PROBE_INTERP_TIME_COMMAND = \
+ffprobe$(PROGSSUF)$(EXESUF) -show_entries packet=pts,dts \
+-print_format default -bitexact -v 0
+
 FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC, AAC_LATM) += 
fate-mpegts-probe-latm
 fate-mpegts-probe-latm: SRC = $(TARGET_SAMPLES)/mpegts/loewe.ts
 fate-mpegts-probe-latm: CMD = run $(PROBE_CODEC_NAME_COMMAND) -i "$(SRC)"
@@ -19,6 +23,9 @@ FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS) += 
fate-mpegts-probe-pmt-merge
 fate-mpegts-probe-pmt-merge: SRC = $(TARGET_SAMPLES)/mpegts/pmtchange.ts
 fate-mpegts-probe-pmt-merge: CMD = run $(PROBE_CODEC_NAME_COMMAND) 
-merge_pmt_versions 1 -i "$(SRC)"
 
+FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC) += fate-mpegts-probe-interptime
+fate-mpegts-probe-interptime: SRC = $(TARGET_SAMPLES)/mpegts/foreman.ts
+fate-mpegts-probe-interptime: CMD = run $(PROBE_INTERP_TIME_COMMAND) -i 
"$(SRC)"
 
 FATE_SAMPLES_FFPROBE += $(FATE_MPEGTS_PROBE-yes)
 
diff --git a/tests/ref/fate/mpegts-probe-interptime 
b/tests/ref/fate/mpegts-probe-interptime
new file mode 100644
index 00..1d83f8d4f4
--- /dev/null
+++ b/tests/ref/fate/mpegts-probe-interptime
@@ -0,0 +1,154 @@
+[PACKET]
+pts=2968975817
+dts=2968975817
+[SIDE_DATA]
+[/SIDE_DATA]
+[/PACKET]
+[PACKET]
+pts=2968987078
+dts=2968987078
+[/PACKET]
+[PACKET]
+pts=2968998328
+dts=2968998328
+[/PACKET]
+[PACKET]
+pts=2969009578
+dts=2969009578
+[/PACKET]
+[PACKET]
+pts=2969020828
+dts=2969020828
+[/PACKET]
+[PACKET]
+pts=2969032078
+dts=2969032078
+[/PACKET]
+[PACKET]
+pts=2969043328
+dts=2969043328
+[SIDE_DATA]
+[/SIDE_DATA]
+[/PACKET]
+[PACKET]
+pts=2969054411
+dts=2969054411
+[/PACKET]
+[PACKET]
+pts=2969065661
+dts=2969065661
+[/PACKET]
+[PACKET]
+pts=2969076911
+dts=2969076911
+[/PACKET]
+[PACKET]
+pts=2969088161
+dts=2969088161
+[SIDE_DATA]
+[/SIDE_DATA]
+[/PACKET]
+[PACKET]
+pts=2969102305
+dts=2969102305
+[/PACKET]
+[PACKET]
+pts=2969113555
+dts=2969113555
+[/PACKET]
+[PACKET]
+pts=2969124805
+dts=2969124805
+[/PACKET]
+[PACKET]
+pts=2969136055
+dts=2969136055
+[/PACKET]
+[PACKET]
+pts=2969147305
+dts=2969147305
+[SIDE_DATA]
+[/SIDE_DATA]
+[/PACKET]
+[PACKET]
+pts=2969155644
+dts=2969155644
+[/PACKET]
+[PACKET]
+pts=2969166894
+dts=2969166894
+[/PACKET]
+[PACKET]
+pts=2969178144
+dts=2969178144
+[/PACKET]
+[PACKET]
+pts=2969189394
+dts=2969189394
+[SIDE_DATA]
+[/SIDE_DATA]
+[/PACKET]
+[PACKET]
+pts=2969200455
+dts=2969200455
+[/PACKET]
+[PACKET]
+pts=2969211705
+dts=2969211705
+[/PACKET]
+[PACKET]
+pts=2969222955
+dts=2969222955
+[/PACKET]
+[PACKET]
+pts=2969234205
+dts=2969234205
+[SIDE_DATA]
+[/SIDE_DATA]
+[/PACKET]
+[PACKET]
+pts=2969245390
+dts=2969245390
+[/PACKET]
+[PACKET]
+pts=2969256640
+dts=2969256640
+[/PACKET]
+[PACKET]
+pts=2969267890
+dts=2969267890
+[/PACKET]
+[PACKET]
+pts=2969279140
+dts=2969279140
+[/PACKET]
+[PACKET]
+pts=2969290390
+dts=2969290390
+[/PACKET]
+[PACKET]
+pts=2969301640
+dts=2969301640
+[SIDE_DATA]
+[/SIDE_DATA]
+[/PACKET]
+[PACKET]
+pts=2969312863
+dts=2969312863
+[/PACKET]
+[PACKET]
+pts=2969324113
+dts=2969324113
+[/PACKET]
+[PACKET]
+pts=2969335363
+dts=2969335363
+[/PACKET]
+[PACKET]
+pts=2969346613
+dts=2969346613
+[/PACKET]
+[PACKET]
+pts=2969357863
+dts=2969357863
+[/PACKET]
-- 
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] avformat/mxfenc: support XAVC long gop

[Thomas Mundt]

Hi Baptiste,

Am Di., 14. Mai 2019 um 18:59 Uhr schrieb Baptiste Coudurier <
baptiste.coudur...@gmail.com>:

> ---
>  libavformat/Makefile |   2 +-
>  libavformat/avc.c| 186 +
>  libavformat/avc.h|  15 +++
>  libavformat/hevc.c   |  36 +---
>  libavformat/mxf.h|   1 +
>  libavformat/mxfenc.c | 213 ++-
>  6 files changed, 372 insertions(+), 81 deletions(-)
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 99be60d184..df87c54a58 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER)  += musx.o
>  OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
>  OBJS-$(CONFIG_MVI_DEMUXER)   += mvi.o
>  OBJS-$(CONFIG_MXF_DEMUXER)   += mxfdec.o mxf.o
> -OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o
> audiointerleave.o
> +OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o
> audiointerleave.o avc.o
>  OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
>  OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
>  OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
> diff --git a/libavformat/avc.c b/libavformat/avc.c
> index ec50033a04..a041e84357 100644
> --- a/libavformat/avc.c
> +++ b/libavformat/avc.c
> @@ -21,6 +21,7 @@
>
>  #include "libavutil/intreadwrite.h"
>  #include "libavcodec/h264.h"
> +#include "libavcodec/get_bits.h"
>  #include "avformat.h"
>  #include "avio.h"
>  #include "avc.h"
> @@ -241,3 +242,188 @@ const uint8_t *ff_avc_mp4_find_startcode(const
> uint8_t *start,
>
>  return start + res;
>  }
> +
> +uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
> +  uint32_t *dst_len, int header_len)
> +{
> +uint8_t *dst;
> +uint32_t i, len;
> +
> +dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
> +if (!dst)
> +return NULL;
> +
> +/* NAL unit header */
> +i = len = 0;
> +while (i < header_len && i < src_len)
> +dst[len++] = src[i++];
> +
> +while (i + 2 < src_len)
> +if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
> +dst[len++] = src[i++];
> +dst[len++] = src[i++];
> +i++; // remove emulation_prevention_three_byte
> +} else
> +dst[len++] = src[i++];
> +
> +while (i < src_len)
> +dst[len++] = src[i++];
> +
> +memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
> +
> +*dst_len = len;
> +return dst;
> +}
> +
> +static const AVRational avc_sample_aspect_ratio[17] = {
> +{   0,  1 },
> +{   1,  1 },
> +{  12, 11 },
> +{  10, 11 },
> +{  16, 11 },
> +{  40, 33 },
> +{  24, 11 },
> +{  20, 11 },
> +{  32, 11 },
> +{  80, 33 },
> +{  18, 11 },
> +{  15, 11 },
> +{  64, 33 },
> +{ 160, 99 },
> +{   4,  3 },
> +{   3,  2 },
> +{   2,  1 },
> +};
> +
> +static inline int get_ue_golomb(GetBitContext *gb) {
> +int i;
> +for (i = 0; i < 32 && !get_bits1(gb); i++)
> +;
> +return get_bitsz(gb, i) + (1 << i) - 1;
> +}
> +
> +static inline int get_se_golomb(GetBitContext *gb) {
> +int v = get_ue_golomb(gb) + 1;
> +int sign = -(v & 1);
> +return ((v >> 1) ^ sign) - sign;
> +}
> +
> +H264SequenceParameterSet *ff_avc_decode_sps(const uint8_t *buf, int
> buf_size)
> +{
> +int i, j, ret, rbsp_size, aspect_ratio_idc, pic_order_cnt_type;
> +int num_ref_frames_in_pic_order_cnt_cycle;
> +int delta_scale, lastScale = 8, nextScale = 8;
> +int sizeOfScalingList;
> +H264SequenceParameterSet *sps = NULL;
> +GetBitContext gb;
> +uint8_t *rbsp_buf;
> +
> +rbsp_buf = ff_nal_unit_extract_rbsp(buf, buf_size, _size, 0);
> +if (!rbsp_buf)
> +return NULL;
> +
> +ret = init_get_bits8(, rbsp_buf, rbsp_size);
> +if (ret < 0)
> +goto end;
> +
> +sps = av_mallocz(sizeof(*sps));
> +if (!sps)
> +goto end;
> +
> +sps->profile_idc = get_bits(, 8);
> +sps->constraint_set_flags |= get_bits1() << 0; //
> constraint_set0_flag
> +sps->constraint_set_flags |= get_bits1() << 1; //
> constraint_set1_flag
> +sps->constraint_set_flags |= get_bits1() << 2; //
> constraint_set2_flag
> +sps->constraint_set_flags |= get_bits1() << 3; //
> constraint_set3_flag
> +sps->constraint_set_flags |= get_bits1() << 4; //
> constraint_set4_flag
> +sps->constraint_set_flags |= get_bits1() << 5; //
> constraint_set5_flag
> +skip_bits(, 2); // reserved_zero_2bits
> +sps->level_idc = get_bits(, 8);
> +sps->id = get_ue_golomb();
> +
> +if (sps->profile_idc == 100 || sps->profile_idc == 110 ||
> +sps->profile_idc == 122 || sps->profile_idc == 244 ||
> sps->profile_idc ==  44 ||
> +sps->profile_idc ==  83 || sps->profile_idc ==  86 ||
> sps->profile_idc == 118 ||
> +sps->profile_idc == 128 || sps->profile_idc == 138 ||
> 

Re: [FFmpeg-devel] [PATCH] "assert(a && b)" --> "assert(a); assert(b)" for more precise diagnostics, except for libformat

[Adam Richter]

On Sun, May 12, 2019 at 11:16 AM Michael Niedermayer
 wrote:
>
> On Sun, May 12, 2019 at 05:58:50PM +0100, Mark Thompson wrote:
> > On 12/05/2019 16:24, Adam Richter wrote:
> > > This patch separates statements of the form "assert(a && b);" into
> > > "assert(a);" and "assert(b);", typically involving an assertion
> > > function like av_assert0.
> > >
> > > This patch covers all of ffmpeg, except for the libavformat, which I
> > > have already submitted separately.
> > >
> > > I have not tested this patch other than observing that ffmpeg still
> > > builds without any apparent new complaints, that no complaints in the
> > > build contain "assert", and that "make fate" seems to succeed.
> > >
> > > Thanks in advance for considering the attached patch.
> > >
> > > Adam
> > >
> > >
> > > From f815a2481a19cfd191b9f97e246b307b71d6c790 Mon Sep 17 00:00:00 2001
> > > From: Adam Richter 
> > > Date: Sun, 12 May 2019 08:02:51 -0700
> > > Subject: [PATCH] "assert(a && b)" --> "assert(a); assert(b)" for more
> > >  precise diagnostics, except for libformat.
> > >
> > > This patch separates statements of the form "assert(a && b);" into
> > > "assert(a);" and "assert(b);", for more precise diagnostics when
> > > an assertion fails, which can be especially important in cases where
> > > the problem may not be easily reproducible and save developer time.
> > > Usually, this involves functions like av_assert0.
> >
> > I don't feel very convinced by the general case of this argument.  
> > Assertions are primarily present to assist a developer reading/writing the 
> > code; they should never be triggering at runtime in non-development 
> > contexts.
> >
> > Where the statements a and b are not related then yes, splitting them is a 
> > good idea.  But when it's something like a bounds check on one variable 
> > ("av_assert0(A < n && n < B)", as appears quite a few times below) then I 
> > think keeping it as one statement feels clearer.  Similarly for highly 
> > related conditions ("av_assert0(p && p->f)" or "av_assert0(x < width && y < 
> > height)").
> >
> > > There are a couple of cases that this patch does not change:
> > > (1) assert conjunctions of the form assert(condition && "string literal
> > > to pass to the user as a helpful tip."), and
> > > (2) assert condjunctions where the first part contained a variable
> > > assignment that was used in the second part of the assertion and
> > > not outside the assert (so that the variable assignment be elided
> > > if the assertion checking omitted).
> > >
> > > This patch covers all of ffmpeg except for libavformat, which was
> > > covered in a patch that I previously submitted separately.
> > >
> > > These changes build without any new complaints that I noticed, and
> > > "make fate" succeeds, but I have not otherwise tested them.
> > >
> > > Signed-off-by: Adam Richter 
> > > ...
> > > diff --git a/libavcodec/aacpsy.c b/libavcodec/aacpsy.c
> > > index fca692cb15..bef52e8b02 100644
> > > --- a/libavcodec/aacpsy.c
> > > +++ b/libavcodec/aacpsy.c
> > > @@ -504,9 +504,11 @@ static int calc_bit_demand(AacPsyContext *ctx, float 
> > > pe, int bits, int size,
> > >  fill_level = av_clipf((float)ctx->fill_level / size, clip_low, 
> > > clip_high);
> > >  clipped_pe = av_clipf(pe, ctx->pe.min, ctx->pe.max);
> > >  bit_save   = (fill_level + bitsave_add) * bitsave_slope;
> > > -assert(bit_save <= 0.3f && bit_save >= -0.0501f);
> > > +assert(bit_save <= 0.3f);
> > > +assert(bit_save >= -0.0501f);
> > >  bit_spend  = (fill_level + bitspend_add) * bitspend_slope;
> > > -assert(bit_spend <= 0.5f && bit_spend >= -0.1f);
> > > +assert(bit_spend <= 0.5f);
> > > +assert(bit_spend >= -0.1f);
> >
> > While you're touching calls to traditional assert() please consider turning 
> > them into suitable av_assertN().
>
> I agree that they should be changed to av_assertN() but it should be
> in a seperate commit/patch
>
> These assert -> av_assertN changes will likely in some cases "activate"
> "dormant" checks which fail. Managing / Testing / Reviewing and correcting
> these should be easier if they are not in a large change splitting asserts
>
> Thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
[...]

Hello, Michael and Mark.

Thank you for your reviews of my proposed changes that would split
most assertions
of the form "a && b" into separate assertions.

Michael, if I understand correctly, you are OK with the patches after
having looked at
them to spot problems, but are not advocating for or against their
inclusion.  Mark, if I
understand correctly, you would rather see assertions split only where "a and
b are not related."  I don't think anyone else has chimed in, but I
would welcome being
told if I missed anyone else's expressed opinion or if anyone wants to
add anything now.

To make the most efficient use of your time, I would like to proceed
as follows.  In the rest
of this 

Re: [FFmpeg-devel] [PATCH 2/2] Revert "lavf/utils: Allow url credentials to contain a slash."

[Hendrik Leppkes]

On Tue, May 14, 2019 at 10:34 PM Marton Balint  wrote:
>
>
>
> On Sun, 5 May 2019, Carl Eugen Hoyos wrote:
>
> > Am So., 5. Mai 2019 um 20:51 Uhr schrieb Marton Balint :
> >>
> >> This reverts commit dd06f022b07438d650c82255dff16908ba04244a.
> >>
> >> Fixes ticket #7871 and reopens ticket #7816.
> >
> > I'll send an alternative patch in a moment.
>
> Ping for this, I still think the revert is the best we can do here.
>

I agree. Slashes are flat out not allowed in that part of the URI and
will always result in ambigious parsing.

- Hendrik
___
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/2] Revert "lavf/utils: Allow url credentials to contain a slash."

[Marton Balint]

On Sun, 5 May 2019, Carl Eugen Hoyos wrote:


Am So., 5. Mai 2019 um 20:51 Uhr schrieb Marton Balint :


This reverts commit dd06f022b07438d650c82255dff16908ba04244a.

Fixes ticket #7871 and reopens ticket #7816.


I'll send an alternative patch in a moment.


Ping for this, I still think the revert is the best we can do here.

Regards,
Marton
___
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 1/2] Revert "avcodec/qtrle: Do not output duplicated frames on insufficient input"

[Marton Balint]

On Wed, 8 May 2019, Michael Niedermayer wrote:


On Tue, May 07, 2019 at 02:03:22AM +0200, Marton Balint wrote:



On Tue, 7 May 2019, Michael Niedermayer wrote:


On Sun, May 05, 2019 at 08:51:08PM +0200, Marton Balint wrote:

This reverts commit a9dacdeea6168787a142209bd19fdd74aefc9dd6.

I don't think it is a good idea to drop frames from CFR input just because they
are duplicated, that can cause issues for API users expecting CFR input. Also
it can cause issues at the end of file, if the last frame is a duplicated
frame.

Fixes ticket #7880.

Signed-off-by: Marton Balint 
---
libavcodec/qtrle.c|  12 ++---
tests/ref/fate/qtrle-8bit | 109 ++
2 files changed, 115 insertions(+), 6 deletions(-)


This change would make the decoder quite a bit slower.


I guess that can be easily fixed by only copying the buffer if it really is
a different frame.


It also would make encoding the output harder.
For example motion estimation would be run over unchanged frames even when
no cfr is wanted.


The performance penalty is much more acceptable to me than the issue
described in the ticket. Do you see a straightforward way to fix it other
than reverting?


decoders can in general have frames at the end which need to be flushed
out. For example IPB mpeg1/2/4/...
In the same way the decoder could output a last frame representing the end
exactly


Yeah, that probably would fix the ticket. However I am still worried 
that it is just a matter of time before somebody reports something else 
that is broken because of VFR and unknown frame duration.


Do you plan on working on fixing the ticket? It is a regression, so 
prefeably it should either be fixed in a reasonable time frame or if 
nobody is willing to do it then we should revert.


The original ossfuzz issue might also be fixed by keeping only the hunk 
which moves ff_reget_buffer down.


Regards,
Marton
___
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/pngdec: Check input space

[Kieran Kunhya]

On Tue, 14 May 2019 at 20:42, Michael Niedermayer 
wrote:

> Fixes: Timeout (33sec -> 78ms)
> Fixes:
> 14668/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LSCR_fuzzer-5767073352908800
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/pngdec.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> index 6a681be29d..78988d9e75 100644
> --- a/libavcodec/pngdec.c
> +++ b/libavcodec/pngdec.c
> @@ -1535,6 +1535,9 @@ static int decode_frame_lscr(AVCodecContext *avctx,
>  AVFrame *frame = data;
>  int ret, nb_blocks, offset = 0;
>
> +if (avpkt->size < 2)
> +return AVERROR_INVALIDDATA;
> +
>

Why not 1?
Or maybe 3?
Or maybe 42?

Random numbers to fix random samples are just absurd.

Kieran
___
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] avcodec/pngdec: Check input space

[Michael Niedermayer]

Fixes: Timeout (33sec -> 78ms)
Fixes: 
14668/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LSCR_fuzzer-5767073352908800

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/pngdec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 6a681be29d..78988d9e75 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -1535,6 +1535,9 @@ static int decode_frame_lscr(AVCodecContext *avctx,
 AVFrame *frame = data;
 int ret, nb_blocks, offset = 0;
 
+if (avpkt->size < 2)
+return AVERROR_INVALIDDATA;
+
 bytestream2_init(gb, avpkt->data, avpkt->size);
 
 if ((ret = ff_get_buffer(avctx, frame, AV_GET_BUFFER_FLAG_REF)) < 0)
-- 
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] libavutil: add an FFT & MDCT implementation

[Lynne]

May 14, 2019, 7:12 PM by one...@gmail.com:

> On 5/14/19, Carl Eugen Hoyos <> ceffm...@gmail.com 
> > > wrote:
>
>>
>>
>>
>>> Am 14.05.2019 um 19:17 schrieb Lynne <>>> d...@lynne.ee 
>>> :
>>>
>>> I've attached the latest version.
>>>
>>
>> This patch is still not ok, please do not commit.
>>
>
> I will and you can not stop me.
>

Attached a version with fft-template.c's copyright and mine like James suggested
so the fighting can at least somewhat stop and I can write some SIMD.

> +/*
> + * Copyright (c) 2019 Lynne mailto:d...@lynne.ee>>
> + * Power of two FFT:
> + * Copyright (c) 2008 Loren Merritt
> + * Copyright (c) 2002 Fabrice Bellard
> + * Partly based on libdjbfft by D. J. Bernstein
> + *
> + * This file is part of FFmpeg.
>From d79083b34db80e87d6cee1d22455bc8330e866ad Mon Sep 17 00:00:00 2001
From: Lynne 
Date: Thu, 2 May 2019 15:07:12 +0100
Subject: [PATCH] libavutil: add an FFT & MDCT implementation

This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.

A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...

The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".

Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
  22353 decicycles in fftwf_execute, 1024 runs,  0 skips
  21836 decicycles in compound_fft_15x8, 1024 runs,  0 skips

128:
  22003 decicycles in   fftwf_execute,   1024 runs,  0 skips
  23132 decicycles in monolithic_fft_ptwo,   1024 runs,  0 skips

384:
  75939 decicycles in  fftwf_execute,1024 runs,  0 skips
  73973 decicycles in compound_fft_3x128,1024 runs,  0 skips

640:
 104354 decicycles in   fftwf_execute,   1024 runs,  0 skips
 149518 decicycles in compound_fft_5x128,1024 runs,  0 skips

768:
 109323 decicycles in  fftwf_execute,1024 runs,  0 skips
 164096 decicycles in compound_fft_3x256,1024 runs,  0 skips

960:
 186210 decicycles in  fftwf_execute,1024 runs,  0 skips
 215256 decicycles in compound_fft_15x64,1024 runs,  0 skips

1024:
 163464 decicycles in   fftwf_execute,   1024 runs,  0 skips
 199686 decicycles in monolithic_fft_ptwo,   1024 runs,  0 skips

With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.

The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
It is unlikely that libavcodec/fft will be removed soon as there's much SIMD
written for exotic or old platforms there, but nevertheless new code
should use this new API throughout the project.

The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical in ATRAC9 as well.
---
 libavutil/Makefile |   2 +
 libavutil/tx.c | 803 +
 libavutil/tx.h |  81 +
 3 files changed, 886 insertions(+)
 create mode 100644 libavutil/tx.c
 create mode 100644 libavutil/tx.h

diff --git a/libavutil/Makefile b/libavutil/Makefile
index 53208fc587..8a7a44e4b5 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -79,6 +79,7 @@ HEADERS = adler32.h \
   version.h \
   xtea.h\
   tea.h \
+  tx.h  \
 
 HEADERS-$(CONFIG_LZO)   += lzo.h
 
@@ -159,6 +160,7 @@ OBJS = adler32.o\
xga_font_data.o  \
xtea.o   \
tea.o   

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Paul B Mahol]

On 5/14/19, Carl Eugen Hoyos  wrote:
>
>
>
>> Am 14.05.2019 um 19:17 schrieb Lynne :
>
>> I've attached the latest version.
>
> This patch is still not ok, please do not commit.
>

I will and you can not stop me.

> 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".
___
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] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

> Am 14.05.2019 um 19:17 schrieb Lynne :

> I've attached the latest version.

This patch is still not ok, please do not commit.

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] libavutil: add an FFT & MDCT implementation

[Lynne]

May 14, 2019, 5:55 PM by one...@gmail.com:

> On 5/10/19, Lynne <> d...@lynne.ee > > wrote:
>
>> Patch updated again.
>> Made some more cleanups to the transforms, the tables and the main context.
>> API changed again, now the init function populates the function pointer for
>> transform.
>> I decided that having a separate function would encourage bad usage (e.g.
>> calling
>> the function every time before doing a transform rather than storing the
>> pointer) when
>> we're trying to avoid the overhead of function calls.
>> Also adjusted file names to match the API.
>>
>
> LGTM, going to apply soon.
>

I've attached the latest version. Not much changed, just some cleaning up, 
twiddle
adjustments to prepare for SIMD and making the scale argument a const.
I've removed AV_TX_NB, wasn't used, if needed it can be added without breaking 
the API.
Added #include  to tx.h as ptrdiff_t is defined there.

One thing to know when using it as an MDCT is that unlike ff_mdct_init where the
window size is required (e.g. for a 1024 sample MDCT you'd put in 2048 since 
that's
your window size), here the frame size is used, so you'd put in a length of 
1024 for
a 1024 sample MDCT (which has a window size of 2048 samples).
Not sure if it makes more sense in general, but we can't change behavior after 
its
pushed as it would break the API.

I've attached a diff which replaces the MDCT in aacenc, vorbisdec/enc, 
atrac9dec and
opusdec/enc with this one for testing. Passes FATE.

>From f7a8edb8c09af61b8f993da46b98d5c9b4d2002a Mon Sep 17 00:00:00 2001
From: Lynne 
Date: Thu, 2 May 2019 15:07:12 +0100
Subject: [PATCH] libavutil: add an FFT & MDCT implementation

This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.

A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...

The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".

Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
  22353 decicycles in fftwf_execute, 1024 runs,  0 skips
  21836 decicycles in compound_fft_15x8, 1024 runs,  0 skips

128:
  22003 decicycles in   fftwf_execute,   1024 runs,  0 skips
  23132 decicycles in monolithic_fft_ptwo,   1024 runs,  0 skips

384:
  75939 decicycles in  fftwf_execute,1024 runs,  0 skips
  73973 decicycles in compound_fft_3x128,1024 runs,  0 skips

640:
 104354 decicycles in   fftwf_execute,   1024 runs,  0 skips
 149518 decicycles in compound_fft_5x128,1024 runs,  0 skips

768:
 109323 decicycles in  fftwf_execute,1024 runs,  0 skips
 164096 decicycles in compound_fft_3x256,1024 runs,  0 skips

960:
 186210 decicycles in  fftwf_execute,1024 runs,  0 skips
 215256 decicycles in compound_fft_15x64,1024 runs,  0 skips

1024:
 163464 decicycles in   fftwf_execute,   1024 runs,  0 skips
 199686 decicycles in monolithic_fft_ptwo,   1024 runs,  0 skips

With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.

The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
It is unlikely that libavcodec/fft will be removed soon as there's much SIMD
written for exotic or old platforms there, but nevertheless new code
should use this new API throughout the project.

The implementation passes fate when used in Opus and AAC, and the output
is identical in ATRAC9 as well.
---
 libavutil/Makefile |   2 +
 libavutil/tx.c | 797 +
 libavutil/tx.h |  81 +
 3 files changed, 880 insertions(+)
 create mode 100644 libavutil/tx.c
 create mode 100644 libavutil/tx.h

diff --git a/libavutil/Makefile b/libavutil/Makefile
index 53208fc587..8a7a44e4b5 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -79,6 

[FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

---
 libavformat/Makefile |   2 +-
 libavformat/avc.c| 186 +
 libavformat/avc.h|  15 +++
 libavformat/hevc.c   |  36 +---
 libavformat/mxf.h|   1 +
 libavformat/mxfenc.c | 213 ++-
 6 files changed, 372 insertions(+), 81 deletions(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 99be60d184..df87c54a58 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER)  += musx.o
 OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
 OBJS-$(CONFIG_MVI_DEMUXER)   += mvi.o
 OBJS-$(CONFIG_MXF_DEMUXER)   += mxfdec.o mxf.o
-OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o
+OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o 
avc.o
 OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
 OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
 OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
diff --git a/libavformat/avc.c b/libavformat/avc.c
index ec50033a04..a041e84357 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -21,6 +21,7 @@
 
 #include "libavutil/intreadwrite.h"
 #include "libavcodec/h264.h"
+#include "libavcodec/get_bits.h"
 #include "avformat.h"
 #include "avio.h"
 #include "avc.h"
@@ -241,3 +242,188 @@ const uint8_t *ff_avc_mp4_find_startcode(const uint8_t 
*start,
 
 return start + res;
 }
+
+uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
+  uint32_t *dst_len, int header_len)
+{
+uint8_t *dst;
+uint32_t i, len;
+
+dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!dst)
+return NULL;
+
+/* NAL unit header */
+i = len = 0;
+while (i < header_len && i < src_len)
+dst[len++] = src[i++];
+
+while (i + 2 < src_len)
+if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
+dst[len++] = src[i++];
+dst[len++] = src[i++];
+i++; // remove emulation_prevention_three_byte
+} else
+dst[len++] = src[i++];
+
+while (i < src_len)
+dst[len++] = src[i++];
+
+memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+
+*dst_len = len;
+return dst;
+}
+
+static const AVRational avc_sample_aspect_ratio[17] = {
+{   0,  1 },
+{   1,  1 },
+{  12, 11 },
+{  10, 11 },
+{  16, 11 },
+{  40, 33 },
+{  24, 11 },
+{  20, 11 },
+{  32, 11 },
+{  80, 33 },
+{  18, 11 },
+{  15, 11 },
+{  64, 33 },
+{ 160, 99 },
+{   4,  3 },
+{   3,  2 },
+{   2,  1 },
+};
+
+static inline int get_ue_golomb(GetBitContext *gb) {
+int i;
+for (i = 0; i < 32 && !get_bits1(gb); i++)
+;
+return get_bitsz(gb, i) + (1 << i) - 1;
+}
+
+static inline int get_se_golomb(GetBitContext *gb) {
+int v = get_ue_golomb(gb) + 1;
+int sign = -(v & 1);
+return ((v >> 1) ^ sign) - sign;
+}
+
+H264SequenceParameterSet *ff_avc_decode_sps(const uint8_t *buf, int buf_size)
+{
+int i, j, ret, rbsp_size, aspect_ratio_idc, pic_order_cnt_type;
+int num_ref_frames_in_pic_order_cnt_cycle;
+int delta_scale, lastScale = 8, nextScale = 8;
+int sizeOfScalingList;
+H264SequenceParameterSet *sps = NULL;
+GetBitContext gb;
+uint8_t *rbsp_buf;
+
+rbsp_buf = ff_nal_unit_extract_rbsp(buf, buf_size, _size, 0);
+if (!rbsp_buf)
+return NULL;
+
+ret = init_get_bits8(, rbsp_buf, rbsp_size);
+if (ret < 0)
+goto end;
+
+sps = av_mallocz(sizeof(*sps));
+if (!sps)
+goto end;
+
+sps->profile_idc = get_bits(, 8);
+sps->constraint_set_flags |= get_bits1() << 0; // constraint_set0_flag
+sps->constraint_set_flags |= get_bits1() << 1; // constraint_set1_flag
+sps->constraint_set_flags |= get_bits1() << 2; // constraint_set2_flag
+sps->constraint_set_flags |= get_bits1() << 3; // constraint_set3_flag
+sps->constraint_set_flags |= get_bits1() << 4; // constraint_set4_flag
+sps->constraint_set_flags |= get_bits1() << 5; // constraint_set5_flag
+skip_bits(, 2); // reserved_zero_2bits
+sps->level_idc = get_bits(, 8);
+sps->id = get_ue_golomb();
+
+if (sps->profile_idc == 100 || sps->profile_idc == 110 ||
+sps->profile_idc == 122 || sps->profile_idc == 244 || sps->profile_idc 
==  44 ||
+sps->profile_idc ==  83 || sps->profile_idc ==  86 || sps->profile_idc 
== 118 ||
+sps->profile_idc == 128 || sps->profile_idc == 138 || sps->profile_idc 
== 139 ||
+sps->profile_idc == 134) {
+sps->chroma_format_idc = get_ue_golomb(); // chroma_format_idc
+if (sps->chroma_format_idc == 3) {
+skip_bits1(); // separate_colour_plane_flag
+}
+sps->bit_depth_luma = get_ue_golomb() + 8;
+get_ue_golomb(); // bit_depth_chroma_minus8
+skip_bits1(); // 

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Paul B Mahol]

On 5/10/19, Lynne  wrote:
> Patch updated again.
> Made some more cleanups to the transforms, the tables and the main context.
> API changed again, now the init function populates the function pointer for
> transform.
> I decided that having a separate function would encourage bad usage (e.g.
> calling
> the function every time before doing a transform rather than storing the
> pointer) when
> we're trying to avoid the overhead of function calls.
> Also adjusted file names to match the API.
>
>

LGTM, going to apply soon.
___
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] libavcodec/qsvenc: fix mpeg2 encoding

[Andreas Håkon]

Fixes bug #7839
https://trac.ffmpeg.org/ticket/7839

Supersedes:
#12935 - https://patchwork.ffmpeg.org/patch/12935/
#12872 - https://patchwork.ffmpeg.org/patch/12872/

Regards.
A.H.

---From 49aa7d21026051dc353a8658509d2ba81520bf78 Mon Sep 17 00:00:00 2001
From: Andreas Hakon 
Date: Tue, 14 May 2019 16:42:08 +0100
Subject: [PATCH] libavcodec/qsvenc: fix mpeg2 encoding

Commit "lavc/qsvenc: enable QVBR mode" generated a regression with the MPEG-2
QSV HW Encoder on the Windows platform. See trac #7839.

This patch fixes the problem by running a runtime check during initialization.
When using the MPEG-2 encoder the extended CO3 buffer is not added to the 
context.

Signed-off-by: Andreas Hakon 
---
 libavcodec/qsvenc.c |   17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index a03ab69..9d26db0 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -267,10 +267,12 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
 #endif
 #endif
 
+#if QSV_HAVE_CO3
 #if QSV_HAVE_GPB
 if (avctx->codec_id == AV_CODEC_ID_HEVC)
 av_log(avctx, AV_LOG_VERBOSE,"GPB: %s\n", print_threestate(co3->GPB));
 #endif
+#endif
 
 if (avctx->codec_id == AV_CODEC_ID_H264) {
 av_log(avctx, AV_LOG_VERBOSE, "Entropy coding: %s; 
MaxDecFrameBuffering: %"PRIu16"\n",
@@ -598,9 +600,11 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
 q->param.mfx.MaxKbps  = max_bitrate_kbps / 
brc_param_multiplier;
 q->param.mfx.BRCParamMultiplier = brc_param_multiplier;
 #if QSV_HAVE_QVBR
+#if QSV_HAVE_CO3
 if (q->param.mfx.RateControlMethod == MFX_RATECONTROL_QVBR)
 q->extco3.QVBRQuality = av_clip(avctx->global_quality, 0, 51);
 #endif
+#endif
 break;
 case MFX_RATECONTROL_CQP:
 quant = avctx->global_quality / FF_QP2LAMBDA;
@@ -751,13 +755,16 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 }
 #if QSV_HAVE_CO3
-q->extco3.Header.BufferId  = MFX_EXTBUFF_CODING_OPTION3;
-q->extco3.Header.BufferSz  = sizeof(q->extco3);
+if (avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO ) {
+av_log(avctx,AV_LOG_DEBUG,"Initializing the MFX context with the 
Extended Coding Option 3 (extco3)\n");
+q->extco3.Header.BufferId  = MFX_EXTBUFF_CODING_OPTION3;
+q->extco3.Header.BufferSz  = sizeof(q->extco3);
 #if QSV_HAVE_GPB
-if (avctx->codec_id == AV_CODEC_ID_HEVC)
-q->extco3.GPB  = q->gpb ? MFX_CODINGOPTION_ON : 
MFX_CODINGOPTION_OFF;
+if (avctx->codec_id == AV_CODEC_ID_HEVC)
+q->extco3.GPB  = q->gpb ? MFX_CODINGOPTION_ON : 
MFX_CODINGOPTION_OFF;
 #endif
-q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer 
*)>extco3;
+q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer 
*)>extco3;
+}
 #endif
 }
 
-- 
1.7.10.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 2/2] avformat/aviobuf: Forward error codes in avio_seek

[Andreas Rheinhardt]

Michael Niedermayer:
> On Tue, May 14, 2019 at 10:49:49AM +0200, Andreas Rheinhardt wrote:
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavformat/aviobuf.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> do you have some testcase for this ?
> 
> thanks
> 
Honestly, no. I just read the code.
(Btw: Thinking of the bigger picture, there is something even weirder:
If an error happens (i.e. an AVIOContext's error is set) and one
performs a successfull seek, then error will still be set, yet
eof_reached will be cleared, although the latter is supposed to be
always set when error is set, isn't it? The same thing can happen when
one calls avio_feof on the AVIOContext.)

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

Re: [FFmpeg-devel] How to correctly use init and uninit

[Ulf Zibis]

Am 19.04.19 um 14:35 schrieb Paul B Mahol:
>>> You do not need to use loop filter on single png.
>> I need real pictures to prove the correctness of my hacking. The
>> smptebars is not appopriate to see errors in the output e.g. from mirroring.
>>
>>> Use something like this:
>>>
>>> ffmpeg -f lavfi -i smptebars=size=hd720 -vf fillborders=... -f null -
>> For performance testing I use the like:
>> -f rawvideo -pix_fmt gray16 -s 400x600 -i /dev/zero
>>
>> Are there doubts if that is good either?
> Use ffmpeg -f lavfi -i color=color=black:size=400x600 ...
>
> Thing about /dev/zero and -f rawvideo is that it will decode zeroes
> over and over again and thus use more CPU for that.

Unfortunately I can not confirm that. :-(

My benchmark needs 60 seconds with
ffmpeg -f lavfi -i
color=color=black:size=400x600,format=rgba64/gray/gray16 ...
but only 25 seconds with
ffmpeg -f rawvideo -pix_fmt rgba64/gray/gray16 -s 400x600 -i /dev/zero ...

-Ult


___
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] avfilter/vf_stack: Don't modify const strings

[Gyan]

On 14-05-2019 06:11 PM, Paul B Mahol wrote:

On 5/14/19, Gyan  wrote:


On 14-05-2019 09:45 AM, Andreas Rheinhardt wrote:

b3b7ba62 introduced undefined behaviour: A (non-modifiable) string
literal has been assigned to a modifiable string; said string was indeed
modified later via av_strtok.
This of course caused compiler warnings because of the discarded
qualifier; these are in particular fixed by this commit.

Signed-off-by: Andreas Rheinhardt 
---
   libavfilter/vf_stack.c | 8 +---
   1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_stack.c b/libavfilter/vf_stack.c
index 1455f196a7..4d254e0013 100644
--- a/libavfilter/vf_stack.c
+++ b/libavfilter/vf_stack.c
@@ -84,9 +84,11 @@ static av_cold int init(AVFilterContext *ctx)

   if (!strcmp(ctx->filter->name, "xstack")) {
   if (!s->layout) {
-if (s->nb_inputs == 2)
-s->layout = "0_0|w0_0";
-else {
+if (s->nb_inputs == 2) {
+s->layout = av_strdup("0_0|w0_0");
+if (!s->layout)
+return AVERROR(ENOMEM);
+} else {
   av_log(ctx, AV_LOG_ERROR, "No layout specified.\n");
   return AVERROR(EINVAL);
   }

Sorry, I missed what was being done with the string later on.


Why you pushed something else that what was reviewed?
The code I pushed was exactly the same as what you reviewed; only the 
commit msg was changed to what you suggested.


See

http://www.ffmpeg.org/pipermail/ffmpeg-devel/2019-May/243664.html

vs

http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavfilter/vf_stack.c;h=1455f196a7cb3124f7a7931f6b56ed985848d75b;hp=b836d96bf09a70d943f28b4424da0af3bf62ecea;hb=b3b7ba623f95224557bd67a060adf4ca7ee94dde;hpb=e25bddf5fce88f95be8bf3cbc8adf4a74bc28fb5

Your review:
http://www.ffmpeg.org/pipermail/ffmpeg-devel/2019-May/243665.html


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

[FFmpeg-devel] [PATCH] lavc/videotoolboxenc: Fix compilation for IOS < 11.0 and OSX, < 10.13

[Thilo Borgmann]

$Subject

Tested compilation only, sanity test actually using it appreciated.

Thanks,
Thilo
From 104b26ca0eab116dcd49b5f2090067b76b5bfc70 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Tue, 14 May 2019 15:11:38 +0200
Subject: [PATCH] lavc/videotoolboxenc: Fix compilation for IOS < 11.0 and OSX
 < 10.13.

Prior OS versions are missing the 10bpp formats.
---
 libavcodec/videotoolboxenc.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 3665581..24e0b62 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -762,12 +762,17 @@ static int get_cv_pixel_format(AVCodecContext* avctx,
 *av_pixel_format = range == AVCOL_RANGE_JPEG ?
 
kCVPixelFormatType_420YpCbCr8PlanarFullRange :
 kCVPixelFormatType_420YpCbCr8Planar;
-} else if (fmt == AV_PIX_FMT_P010LE) {
+}
+#if ((!TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 101300) || \
+ (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 11))
+else if (fmt == AV_PIX_FMT_P010LE) {
 *av_pixel_format = range == AVCOL_RANGE_JPEG ?
 
kCVPixelFormatType_420YpCbCr10BiPlanarFullRange :
 
kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange;
 *av_pixel_format = kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange;
-} else {
+}
+#endif
+else {
 return AVERROR(EINVAL);
 }
 
@@ -1991,6 +1996,8 @@ static int get_cv_pixel_info(
 strides[2] = frame ? frame->linesize[2] : (avctx->width + 1) / 2;
 break;
 
+#if ((!TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 101300) || \
+ (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 11))
 case AV_PIX_FMT_P010LE:
 *plane_count = 2;
 widths[0] = avctx->width;
@@ -2001,6 +2008,7 @@ static int get_cv_pixel_info(
 heights[1] = (avctx->height + 1) / 2;
 strides[1] = frame ? frame->linesize[1] : ((avctx->width + 1) / 2 + 
63) & -64;
 break;
+#endif
 
 default:
 av_log(
@@ -2488,7 +2496,10 @@ static const enum AVPixelFormat hevc_pix_fmts[] = {
 AV_PIX_FMT_VIDEOTOOLBOX,
 AV_PIX_FMT_NV12,
 AV_PIX_FMT_YUV420P,
+#if ((!TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 101300) || \
+ (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 11))
 AV_PIX_FMT_P010LE,
+#endif
 AV_PIX_FMT_NONE
 };
 
-- 
1.8.3.2

___
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/2] avformat/mp3enc: Avoid SEEK_END as it is unsupported

[Andreas Rheinhardt]

James Almer:
> On 5/14/2019 8:04 AM, Michael Niedermayer wrote:
>> Signed-off-by: Michael Niedermayer 
>> ---
>>  libavformat/mp3enc.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
>> index dd662f5473..f4814be80e 100644
>> --- a/libavformat/mp3enc.c
>> +++ b/libavformat/mp3enc.c
>> @@ -391,6 +391,7 @@ static void mp3_update_xing(AVFormatContext *s)
>>  uint16_t tag_crc;
>>  uint8_t *toc;
>>  int i, rg_size;
>> +int64_t old_pos = avio_tell(s->pb);
>>  
>>  /* replace "Xing" identification string with "Info" for CBR files. */
>>  if (!mp3->has_variable_bitrate)
>> @@ -450,7 +451,7 @@ static void mp3_update_xing(AVFormatContext *s)
>>  
>>  avio_seek(s->pb,  mp3->xing_frame_offset, SEEK_SET);
>>  avio_write(s->pb, mp3->xing_frame, mp3->xing_frame_size);
>> -avio_seek(s->pb, 0, SEEK_END);
>> +avio_seek(s->pb, old_pos, SEEK_SET);
> 
> What do you mean unsupported?
> 
avio_seek only accepts SEEK_CUR and SEEK_SET (possibly OR'ed with
AVSEEK_FORCE) as whence parameter (everything else is AVERROR(EINVAL)).

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_stack: Don't modify const strings

[Paul B Mahol]

On 5/14/19, Andreas Rheinhardt  wrote:
> b3b7ba62 introduced undefined behaviour: A (non-modifiable) string
> literal has been assigned to a modifiable string; said string was indeed
> modified later via av_strtok.
> This of course caused compiler warnings because of the discarded
> qualifier; these are in particular fixed by this commit.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavfilter/vf_stack.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/vf_stack.c b/libavfilter/vf_stack.c
> index 1455f196a7..4d254e0013 100644
> --- a/libavfilter/vf_stack.c
> +++ b/libavfilter/vf_stack.c
> @@ -84,9 +84,11 @@ static av_cold int init(AVFilterContext *ctx)
>
>  if (!strcmp(ctx->filter->name, "xstack")) {
>  if (!s->layout) {
> -if (s->nb_inputs == 2)
> -s->layout = "0_0|w0_0";
> -else {
> +if (s->nb_inputs == 2) {
> +s->layout = av_strdup("0_0|w0_0");
> +if (!s->layout)
> +return AVERROR(ENOMEM);
> +} else {
>  av_log(ctx, AV_LOG_ERROR, "No layout specified.\n");
>  return AVERROR(EINVAL);
>  }
> --
> 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".

Applied.
___
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/2] avformat/mp3enc: Avoid SEEK_END as it is unsupported

[James Almer]

On 5/14/2019 8:04 AM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mp3enc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
> index dd662f5473..f4814be80e 100644
> --- a/libavformat/mp3enc.c
> +++ b/libavformat/mp3enc.c
> @@ -391,6 +391,7 @@ static void mp3_update_xing(AVFormatContext *s)
>  uint16_t tag_crc;
>  uint8_t *toc;
>  int i, rg_size;
> +int64_t old_pos = avio_tell(s->pb);
>  
>  /* replace "Xing" identification string with "Info" for CBR files. */
>  if (!mp3->has_variable_bitrate)
> @@ -450,7 +451,7 @@ static void mp3_update_xing(AVFormatContext *s)
>  
>  avio_seek(s->pb,  mp3->xing_frame_offset, SEEK_SET);
>  avio_write(s->pb, mp3->xing_frame, mp3->xing_frame_size);
> -avio_seek(s->pb, 0, SEEK_END);
> +avio_seek(s->pb, old_pos, SEEK_SET);

What do you mean unsupported?

>  }
>  
>  static int mp3_write_trailer(struct AVFormatContext *s)
> 

___
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] avcodec/mss4: Check input size against skip bits

[Michael Niedermayer]

Fixes: Timeout (17sec -> 20ms)
Fixes: 
14615/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MTS2_fuzzer-5093007763701760

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/mss4.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavcodec/mss4.c b/libavcodec/mss4.c
index b58c21be93..76c746a2d5 100644
--- a/libavcodec/mss4.c
+++ b/libavcodec/mss4.c
@@ -552,6 +552,11 @@ static int mss4_decode_frame(AVCodecContext *avctx, void 
*data, int *got_frame,
"Empty frame found but it is not a skip frame.\n");
 return AVERROR_INVALIDDATA;
 }
+mb_width  = FFALIGN(width,  16) >> 4;
+mb_height = FFALIGN(height, 16) >> 4;
+
+if (frame_type != SKIP_FRAME && 8*buf_size < 8*HEADER_SIZE + 
mb_width*mb_height)
+return AVERROR_INVALIDDATA;
 
 if ((ret = ff_reget_buffer(avctx, c->pic)) < 0)
 return ret;
@@ -574,9 +579,6 @@ static int mss4_decode_frame(AVCodecContext *avctx, void 
*data, int *got_frame,
 
 if ((ret = init_get_bits8(, buf + HEADER_SIZE, buf_size - HEADER_SIZE)) 
< 0)
 return ret;
-
-mb_width  = FFALIGN(width,  16) >> 4;
-mb_height = FFALIGN(height, 16) >> 4;
 dst[0] = c->pic->data[0];
 dst[1] = c->pic->data[1];
 dst[2] = c->pic->data[2];
-- 
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] libavformat/qsvenc: fix mpeg2 missing headers

[Andreas Rheinhardt]

Hello,

Andreas Håkon:
> Hi,
> 
> A fix for the missing in-band Sequence Headers from the QSV MPEG-2 HW Encoder.
> 
> Regards.
> A.H.

I know nothing about QSV, but I know a bit about MPEG-2 and have
therefore taken a quick look at this:

1.
> +if ((p_buf[7] & 0x1) == 1) {
> +memcpy(q->matrix, p_buf + 8, 64);
> +p_sec += 4;
> +av_log(avctx, AV_LOG_VERBOSE, "Found
> MPEG-2 Matrix\n");
You are checking the wrong bit here (it should be the 0x2 bit) and you
are copying the wrong bits. That's because the intra_quantiser_matrix
matrix (if it is explicitly coded) doesn't start at a byte-aligned
position. Maybe you should not split the sequence header into two
buffers, but simply use one big buffer (and record the size of the
actual data in the buffer (which of course depends on the whether the
matrices are explicitly coded or not) somewhere)?
(If it is so that MPEG-2-QSV only ever uses the
non_intra_quantiser_matrix, then your approach might make sense.)

2. You are implicitly assuming that only one of the matrices exists,
but there can be two in the sequence header. Or is it documented
somewhere that MPEG-2-QSV can only use one matrix?

3. You are also implicitly assuming that there is no
quant_matrix_extension (which can have up to four matrices in it, but
only up to two for 4:2:0 video). Is it documented somewhere that this
is so?

4. According to the standard (section 6.1.1.6), if a sequence header
access unit contains a sequence_scalable_extension or
sequence_display_extension, then these need to be repeated in every
access unit with a repeat sequence header. So if MPEG-2-QSV might emit
them at the beginning, you need to record them and reinsert them along
with the rest every time you insert sequence headers.

5. You seem to use p_sec as a bitfield; so it would seem appropriate
to use |= to set the bits and not addition.

6. Is it really certain (and not only observed behaviour) that the QSV
encoder does not repeat sequence header in-band? (It is against the
specs to have two sequence headers in an access unit.)

7.
> +case 1:
> +memmove(bs->Data + 23, bs->Data, bs->DataLength - 23);
> +bs->DataLength  += 23;
> +memcpy( bs->Data + 0 , q->seq_header, 13);
> +memcpy( bs->Data + 13, q->seq_ext,10);
> +break;
> +case 2:
> +memmove(bs->Data + 87, bs->Data, bs->DataLength - 87);
> +bs->DataLength  += 87;
> +memcpy( bs->Data + 0 , q->seq_header, 13);
> +memcpy( bs->Data + 13, q->matrix, 64);
> +memcpy( bs->Data + 77, q->seq_ext,10);
> +break;

This looks extremely fishy: You essentially throw the last 23/87 bytes
of the bs.Data buffer away and nevertheless you increase the length of
the data by 23/87 bytes.

8.
>+if (avctx->codec_id == AV_CODEC_ID_MPEG2VIDEO) {
>+q->section_state = 0;
>+}
>+else {
>+q->section_state = -1;
>+}

The "else {" should be on the same line as the preceding closing }.

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_stack: Don't modify const strings

[Paul B Mahol]

On 5/14/19, Gyan  wrote:
>
>
> On 14-05-2019 09:45 AM, Andreas Rheinhardt wrote:
>> b3b7ba62 introduced undefined behaviour: A (non-modifiable) string
>> literal has been assigned to a modifiable string; said string was indeed
>> modified later via av_strtok.
>> This of course caused compiler warnings because of the discarded
>> qualifier; these are in particular fixed by this commit.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>   libavfilter/vf_stack.c | 8 +---
>>   1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavfilter/vf_stack.c b/libavfilter/vf_stack.c
>> index 1455f196a7..4d254e0013 100644
>> --- a/libavfilter/vf_stack.c
>> +++ b/libavfilter/vf_stack.c
>> @@ -84,9 +84,11 @@ static av_cold int init(AVFilterContext *ctx)
>>
>>   if (!strcmp(ctx->filter->name, "xstack")) {
>>   if (!s->layout) {
>> -if (s->nb_inputs == 2)
>> -s->layout = "0_0|w0_0";
>> -else {
>> +if (s->nb_inputs == 2) {
>> +s->layout = av_strdup("0_0|w0_0");
>> +if (!s->layout)
>> +return AVERROR(ENOMEM);
>> +} else {
>>   av_log(ctx, AV_LOG_ERROR, "No layout specified.\n");
>>   return AVERROR(EINVAL);
>>   }
>
> Sorry, I missed what was being done with the string later on.
>

Why you pushed something else that what was reviewed?

> 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".
___
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 1/2] VP4 video decoder

[James Almer]

On 5/14/2019 9:37 AM, Peter Ross wrote:
> On Sun, May 12, 2019 at 01:24:56PM +0200, Reimar Döffinger wrote:
>> On 12.05.2019, at 08:12, Peter Ross  wrote:
>>> +static int read_mb_value(GetBitContext *gb)
>>> +{
>>> +int v = 1;
>>> +int size;
>>> +
>>> +do {
>>> +size = 0;
>>> +if (!get_bits1(gb))
>>> +break;
>>> +v++;
>>> +do {
>>> +if (!get_bits1(gb))
>>> +break;
>>> +v += 1 << size++;
>>> +} while (size < 8);
>>> +} while (size == 8);
>>> +
>>> +if (size)
>>> +v += get_bits(gb, size);
>>> +
>>> +return v;
>>> +}
>>
>> Maybe not worth it performance wise, but did you check if this could be 
>> simplified?
>> For example the get_bits1 cases that end up with size 0 could return 
>> directly.
>> Or it could peek ahead 9 bits in the bitstream and count the leading 1s to 
>> get v and size without looping (i.e. loop only for the 9 bits of 1s 
>> specifically).
>> Alternatively add a comment to clarify the encoding scheme it implements 
>> (like 9 consecutive 1s is a prefix encoding an offset of 257 etc).
> 
> thanks for these suggestions.
> 
> replacing get_bits() with OPEN_READER/UPDATE_CACHE/SHOW_UBITS/etc results in a
> consistent 0.50 % speedup.

You could also test the cached reader Paul wrote some time ago, and see
if it's faster. Just define CACHED_BITSTREAM_READER to 1 to enable it
and use the get_bits functions normally (don't use the above macros).

Make sure to test in both x86_32 and x86_64, since it uses a 64bit
variable as bit cache. If it's only faster in x86_64, you could enable
it only for those targets.

> 
> checking the initial bit, and returning from the function early, appears to 
> make
> no difference to decoder speed.
> 
> moving 'v += 1 << size++' to go outside the inner loop makes it more clear
> what the algorithm is doing. i was hoping for a speed improvement, but see no 
> change.
> 
> -- Peter
> (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
> 
> 
> ___
> 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 1/2] VP4 video decoder

[Peter Ross]

On Sun, May 12, 2019 at 01:24:56PM +0200, Reimar Döffinger wrote:
> On 12.05.2019, at 08:12, Peter Ross  wrote:
> > +static int read_mb_value(GetBitContext *gb)
> > +{
> > +int v = 1;
> > +int size;
> > +
> > +do {
> > +size = 0;
> > +if (!get_bits1(gb))
> > +break;
> > +v++;
> > +do {
> > +if (!get_bits1(gb))
> > +break;
> > +v += 1 << size++;
> > +} while (size < 8);
> > +} while (size == 8);
> > +
> > +if (size)
> > +v += get_bits(gb, size);
> > +
> > +return v;
> > +}
> 
> Maybe not worth it performance wise, but did you check if this could be 
> simplified?
> For example the get_bits1 cases that end up with size 0 could return directly.
> Or it could peek ahead 9 bits in the bitstream and count the leading 1s to 
> get v and size without looping (i.e. loop only for the 9 bits of 1s 
> specifically).
> Alternatively add a comment to clarify the encoding scheme it implements 
> (like 9 consecutive 1s is a prefix encoding an offset of 257 etc).

thanks for these suggestions.

replacing get_bits() with OPEN_READER/UPDATE_CACHE/SHOW_UBITS/etc results in a
consistent 0.50 % speedup.

checking the initial bit, and returning from the function early, appears to make
no difference to decoder speed.

moving 'v += 1 << size++' to go outside the inner loop makes it more clear
what the algorithm is doing. i was hoping for a speed improvement, but see no 
change.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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/2] avformat/mp3enc: Avoid SEEK_END as it is unsupported

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavformat/mp3enc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
index dd662f5473..f4814be80e 100644
--- a/libavformat/mp3enc.c
+++ b/libavformat/mp3enc.c
@@ -391,6 +391,7 @@ static void mp3_update_xing(AVFormatContext *s)
 uint16_t tag_crc;
 uint8_t *toc;
 int i, rg_size;
+int64_t old_pos = avio_tell(s->pb);
 
 /* replace "Xing" identification string with "Info" for CBR files. */
 if (!mp3->has_variable_bitrate)
@@ -450,7 +451,7 @@ static void mp3_update_xing(AVFormatContext *s)
 
 avio_seek(s->pb,  mp3->xing_frame_offset, SEEK_SET);
 avio_write(s->pb, mp3->xing_frame, mp3->xing_frame_size);
-avio_seek(s->pb, 0, SEEK_END);
+avio_seek(s->pb, old_pos, SEEK_SET);
 }
 
 static int mp3_write_trailer(struct AVFormatContext *s)
-- 
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 1/2] avformat/dashenc: use 64bit for handling the return of avio_tell()

[Michael Niedermayer]

The return code is 64bit, so this is more correct, especially in case it
actually would be a file of such large size

Signed-off-by: Michael Niedermayer 
---
 libavformat/dashenc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index b88d4b3496..94b198ceb8 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1611,11 +1611,11 @@ static int dash_flush(AVFormatContext *s, int final, 
int stream)
 for (i = 0; i < s->nb_streams; i++) {
 OutputStream *os = >streams[i];
 if (os->ctx && os->ctx_inited) {
-int file_size = avio_tell(os->ctx->pb);
+int64_t file_size = avio_tell(os->ctx->pb);
 av_write_trailer(os->ctx);
 if (c->global_sidx) {
 int j, start_index, start_number;
-int sidx_size = avio_tell(os->ctx->pb) - file_size;
+int64_t sidx_size = avio_tell(os->ctx->pb) - file_size;
 get_start_index_number(os, c, _index, _number);
 if (start_index >= os->nb_segments ||
 os->segment_type != SEGMENT_TYPE_MP4)
-- 
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] ffplay: added option always on top for video window

[Daniel Kučera]

po 13. 5. 2019 o 13:42 Daniel Kucera  napísal(a):
>
> From: Daniel Kucera 
>
> Signed-off-by: Daniel Kucera 
> ---
>  doc/ffplay.texi  | 2 ++
>  fftools/ffplay.c | 8 
>  2 files changed, 10 insertions(+)
>
> diff --git a/doc/ffplay.texi b/doc/ffplay.texi
> index c305465078..a487c0de8d 100644
> --- a/doc/ffplay.texi
> +++ b/doc/ffplay.texi
> @@ -66,6 +66,8 @@ Set custom interval, in seconds, for seeking using 
> left/right keys. Default is 1
>  Disable graphical display.
>  @item -noborder
>  Borderless window.
> +@item -alwaysontop
> +Window always on top. Available on: X11 with SDL >= 2.0.5, Windows SDL >= 
> 2.0.6.
>  @item -volume
>  Set the startup volume. 0 means silence, 100 means no volume reduction or
>  amplification. Negative values are treated as 0, values above 100 are treated
> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> index 8f050e16e6..8fb8faeb06 100644
> --- a/fftools/ffplay.c
> +++ b/fftools/ffplay.c
> @@ -324,6 +324,7 @@ static int seek_by_bytes = -1;
>  static float seek_interval = 10;
>  static int display_disable;
>  static int borderless;
> +static int alwaysontop;
>  static int startup_volume = 100;
>  static int show_status = 1;
>  static int av_sync_type = AV_SYNC_AUDIO_MASTER;
> @@ -3581,6 +3582,7 @@ static const OptionDef options[] = {
>  { "seek_interval", OPT_FLOAT | HAS_ARG, { _interval }, "set seek 
> interval for left/right keys, in seconds", "seconds" },
>  { "nodisp", OPT_BOOL, { _disable }, "disable graphical display" 
> },
>  { "noborder", OPT_BOOL, {  }, "borderless window" },
> +{ "alwaysontop", OPT_BOOL, {  }, "window always on top" },
>  { "volume", OPT_INT | HAS_ARG, { _volume}, "set startup volume 
> 0=min 100=max", "volume" },
>  { "f", HAS_ARG, { .func_arg = opt_format }, "force format", "fmt" },
>  { "pix_fmt", HAS_ARG | OPT_EXPERT | OPT_VIDEO, { .func_arg = 
> opt_frame_pix_fmt }, "set pixel format", "format" },
> @@ -3722,6 +3724,12 @@ int main(int argc, char **argv)
>
>  if (!display_disable) {
>  int flags = SDL_WINDOW_HIDDEN;
> +if (alwaysontop)
> +#if SDL_VERSION_ATLEAST(2,0,5)
> +flags |= SDL_WINDOW_ALWAYS_ON_TOP;
> +#else
> +av_log(NULL, AV_LOG_WARNING, "Your SDL version doesn't support 
> SDL_WINDOW_ALWAYS_ON_TOP. Feature will be inactive.\n");
> +#endif
>  if (borderless)
>  flags |= SDL_WINDOW_BORDERLESS;
>  else
> --
> 2.17.1
>

Ping.

-- 

S pozdravom / Best regards
Daniel Kucera.
___
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] avfilter/drawtext: make command processing error-resilient

[Gyan]

On 14-05-2019 02:03 PM, Timo Rothenpieler wrote:

On 10/05/2019 15:55, Gyan wrote:
At present, if the command args passed to drawtext contain any 
invalid values, ffmpeg may crash or, at best, stop drawing any text.
Attached patch gets the filter to continue with existing parameters, 
if not all of the changes can be parsed or applied. This allows users 
in live processing to correct and resubmit.


Gyan


This patch has at least two mis-uses of av_freep(), which potentially 
lead to a crash.



+    av_freep(old);
+
+    ctx->priv = new;


Should probably be av_freep();


+fail:
+    av_log(ctx, AV_LOG_ERROR, "Failed to process command. Continuing 
with existing parameters.\n");

+    av_freep(new);
+    return ret;


Should probably be av_freep();


Will push these soon.

I did not do a full review of the patch, just pointing out those 
issues Coverity found. See coverity CID 1445099.


Requested Coverity access via Synopsys.

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

[FFmpeg-devel] [PATCH] libavformat/qsvenc: fix mpeg2 missing headers

[Andreas Håkon]

Hi,

A fix for the missing in-band Sequence Headers from the QSV MPEG-2 HW Encoder.

Regards.
A.H.

---From a0b8525e0ebfd1a3b91bad7a21cc9de5c5a01e0e Mon Sep 17 00:00:00 2001
From: Andreas Hakon 
Date: Tue, 14 May 2019 11:07:10 +0100
Subject: [PATCH] libavformat/qsvenc: fix mpeg2 missing headers

The current implementation of the QSV MPEG-2 HW encoder writes the value
of MPEG-2 sequence headers in-band one time only. That is, in the first GOP
of the stream. This behavior generates a bitstream that is not suitable for
streaming or broadcasting.
This patch resolves this problem by reading these headers the first time 
they appear, and reinserting them back into each GOP with the rest of
the MPEG-2 headers.

Signed-off-by: Andreas Hakon 
---
 libavcodec/qsvenc.c |   88 +++
 libavcodec/qsvenc.h |5 +++
 2 files changed, 93 insertions(+)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index a03ab69..18d4540 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -39,6 +39,7 @@
 #include "qsv.h"
 #include "qsv_internal.h"
 #include "qsvenc.h"
+#include "mpegvideo.h"
 
 static const struct {
 mfxU16 profile;
@@ -998,6 +999,13 @@ int ff_qsv_enc_init(AVCodecContext *avctx, QSVEncContext 
*q)
 int opaque_alloc = 0;
 int ret;
 
+if (avctx->codec_id == AV_CODEC_ID_MPEG2VIDEO) {
+q->section_state = 0;
+}
+else {
+q->section_state = -1;
+}
+
 q->param.AsyncDepth = q->async_depth;
 
 q->async_fifo = av_fifo_alloc(q->async_depth * qsv_fifo_item_size());
@@ -1296,6 +1304,10 @@ static int encode_frame(AVCodecContext *avctx, 
QSVEncContext *q,
 QSVFrame *qsv_frame = NULL;
 mfxEncodeCtrl* enc_ctrl = NULL;
 int ret;
+int p_sec, p_bytes_left;
+const uint8_t *p_buf;
+const uint8_t *p_buf_end;
+uint32_t start_code;
 
 if (frame) {
 ret = submit_frame(q, frame, _frame);
@@ -1388,6 +1400,82 @@ static int encode_frame(AVCodecContext *avctx, 
QSVEncContext *q,
0 : ff_qsv_print_error(avctx, ret, "Error during encoding");
 }
 
+// Patch MPEG-2 missing Sequence Sections
+if (avctx->codec_id == AV_CODEC_ID_MPEG2VIDEO &&
+(bs->FrameType & MFX_FRAMETYPE_I || bs->FrameType & MFX_FRAMETYPE_xI)) 
{
+if (q->section_state == 0) {
+av_log(avctx, AV_LOG_VERBOSE, "Searching for MPEG-2 initial 
Sequence Sections\n");
+// LOAD Sequence sections
+p_sec = 0;
+p_buf = bs->Data;
+p_buf_end = bs->Data + bs->DataLength;
+while (p_buf < p_buf_end) {
+start_code= -1;
+p_buf = avpriv_find_start_code(p_buf, p_buf_end, _code);
+p_bytes_left = p_buf_end - p_buf;
+switch(start_code) {
+case SEQ_START_CODE:
+if (p_bytes_left >= 7) {
+memcpy(q->seq_header, p_buf - 4, 13);
+p_sec += 1;
+av_log(avctx, AV_LOG_VERBOSE, "Found MPEG-2 
SEQ_START_CODE Section\n");
+if ((p_buf[7] & 0x1) == 1) {
+memcpy(q->matrix, p_buf + 8, 64);
+p_sec += 4;
+av_log(avctx, AV_LOG_VERBOSE, "Found MPEG-2 
Matrix\n");
+}
+}
+continue;
+case EXT_START_CODE:
+if (p_bytes_left >= 5 && (p_buf[0] >> 4) == 0x01) {
+memcpy(q->seq_ext, p_buf - 4, 10);
+p_sec += 2;
+av_log(avctx, AV_LOG_VERBOSE, "Found MPEG-2 
EXT_START_CODE Section\n");
+}
+continue;
+case -1:
+break;
+default:
+if (start_code >= SLICE_MIN_START_CODE &&
+start_code <= SLICE_MAX_START_CODE)
+break;
+continue;
+}
+break;
+}
+switch (p_sec) {
+case 3:
+q->section_state = 1;  // SEQ_START_CODE & EXT_START_CODE
+break;
+case 7:
+q->section_state = 2;  // SEQ_START_CODE+Matrix & 
EXT_START_CODE
+break;
+default:
+q->section_state = 0;  // Insufficient data
+}
+} else {
+// ADD stored sections
+switch (q->section_state) {
+case 1:
+memmove(bs->Data + 23, bs->Data, bs->DataLength - 23);
+bs->DataLength  += 23;
+memcpy( bs->Data + 0 , q->seq_header, 13);
+memcpy( bs->Data + 13, q->seq_ext,10);
+break;
+case 2:
+memmove(bs->Data + 87, bs->Data, bs->DataLength - 87);
+bs->DataLength  += 87;
+

Re: [FFmpeg-devel] [PATCH] avutil: Add missing reference files for pixdesc fate test

[Michael Niedermayer]

On Tue, May 14, 2019 at 07:53:13AM +0200, Andreas Rheinhardt wrote:
> Commit cd48318035 added support for NV24 and NV42, including several
> fate tests for these formats, but did not include the reference files
> for the tests filter-pixdesc-nv24 and filter-pixdesc-nv42. As a result,
> these two tests were broken.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  tests/ref/fate/filter-pixdesc-nv24 | 1 +
>  tests/ref/fate/filter-pixdesc-nv42 | 1 +
>  2 files changed, 2 insertions(+)
>  create mode 100644 tests/ref/fate/filter-pixdesc-nv24
>  create mode 100644 tests/ref/fate/filter-pixdesc-nv42

will apply

thx

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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/2] avcodec/cinepak: Check available input against encoded buffer size

[Michael Niedermayer]

On Mon, May 13, 2019 at 02:32:11PM +0200, Tomas Härdin wrote:
> sön 2019-05-12 klockan 23:21 +0200 skrev Michael Niedermayer:
> > Fixes: Timeout (12sec -> 2sec)
> > Fixes: 
> > 14606/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5738687561728000
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/cinepak.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c
> > index a5132ddbc0..aeb15de0ed 100644
> > --- a/libavcodec/cinepak.c
> > +++ b/libavcodec/cinepak.c
> > @@ -323,6 +323,9 @@ static int cinepak_predecode_check (CinepakContext *s)
> >  num_strips  = AV_RB16 (>data[8]);
> >  encoded_buf_size = AV_RB24(>data[1]);
> >  
> > +if (s->size < encoded_buf_size * (int64_t)(100 - 
> > s->avctx->discard_damaged_percentage) / 100)
> > +return AVERROR_INVALIDDATA;
> 
> Looks OK

will apply

thx

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- 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/2] avformat/aviobuf: Forward error codes in avio_seek

[Michael Niedermayer]

On Tue, May 14, 2019 at 10:49:49AM +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/aviobuf.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

do you have some testcase for this ?

thanks

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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 1/2] avformat/aviobuf: Remove dead check

[Andreas Rheinhardt]

avio_seek only accepts SEEK_CUR and SEEK_SET (possibly OR'ed with
AVSEEK_FORCE) as whence parameter. Therefore the check
"whence != SEEK_END || force" is always true and can be removed.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/aviobuf.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 5a33f82950..5c01423a2e 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -290,8 +290,7 @@ int64_t avio_seek(AVIOContext *s, int64_t offset, int 
whence)
 } else if ((!(s->seekable & AVIO_SEEKABLE_NORMAL) ||
offset1 <= buffer_size + short_seek) &&
!s->write_flag && offset1 >= 0 &&
-   (!s->direct || !s->seek) &&
-  (whence != SEEK_END || force)) {
+   (!s->direct || !s->seek)) {
 while(s->pos < offset && !s->eof_reached)
 fill_buffer(s);
 if (s->eof_reached)
-- 
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 2/2] avformat/aviobuf: Forward error codes in avio_seek

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/aviobuf.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 5c01423a2e..2462b95b16 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -293,8 +293,11 @@ int64_t avio_seek(AVIOContext *s, int64_t offset, int 
whence)
(!s->direct || !s->seek)) {
 while(s->pos < offset && !s->eof_reached)
 fill_buffer(s);
-if (s->eof_reached)
+if (s->eof_reached) {
+if (s->error)
+return s->error;
 return AVERROR_EOF;
+}
 s->buf_ptr = s->buf_end - (s->pos - offset);
 } else if(!s->write_flag && offset1 < 0 && -offset1 < buffer_size>>1 && 
s->seek && offset > 0) {
 int64_t res;
-- 
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] avformat/mxfenc: support XAVC long gop

[Thomas Mundt]

Hi Baptiste,

Am Di., 14. Mai 2019 um 00:33 Uhr schrieb Baptiste Coudurier <
baptiste.coudur...@gmail.com>:

> ---
>  libavformat/Makefile |   2 +-
>  libavformat/avc.c| 186 +
>  libavformat/avc.h|  15 +++
>  libavformat/hevc.c   |  36 +---
>  libavformat/mxf.h|   1 +
>  libavformat/mxfenc.c | 213 ++-
>  6 files changed, 372 insertions(+), 81 deletions(-)
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 99be60d184..df87c54a58 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER)  += musx.o
>  OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
>  OBJS-$(CONFIG_MVI_DEMUXER)   += mvi.o
>  OBJS-$(CONFIG_MXF_DEMUXER)   += mxfdec.o mxf.o
> -OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o
> audiointerleave.o
> +OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o
> audiointerleave.o avc.o
>  OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
>  OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
>  OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
> diff --git a/libavformat/avc.c b/libavformat/avc.c
> index ec50033a04..a041e84357 100644
> --- a/libavformat/avc.c
> +++ b/libavformat/avc.c
> @@ -21,6 +21,7 @@
>
>  #include "libavutil/intreadwrite.h"
>  #include "libavcodec/h264.h"
> +#include "libavcodec/get_bits.h"
>  #include "avformat.h"
>  #include "avio.h"
>  #include "avc.h"
> @@ -241,3 +242,188 @@ const uint8_t *ff_avc_mp4_find_startcode(const
> uint8_t *start,
>
>  return start + res;
>  }
> +
> +uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
> +  uint32_t *dst_len, int header_len)
> +{
> +uint8_t *dst;
> +uint32_t i, len;
> +
> +dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
> +if (!dst)
> +return NULL;
> +
> +/* NAL unit header */
> +i = len = 0;
> +while (i < header_len && i < src_len)
> +dst[len++] = src[i++];
> +
> +while (i + 2 < src_len)
> +if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
> +dst[len++] = src[i++];
> +dst[len++] = src[i++];
> +i++; // remove emulation_prevention_three_byte
> +} else
> +dst[len++] = src[i++];
> +
> +while (i < src_len)
> +dst[len++] = src[i++];
> +
> +memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
> +
> +*dst_len = len;
> +return dst;
> +}
> +
> +static const AVRational avc_sample_aspect_ratio[17] = {
> +{   0,  1 },
> +{   1,  1 },
> +{  12, 11 },
> +{  10, 11 },
> +{  16, 11 },
> +{  40, 33 },
> +{  24, 11 },
> +{  20, 11 },
> +{  32, 11 },
> +{  80, 33 },
> +{  18, 11 },
> +{  15, 11 },
> +{  64, 33 },
> +{ 160, 99 },
> +{   4,  3 },
> +{   3,  2 },
> +{   2,  1 },
> +};
> +
> +static inline int get_ue_golomb(GetBitContext *gb) {
> +int i;
> +for (i = 0; i < 32 && !get_bits1(gb); i++)
> +;
> +return get_bitsz(gb, i) + (1 << i) - 1;
> +}
> +
> +static inline int get_se_golomb(GetBitContext *gb) {
> +int v = get_ue_golomb(gb) + 1;
> +int sign = -(v & 1);
> +return ((v >> 1) ^ sign) - sign;
> +}
> +
> +H264SequenceParameterSet *ff_avc_decode_sps(const uint8_t *buf, int
> buf_size)
> +{
> +int i, j, ret, rbsp_size, aspect_ratio_idc, pic_order_cnt_type;
> +int num_ref_frames_in_pic_order_cnt_cycle;
> +int delta_scale, lastScale = 8, nextScale = 8;
> +int sizeOfScalingList;
> +H264SequenceParameterSet *sps = NULL;
> +GetBitContext gb;
> +uint8_t *rbsp_buf;
> +
> +rbsp_buf = ff_nal_unit_extract_rbsp(buf, buf_size, _size, 0);
> +if (!rbsp_buf)
> +return NULL;
> +
> +ret = init_get_bits8(, rbsp_buf, rbsp_size);
> +if (ret < 0)
> +goto end;
> +
> +sps = av_mallocz(sizeof(*sps));
> +if (!sps)
> +goto end;
> +
> +sps->profile_idc = get_bits(, 8);
> +sps->constraint_set_flags |= get_bits1() << 0; //
> constraint_set0_flag
> +sps->constraint_set_flags |= get_bits1() << 1; //
> constraint_set1_flag
> +sps->constraint_set_flags |= get_bits1() << 2; //
> constraint_set2_flag
> +sps->constraint_set_flags |= get_bits1() << 3; //
> constraint_set3_flag
> +sps->constraint_set_flags |= get_bits1() << 4; //
> constraint_set4_flag
> +sps->constraint_set_flags |= get_bits1() << 5; //
> constraint_set5_flag
> +skip_bits(, 2); // reserved_zero_2bits
> +sps->level_idc = get_bits(, 8);
> +sps->id = get_ue_golomb();
> +
> +if (sps->profile_idc == 100 || sps->profile_idc == 110 ||
> +sps->profile_idc == 122 || sps->profile_idc == 244 ||
> sps->profile_idc ==  44 ||
> +sps->profile_idc ==  83 || sps->profile_idc ==  86 ||
> sps->profile_idc == 118 ||
> +sps->profile_idc == 128 || sps->profile_idc == 138 ||
> 

Re: [FFmpeg-devel] [PATCH] avfilter/drawtext: make command processing error-resilient

[Timo Rothenpieler]

On 10/05/2019 15:55, Gyan wrote:
At present, if the command args passed to drawtext contain any invalid 
values, ffmpeg may crash or, at best, stop drawing any text.
Attached patch gets the filter to continue with existing parameters, if 
not all of the changes can be parsed or applied. This allows users in 
live processing to correct and resubmit.


Gyan


This patch has at least two mis-uses of av_freep(), which potentially 
lead to a crash.



+av_freep(old);
+
+ctx->priv = new;


Should probably be av_freep();


+fail:
+av_log(ctx, AV_LOG_ERROR, "Failed to process command. Continuing with existing 
parameters.\n");
+av_freep(new);
+return ret;


Should probably be av_freep();

I did not do a full review of the patch, just pointing out those issues 
Coverity found. See coverity CID 1445099.



Timo



smime.p7s
Description: S/MIME Cryptographic 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] [DECISION] Project policy on closed source components

[Reimar Döffinger]

Hello everyone!
(no meaning attached to which mail I respond to)
While it reads less bad today than it did yesterday night, please try to keep 
the things written in the code of conduct in mind, assume best intentions etc., 
this thread didn't quite live up to it IMO.
It's possible to state even strong disagreement in more respectful ways.
If you permit, I'd also suggest that people in favour of removal take the win 
and don't push it - having a majority should be no excuse for making it a 
"tyranny of the majority".
If one wants an actual working community, minorities (of any form) sometimes 
need to be respected and get concessions beyond what they can get by votes 
(ignoring the technical question here).
And for anyone in favour of votes I hope it shows why votes are a bad idea: 
they don't resolve the conflict and there's at least one loser. Don't call them 
if you have other options. Compromise and consesus is always better.
Though I admit a way to ask the mood more like a poll sounds interesting to me, 
maybe even anonymous?

Best regards,
Reimar Döffinger
___
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".