Re: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC modes

[Mark Thompson]

On 28/01/2019 04:23, Eoff, Ullysses A wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
>> Mark Thompson
>> Sent: Sunday, January 27, 2019 3:47 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC modes
>>
>> Allow setting the mode explicitly, and try to make a sensible choice
>> given the available parameters if not.
>> ---
>>  doc/encoders.texi |  24 +++
>>  libavcodec/vaapi_encode.c | 370 +++---
>>  libavcodec/vaapi_encode.h |  65 +++
>>  3 files changed, 351 insertions(+), 108 deletions(-)
>>
>> ...
>>  if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
>>  av_log(avctx, AV_LOG_VERBOSE, "Driver does not report any "
>> -   "supported rate control modes: assuming 
>> constant-quality.\n");
>> -ctx->va_rc_mode = VA_RC_CQP;
>> -return 0;
>> ...
> 
> With this patch series, mjpeg_vaapi encoder breaks with iHD driver:
> 
> LIBVA_DRIVER_NAME=iHD ffmpeg -hwaccel vaapi \
>   -vaapi_device /dev/dri/renderD128 -v debug \
>   -f rawvideo -pix_fmt yuv420p -s:v 1920x1080 \
>   -i input.yuv -vf 'format=nv12,hwupload' -c:v mjpeg_vaapi \
>   -global_quality 100 -vframes 10 -y output.mjpg
> 
> 
> [AVHWDeviceContext @ 0x193c580] Opened VA display via DRM device 
> /dev/dri/renderD128.
> [AVHWDeviceContext @ 0x193c580] libva: VA-API version 1.4.0
> [AVHWDeviceContext @ 0x193c580] libva: va_getDriverName() returns 0
> [AVHWDeviceContext @ 0x193c580] libva: User requested driver 'iHD'
> [AVHWDeviceContext @ 0x193c580] libva: Trying to open 
> /home/uaeoff/Work/workspace/media/install/lib/dri/iHD_drv_video.so
> [AVHWDeviceContext @ 0x193c580] libva: Found init function __vaDriverInit_1_4
> [AVHWDeviceContext @ 0x193c580] libva: va_openDriver() returns 0
> [AVHWDeviceContext @ 0x193c580] Initialised VAAPI connection: version 1.4
> 
> [mjpeg_vaapi @ 0x19847c0] Input surface format is nv12.
> [mjpeg_vaapi @ 0x19847c0] Using VAAPI profile VAProfileJPEGBaseline (12).
> [mjpeg_vaapi @ 0x19847c0] Using VAAPI entrypoint VAEntrypointEncPicture (7).
> [mjpeg_vaapi @ 0x19847c0] Using VAAPI render target format YUV420 (0x1).
> [mjpeg_vaapi @ 0x19847c0] Driver does not report any supported rate control 
> modes: assuming CQP only.
> [mjpeg_vaapi @ 0x19847c0] RC mode: CQP.
> [mjpeg_vaapi @ 0x19847c0] RC quality: 100.
> [mjpeg_vaapi @ 0x19847c0] RC framerate (CFR mode): 25/1 (25.00 fps).
> [mjpeg_vaapi @ 0x19847c0] Using intra frames only.
> [mjpeg_vaapi @ 0x19847c0] All wanted packed headers available (wanted 0x10, 
> found 0x10).
> [mjpeg_vaapi @ 0x19847c0] Failed to create encode pipeline configuration: 10 
> (attribute not supported).
> Error initializing output stream 0:0 -- Error while opening encoder for 
> output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width 
> or height
> [AVIOContext @ 0x1987000] Statistics: 0 seeks, 0 writeouts
> [AVIOContext @ 0x19802c0] Statistics: 3110400 bytes read, 0 seeks
> Conversion failed!
> 
> ... it works fine on i965 driver.

Right, the specific workaround to not set any options on drivers which report 
no supported RC modes (highlighted above) needs to be carried forward to this.  
Added.

Thank you for testing!

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

Re: [FFmpeg-devel] [PATCH v2 09/11] vaapi_encode: Add support for VFR mode

[Mark Thompson]

On 28/01/2019 20:45, Michael Niedermayer wrote:
> On Sun, Jan 27, 2019 at 11:47:05PM +, Mark Thompson wrote:
>> Use the frame-skip feature to maintain a specified framerate from the
>> point of view of the driver.
>> ---
>>  doc/encoders.texi |   7 +++
>>  libavcodec/vaapi_encode.c | 116 +++---
>>  libavcodec/vaapi_encode.h |  18 +-
>>  3 files changed, 132 insertions(+), 9 deletions(-)
> 
> seems to break build
> 
> 
> CClibavcodec/vaapi_encode.o
> libavcodec/vaapi_encode.c: In function ‘vaapi_encode_init_framerate’:
> libavcodec/vaapi_encode.c:1718:12: error: ‘VAAPIEncodeContext’ has no member 
> named ‘max_fps’
>  if (ctx->max_fps.num > 0 && ctx->max_fps.den > 0) {
> ^
> libavcodec/vaapi_encode.c:1718:36: error: ‘VAAPIEncodeContext’ has no member 
> named ‘max_fps’
>  if (ctx->max_fps.num > 0 && ctx->max_fps.den > 0) {
> ^
> make: *** [libavcodec/vaapi_encode.o] Error 1
> make: Target `all' not remade because of errors.

Urgh, not retested on older versions after late refactoring which changed the 
name of a variable.

Fixed.

Thanks,

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

Re: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC modes

[Mark Thompson]

On 28/01/2019 02:19, Fu, Linjie wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Mark Thompson
>> Sent: Monday, January 28, 2019 07:47
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC
>> modes
>>
>> Allow setting the mode explicitly, and try to make a sensible choice
>> given the available parameters if not.
>> ---
>>  doc/encoders.texi |  24 +++
>>  libavcodec/vaapi_encode.c | 370 +++-
>> --
>>  libavcodec/vaapi_encode.h |  65 +++
>>  3 files changed, 351 insertions(+), 108 deletions(-)
>>
>> ...
>> +
>>  static av_cold int vaapi_encode_init_rate_control(AVCodecContext *avctx)
>>  {
>>  VAAPIEncodeContext *ctx = avctx->priv_data;
>> +uint32_t supported_va_rc_modes;
>> +const VAAPIEncodeRCMode *rc_mode;
>>  int64_t rc_bits_per_second;
>>  int rc_target_percentage;
>>  int rc_window_size;
>> +int rc_quality;
>>  int64_t hrd_buffer_size;
>>  int64_t hrd_initial_buffer_fullness;
>>  int fr_num, fr_den;
>>  VAConfigAttrib rc_attr = { VAConfigAttribRateControl };
>>  VAStatus vas;
>> +char supported_rc_modes_string[64];
>>
>>  vas = vaGetConfigAttributes(ctx->hwctx->display,
>>  ctx->va_profile, ctx->va_entrypoint,
>> @@ -1303,119 +1328,215 @@ static av_cold int
>> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>> "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
>>  return AVERROR_EXTERNAL;
>>  }
>> -
>>  if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
>>  av_log(avctx, AV_LOG_VERBOSE, "Driver does not report any "
>> -   "supported rate control modes: assuming 
>> constant-quality.\n");
>> -ctx->va_rc_mode = VA_RC_CQP;
>> -return 0;
>> -}
>> -if (ctx->codec->flags & FLAG_CONSTANT_QUALITY_ONLY ||
>> -avctx->flags & AV_CODEC_FLAG_QSCALE ||
>> -avctx->bit_rate <= 0) {
>> -if (rc_attr.value & VA_RC_CQP) {
>> -av_log(avctx, AV_LOG_VERBOSE, "Using constant-quality mode.\n");
>> -ctx->va_rc_mode = VA_RC_CQP;
>> -if (avctx->bit_rate > 0 || avctx->rc_max_rate > 0) {
>> -av_log(avctx, AV_LOG_WARNING, "Bitrate target parameters "
>> -   "ignored in constant-quality mode.\n");
>> +   "supported rate control modes: assuming CQP only.\n");
>> +supported_va_rc_modes = VA_RC_CQP;
>> +strcpy(supported_rc_modes_string, "unknown");
>> +} else {
>> +char *str = supported_rc_modes_string;
>> +size_t len = sizeof(supported_rc_modes_string);
>> +int i, first = 1, res;
>> +
>> +supported_va_rc_modes = rc_attr.value;
>> +
>> +first = 1;
> 
> Redundant “first” here I think.

Yep, removed.

>> +for (i = 0; i < FF_ARRAY_ELEMS(vaapi_encode_rc_modes); i++) {
>> +rc_mode = &vaapi_encode_rc_modes[i];
>> +if (supported_va_rc_modes & rc_mode->va_mode) {
>> +res = snprintf(str, len, "%s%s",
>> +   first ? "" : ", ", rc_mode->name);
>> +first = 0;
>> +if (res < 0) {
>> +*str = 0;
>> +break;
>> +}
>> +len -= res;
>> +str += res;
>> +if (len == 0)
>> +break;
>>  }
>> -return 0;
>> -} else {
>> -av_log(avctx, AV_LOG_ERROR, "Driver does not support "
>> -   "constant-quality mode (%#x).\n", rc_attr.value);
>> -return AVERROR(EINVAL);
>>  }
>> -}
>>
>> -if (!(rc_attr.value & (VA_RC_CBR | VA_RC_VBR))) {
>> -av_log(avctx, AV_LOG_ERROR, "Driver does not support any "
>> -   "bitrate-targetted rate control modes.\n");
>> -return AVERROR(EINVAL);
>> +av_log(avctx, AV_LOG_DEBUG, "Driver supports RC modes %s.\n",
>> +   supported_rc_modes_string);
>> +}
>> +
>> +// Rate control mode selection:
>> +// * If the user has set a mode explicitly with the rc_mode option,
>> +//   use it and fail if it is not available.
>> +// * If an explicit QP option has been set, use CQP.
>> +// * If the codec is CQ-only, use CQP.
>> +// * If the QSCALE avcodec option is set, use CQP.
>> +// * If bitrate and quality are both set, try QVBR.
>> +// * If quality is set, try ICQ, then CQP.
>> +// * If bitrate and maxrate are set and have the same value, try CBR.
>> +// * If a bitrate is set, try AVBR, then VBR, then CBR.
>> +// * If no bitrate is set, try ICQ, then CQP.
>> +
>> +#define TRY_RC_MODE(mode, fail) do { \
>> +rc_mode = &vaapi_encode_rc_modes[mode]; \
>> +if (!(rc_mode->va_mode & supported_va_rc_modes)) { \
>> +if (fail) 

Re: [FFmpeg-devel] [PATCH] avcodec/libx264: update notes to explain the scale chosen for ROI encoding

[Mark Thompson]

On 29/01/2019 10:14, Guo, Yejun wrote:
> Signed-off-by: Guo, Yejun 
> ---
>  libavcodec/libx264.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index a3493f3..8c96728 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -383,7 +383,9 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, 
> const AVFrame *frame,
>  qoffset = roi->qoffset.num * 1.0f / roi->qoffset.den;
>  qoffset = av_clipf(qoffset, -1.0f, 1.0f);
>  
> -// 25 is a number that I think it is a possible 
> proper scale value.
> +/* qp range of x264 is from 0 to 51, just choose 25 
> as the scale value,
> + * so the range of final qoffset is [-25.0, 25.0].
> + */
>  qoffset = qoffset * 25;
>  
>  for (int y = starty; y < endy; y++) {
> 

I'm not understanding where this number has come from at all.  Is 25 purely 
arbitrary?  Why does the effect vary by bit depth?

From the docs explaining the best/worst behaviour on the range, I would expect 
this to map 0 to 0 and 1 to 3 + 6 * bit_depth (positive or negative).

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

Re: [FFmpeg-devel] [PATCH] amfenc: Add support for pict_type field

[Mark Thompson]

On 15/01/2019 22:05, michael.di...@xaymar.com wrote:
> From: Michael Fabian 'Xaymar' Dirks 
> 
> Adds support for the pict_type field in AVFrame to amf_h264 and amf_h265 
> simultaneously. This field is needed in cases where the application wishes to 
> override the frame type with another one, such as forcefully inserting a key 
> frame for chapter markers or similar.
> 
> Additionally this abuses AV_PICTURE_TYPE_S for marking Skip frames, a special 
> type of frame in AVC, SVC and HEVC which is a flag for the decoder to repeat 
> the last frame.

Overloading the meaning of a flag like this is probably confusing.

Can you explain what this "skip frame" actually does in the encoder?  The 
concept does not exist in H.264 or H.265, as far as I know.

>  Changelog   |  1 +
>  libavcodec/amfenc.c | 46 +
>  2 files changed, 47 insertions(+)
> 
> diff --git a/Changelog b/Changelog
> index 1cd53916cb..4fc48ba210 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -15,6 +15,7 @@ version :
>  - hymt decoder
>  - anlmdn filter
>  - maskfun filter
> +- AMF now supports AVFrame->pict_type override
>  
>  
>  version 4.1:
> diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
> index 384d8efc92..3be9ff9ee2 100644
> --- a/libavcodec/amfenc.c
> +++ b/libavcodec/amfenc.c
> @@ -680,6 +680,52 @@ int ff_amf_send_frame(AVCodecContext *avctx, const 
> AVFrame *frame)
>  break;
>  }
>  
> +// Override Picture Type for Frame
> +if (avctx->codec->id == AV_CODEC_ID_H264) {
> +switch (frame->pict_type) {
> +case AV_PICTURE_TYPE_I:
> +AMF_ASSIGN_PROPERTY_INT64(res, surface, 
> AMF_VIDEO_ENCODER_FORCE_PICTURE_TYPE, AMF_VIDEO_ENCODER_PICTURE_TYPE_I);

Consider whether you need to set IDR here rather than I, and maybe add a 
comment explaining the choice?  The normal use of this is to indicate that an 
IRAP should be generated, not just a single intra picture.  (Compare libx264, 
which has an additional flag controlling whether the forced picture is IDR or 
I, but I believe it is still always an IRAP there.)

> +break;
> +case AV_PICTURE_TYPE_P:
> +AMF_ASSIGN_PROPERTY_INT64(res, surface, 
> AMF_VIDEO_ENCODER_FORCE_PICTURE_TYPE, AMF_VIDEO_ENCODER_PICTURE_TYPE_P);
> +break;
> +case AV_PICTURE_TYPE_B:
> +AMF_ASSIGN_PROPERTY_INT64(res, surface, 
> AMF_VIDEO_ENCODER_FORCE_PICTURE_TYPE, AMF_VIDEO_ENCODER_PICTURE_TYPE_B);
> +break;
> +case AV_PICTURE_TYPE_S:
> +AMF_ASSIGN_PROPERTY_INT64(res, surface, 
> AMF_VIDEO_ENCODER_FORCE_PICTURE_TYPE, AMF_VIDEO_ENCODER_PICTURE_TYPE_SKIP);
> +break;
> +default:
> +AMF_ASSIGN_PROPERTY_INT64(res, surface, 
> AMF_VIDEO_ENCODER_FORCE_PICTURE_TYPE, AMF_VIDEO_ENCODER_PICTURE_TYPE_NONE);
> +break;
> +}
> +// Keyframe overrides previous assignment.
> +if (frame->key_frame) {

This flag shouldn't be read by encoders.  (I believe it is set by the decoder 
and never cleared, so with this test you will have surprising behaviour where 
the output stream gets key frames everywhere that the input stream had them, in 
addition to those dictated by its own GOP structure.)

> +AMF_ASSIGN_PROPERTY_INT64(res, surface, 
> AMF_VIDEO_ENCODER_FORCE_PICTURE_TYPE, AMF_VIDEO_ENCODER_PICTURE_TYPE_IDR);
> +}
> +} else if (avctx->codec->id == AV_CODEC_ID_HEVC) {
> +switch (frame->pict_type) {
> +case AV_PICTURE_TYPE_I:
> +AMF_ASSIGN_PROPERTY_INT64(res, surface, 
> AMF_VIDEO_ENCODER_HEVC_FORCE_PICTURE_TYPE, 
> AMF_VIDEO_ENCODER_HEVC_PICTURE_TYPE_I);
> +break;
> +case AV_PICTURE_TYPE_P:
> +AMF_ASSIGN_PROPERTY_INT64(res, surface, 
> AMF_VIDEO_ENCODER_HEVC_FORCE_PICTURE_TYPE, 
> AMF_VIDEO_ENCODER_HEVC_PICTURE_TYPE_P);
> +break;
> +case AV_PICTURE_TYPE_B:
> +av_log(ctx, AV_LOG_WARNING, "Ignoring B-Frame, unsupported 
> by AMD AMF H.265 Encoder.");
> +break;
> +case AV_PICTURE_TYPE_S:
> +AMF_ASSIGN_PROPERTY_INT64(res, surface, 
> AMF_VIDEO_ENCODER_HEVC_FORCE_PICTURE_TYPE, 
> AMF_VIDEO_ENCODER_HEVC_PICTURE_TYPE_SKIP);
> +break;
> +default:
> +AMF_ASSIGN_PROPERTY_INT64(res, surface, 
> AMF_VIDEO_ENCODER_HEVC_FORCE_PICTURE_TYPE, 
> AMF_VIDEO_ENCODER_HEVC_PICTURE_TYPE_NONE);
> +break;
> +}
> +// Keyframe overrides previous assignment.
> +if (frame->key_frame) {
> +AMF_ASSIGN_PROPERTY_INT64(res, surface, 
> AMF_VIDEO_ENCODER_HEVC_FORCE_PICTURE_TYPE, 
> AMF_VIDEO_ENCODER_HEVC_PICTURE_TYPE_IDR);
> +}
> +}
>  
>  // submit surface
>  res = ctx->encode

[FFmpeg-devel] [PATCH] doc/examples: port muxing example to new send/receive API

[Lennart Blanco]

Hi

Noticed that the example code for muxing uses depricated API. This is my
attempt to
port the doc/examples/muxing.c to use the avcodec_send_frame() and
avcodec_receive_packet() API.

Regards,
Lennart
From 2dce8373cb7adfd3228759bfa5ff80ebcd9116db Mon Sep 17 00:00:00 2001
From: Lennart Blanco 
Date: Wed, 30 Jan 2019 12:26:54 +0100
Subject: [PATCH] doc/examples: port muxing example to new send/receive API

Replaces calls to the depricated avcodec_encode_audio2() and
avcodec_encode_video2() function with calls to
avcodec_send_frame()/avcodec_receive_packet() pair.

Fixes the depricated warning/error while compiling muxing example.
---
 doc/examples/muxing.c | 76 +++
 1 file changed, 52 insertions(+), 24 deletions(-)

diff --git a/doc/examples/muxing.c b/doc/examples/muxing.c
index 08da98e..3f3948d 100644
--- a/doc/examples/muxing.c
+++ b/doc/examples/muxing.c
@@ -303,7 +303,10 @@ static AVFrame *get_audio_frame(OutputStream *ost)
 }
 
 /*
- * encode one audio frame and send it to the muxer
+ * send one audio frame to the encoder,
+ * get one encoded packet, if available,
+ * and send it to the muxer
+ *
  * return 1 when encoding is finished, 0 otherwise
  */
 static int write_audio_frame(AVFormatContext *oc, OutputStream *ost)
@@ -349,22 +352,34 @@ static int write_audio_frame(AVFormatContext *oc, OutputStream *ost)
 ost->samples_count += dst_nb_samples;
 }
 
-ret = avcodec_encode_audio2(c, &pkt, frame, &got_packet);
-if (ret < 0) {
-fprintf(stderr, "Error encoding audio frame: %s\n", av_err2str(ret));
+ret = avcodec_send_frame(c, frame);
+if (ret < 0 && ret != AVERROR_EOF) {
+fprintf(stderr, "Error sending a frame for encoding %s\n", av_err2str(ret));
 exit(1);
 }
 
-if (got_packet) {
-ret = write_frame(oc, &c->time_base, ost->st, &pkt);
-if (ret < 0) {
-fprintf(stderr, "Error while writing audio frame: %s\n",
-av_err2str(ret));
-exit(1);
-}
+/* try to get encoded packet */
+ret = avcodec_receive_packet(c, &pkt);
+if (ret == AVERROR(EAGAIN))
+return 0;
+else if (ret == AVERROR_EOF)
+/* done encoding */
+return 1;
+else if (ret < 0) {
+fprintf(stderr, "Error during encoding\n");
+exit(1);
+}
+
+/* write packet package to the file */
+ret = write_frame(oc, &c->time_base, ost->st, &pkt);
+if (ret < 0) {
+fprintf(stderr, "Error while writing video frame: %s\n", av_err2str(ret));
+exit(1);
 }
 
-return (frame || got_packet) ? 0 : 1;
+av_packet_unref(&pkt);
+
+return 0;
 }
 
 /**/
@@ -501,7 +516,10 @@ static AVFrame *get_video_frame(OutputStream *ost)
 }
 
 /*
- * encode one video frame and send it to the muxer
+ * send one video frame to the encoder,
+ * get one encoded packet, if available,
+ * and send it to the muxer
+ *
  * return 1 when encoding is finished, 0 otherwise
  */
 static int write_video_frame(AVFormatContext *oc, OutputStream *ost)
@@ -514,29 +532,39 @@ static int write_video_frame(AVFormatContext *oc, OutputStream *ost)
 
 c = ost->enc;
 
+/* send new frame to the encoder */
 frame = get_video_frame(ost);
+ret = avcodec_send_frame(c, frame);
 
-av_init_packet(&pkt);
-
-/* encode the image */
-ret = avcodec_encode_video2(c, &pkt, frame, &got_packet);
-if (ret < 0) {
-fprintf(stderr, "Error encoding video frame: %s\n", av_err2str(ret));
+if (ret < 0 && ret != AVERROR_EOF) {
+fprintf(stderr, "Error sending a frame for encoding %s\n", av_err2str(ret));
 exit(1);
 }
 
-if (got_packet) {
-ret = write_frame(oc, &c->time_base, ost->st, &pkt);
-} else {
-ret = 0;
+av_init_packet(&pkt);
+
+/* try to get encoded packet */
+ret = avcodec_receive_packet(c, &pkt);
+if (ret == AVERROR(EAGAIN))
+return 0;
+else if (ret == AVERROR_EOF)
+/* done encoding */
+return 1;
+else if (ret < 0) {
+fprintf(stderr, "Error during encoding\n");
+exit(1);
 }
 
+/* write packet package to the file */
+ret = write_frame(oc, &c->time_base, ost->st, &pkt);
 if (ret < 0) {
 fprintf(stderr, "Error while writing video frame: %s\n", av_err2str(ret));
 exit(1);
 }
 
-return (frame || got_packet) ? 0 : 1;
+av_packet_unref(&pkt);
+
+return 0;
 }
 
 static void close_stream(AVFormatContext *oc, OutputStream *ost)
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH] amfenc: Add support for pict_type field

[Michael Dirks]

On 04.02.2019 11:05, Mark Thompson wrote:

Can you explain what this "skip frame" actually does in the encoder?  The 
concept does not exist in H.264 or H.265, as far as I know.


I believe this has to do with the pic_struct flag which has a value of 7 
for frame doubling and 8 for frame tripling, see page 345 (PDF page 367) 
Table D-1 Interpretation of pic_struct in Rec. ITU-T H.264 (04/2017). 
However I do not work for AMD (and their encoder is closed source and a 
piece of hardware), so I can't confirm that this is actually the 
behavior, nor do I have any tools that can read and show all H.264 
headers. An alternative would be that AMDs encoder is instead choosing 
to emit a frame that has maximum compression and references the previous 
frame for all data, thus causing a copy of it.



+case AV_PICTURE_TYPE_I:
+AMF_ASSIGN_PROPERTY_INT64(res, surface, 
AMF_VIDEO_ENCODER_FORCE_PICTURE_TYPE, AMF_VIDEO_ENCODER_PICTURE_TYPE_I);

Consider whether you need to set IDR here rather than I, and maybe add a 
comment explaining the choice?  The normal use of this is to indicate that an 
IRAP should be generated, not just a single intra picture.  (Compare libx264, 
which has an additional flag controlling whether the forced picture is IDR or 
I, but I believe it is still always an IRAP there.)

+// Keyframe overrides previous assignment.
+if (frame->key_frame) {

This flag shouldn't be read by encoders.  (I believe it is set by the decoder 
and never cleared, so with this test you will have surprising behaviour where 
the output stream gets key frames everywhere that the input stream had them, in 
addition to those dictated by its own GOP structure.)
I went by the documentation in the individual header files, which does 
not actually claim key_frame to be a decoder only field (libavutil/frame.h):


> /**
> * 1 -> keyframe, 0-> not
> */
>    int key_frame;

Therefore this patch uses the field exactly as it is documented in the 
frame.h file, and also treats AV_PICTURE_TYPE_I as a request for an 
Intra Picture instead of an IDR Picture.


Sincerely
Michael Fabian Dirks

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

Re: [FFmpeg-devel] Access to the dolby vision decoder info

[Gresserman Dmitrij]

Hello Hendrik,

I fully agree with your approach and already thought about this. Parsing this 
directly to a structure would the correct approach for a final future patch. 
Unfortunately at this point in development, i need the most flexibility 
possible, with simultaneously minimal reaction time.

Best Regards
[Ein einzigartiges Sounderlebnis mit Loewe und Mimi 
Defined™]

Visit our website: https://www.loewe.tv/int

[Facebook]  [Instagram] 
   [Pinterest] 
   [YouTube] 


Loewe Technologies GmbH, Industriestraße 11, 96317 Kronach
Tel. +49 9261 99-500 • Fax +49 9261 99-515
c...@loewe.de • www.loewe.tv

Executive Management: Dr. Ralf Vogt, Peter Nortmann • Registered Office: 
Kronach • Commercial Register: Amtsgericht Coburg HRB 5443
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Access to the dolby vision decoder info

[Hendrik Leppkes]

On Mon, Feb 4, 2019 at 5:04 PM Gresserman Dmitrij
 wrote:
>
> I fully agree with your approach and already thought about this. Parsing this 
> directly to a structure would the correct approach for a final future patch. 
> Unfortunately at this point in development, i need the most flexibility 
> possible, with simultaneously minimal reaction time.
>

Since adding new types like this is basically public API, with certain
stability guarantees once added, we prefer proper solutions, instead
of quick hacks, otherwise we'll be dragging it around for years to
come.

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

Re: [FFmpeg-devel] Access to the dolby vision decoder info

[Gresserman Dmitrij]

Once again you are right.
I just wanted to show my approach to this community, to let you know, maybe it 
could help someone else.
I don't insist on adding this approach to your repositories.

Best Regards
[Ein einzigartiges Sounderlebnis mit Loewe und Mimi 
Defined™]

Visit our website: https://www.loewe.tv/int

[Facebook]  [Instagram] 
   [Pinterest] 
   [YouTube] 


Loewe Technologies GmbH, Industriestraße 11, 96317 Kronach
Tel. +49 9261 99-500 • Fax +49 9261 99-515
c...@loewe.de • www.loewe.tv

Executive Management: Dr. Ralf Vogt, Peter Nortmann • Registered Office: 
Kronach • Commercial Register: Amtsgericht Coburg HRB 5443
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself to the PPC section

[Michael Niedermayer]

On Sun, Jan 27, 2019 at 08:51:19PM +0200, Lauri Kasanen wrote:
> Signed-off-by: Lauri Kasanen 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)

will apply

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
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov: fix hang while seek on a kind of fragmented mp4.

[Michael Niedermayer]

On Sat, Feb 02, 2019 at 05:03:25PM +0100, Marton Balint wrote:
> 
> 
> On Sat, 2 Feb 2019, Charles Liu wrote:
> 
> >Binary searching would hang if the fragment items do NOT have timestamp for 
> >the specified stream.
> >
> >For example, a fmp4 consists of separated 'moof' boxes for each track, and 
> >separated 'sidx' for each segment, but no 'mfra' box.
> >Then every fragment item only have the timestamp for one of its tracks.
> 
> I don't see why you are changing the search to be linear. Is it possible the
> some of the stream fragmens have NOPTS_VALUE but other don't? In this case
> you should keep the binary search and only fall back to linear search if
> binary search finds an AV_NOPTS_VALUE. See similar code in function
> mxf_absolute_bodysid_offset of libavformat/mxfdec.c.

The point of binary searching is to achieve O(log n) time
if there is any linear search this is no longer achieved.
So its not ideal to have any AV_NOPTS_VALUE in the array that is
searched. It would be better if the unknown entries are not in the
array that is used for the search or if their value is monotonized
once for all searches
that being ideal at least ...

Thanks

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/mpeg4_unpack_bframes_bsf: Improve DivX userdata check

[Michael Niedermayer]

On Sat, Feb 02, 2019 at 08:34:12PM +0100, Andreas Rheinhardt wrote:
> The earlier version didn't really check that the 'p' of a "p\0" is
> actually part of a DivX user_data section, instead it treated the first
> "p\0" after the start of a user_data section as end of a DivX user_data
> section if it is close enough to the beginning of the user_data section;
> it actually needn't be part of a user_data section at all.
> 
> Furthermore, the code worked under the assumption that there is a 0x00
> after the 'p' although this might not be true for extradata if the DivX
> user_data unit is at the end of the extradata.
> 
> Both of these flaws have been fixed.

The absence of a check for DivX was intentional so other codecs could
also generate packed bitstreams and be supported.

extradata generally has 0 value padding bytes at the end. But yes it
would be better to avoid depending on that.

Thanks


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

Observe your enemies, for they first find out your faults. -- Antisthenes


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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/mpeg4videodec: Fix nonsense warning

[Michael Niedermayer]

On Sat, Feb 02, 2019 at 08:34:10PM +0100, Andreas Rheinhardt wrote:
> Since db772308941a2a338c7809f90d347219a6a93074 parsing of
> mpeg4-extradata lead to a "Failed to parse extradata" warning, because
> ff_mpeg4_decode_picture_header returns AVERROR_INVALIDDATA in case that
> no VOP was found. This patch changes the return value back to -1 in case
> no error occured and no VOP was found.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/mpeg4videodec.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
> index f44ee76bd4..9d820c2d71 100644
> --- a/libavcodec/mpeg4videodec.c
> +++ b/libavcodec/mpeg4videodec.c
> @@ -3202,7 +3202,8 @@ static int decode_studio_vol_header(Mpeg4DecContext 
> *ctx, GetBitContext *gb)
>  
>  /**
>   * Decode MPEG-4 headers.
> - * @return <0 if no VOP found (or a damaged one)
> + * @return -1 if no error occured, but no VOP was found
> + * <0 if no VOP found (or a damaged one)
>   * FRAME_SKIPPED if a not coded VOP is found
>   * 0 if a VOP is found
>   */
> @@ -3235,6 +3236,8 @@ int ff_mpeg4_decode_picture_header(Mpeg4DecContext 
> *ctx, GetBitContext *gb)
>  (ctx->divx_version >= 0 || ctx->xvid_build >= 0) || 
> s->codec_tag == AV_RL32("QMP4")) {
>  av_log(s->avctx, AV_LOG_VERBOSE, "frame skip %d\n", 
> gb->size_in_bits);
>  return FRAME_SKIPPED;  // divx bug
> +} else if (get_bits_count(gb) == gb->size_in_bits) {
> +return -1; // ordinary return value for parsing of extradata

There is no gurantee that this condition is only true within extradata
also -1 is not an ideal code because it can overlap with some
AVERROR(E*)

Its probably cleaner to just pass a flag as argument that indicates if
the code is parsing a frame or a global header.

Thanks
[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.


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

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/mpeg4_unpack_bframes_bsf: Use avpriv_find_start_code

[Michael Niedermayer]

On Sat, Feb 02, 2019 at 08:34:11PM +0100, Andreas Rheinhardt wrote:
> instead of an ad-hoc function to search for start codes in order to
> remove code duplication and to improve performance.
> 
> Improved performance of finding startcodes from 52606 decicycles to
> 9543 decicycles based upon 262144 runs for a 1 Mb/s MPEG4 video.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/mpeg4_unpack_bframes_bsf.c | 34 ---
>  1 file changed, 10 insertions(+), 24 deletions(-)

will apply

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


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

[FFmpeg-devel] [PATCH 0/1] Seeking disabled unconditionally in DASH demuxer

[Paweł Wegner]

Hello,

any reason why this commit:
https://github.com/FFmpeg/FFmpeg/commit/d54ae9b782c85e626a1e49a8ee204728746227d1#diff-ce2d1d31314e57cff2d1f3eb78988c88R1903
 
disables seeking in dash demuxer? Seeking works fine for my dash manifests 
when I remove the highlighted line.

--
Paweł Wegner

Paweł Wegner (1):
  libavformat/dashdec: disable seeking only for live streams.

 libavformat/dashdec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.17.1

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

[FFmpeg-devel] [PATCH 1/1] libavformat/dashdec: disable seeking only for live streams.

[Paweł Wegner]

Signed-off-by: Paweł Wegner 
---
 libavformat/dashdec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index f4f4e935de..89acd5807d 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -2000,8 +2000,6 @@ static int dash_read_header(AVFormatContext *s)
 if ((ret = save_avio_options(s)) < 0)
 goto fail;
 
-av_dict_set(&c->avio_opts, "seekable", "0", 0);
-
 if ((ret = parse_manifest(s, s->url, s->pb)) < 0)
 goto fail;
 
@@ -2009,6 +2007,8 @@ static int dash_read_header(AVFormatContext *s)
  * stream. */
 if (!c->is_live) {
 s->duration = (int64_t) c->media_presentation_duration * AV_TIME_BASE;
+} else {
+av_dict_set(&c->avio_opts, "seekable", "0", 0);
 }
 
 if(c->n_videos)
-- 
2.17.1

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

Re: [FFmpeg-devel] [PATCH] lavf/mov: fix hang while seek on a kind of fragmented mp4.

[Marton Balint]

On Mon, 4 Feb 2019, Michael Niedermayer wrote:


On Sat, Feb 02, 2019 at 05:03:25PM +0100, Marton Balint wrote:



On Sat, 2 Feb 2019, Charles Liu wrote:


Binary searching would hang if the fragment items do NOT have timestamp for the 
specified stream.

For example, a fmp4 consists of separated 'moof' boxes for each track, and 
separated 'sidx' for each segment, but no 'mfra' box.
Then every fragment item only have the timestamp for one of its tracks.


I don't see why you are changing the search to be linear. Is it possible the
some of the stream fragmens have NOPTS_VALUE but other don't? In this case
you should keep the binary search and only fall back to linear search if
binary search finds an AV_NOPTS_VALUE. See similar code in function
mxf_absolute_bodysid_offset of libavformat/mxfdec.c.


The point of binary searching is to achieve O(log n) time
if there is any linear search this is no longer achieved.
So its not ideal to have any AV_NOPTS_VALUE in the array that is
searched. It would be better if the unknown entries are not in the
array that is used for the search or if their value is monotonized
once for all searches
that being ideal at least ...


Yeah that is true, but that would require maintaining a different array 
with pts-es, and getting/updating fragment pts-es are complicated as is.


Considering that this fixes a hang, I'd rather see the last version of the 
patch applied than wait for a more complicated, yet faster implementation.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mpegts: cache PID discard values

[Marton Balint]

On Sat, 2 Feb 2019, Michael Niedermayer wrote:


On Fri, Feb 01, 2019 at 10:29:13PM +0100, Marton Balint wrote:



On Fri, 25 Jan 2019, Marton Balint wrote:




On Fri, 25 Jan 2019, Michael Niedermayer wrote:


On Thu, Jan 24, 2019 at 09:38:00PM +0100, Marton Balint wrote:

discard_pid can be quite expensive, so let's cache it and recalculate
it

on

every packet start.

ffmpeg -y -i samples/MPEG-VOB/sdtv/RAI.ts -c copy -map 0:v:0 -map
0:a:0 -f

mpegts /dev/null


Before:
  1685 decicycles in handle_packet,  523483 runs,805 skips

After:
   883 decicycles in handle_packet,  523505 runs,783 skips

Signed-off-by: Marton Balint 
---
libavformat/mpegts.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 300db110d4..b04fd7b4f4 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -91,6 +91,7 @@ struct MpegTSFilter {
int es_id;
int last_cc; /* last cc code (-1 if first packet) */
int64_t last_pcr;
+int discard;
enum MpegTSFilterType type;
union {
MpegTSPESFilter pes_filter;
@@ -2474,8 +2475,6 @@ static int handle_packet(MpegTSContext *ts,
const

uint8_t *packet)

int64_t pos;

pid = AV_RB16(packet + 1) & 0x1fff;
-if (pid && discard_pid(ts, pid))
-return 0;
is_start = packet[1] & 0x40;
tss = ts->pids[pid];
if (ts->auto_guess && !tss && is_start) {
@@ -2484,6 +2483,10 @@ static int handle_packet(MpegTSContext *ts,
const

uint8_t *packet)

}
if (!tss)
return 0;
+if (is_start)
+tss->discard = discard_pid(ts, pid);
+if (tss->discard)
+return 0;


this is moving the discard check over the auto_guess /add_pes_stream()
have you checked or know that this is ok ?
its not immedeatly obviouls (to me) why this would have no side effects


As far as I see that code is used to add streams which are not part of the
detected programs. Therefore program discards should not concern them.


Will apply soon.


sure ok


Thanks, applied.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/async: fix assertion condition when draining buffer

[Marton Balint]

On Sun, 27 Jan 2019, Marton Balint wrote:


Fixes some random assertion failures with

ffprobe -show_packets 
async:samples/ffmpeg-bugs/trac/ticket6132/Samsung_HDR_-_Chasing_the_Light.ts > 
/dev/null

Signed-off-by: Marton Balint 
---
libavformat/async.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/async.c b/libavformat/async.c
index 54dbd2312a..4e295b5e10 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -142,7 +142,7 @@ static int ring_size_of_read_back(RingBuffer *ring)
static int ring_drain(RingBuffer *ring, int offset)
{
av_assert2(offset >= -ring_size_of_read_back(ring));
-av_assert2(offset <= -ring_size(ring));
+av_assert2(offset <= ring_size(ring));
ring->read_pos += offset;
return 0;
}


Pushed.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/3] ffplay: use different decoder names for each media type

[Marton Balint]

Signed-off-by: Marton Balint 
---
 fftools/ffplay.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 6a195e5542..97009f322d 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -2103,10 +2103,10 @@ static int audio_thread(void *arg)
 return ret;
 }
 
-static int decoder_start(Decoder *d, int (*fn)(void *), void *arg)
+static int decoder_start(Decoder *d, int (*fn)(void *), const char 
*thread_name, void* arg)
 {
 packet_queue_start(d->queue);
-d->decoder_tid = SDL_CreateThread(fn, "decoder", arg);
+d->decoder_tid = SDL_CreateThread(fn, thread_name, arg);
 if (!d->decoder_tid) {
 av_log(NULL, AV_LOG_ERROR, "SDL_CreateThread(): %s\n", SDL_GetError());
 return AVERROR(ENOMEM);
@@ -2676,7 +2676,7 @@ static int stream_component_open(VideoState *is, int 
stream_index)
 is->auddec.start_pts = is->audio_st->start_time;
 is->auddec.start_pts_tb = is->audio_st->time_base;
 }
-if ((ret = decoder_start(&is->auddec, audio_thread, is)) < 0)
+if ((ret = decoder_start(&is->auddec, audio_thread, "audio_decoder", 
is)) < 0)
 goto out;
 SDL_PauseAudioDevice(audio_dev, 0);
 break;
@@ -2685,7 +2685,7 @@ static int stream_component_open(VideoState *is, int 
stream_index)
 is->video_st = ic->streams[stream_index];
 
 decoder_init(&is->viddec, avctx, &is->videoq, 
is->continue_read_thread);
-if ((ret = decoder_start(&is->viddec, video_thread, is)) < 0)
+if ((ret = decoder_start(&is->viddec, video_thread, "video_decoder", 
is)) < 0)
 goto out;
 is->queue_attachments_req = 1;
 break;
@@ -2694,7 +2694,7 @@ static int stream_component_open(VideoState *is, int 
stream_index)
 is->subtitle_st = ic->streams[stream_index];
 
 decoder_init(&is->subdec, avctx, &is->subtitleq, 
is->continue_read_thread);
-if ((ret = decoder_start(&is->subdec, subtitle_thread, is)) < 0)
+if ((ret = decoder_start(&is->subdec, subtitle_thread, 
"subtitle_decoder", is)) < 0)
 goto out;
 break;
 default:
-- 
2.16.4

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

[FFmpeg-devel] [PATCH 2/3] ffplay: add missing avfilter_graph_alloc result check

[Marton Balint]

Also do not allocate a graph at start, we will reallocate it anyway.

Signed-off-by: Marton Balint 
---
 fftools/ffplay.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 97009f322d..f84052a89b 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -2125,26 +2125,17 @@ static int video_thread(void *arg)
 AVRational frame_rate = av_guess_frame_rate(is->ic, is->video_st, NULL);
 
 #if CONFIG_AVFILTER
-AVFilterGraph *graph = avfilter_graph_alloc();
+AVFilterGraph *graph = NULL;
 AVFilterContext *filt_out = NULL, *filt_in = NULL;
 int last_w = 0;
 int last_h = 0;
 enum AVPixelFormat last_format = -2;
 int last_serial = -1;
 int last_vfilter_idx = 0;
-if (!graph) {
-av_frame_free(&frame);
-return AVERROR(ENOMEM);
-}
-
 #endif
 
-if (!frame) {
-#if CONFIG_AVFILTER
-avfilter_graph_free(&graph);
-#endif
+if (!frame)
 return AVERROR(ENOMEM);
-}
 
 for (;;) {
 ret = get_video_frame(is, frame);
@@ -2167,6 +2158,10 @@ static int video_thread(void *arg)
(const char 
*)av_x_if_null(av_get_pix_fmt_name(frame->format), "none"), 
is->viddec.pkt_serial);
 avfilter_graph_free(&graph);
 graph = avfilter_graph_alloc();
+if (!graph) {
+ret = AVERROR(ENOMEM);
+goto the_end;
+}
 if ((ret = configure_video_filters(graph, is, vfilters_list ? 
vfilters_list[is->vfilter_idx] : NULL, frame)) < 0) {
 SDL_Event event;
 event.type = FF_QUIT_EVENT;
-- 
2.16.4

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

[FFmpeg-devel] [PATCH 3/3] ffplay: add support for setting the number of filter threads

[Marton Balint]

Signed-off-by: Marton Balint 
---
 doc/ffplay.texi  | 6 ++
 fftools/ffplay.c | 4 
 2 files changed, 10 insertions(+)

diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index 99e1d7468a..c305465078 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -195,6 +195,12 @@ input as soon as possible. Enabled by default for realtime 
streams, where data
 may be dropped if not read in time. Use this option to enable infinite buffers
 for all inputs, use @option{-noinfbuf} to disable it.
 
+@item -filter_threads @var{nb_threads}
+Defines how many threads are used to process a filter pipeline. Each pipeline
+will produce a thread pool with this many threads available for parallel
+processing. The default is 0 which means that the thread count will be
+determined by the number of available CPUs.
+
 @end table
 
 @section While playing
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index f84052a89b..8f050e16e6 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -353,6 +353,7 @@ static char *afilters = NULL;
 #endif
 static int autorotate = 1;
 static int find_stream_info = 1;
+static int filter_nbthreads = 0;
 
 /* current context */
 static int is_full_screen;
@@ -1954,6 +1955,7 @@ static int configure_audio_filters(VideoState *is, const 
char *afilters, int for
 avfilter_graph_free(&is->agraph);
 if (!(is->agraph = avfilter_graph_alloc()))
 return AVERROR(ENOMEM);
+is->agraph->nb_threads = filter_nbthreads;
 
 while ((e = av_dict_get(swr_opts, "", e, AV_DICT_IGNORE_SUFFIX)))
 av_strlcatf(aresample_swr_opts, sizeof(aresample_swr_opts), "%s=%s:", 
e->key, e->value);
@@ -2162,6 +2164,7 @@ static int video_thread(void *arg)
 ret = AVERROR(ENOMEM);
 goto the_end;
 }
+graph->nb_threads = filter_nbthreads;
 if ((ret = configure_video_filters(graph, is, vfilters_list ? 
vfilters_list[is->vfilter_idx] : NULL, frame)) < 0) {
 SDL_Event event;
 event.type = FF_QUIT_EVENT;
@@ -3611,6 +3614,7 @@ static const OptionDef options[] = {
 { "autorotate", OPT_BOOL, { &autorotate }, "automatically rotate video", 
"" },
 { "find_stream_info", OPT_BOOL | OPT_INPUT | OPT_EXPERT, { 
&find_stream_info },
 "read and decode the streams to fill missing information with 
heuristics" },
+{ "filter_threads", HAS_ARG | OPT_INT | OPT_EXPERT, { &filter_nbthreads }, 
"number of filter threads per graph" },
 { NULL, },
 };
 
-- 
2.16.4

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

Re: [FFmpeg-devel] [PATCH] avformat/isom.h: use usnigned types in MOVStsc

[Chris Cunningham]

On Sat, Feb 2, 2019 at 3:37 AM Michael Niedermayer 
wrote:

> Is this change needed by some valid file ?
>

No, just a drive by fix since I happened to be looking at these types and
the spec.


> The change taken on its own is probably correct but its increasing the
> range
> of values without actually adding support for that thus quite possibly
> introducing bugs.
>
> In case of the id, we use signed int for the entries this indexes into,
> so the extended range is not going to work.  also wonder if billions
> of STSD entries in a stream will work when more than 1 cause problems
> already.
>
> Another obvious issue is that currently we scan this table for negative
> values and eliminate them but when this is made unsigned suddenly
> larger values pass through. This has the potential to introduce
> integer overflow bugs in later stages. More so unsigned overflows dont
> show up in asan and these first/count values might affect array indexes
> iam not saying theres a bug here just that its the set of circunstances
> that is fertile for such bugs.
>
> variables related to indexes or counts always require extra scrutiny
> when their type is changed
>

I really appreciate the scrutiny. Given I don't have a file that needs
this, happy to abandon this patch.

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

Re: [FFmpeg-devel] [PATCH] configure: request explicitly enabled components

[Carl Eugen Hoyos]

2019-02-03 16:24 GMT+01:00, Marton Balint :
>
>
> On Sun, 3 Feb 2019, Carl Eugen Hoyos wrote:
>
>> 2019-01-28 2:00 GMT+01:00, Marton Balint :
>>> If we enable a component but a dependant library is disabled, then the
>>> enabled
>>> component get silently disabled. Requesting all explicitly enabled
>>> components
>>> allows configure to fail and show the missing dependencies instead of
>>> ignoring
>>> our request.
>>>
>>> For example if libdav1d is not availble ./configure
>>> --enable-decoder=libdav1d
>>> succeeds but the libdav1d decoder will not be enabled. After the patch
>>> the
>>> configure line will fail with the following message:
>>> ERROR: libdav1d_decoder requested, but not all dependencies are
>>> satisfied:
>>> libdav1d
>>>
>>> Signed-off-by: Marton Balint 
>>> ---
>>>  configure | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/configure b/configure
>>> index e1412352fa..1f6c6a7311 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -3881,6 +3881,7 @@ for opt do
>>>  list=$(filter "$name" $list)
>>>  [ "$list" = "" ] && warn "Option $opt did not match
>>> anything"
>>>  $action $list
>>
>>> +test $action = enable && request $list
>>
>> I strongly suspect that this will break regression tests.
>
> You mean fate with different configure options?

No, I believe this would break regression tests with
--disable-everything (and an enable for a feature that
was added in the meantime and is needed to reproduce
the issue).
Please print a warning like for "--enable-decoder=foo"
to fix the issue you see.

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

Re: [FFmpeg-devel] [PATCH] configure: request explicitly enabled components

[Marton Balint]

On Tue, 5 Feb 2019, Carl Eugen Hoyos wrote:


2019-02-03 16:24 GMT+01:00, Marton Balint :



On Sun, 3 Feb 2019, Carl Eugen Hoyos wrote:


2019-01-28 2:00 GMT+01:00, Marton Balint :

If we enable a component but a dependant library is disabled, then the
enabled
component get silently disabled. Requesting all explicitly enabled
components
allows configure to fail and show the missing dependencies instead of
ignoring
our request.

For example if libdav1d is not availble ./configure
--enable-decoder=libdav1d
succeeds but the libdav1d decoder will not be enabled. After the patch
the
configure line will fail with the following message:
ERROR: libdav1d_decoder requested, but not all dependencies are
satisfied:
libdav1d

Signed-off-by: Marton Balint 
---
 configure | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index e1412352fa..1f6c6a7311 100755
--- a/configure
+++ b/configure
@@ -3881,6 +3881,7 @@ for opt do
 list=$(filter "$name" $list)
 [ "$list" = "" ] && warn "Option $opt did not match
anything"
 $action $list



+test $action = enable && request $list


I strongly suspect that this will break regression tests.


You mean fate with different configure options?


No, I believe this would break regression tests with
--disable-everything (and an enable for a feature that
was added in the meantime and is needed to reproduce
the issue).


Could you give a more concrete example? I am not sure I understand what 
you mean.


Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/1] Seeking disabled unconditionally in DASH demuxer

[Carl Eugen Hoyos]

2019-02-04 21:27 GMT+01:00, Paweł Wegner :

> any reason why this commit:
> https://github.com/FFmpeg/FFmpeg/commit/d54ae9b782c85e626a1e49a8ee204728746227d1#diff-ce2d1d31314e57cff2d1f3eb78988c88R1903
> disables seeking in dash demuxer? Seeking works fine
> for my dash manifests when I remove the highlighted line.

Looks like a regression since d54ae9b7 to me.

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

Re: [FFmpeg-devel] [PATCH 0/2] ARIB STD-B24 caption decoding using libaribb24

[Carl Eugen Hoyos]

2019-02-02 15:21 GMT+01:00, Jan Ekström :
> On Sat, Feb 2, 2019 at 3:55 PM Carl Eugen Hoyos  wrote:
>>
>> 2019-02-02 14:31 GMT+01:00, Jan Ekström :
>>
>> > I will proceed to making a FATE test
>>
>> You cannot add fate tests for external libraries.
>>
>
> Ouch. I was asked by Clement to make one which is why I wanted to do
> it. Possibly he didn't understand that a library was being utilized.
>
>> Is there no chance of adding the aribb24 code to FFmpeg?
>> The library looks small although it also contains an mpegts
>> parser iiuc.
>>
>
> As we generally want code to be LGPLv2.1+ when taking it in, we cannot
> internalize libaribb24 as it is right now (LGPLv3 as of git master).

We prefer LGPL2 but I don't think LGPL3 is unreasonable, we
have a configure switch already...

> All of the files do contain LGPLv2.1 license headers, so I did ask the
> author to confirm and/or normalize them if possible, but there has
> been very little activity around the library recently:
> https://github.com/nkoriyama/aribb24/issues/9

That seems like a very strong indication we should not link
against the library.

>
> There are currently two main things which aribb24 provides:
> - Text conversion from the STD-B24 text encoding to UTF-8
> - Decoding of STD-B24 caption regions into region structures while
> converting the text into UTF-8 by utilizing the previous functionality
>
> The first feature one is available in a not-accepted-upstream iconv
> module implemented under LGPLv2.1:
> https://git.linuxtv.org/v4l-utils.git/tree/contrib/gconv/arib-std-b24.c
> (it also includes encoding support if we want to later add support for
> writing properly coded metadata into MPEG-TS in ARIB mode)
>
> The second feature I have found in an anonymous fork of FFmpeg (it
> utilizes this custom iconv module for the text conversion):
> https://github.com/0p1pp1/FFmpeg/blob/isdb-4.0/libavcodec/isdbsubdec.c
>
> Now, the problem is that this decoder has been written by a person who
> is not in touch with upstream, and also seems to utilize an awful lot
> of customized things in general with regards to ASS and other parts -
> which is why I initially decided to pick the alternative of using an
> already utilized/packaged open source library, for which the wrapper
> would not be of too large size. Additionally, the output of this
> library could then be compared against what this anonymous decoder
> generates.

Reasons and reasons for not adding the external dependency imo...

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

Re: [FFmpeg-devel] [PATCH] libavcodec: vp8 neon optimizations for aarch64

[James Almer]

On 1/31/2019 4:23 PM, Carl Eugen Hoyos wrote:
> 2019-01-31 17:04 GMT+01:00, Magnus Röös :
>> Partial port of the ARM Neon for aarch64.
> 
> Reproduced a >20% speedup for fate-vp8 and applied.
> 
> Thank you, Carl Eugen

This seems to have broken builds with Clang on aarch64. GCC seems fine.

http://fate.ffmpeg.org/report.cgi?time=20190204212326&slot=armv8-linux-clang-7
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: request explicitly enabled components

[Carl Eugen Hoyos]

2019-02-05 0:53 GMT+01:00, Marton Balint :
>
>
> On Tue, 5 Feb 2019, Carl Eugen Hoyos wrote:
>
>> 2019-02-03 16:24 GMT+01:00, Marton Balint :
>>>
>>>
>>> On Sun, 3 Feb 2019, Carl Eugen Hoyos wrote:
>>>
 2019-01-28 2:00 GMT+01:00, Marton Balint :
> If we enable a component but a dependant library is disabled, then the
> enabled
> component get silently disabled. Requesting all explicitly enabled
> components
> allows configure to fail and show the missing dependencies instead of
> ignoring
> our request.
>
> For example if libdav1d is not availble ./configure
> --enable-decoder=libdav1d
> succeeds but the libdav1d decoder will not be enabled. After the patch
> the
> configure line will fail with the following message:
> ERROR: libdav1d_decoder requested, but not all dependencies are
> satisfied:
> libdav1d
>
> Signed-off-by: Marton Balint 
> ---
>  configure | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/configure b/configure
> index e1412352fa..1f6c6a7311 100755
> --- a/configure
> +++ b/configure
> @@ -3881,6 +3881,7 @@ for opt do
>  list=$(filter "$name" $list)
>  [ "$list" = "" ] && warn "Option $opt did not match
> anything"
>  $action $list

> +test $action = enable && request $list

 I strongly suspect that this will break regression tests.
>>>
>>> You mean fate with different configure options?
>>
>> No, I believe this would break regression tests with
>> --disable-everything (and an enable for a feature that
>> was added in the meantime and is needed to reproduce
>> the issue).
>
> Could you give a more concrete example? I am not sure I
> understand what you mean.

$ ./configure --disable-everything --enable-bsf=prores_metadata
currently does not fail for current FFmpeg and 936d18fb, this
would change for future new features with your patch.

Please print a warning for --enable-decoder=libdav1d if
libdav1d was not enabled.

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

Re: [FFmpeg-devel] [PATCH] libavcodec: vp8 neon optimizations for aarch64

[Carl Eugen Hoyos]

2019-02-05 0:59 GMT+01:00, James Almer :
> On 1/31/2019 4:23 PM, Carl Eugen Hoyos wrote:
>> 2019-01-31 17:04 GMT+01:00, Magnus Röös :
>>> Partial port of the ARM Neon for aarch64.
>>
>> Reproduced a >20% speedup for fate-vp8 and applied.
>>
>> Thank you, Carl Eugen
>
> This seems to have broken builds with Clang on aarch64. GCC seems fine.
>
> http://fate.ffmpeg.org/report.cgi?time=20190204212326&slot=armv8-linux-clang-7

Yes.

Do you know if Martin plans to push his patch?
I can do it but I cannot test MS.

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

Re: [FFmpeg-devel] [PATCH] libavcodec: vp8 neon optimizations for aarch64

[Carl Eugen Hoyos]

2019-02-05 0:59 GMT+01:00, James Almer :
> On 1/31/2019 4:23 PM, Carl Eugen Hoyos wrote:
>> 2019-01-31 17:04 GMT+01:00, Magnus Röös :
>>> Partial port of the ARM Neon for aarch64.
>>
>> Reproduced a >20% speedup for fate-vp8 and applied.
>>
>> Thank you, Carl Eugen
>
> This seems to have broken builds with Clang on aarch64. GCC seems fine.
>
> http://fate.ffmpeg.org/report.cgi?time=20190204212326&slot=armv8-linux-clang-7

(Note that it's no problem to build with clang on Linux but
I suspect Android and ios are more difficult / would not work.)

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

Re: [FFmpeg-devel] [PATCH] configure: request explicitly enabled components

[Hendrik Leppkes]

On Tue, Feb 5, 2019 at 1:01 AM Carl Eugen Hoyos  wrote:
>
> 2019-02-05 0:53 GMT+01:00, Marton Balint :
> >
> >
> > On Tue, 5 Feb 2019, Carl Eugen Hoyos wrote:
> >
> >> 2019-02-03 16:24 GMT+01:00, Marton Balint :
> >>>
> >>>
> >>> On Sun, 3 Feb 2019, Carl Eugen Hoyos wrote:
> >>>
>  2019-01-28 2:00 GMT+01:00, Marton Balint :
> > If we enable a component but a dependant library is disabled, then the
> > enabled
> > component get silently disabled. Requesting all explicitly enabled
> > components
> > allows configure to fail and show the missing dependencies instead of
> > ignoring
> > our request.
> >
> > For example if libdav1d is not availble ./configure
> > --enable-decoder=libdav1d
> > succeeds but the libdav1d decoder will not be enabled. After the patch
> > the
> > configure line will fail with the following message:
> > ERROR: libdav1d_decoder requested, but not all dependencies are
> > satisfied:
> > libdav1d
> >
> > Signed-off-by: Marton Balint 
> > ---
> >  configure | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/configure b/configure
> > index e1412352fa..1f6c6a7311 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3881,6 +3881,7 @@ for opt do
> >  list=$(filter "$name" $list)
> >  [ "$list" = "" ] && warn "Option $opt did not match
> > anything"
> >  $action $list
> 
> > +test $action = enable && request $list
> 
>  I strongly suspect that this will break regression tests.
> >>>
> >>> You mean fate with different configure options?
> >>
> >> No, I believe this would break regression tests with
> >> --disable-everything (and an enable for a feature that
> >> was added in the meantime and is needed to reproduce
> >> the issue).
> >
> > Could you give a more concrete example? I am not sure I
> > understand what you mean.
>
> $ ./configure --disable-everything --enable-bsf=prores_metadata
> currently does not fail for current FFmpeg and 936d18fb, this
> would change for future new features with your patch.
>

What sort of testing would involve trying to enable a certain
component, and then *succeeding* when the component does not exist? If
anything, you would make it fail sooner, before any actual testing
that would presumably actually fail later (otherwise, what would be
the point exactly?)

Please elaborate more then one random command line that without
explanation does not really make sense. If I request a certain
component, I would expect one of two things: I get an error, or I get
a build that includes that component. Anything else would be
unexpected, and therefor bad.
We have this wanted behavior with other options already, just not this
one, so its  not even consistent at all.

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

Re: [FFmpeg-devel] [PATCH] avformat/mov: validate chunk_count vs stsc_data

[Chris Cunningham]

On Sat, Feb 2, 2019 at 3:55 AM Michael Niedermayer 
wrote:

> >  static inline int64_t mov_get_stsc_samples(MOVStreamContext *sc,
> unsigned int index)
> >  {
> > -int chunk_count;
> > +unsigned int chunk_count = 0;
> >
> >  if (mov_stsc_index_valid(index, sc->stsc_count))
> >  chunk_count = sc->stsc_data[index + 1].first -
> sc->stsc_data[index].first;
> > -else
> > +else if (sc->chunk_count >= sc->stsc_data[index].first)
> >  chunk_count = sc->chunk_count - (sc->stsc_data[index].first -
> 1);
>
> This construct occurs a 2nd time (in mov_build_index()) is this not
> affected?
>

Didn't notice it, but I think it would be affected. I'll leave this alone
for now, but I'm open to adding a mov_get_chunk_count helper to call from
both mov_build_index and mov_get_stsc_samples.


> mov_read_trak() contains a check for chunk_count and the first index(es)
> (obviously this is not catching this one but)
> is there a reason not to eliminate the inconsistancy at that or some other
> "early" point?
>

Agree this sounds better. Stand by for patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/mov: validate chunk_count vs stsc_data

[chcunningham]

Bad content may contain stsc boxes with a first_chunk index that
exceeds stco.entries (chunk_count). This ammends the existing check to
include cases where chunk_count == 0.
---
 libavformat/mov.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9b9739f788..2f3ad38ac3 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2694,8 +2694,11 @@ static inline int64_t 
mov_get_stsc_samples(MOVStreamContext *sc, unsigned int in
 
 if (mov_stsc_index_valid(index, sc->stsc_count))
 chunk_count = sc->stsc_data[index + 1].first - 
sc->stsc_data[index].first;
-else
+else {
+// Validation for stsc / stco  happens earlier in mov_read_stsc + 
mov_read_trak.
+av_assert0(sc->stsc_data[index].first <= sc->chunk_count);
 chunk_count = sc->chunk_count - (sc->stsc_data[index].first - 1);
+}
 
 return sc->stsc_data[index].count * (int64_t)chunk_count;
 }
@@ -4175,7 +4178,7 @@ static int mov_read_trak(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
st->index);
 return 0;
 }
-if (sc->chunk_count && sc->stsc_count && sc->stsc_data[ sc->stsc_count - 1 
].first > sc->chunk_count) {
+if (sc->stsc_count && sc->stsc_data[ sc->stsc_count - 1 ].first > 
sc->chunk_count) {
 av_log(c->fc, AV_LOG_ERROR, "stream %d, contradictionary STSC and 
STCO\n",
st->index);
 return AVERROR_INVALIDDATA;
-- 
2.20.1.611.gfbb209baf1-goog

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

Re: [FFmpeg-devel] [PATCH] avcodec/gsm_parser: return -1 on parse error

[Chris Cunningham]

>
> The underlined bit above seems like the root cause. Where should we be
> updating st->internal->avctx->codec_id?
>

Friendly ping for review
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/movenc: Add more error checking when writing sample entries.

[Nikolas Bowe]

Fixes a problem where a sample entry which cannot be written correctly appears 
to succeed, but produces an invalid file.
For example, this command:
ffmpeg -f lavfi -i sine=frequency=1000:duration=5 -codec:a ac3 -movflags 
+empty_moov -frag_duration 500 /tmp/foo.mp4
produced a file with the ac-3 sample entry, but no AC3SpecificBox (dac3) child, 
which is invalid according to ETSI TS 102 366.
---
 libavformat/movenc.c | 73 
 1 file changed, 47 insertions(+), 26 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 65be2968a1..3a1ce40e4f 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -320,8 +320,12 @@ static int mov_write_ac3_tag(AVIOContext *pb, MOVTrack 
*track)
 uint8_t buf[3];
 int fscod, bsid, bsmod, acmod, lfeon, frmsizecod;
 
-if (track->vos_len < 7)
-return -1;
+if (track->vos_len < 7) {
+av_log(pb, AV_LOG_ERROR,
+   "Cannot write moov atom before AC3 packets."
+   " Set the delay_moov flag to fix this.\n");
+return AVERROR(EINVAL);
+}
 
 avio_wb32(pb, 11);
 ffio_wfourcc(pb, "dac3");
@@ -538,8 +542,11 @@ static int mov_write_eac3_tag(AVIOContext *pb, MOVTrack 
*track)
 struct eac3_info *info;
 int size, i;
 
-if (!track->eac3_priv)
+if (!track->eac3_priv) {
+av_log(pb, AV_LOG_ERROR, 
+   "Cannot write moov atom before EAC3 packets parsed.\n");
 return AVERROR(EINVAL);
+}
 
 info = track->eac3_priv;
 size = 2 + ((34 * (info->num_ind_sub + 1) + 7) >> 3);
@@ -1022,6 +1029,7 @@ static int mov_write_audio_tag(AVFormatContext *s, 
AVIOContext *pb, MOVMuxContex
 int64_t pos = avio_tell(pb);
 int version = 0;
 uint32_t tag = track->tag;
+int ret = 0;
 
 if (track->mode == MODE_MOV) {
 if (track->timescale > UINT16_MAX || !track->par->channels) {
@@ -1125,34 +1133,41 @@ static int mov_write_audio_tag(AVFormatContext *s, 
AVIOContext *pb, MOVMuxContex
  track->par->codec_id == AV_CODEC_ID_QDM2  ||
  (mov_pcm_le_gt16(track->par->codec_id) && version==1) ||
  (mov_pcm_be_gt16(track->par->codec_id) && version==1)))
-mov_write_wave_tag(s, pb, track);
+ret = mov_write_wave_tag(s, pb, track);
 else if (track->tag == MKTAG('m','p','4','a'))
-mov_write_esds_tag(pb, track);
+ret = mov_write_esds_tag(pb, track);
 else if (track->par->codec_id == AV_CODEC_ID_AMR_NB)
-mov_write_amr_tag(pb, track);
+ret = mov_write_amr_tag(pb, track);
 else if (track->par->codec_id == AV_CODEC_ID_AC3)
-mov_write_ac3_tag(pb, track);
+ret = mov_write_ac3_tag(pb, track);
 else if (track->par->codec_id == AV_CODEC_ID_EAC3)
-mov_write_eac3_tag(pb, track);
+ret = mov_write_eac3_tag(pb, track);
 else if (track->par->codec_id == AV_CODEC_ID_ALAC)
-mov_write_extradata_tag(pb, track);
+ret = mov_write_extradata_tag(pb, track);
 else if (track->par->codec_id == AV_CODEC_ID_WMAPRO)
-mov_write_wfex_tag(s, pb, track);
+ret = mov_write_wfex_tag(s, pb, track);
 else if (track->par->codec_id == AV_CODEC_ID_FLAC)
-mov_write_dfla_tag(pb, track);
+ret = mov_write_dfla_tag(pb, track);
 else if (track->par->codec_id == AV_CODEC_ID_OPUS)
-mov_write_dops_tag(pb, track);
+ret = mov_write_dops_tag(pb, track);
 else if (track->vos_len > 0)
-mov_write_glbl_tag(pb, track);
+ret = mov_write_glbl_tag(pb, track);
 
-if (track->mode == MODE_MOV && track->par->codec_type == 
AVMEDIA_TYPE_AUDIO)
-mov_write_chan_tag(s, pb, track);
+if (ret < 0)
+return ret;
 
-if (mov->encryption_scheme != MOV_ENC_NONE) {
-ff_mov_cenc_write_sinf_tag(track, pb, mov->encryption_kid);
+if (track->mode == MODE_MOV && track->par->codec_type == 
AVMEDIA_TYPE_AUDIO 
+&& ((ret = mov_write_chan_tag(s, pb, track)) < 0)) {
+return ret;
 }
 
-return update_size(pb, pos);
+if (mov->encryption_scheme != MOV_ENC_NONE
+&& ((ret = ff_mov_cenc_write_sinf_tag(track, pb, 
mov->encryption_kid)) < 0)) {
+return ret;
+}
+
+ret = update_size(pb, pos);
+return ret;
 }
 
 static int mov_write_d263_tag(AVIOContext *pb)
@@ -2217,22 +2232,27 @@ static int mov_write_gpmd_tag(AVIOContext *pb, const 
MOVTrack *track)
 static int mov_write_stsd_tag(AVFormatContext *s, AVIOContext *pb, 
MOVMuxContext *mov, MOVTrack *track)
 {
 int64_t pos = avio_tell(pb);
+int ret = 0;
 avio_wb32(pb, 0); /* size */
 ffio_wfourcc(pb, "stsd");
 avio_wb32(pb, 0); /* version & flags */
 avio_wb32(pb, 1); /* entry count */
 if (track->par->codec_type == AVMEDIA_TYPE_VIDEO)
-mov_write_video_tag(pb, mov, track);
+ret = mov_write_video_tag(pb, mov, track);
 else if (track->par->codec_type == AVMEDIA_TYPE_AUDIO)
-mov_write_aud

Re: [FFmpeg-devel] [PATCH] avformat/movenc: Add more error checking when writing sample entries.

[Baptiste Coudurier]

Hi Nikolas,

> On Feb 4, 2019, at 5:02 PM, Nikolas Bowe  
> wrote:
> 
> Fixes a problem where a sample entry which cannot be written correctly 
> appears to succeed, but produces an invalid file.
> For example, this command:
> ffmpeg -f lavfi -i sine=frequency=1000:duration=5 -codec:a ac3 -movflags 
> +empty_moov -frag_duration 500 /tmp/foo.mp4
> produced a file with the ac-3 sample entry, but no AC3SpecificBox (dac3) 
> child, which is invalid according to ETSI TS 102 366.

Ideally I feel that the code you fail as early as possible, so ideally fail 
during “mov_write_header” if the issue is extradata related.

[…]

— 
Baptiste

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

[FFmpeg-devel] [PATCH] avformat/utils: parse some stream specifiers recursively

[Marton Balint]

This removes lots of code duplication and also allows more complex specifiers,
for example you can use p:204:a:m:language:eng to select the English language
audio stream from program 204.

Signed-off-by: Marton Balint 
---
 doc/fftools-common-opts.texi |  30 +++-
 libavformat/utils.c  | 172 +--
 2 files changed, 65 insertions(+), 137 deletions(-)

diff --git a/doc/fftools-common-opts.texi b/doc/fftools-common-opts.texi
index 84705c0b68..43c1f4d2d6 100644
--- a/doc/fftools-common-opts.texi
+++ b/doc/fftools-common-opts.texi
@@ -34,27 +34,21 @@ Possible forms of stream specifiers are:
 @table @option
 @item @var{stream_index}
 Matches the stream with this index. E.g. @code{-threads:1 4} would set the
-thread count for the second stream to 4.
-@item @var{stream_type}[:@var{stream_index}]
+thread count for the second stream to 4. If @var{stream_index} is used as an
+additional stream specifier (see below), then it selects stream number
+@var{stream_index} from the matching streams.
+@item @var{stream_type}[:@var{additional_stream_specifier}]
 @var{stream_type} is one of following: 'v' or 'V' for video, 'a' for audio, 's'
 for subtitle, 'd' for data, and 't' for attachments. 'v' matches all video
 streams, 'V' only matches video streams which are not attached pictures, video
-thumbnails or cover arts.  If @var{stream_index} is given, then it matches
-stream number @var{stream_index} of this type. Otherwise, it matches all
-streams of this type.
-@item p:@var{program_id}[:@var{stream_index}] or 
p:@var{program_id}[:@var{stream_type}[:@var{stream_index}]] or
-p:@var{program_id}:m:@var{key}[:@var{value}]
-In first version, if @var{stream_index} is given, then it matches the stream 
with number @var{stream_index}
-in the program with the id @var{program_id}. Otherwise, it matches all streams 
in the
-program. In the second version, @var{stream_type} is one of following: 'v' for 
video, 'a' for audio, 's'
-for subtitle, 'd' for data. If @var{stream_index} is also given, then it 
matches
-stream number @var{stream_index} of this type in the program with the id 
@var{program_id}.
-Otherwise, if only @var{stream_type} is given, it matches all
-streams of this type in the program with the id @var{program_id}.
-In the third version matches streams in the program with the id 
@var{program_id} with the metadata
-tag @var{key} having the specified value. If
-@var{value} is not given, matches streams that contain the given tag with any
-value.
+thumbnails or cover arts. If @var{additional_stream_specifier} is used, then
+it matches streams which both have this type and match the
+@var{additional_stream_specifier}. Otherwise, it matches all streams of the
+specified type.
+@item p:@var{program_id}[:@var{additional_stream_specifier}]
+Matches streams which are in the program with the id @var{program_id}. If
+@var{additional_stream_specifier} is used, then it matches streams which both
+are part of the program and match the @var{additional_stream_specifier}.
 
 @item #@var{stream_id} or i:@var{stream_id}
 Match the stream by stream id (e.g. PID in MPEG-TS container).
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 7afef545fe..b3c30fe14c 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -5097,13 +5097,21 @@ AVRational av_guess_frame_rate(AVFormatContext *format, 
AVStream *st, AVFrame *f
 return fr;
 }
 
-int avformat_match_stream_specifier(AVFormatContext *s, AVStream *st,
-const char *spec)
-{
-if (*spec <= '9' && *spec >= '0') /* opt:index */
-return strtol(spec, NULL, 0) == st->index;
-else if (*spec == 'v' || *spec == 'a' || *spec == 's' || *spec == 'd' ||
- *spec == 't' || *spec == 'V') { /* opt:[vasdtV] */
+/* Matches a stream specifier (but ignores requested index)
+ * Returns:
+ *  - negative on error
+ *  - 0 if st is NOT a matching stream
+ *  - >0 if st is a matching stream
+ * *index is set if a specific index is requested from the matching streams. */
+static int match_stream_specifier(AVFormatContext *s, AVStream *st,
+  const char *spec, int *index)
+{
+if (*spec <= '9' && *spec >= '0') { /* opt:index */
+if (index)
+*index = strtol(spec, NULL, 0);
+return 1;
+} else if (*spec == 'v' || *spec == 'a' || *spec == 's' || *spec == 'd' ||
+   *spec == 't' || *spec == 'V') { /* opt:[vasdtV] */
 enum AVMediaType type;
 int nopic = 0;
 
@@ -5128,27 +5136,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 if (nopic && (st->disposition & AV_DISPOSITION_ATTACHED_PIC))
 return 0;
-if (*spec++ == ':') { /* possibly followed by :index */
-int i, index = strtol(spec, NULL, 0);
-for (i = 0; i < s->nb_streams; i++) {
-#if FF_API_LAVF_AVCTX
-FF_DISABLE_DEPRECATION_WARNINGS
-if ((s->streams[i]->codecpar->codec_type == type
-  

Re: [FFmpeg-devel] [PATCH] configure: request explicitly enabled components

[Carl Eugen Hoyos]

2019-02-05 1:13 GMT+01:00, Hendrik Leppkes :
> On Tue, Feb 5, 2019 at 1:01 AM Carl Eugen Hoyos  wrote:
>>
>> 2019-02-05 0:53 GMT+01:00, Marton Balint :
>> >
>> >
>> > On Tue, 5 Feb 2019, Carl Eugen Hoyos wrote:
>> >
>> >> 2019-02-03 16:24 GMT+01:00, Marton Balint :
>> >>>
>> >>>
>> >>> On Sun, 3 Feb 2019, Carl Eugen Hoyos wrote:
>> >>>
>>  2019-01-28 2:00 GMT+01:00, Marton Balint :
>> > If we enable a component but a dependant library is disabled, then
>> > the
>> > enabled
>> > component get silently disabled. Requesting all explicitly enabled
>> > components
>> > allows configure to fail and show the missing dependencies instead
>> > of
>> > ignoring
>> > our request.
>> >
>> > For example if libdav1d is not availble ./configure
>> > --enable-decoder=libdav1d
>> > succeeds but the libdav1d decoder will not be enabled. After the
>> > patch
>> > the
>> > configure line will fail with the following message:
>> > ERROR: libdav1d_decoder requested, but not all dependencies are
>> > satisfied:
>> > libdav1d
>> >
>> > Signed-off-by: Marton Balint 
>> > ---
>> >  configure | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/configure b/configure
>> > index e1412352fa..1f6c6a7311 100755
>> > --- a/configure
>> > +++ b/configure
>> > @@ -3881,6 +3881,7 @@ for opt do
>> >  list=$(filter "$name" $list)
>> >  [ "$list" = "" ] && warn "Option $opt did not match
>> > anything"
>> >  $action $list
>> 
>> > +test $action = enable && request $list
>> 
>>  I strongly suspect that this will break regression tests.
>> >>>
>> >>> You mean fate with different configure options?
>> >>
>> >> No, I believe this would break regression tests with
>> >> --disable-everything (and an enable for a feature that
>> >> was added in the meantime and is needed to reproduce
>> >> the issue).
>> >
>> > Could you give a more concrete example? I am not sure I
>> > understand what you mean.
>>
>> $ ./configure --disable-everything --enable-bsf=prores_metadata
>> currently does not fail for current FFmpeg and 936d18fb, this
>> would change for future new features with your patch.
>>
>
> What sort of testing would involve trying to enable a certain
> component, and then *succeeding* when the component does not exist?

Several regression tests have needed that in the past, I find it
strange that you seem to imply this will not happen in the
future.
Or is that not what you were saying?

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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: Add more error checking when writing sample entries.

[Niki Bowe]

Hi Baptiste.
I agree. This patch does cause it to fail in mov_write_header in the given
example, by propagating the errors returned from mov_write_ac3_tag.

It is not always extradata related.
Eg EAC3 parses the packets during muxing to build the dec3 atom. Perhaps
this should be made extradata, but its not today.
A definitely not extradata related example: mov_write_tmcd_tag can fail for
fps reasons.
Many atom writing functions can fail and return error codes, but today very
little error checking exists.


On Mon, Feb 4, 2019 at 5:22 PM Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> Hi Nikolas,
>
> On Feb 4, 2019, at 5:02 PM, Nikolas Bowe 
> wrote:
>
> Fixes a problem where a sample entry which cannot be written correctly
> appears to succeed, but produces an invalid file.
> For example, this command:
> ffmpeg -f lavfi -i sine=frequency=1000:duration=5 -codec:a ac3 -movflags
> +empty_moov -frag_duration 500 /tmp/foo.mp4
> produced a file with the ac-3 sample entry, but no AC3SpecificBox (dac3)
> child, which is invalid according to ETSI TS 102 366.
>
>
> Ideally I feel that the code you fail as early as possible, so ideally
> fail during “mov_write_header” if the issue is extradata related.
>
> […]
>
> —
> Baptiste
>
>

-- 

Nikolas Bowe |  SWE |  nb...@google.com |  408-565-5137
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/movenc: Fix muxing EAC3 with delay_moov

[Nikolas Bowe]

When using delay_moov mov_write_moov_tag gets called multiple times. Therefore 
we need to keep eac3_priv around for subsequent calls.

Signed-off-by: Nikolas Bowe 
---
 libavformat/movenc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 65be2968a1..ba811ddbc3 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -579,7 +579,6 @@ static int mov_write_eac3_tag(AVIOContext *pb, MOVTrack 
*track)
 
 end:
 av_packet_unref(&info->pkt);
-av_freep(&track->eac3_priv);
 
 return size;
 }
@@ -5956,6 +5955,9 @@ static void mov_free(AVFormatContext *s)
 av_freep(&mov->tracks[i].vos_data);
 
 ff_mov_cenc_free(&mov->tracks[i].cenc);
+
+if (mov->tracks[i].eac3_priv)
+av_freep(&mov->tracks[i].eac3_priv);
 }
 
 av_freep(&mov->tracks);
-- 
2.20.1.611.gfbb209baf1-goog

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

Re: [FFmpeg-devel] [PATCH] movenc: Fix VPCC bitdepth for hardware pixel formats

[Niki Bowe]

My apologies.
I realized I applied my patch incorrectly before sending this.
I will send a corrected version tomorrow



On Thu, Jan 31, 2019 at 4:28 PM Nikolas Bowe  wrote:

> If a hardware encoder is used, the pixel format may be a hardware pixel
> format.
> This leads to invalid VPCC atom being written, due to depth of hardware
> pixel formats being 0.
> To work around this, fallback on bits_per_raw_sample.
>
> Signed-off-by: Nikolas Bowe 
> ---
>  libavcodec/vaapi_encode.c |  2 +-
>  libavformat/vpcc.c| 13 +
>  2 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index b4e9fadaee..cfd9413f0f 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1116,7 +1116,7 @@ static av_cold int
> vaapi_encode_profile_entrypoint(AVCodecContext *avctx)
> ctx->input_frames->sw_format);
>  return AVERROR(EINVAL);
>  }
> -depth = desc->comp[0].depth;
> +avctx->bits_per_raw_sample = depth = desc->comp[0].depth;
>  for (i = 1; i < desc->nb_components; i++) {
>  if (desc->comp[i].depth != depth) {
>  av_log(avctx, AV_LOG_ERROR, "Invalid input pixfmt (%s).\n",
> diff --git a/libavformat/vpcc.c b/libavformat/vpcc.c
> index e0b7f288a6..f667ca9c00 100644
> --- a/libavformat/vpcc.c
> +++ b/libavformat/vpcc.c
> @@ -51,15 +51,20 @@ static int get_vpx_chroma_subsampling(AVFormatContext
> *s,
>  return -1;
>  }
>
> -static int get_bit_depth(AVFormatContext *s, enum AVPixelFormat
> pixel_format)
> +static int get_bit_depth(AVFormatContext *s, AVCodecParameters *par)
>  {
> +enum AVPixelFormat pixel_format = par->format;
>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pixel_format);
>  if (desc == NULL) {
>  av_log(s, AV_LOG_ERROR, "Unsupported pixel format (%d)\n",
> pixel_format);
>  return -1;
>  }
> -return desc->comp[0].depth;
> +if (desc->comp[0].depth) {
> +return desc->comp[0].depth;
> +}
> +// Fallback on bits_per_raw_sample if pix_fmt is a hw format.
> +return par->bits_per_raw_sample;
>  }
>
>  static int get_vpx_video_full_range_flag(enum AVColorRange color_range)
> @@ -119,13 +124,13 @@ int ff_isom_get_vpcc_features(AVFormatContext *s,
> AVCodecParameters *par,
>  int profile = par->profile;
>  int level = par->level == FF_LEVEL_UNKNOWN ?
>  get_vp9_level(par, frame_rate) : par->level;
> -int bit_depth = get_bit_depth(s, par->format);
> +int bit_depth = get_bit_depth(s, par);
>  int vpx_chroma_subsampling =
>  get_vpx_chroma_subsampling(s, par->format, par->chroma_location);
>  int vpx_video_full_range_flag =
>  get_vpx_video_full_range_flag(par->color_range);
>
> -if (bit_depth < 0 || vpx_chroma_subsampling < 0)
> +if (bit_depth <= 0 || vpx_chroma_subsampling < 0)
>  return AVERROR_INVALIDDATA;
>
>  if (profile == FF_PROFILE_UNKNOWN) {
> --
> 2.20.1.611.gfbb209baf1-goog
>
>

-- 

Nikolas Bowe |  SWE |  nb...@google.com |  408-565-5137
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/movenc: Fix muxing EAC3 with delay_moov

[Carl Eugen Hoyos]

2019-02-05 3:11 GMT+01:00, Nikolas Bowe :

> +if (mov->tracks[i].eac3_priv)
> +av_freep(&mov->tracks[i].eac3_priv);

I would have expected that the if() is unneeded, no?

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

Re: [FFmpeg-devel] [PATCH] lavf/mov: fix hang while seek on a kind of fragmented mp4.

[C.H.Liu]

I also think it would be better if we store pts-es in different lists for
each track. However, it does NOT match the original design of data
structures. Several boxes will be affected. So I am trying to commit this
patch to discuss with maintainers.

At present, I prefer the last version patch(fall back to linear searching
only if needed). I could research more later.


Thanks and Regards,

Charles Liu

Marton Balint  于2019年2月5日周二 上午4:42写道：

>
>
> On Mon, 4 Feb 2019, Michael Niedermayer wrote:
>
> > On Sat, Feb 02, 2019 at 05:03:25PM +0100, Marton Balint wrote:
> >>
> >>
> >> On Sat, 2 Feb 2019, Charles Liu wrote:
> >>
> >>> Binary searching would hang if the fragment items do NOT have
> timestamp for the specified stream.
> >>>
> >>> For example, a fmp4 consists of separated 'moof' boxes for each track,
> and separated 'sidx' for each segment, but no 'mfra' box.
> >>> Then every fragment item only have the timestamp for one of its tracks.
> >>
> >> I don't see why you are changing the search to be linear. Is it
> possible the
> >> some of the stream fragmens have NOPTS_VALUE but other don't? In this
> case
> >> you should keep the binary search and only fall back to linear search if
> >> binary search finds an AV_NOPTS_VALUE. See similar code in function
> >> mxf_absolute_bodysid_offset of libavformat/mxfdec.c.
> >
> > The point of binary searching is to achieve O(log n) time
> > if there is any linear search this is no longer achieved.
> > So its not ideal to have any AV_NOPTS_VALUE in the array that is
> > searched. It would be better if the unknown entries are not in the
> > array that is used for the search or if their value is monotonized
> > once for all searches
> > that being ideal at least ...
>
> Yeah that is true, but that would require maintaining a different array
> with pts-es, and getting/updating fragment pts-es are complicated as is.
>
> Considering that this fixes a hang, I'd rather see the last version of the
> patch applied than wait for a more complicated, yet faster implementation.
>
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/ppc/cpu: Fix power8 linux detection

[Lauri Kasanen]

On Tue, 8 Jan 2019 11:08:04 +0200
Lauri Kasanen  wrote:

> The existing code was in no released kernel that I can see. The corrected code
> was added in 3.9.
> 
> Signed-off-by: Lauri Kasanen 
> ---
>  libavutil/ppc/cpu.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

Applying.

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

Re: [FFmpeg-devel] [PATCH v6] libswscale/ppc: VSX-optimize 9-16 bit yuv2planeX

[Lauri Kasanen]

On Sun, 13 Jan 2019 10:26:20 +0200
Lauri Kasanen  wrote:

> ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt 
> yuv420p16be \
> -s 1920x1728 -f null -vframes 100 -v error -nostats -
> 
> 9-14 bit funcs get about 6x speedup, 16-bit gets about 15x.
> Fate passes, each format tested with an image to video conversion.
> 
> Only POWER8 includes 32-bit vector multiplies, so POWER7 is locked out
> of the 16-bit function. This includes the vec_mulo/mule functions too,
> not just vmuluwm.

Applying.

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