Re: [FFmpeg-devel] [PATCH] mmaldec: Set the output pix_fmt after detecting format

[wm4]

On Wed, 21 Oct 2015 15:55:09 +0200
Julian Scheel  wrote:

> Wait for the first decoded frame to be returned by mmal before setting
> pix_fmt. This is important for avformat probing to work properly as it is one
> of the criterions to decide whether to decode a frame or not for probing.
> 
> Signed-off-by: Julian Scheel 
> ---
>  libavcodec/mmaldec.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
> index 7db90d2..429990a 100644
> --- a/libavcodec/mmaldec.c
> +++ b/libavcodec/mmaldec.c
> @@ -338,11 +338,6 @@ static av_cold int ffmmal_init_decoder(AVCodecContext 
> *avctx)
>  return AVERROR(ENOSYS);
>  }
>  
> -if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
> -return ret;
> -
> -avctx->pix_fmt = ret;
> -
>  if ((status = 
> mmal_component_create(MMAL_COMPONENT_DEFAULT_VIDEO_DECODER, >decoder)))
>  goto fail;
>  
> @@ -678,6 +673,11 @@ static int ffmmal_read_frame(AVCodecContext *avctx, 
> AVFrame *frame, int *got_fra
>  
>  av_log(avctx, AV_LOG_INFO, "Changing output format.\n");
>  
> +if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
> +return ret;
> +
> +avctx->pix_fmt = ret;
> +
>  if ((status = mmal_port_disable(decoder->output[0])))
>  goto done;
>  

MMAL_EVENT_FORMAT_CHANGED does not always happen. Some streams start
decoding without it. So you'd need to delay this somehow. Maybe when
the first decode call is done? (Other places also would work, but to
make fallback from hw decoding work well, it should happen when the
first packet is being consumed.)

I'd also like to test this with opaque formats first.

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

[FFmpeg-devel] [PATCH] mmaldec: Set the output pix_fmt after detecting format

[Julian Scheel]

Wait for the first decoded frame to be returned by mmal before setting
pix_fmt. This is important for avformat probing to work properly as it is one
of the criterions to decide whether to decode a frame or not for probing.

Signed-off-by: Julian Scheel 
---
 libavcodec/mmaldec.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 7db90d2..429990a 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -338,11 +338,6 @@ static av_cold int ffmmal_init_decoder(AVCodecContext 
*avctx)
 return AVERROR(ENOSYS);
 }
 
-if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
-return ret;
-
-avctx->pix_fmt = ret;
-
 if ((status = mmal_component_create(MMAL_COMPONENT_DEFAULT_VIDEO_DECODER, 
>decoder)))
 goto fail;
 
@@ -678,6 +673,11 @@ static int ffmmal_read_frame(AVCodecContext *avctx, 
AVFrame *frame, int *got_fra
 
 av_log(avctx, AV_LOG_INFO, "Changing output format.\n");
 
+if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
+return ret;
+
+avctx->pix_fmt = ret;
+
 if ((status = mmal_port_disable(decoder->output[0])))
 goto done;
 
-- 
2.6.0


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

Re: [FFmpeg-devel] [PATCH] mmaldec: Add mpeg2 decoding support

[wm4]

On Wed, 21 Oct 2015 15:54:39 +0200
Julian Scheel  wrote:

> Register mmaldec as mpeg2 decoder. Supporting mpeg2 in mmaldec is just a
> matter of setting the correct MMAL_ENCODING on the input port. To ease the
> addition of further supported mmal codecs a macro is introduced to generate
> the decoder and decoder class structs.
> 
> Signed-off-by: Julian Scheel 
> ---
>  configure  |  3 +++
>  libavcodec/Makefile|  1 +
>  libavcodec/allcodecs.c |  2 ++
>  libavcodec/mmaldec.c   | 71 
> +-
>  4 files changed, 53 insertions(+), 24 deletions(-)
> 
> diff --git a/configure b/configure
> index 1bbaf7f..a38b290 100755
> --- a/configure
> +++ b/configure
> @@ -2481,6 +2481,9 @@ mpeg2_d3d11va_hwaccel_deps="d3d11va"
>  mpeg2_d3d11va_hwaccel_select="mpeg2video_decoder"
>  mpeg2_dxva2_hwaccel_deps="dxva2"
>  mpeg2_dxva2_hwaccel_select="mpeg2video_decoder"
> +mpeg2_mmal_decoder_deps="mmal"
> +mpeg2_mmal_hwaccel_deps="mmal"
> +mpeg2_mmal_decoder_select="mpeg2video_decoder"
>  mpeg2_qsv_hwaccel_deps="libmfx"
>  mpeg2_qsv_hwaccel_select="qsvdec_mpeg2"
>  mpeg2_vaapi_hwaccel_deps="vaapi"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index af93f8a..f85fc18 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -370,6 +370,7 @@ OBJS-$(CONFIG_MPEG1VIDEO_DECODER)  += mpeg12dec.o 
> mpeg12.o mpeg12data.o
>  OBJS-$(CONFIG_MPEG1VIDEO_ENCODER)  += mpeg12enc.o mpeg12.o
>  OBJS-$(CONFIG_MPEG2VIDEO_DECODER)  += mpeg12dec.o mpeg12.o mpeg12data.o
>  OBJS-$(CONFIG_MPEG2VIDEO_ENCODER)  += mpeg12enc.o mpeg12.o
> +OBJS-$(CONFIG_MPEG2_MMAL_DECODER)  += mmaldec.o
>  OBJS-$(CONFIG_MPEG2_QSV_DECODER)   += qsvdec_mpeg2.o
>  OBJS-$(CONFIG_MPEG2_QSV_ENCODER)   += qsvenc_mpeg2.o
>  OBJS-$(CONFIG_MPEG4_DECODER)   += xvididct.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index d62bec7..7279620 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -97,6 +97,7 @@ void avcodec_register_all(void)
>  REGISTER_HWACCEL(MPEG2_XVMC,mpeg2_xvmc);
>  REGISTER_HWACCEL(MPEG2_D3D11VA, mpeg2_d3d11va);
>  REGISTER_HWACCEL(MPEG2_DXVA2,   mpeg2_dxva2);
> +REGISTER_HWACCEL(MPEG2_MMAL,mpeg2_mmal);
>  REGISTER_HWACCEL(MPEG2_QSV, mpeg2_qsv);
>  REGISTER_HWACCEL(MPEG2_VAAPI,   mpeg2_vaapi);
>  REGISTER_HWACCEL(MPEG2_VDPAU,   mpeg2_vdpau);
> @@ -238,6 +239,7 @@ void avcodec_register_all(void)
>  REGISTER_DECODER(MPEG_VDPAU,mpeg_vdpau);
>  REGISTER_DECODER(MPEG1_VDPAU,   mpeg1_vdpau);
>  #endif
> +REGISTER_DECODER(MPEG2_MMAL,mpeg2_mmal);
>  REGISTER_DECODER(MPEG2_CRYSTALHD,   mpeg2_crystalhd);
>  REGISTER_DECODER(MPEG2_QSV, mpeg2_qsv);
>  REGISTER_DECODER(MSA1,  msa1);
> diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
> index 13cc191..7db90d2 100644
> --- a/libavcodec/mmaldec.c
> +++ b/libavcodec/mmaldec.c
> @@ -350,7 +350,17 @@ static av_cold int ffmmal_init_decoder(AVCodecContext 
> *avctx)
>  
>  format_in = decoder->input[0]->format;
>  format_in->type = MMAL_ES_TYPE_VIDEO;
> -format_in->encoding = MMAL_ENCODING_H264;
> +switch (avctx->codec_id) {
> +case AV_CODEC_ID_MPEG2VIDEO:
> +format_in->encoding = MMAL_ENCODING_MP2V;
> +av_log(avctx, AV_LOG_ERROR, "Use MP2V encoding!\n");
> +break;
> +case AV_CODEC_ID_H264:
> +default:
> +format_in->encoding = MMAL_ENCODING_H264;
> +av_log(avctx, AV_LOG_ERROR, "Use H264 encoding!\n");
> +break;
> +}
>  format_in->es->video.width = FFALIGN(avctx->width, 32);
>  format_in->es->video.height = FFALIGN(avctx->height, 16);
>  format_in->es->video.crop.width = avctx->width;
> @@ -766,31 +776,44 @@ AVHWAccel ff_h264_mmal_hwaccel = {
>  .pix_fmt= AV_PIX_FMT_MMAL,
>  };
>  
> +AVHWAccel ff_mpeg2_mmal_hwaccel = {
> +.name   = "mpeg2_mmal",
> +.type   = AVMEDIA_TYPE_VIDEO,
> +.id = AV_CODEC_ID_MPEG2VIDEO,
> +.pix_fmt= AV_PIX_FMT_MMAL,
> +};
> +
>  static const AVOption options[]={
>  {"extra_buffers", "extra buffers", offsetof(MMALDecodeContext, 
> extra_buffers), AV_OPT_TYPE_INT, {.i64 = 10}, 0, 256, 0},
>  {NULL}
>  };
>  
> -static const AVClass ffmmaldec_class = {
> -.class_name = "mmaldec",
> -.option = options,
> -.version= LIBAVUTIL_VERSION_INT,
> -};
> -
> -AVCodec ff_h264_mmal_decoder = {
> -.name   = "h264_mmal",
> -.long_name  = NULL_IF_CONFIG_SMALL("h264 (mmal)"),
> -.type   = AVMEDIA_TYPE_VIDEO,
> -.id = AV_CODEC_ID_H264,
> -.priv_data_size = sizeof(MMALDecodeContext),
> -.init   = ffmmal_init_decoder,
> -.close  = ffmmal_close_decoder,
> -.decode = ffmmal_decode,
> -.flush  = ffmmal_flush,
> -

Re: [FFmpeg-devel] [PATCH] mmaldec: Add mpeg2 decoding support

[Hendrik Leppkes]

On Wed, Oct 21, 2015 at 3:54 PM, Julian Scheel  wrote:
> Register mmaldec as mpeg2 decoder. Supporting mpeg2 in mmaldec is just a
> matter of setting the correct MMAL_ENCODING on the input port. To ease the
> addition of further supported mmal codecs a macro is introduced to generate
> the decoder and decoder class structs.
>
> Signed-off-by: Julian Scheel 
> ---
>  configure  |  3 +++
>  libavcodec/Makefile|  1 +
>  libavcodec/allcodecs.c |  2 ++
>  libavcodec/mmaldec.c   | 71 
> +-
>  4 files changed, 53 insertions(+), 24 deletions(-)
>
> diff --git a/configure b/configure
> index 1bbaf7f..a38b290 100755
> --- a/configure
> +++ b/configure
> @@ -2481,6 +2481,9 @@ mpeg2_d3d11va_hwaccel_deps="d3d11va"
>  mpeg2_d3d11va_hwaccel_select="mpeg2video_decoder"
>  mpeg2_dxva2_hwaccel_deps="dxva2"
>  mpeg2_dxva2_hwaccel_select="mpeg2video_decoder"
> +mpeg2_mmal_decoder_deps="mmal"
> +mpeg2_mmal_hwaccel_deps="mmal"
> +mpeg2_mmal_decoder_select="mpeg2video_decoder"
>  mpeg2_qsv_hwaccel_deps="libmfx"
>  mpeg2_qsv_hwaccel_select="qsvdec_mpeg2"
>  mpeg2_vaapi_hwaccel_deps="vaapi"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index af93f8a..f85fc18 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -370,6 +370,7 @@ OBJS-$(CONFIG_MPEG1VIDEO_DECODER)  += mpeg12dec.o 
> mpeg12.o mpeg12data.o
>  OBJS-$(CONFIG_MPEG1VIDEO_ENCODER)  += mpeg12enc.o mpeg12.o
>  OBJS-$(CONFIG_MPEG2VIDEO_DECODER)  += mpeg12dec.o mpeg12.o mpeg12data.o
>  OBJS-$(CONFIG_MPEG2VIDEO_ENCODER)  += mpeg12enc.o mpeg12.o
> +OBJS-$(CONFIG_MPEG2_MMAL_DECODER)  += mmaldec.o
>  OBJS-$(CONFIG_MPEG2_QSV_DECODER)   += qsvdec_mpeg2.o
>  OBJS-$(CONFIG_MPEG2_QSV_ENCODER)   += qsvenc_mpeg2.o
>  OBJS-$(CONFIG_MPEG4_DECODER)   += xvididct.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index d62bec7..7279620 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -97,6 +97,7 @@ void avcodec_register_all(void)
>  REGISTER_HWACCEL(MPEG2_XVMC,mpeg2_xvmc);
>  REGISTER_HWACCEL(MPEG2_D3D11VA, mpeg2_d3d11va);
>  REGISTER_HWACCEL(MPEG2_DXVA2,   mpeg2_dxva2);
> +REGISTER_HWACCEL(MPEG2_MMAL,mpeg2_mmal);
>  REGISTER_HWACCEL(MPEG2_QSV, mpeg2_qsv);
>  REGISTER_HWACCEL(MPEG2_VAAPI,   mpeg2_vaapi);
>  REGISTER_HWACCEL(MPEG2_VDPAU,   mpeg2_vdpau);
> @@ -238,6 +239,7 @@ void avcodec_register_all(void)
>  REGISTER_DECODER(MPEG_VDPAU,mpeg_vdpau);
>  REGISTER_DECODER(MPEG1_VDPAU,   mpeg1_vdpau);
>  #endif
> +REGISTER_DECODER(MPEG2_MMAL,mpeg2_mmal);
>  REGISTER_DECODER(MPEG2_CRYSTALHD,   mpeg2_crystalhd);
>  REGISTER_DECODER(MPEG2_QSV, mpeg2_qsv);
>  REGISTER_DECODER(MSA1,  msa1);
> diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
> index 13cc191..7db90d2 100644
> --- a/libavcodec/mmaldec.c
> +++ b/libavcodec/mmaldec.c
> @@ -350,7 +350,17 @@ static av_cold int ffmmal_init_decoder(AVCodecContext 
> *avctx)
>
>  format_in = decoder->input[0]->format;
>  format_in->type = MMAL_ES_TYPE_VIDEO;
> -format_in->encoding = MMAL_ENCODING_H264;
> +switch (avctx->codec_id) {
> +case AV_CODEC_ID_MPEG2VIDEO:
> +format_in->encoding = MMAL_ENCODING_MP2V;
> +av_log(avctx, AV_LOG_ERROR, "Use MP2V encoding!\n");
> +break;
> +case AV_CODEC_ID_H264:
> +default:
> +format_in->encoding = MMAL_ENCODING_H264;
> +av_log(avctx, AV_LOG_ERROR, "Use H264 encoding!\n");
> +break;
> +}

These log messages are probably not meant to be in there anymore, not
as error anyway? :)

>  format_in->es->video.width = FFALIGN(avctx->width, 32);
>  format_in->es->video.height = FFALIGN(avctx->height, 16);
>  format_in->es->video.crop.width = avctx->width;
> @@ -766,31 +776,44 @@ AVHWAccel ff_h264_mmal_hwaccel = {
>  .pix_fmt= AV_PIX_FMT_MMAL,
>  };
>
> +AVHWAccel ff_mpeg2_mmal_hwaccel = {
> +.name   = "mpeg2_mmal",
> +.type   = AVMEDIA_TYPE_VIDEO,
> +.id = AV_CODEC_ID_MPEG2VIDEO,
> +.pix_fmt= AV_PIX_FMT_MMAL,
> +};
> +
>  static const AVOption options[]={
>  {"extra_buffers", "extra buffers", offsetof(MMALDecodeContext, 
> extra_buffers), AV_OPT_TYPE_INT, {.i64 = 10}, 0, 256, 0},
>  {NULL}
>  };
>
> -static const AVClass ffmmaldec_class = {
> -.class_name = "mmaldec",
> -.option = options,
> -.version= LIBAVUTIL_VERSION_INT,
> -};
> -
> -AVCodec ff_h264_mmal_decoder = {
> -.name   = "h264_mmal",
> -.long_name  = NULL_IF_CONFIG_SMALL("h264 (mmal)"),
> -.type   = AVMEDIA_TYPE_VIDEO,
> -.id = AV_CODEC_ID_H264,
> -.priv_data_size = sizeof(MMALDecodeContext),
> -.init   = ffmmal_init_decoder,
> -.close  = ffmmal_close_decoder,
> -

[FFmpeg-devel] [PATCH] mmaldec: Add mpeg2 decoding support

[Julian Scheel]

Register mmaldec as mpeg2 decoder. Supporting mpeg2 in mmaldec is just a
matter of setting the correct MMAL_ENCODING on the input port. To ease the
addition of further supported mmal codecs a macro is introduced to generate
the decoder and decoder class structs.

Signed-off-by: Julian Scheel 
---
 configure  |  3 +++
 libavcodec/Makefile|  1 +
 libavcodec/allcodecs.c |  2 ++
 libavcodec/mmaldec.c   | 71 +-
 4 files changed, 53 insertions(+), 24 deletions(-)

diff --git a/configure b/configure
index 1bbaf7f..a38b290 100755
--- a/configure
+++ b/configure
@@ -2481,6 +2481,9 @@ mpeg2_d3d11va_hwaccel_deps="d3d11va"
 mpeg2_d3d11va_hwaccel_select="mpeg2video_decoder"
 mpeg2_dxva2_hwaccel_deps="dxva2"
 mpeg2_dxva2_hwaccel_select="mpeg2video_decoder"
+mpeg2_mmal_decoder_deps="mmal"
+mpeg2_mmal_hwaccel_deps="mmal"
+mpeg2_mmal_decoder_select="mpeg2video_decoder"
 mpeg2_qsv_hwaccel_deps="libmfx"
 mpeg2_qsv_hwaccel_select="qsvdec_mpeg2"
 mpeg2_vaapi_hwaccel_deps="vaapi"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index af93f8a..f85fc18 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -370,6 +370,7 @@ OBJS-$(CONFIG_MPEG1VIDEO_DECODER)  += mpeg12dec.o 
mpeg12.o mpeg12data.o
 OBJS-$(CONFIG_MPEG1VIDEO_ENCODER)  += mpeg12enc.o mpeg12.o
 OBJS-$(CONFIG_MPEG2VIDEO_DECODER)  += mpeg12dec.o mpeg12.o mpeg12data.o
 OBJS-$(CONFIG_MPEG2VIDEO_ENCODER)  += mpeg12enc.o mpeg12.o
+OBJS-$(CONFIG_MPEG2_MMAL_DECODER)  += mmaldec.o
 OBJS-$(CONFIG_MPEG2_QSV_DECODER)   += qsvdec_mpeg2.o
 OBJS-$(CONFIG_MPEG2_QSV_ENCODER)   += qsvenc_mpeg2.o
 OBJS-$(CONFIG_MPEG4_DECODER)   += xvididct.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d62bec7..7279620 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -97,6 +97,7 @@ void avcodec_register_all(void)
 REGISTER_HWACCEL(MPEG2_XVMC,mpeg2_xvmc);
 REGISTER_HWACCEL(MPEG2_D3D11VA, mpeg2_d3d11va);
 REGISTER_HWACCEL(MPEG2_DXVA2,   mpeg2_dxva2);
+REGISTER_HWACCEL(MPEG2_MMAL,mpeg2_mmal);
 REGISTER_HWACCEL(MPEG2_QSV, mpeg2_qsv);
 REGISTER_HWACCEL(MPEG2_VAAPI,   mpeg2_vaapi);
 REGISTER_HWACCEL(MPEG2_VDPAU,   mpeg2_vdpau);
@@ -238,6 +239,7 @@ void avcodec_register_all(void)
 REGISTER_DECODER(MPEG_VDPAU,mpeg_vdpau);
 REGISTER_DECODER(MPEG1_VDPAU,   mpeg1_vdpau);
 #endif
+REGISTER_DECODER(MPEG2_MMAL,mpeg2_mmal);
 REGISTER_DECODER(MPEG2_CRYSTALHD,   mpeg2_crystalhd);
 REGISTER_DECODER(MPEG2_QSV, mpeg2_qsv);
 REGISTER_DECODER(MSA1,  msa1);
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 13cc191..7db90d2 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -350,7 +350,17 @@ static av_cold int ffmmal_init_decoder(AVCodecContext 
*avctx)
 
 format_in = decoder->input[0]->format;
 format_in->type = MMAL_ES_TYPE_VIDEO;
-format_in->encoding = MMAL_ENCODING_H264;
+switch (avctx->codec_id) {
+case AV_CODEC_ID_MPEG2VIDEO:
+format_in->encoding = MMAL_ENCODING_MP2V;
+av_log(avctx, AV_LOG_ERROR, "Use MP2V encoding!\n");
+break;
+case AV_CODEC_ID_H264:
+default:
+format_in->encoding = MMAL_ENCODING_H264;
+av_log(avctx, AV_LOG_ERROR, "Use H264 encoding!\n");
+break;
+}
 format_in->es->video.width = FFALIGN(avctx->width, 32);
 format_in->es->video.height = FFALIGN(avctx->height, 16);
 format_in->es->video.crop.width = avctx->width;
@@ -766,31 +776,44 @@ AVHWAccel ff_h264_mmal_hwaccel = {
 .pix_fmt= AV_PIX_FMT_MMAL,
 };
 
+AVHWAccel ff_mpeg2_mmal_hwaccel = {
+.name   = "mpeg2_mmal",
+.type   = AVMEDIA_TYPE_VIDEO,
+.id = AV_CODEC_ID_MPEG2VIDEO,
+.pix_fmt= AV_PIX_FMT_MMAL,
+};
+
 static const AVOption options[]={
 {"extra_buffers", "extra buffers", offsetof(MMALDecodeContext, 
extra_buffers), AV_OPT_TYPE_INT, {.i64 = 10}, 0, 256, 0},
 {NULL}
 };
 
-static const AVClass ffmmaldec_class = {
-.class_name = "mmaldec",
-.option = options,
-.version= LIBAVUTIL_VERSION_INT,
-};
-
-AVCodec ff_h264_mmal_decoder = {
-.name   = "h264_mmal",
-.long_name  = NULL_IF_CONFIG_SMALL("h264 (mmal)"),
-.type   = AVMEDIA_TYPE_VIDEO,
-.id = AV_CODEC_ID_H264,
-.priv_data_size = sizeof(MMALDecodeContext),
-.init   = ffmmal_init_decoder,
-.close  = ffmmal_close_decoder,
-.decode = ffmmal_decode,
-.flush  = ffmmal_flush,
-.priv_class = _class,
-.capabilities   = AV_CODEC_CAP_DELAY,
-.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
-.pix_fmts   = (const enum AVPixelFormat[]) { AV_PIX_FMT_MMAL,
- AV_PIX_FMT_YUV420P,
-

Re: [FFmpeg-devel] [PATCH] mmaldec: Set the output pix_fmt after detecting format

[wm4]

On Wed, 21 Oct 2015 16:07:08 +0200
Hendrik Leppkes  wrote:

> On Wed, Oct 21, 2015 at 3:55 PM, Julian Scheel  wrote:
> > Wait for the first decoded frame to be returned by mmal before setting
> > pix_fmt. This is important for avformat probing to work properly as it is 
> > one
> > of the criterions to decide whether to decode a frame or not for probing.
> >
> > Signed-off-by: Julian Scheel 
> > ---
> >  libavcodec/mmaldec.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
> > index 7db90d2..429990a 100644
> > --- a/libavcodec/mmaldec.c
> > +++ b/libavcodec/mmaldec.c
> > @@ -338,11 +338,6 @@ static av_cold int ffmmal_init_decoder(AVCodecContext 
> > *avctx)
> >  return AVERROR(ENOSYS);
> >  }
> >
> > -if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
> > -return ret;
> > -
> > -avctx->pix_fmt = ret;
> > -
> >  if ((status = 
> > mmal_component_create(MMAL_COMPONENT_DEFAULT_VIDEO_DECODER, >decoder)))
> >  goto fail;
> >
> > @@ -678,6 +673,11 @@ static int ffmmal_read_frame(AVCodecContext *avctx, 
> > AVFrame *frame, int *got_fra
> >
> >  av_log(avctx, AV_LOG_INFO, "Changing output format.\n");
> >
> > +if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
> > +return ret;
> > +
> > +avctx->pix_fmt = ret;
> > +
> >  if ((status = mmal_port_disable(decoder->output[0])))
> >  goto done;
> >  
> 
> pix_fmt is already used by the decoder before this point to decide if
> mmal surfaces or memory buffers are to be used, changing it afterwards
> will not have the same effect as doing it in init.

Oh, you're right. It's used in ffmal_update_format(), so this patch can
only work if the decoder sends MMAL_EVENT_FORMAT_CHANGED on init, or if
the entire decoding init is delayed and not done in AVCodec.init.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv2] mmaldec: Add mpeg2 decoding support

[Julian Scheel]

Register mmaldec as mpeg2 decoder. Supporting mpeg2 in mmaldec is just a
matter of setting the correct MMAL_ENCODING on the input port. To ease the
addition of further supported mmal codecs a macro is introduced to generate
the decoder and decoder class structs.

Signed-off-by: Julian Scheel 
---
Changes in v2:
- Replace error log message in init decoder with debug log message (thanks
  Hendrik for spotting it)
---
 configure  |  3 +++
 libavcodec/Makefile|  1 +
 libavcodec/allcodecs.c |  2 ++
 libavcodec/mmaldec.c   | 71 +-
 4 files changed, 53 insertions(+), 24 deletions(-)

diff --git a/configure b/configure
index 1bbaf7f..a38b290 100755
--- a/configure
+++ b/configure
@@ -2481,6 +2481,9 @@ mpeg2_d3d11va_hwaccel_deps="d3d11va"
 mpeg2_d3d11va_hwaccel_select="mpeg2video_decoder"
 mpeg2_dxva2_hwaccel_deps="dxva2"
 mpeg2_dxva2_hwaccel_select="mpeg2video_decoder"
+mpeg2_mmal_decoder_deps="mmal"
+mpeg2_mmal_hwaccel_deps="mmal"
+mpeg2_mmal_decoder_select="mpeg2video_decoder"
 mpeg2_qsv_hwaccel_deps="libmfx"
 mpeg2_qsv_hwaccel_select="qsvdec_mpeg2"
 mpeg2_vaapi_hwaccel_deps="vaapi"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index af93f8a..f85fc18 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -370,6 +370,7 @@ OBJS-$(CONFIG_MPEG1VIDEO_DECODER)  += mpeg12dec.o 
mpeg12.o mpeg12data.o
 OBJS-$(CONFIG_MPEG1VIDEO_ENCODER)  += mpeg12enc.o mpeg12.o
 OBJS-$(CONFIG_MPEG2VIDEO_DECODER)  += mpeg12dec.o mpeg12.o mpeg12data.o
 OBJS-$(CONFIG_MPEG2VIDEO_ENCODER)  += mpeg12enc.o mpeg12.o
+OBJS-$(CONFIG_MPEG2_MMAL_DECODER)  += mmaldec.o
 OBJS-$(CONFIG_MPEG2_QSV_DECODER)   += qsvdec_mpeg2.o
 OBJS-$(CONFIG_MPEG2_QSV_ENCODER)   += qsvenc_mpeg2.o
 OBJS-$(CONFIG_MPEG4_DECODER)   += xvididct.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d62bec7..7279620 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -97,6 +97,7 @@ void avcodec_register_all(void)
 REGISTER_HWACCEL(MPEG2_XVMC,mpeg2_xvmc);
 REGISTER_HWACCEL(MPEG2_D3D11VA, mpeg2_d3d11va);
 REGISTER_HWACCEL(MPEG2_DXVA2,   mpeg2_dxva2);
+REGISTER_HWACCEL(MPEG2_MMAL,mpeg2_mmal);
 REGISTER_HWACCEL(MPEG2_QSV, mpeg2_qsv);
 REGISTER_HWACCEL(MPEG2_VAAPI,   mpeg2_vaapi);
 REGISTER_HWACCEL(MPEG2_VDPAU,   mpeg2_vdpau);
@@ -238,6 +239,7 @@ void avcodec_register_all(void)
 REGISTER_DECODER(MPEG_VDPAU,mpeg_vdpau);
 REGISTER_DECODER(MPEG1_VDPAU,   mpeg1_vdpau);
 #endif
+REGISTER_DECODER(MPEG2_MMAL,mpeg2_mmal);
 REGISTER_DECODER(MPEG2_CRYSTALHD,   mpeg2_crystalhd);
 REGISTER_DECODER(MPEG2_QSV, mpeg2_qsv);
 REGISTER_DECODER(MSA1,  msa1);
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 13cc191..91fb084 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -350,7 +350,17 @@ static av_cold int ffmmal_init_decoder(AVCodecContext 
*avctx)
 
 format_in = decoder->input[0]->format;
 format_in->type = MMAL_ES_TYPE_VIDEO;
-format_in->encoding = MMAL_ENCODING_H264;
+switch (avctx->codec_id) {
+case AV_CODEC_ID_MPEG2VIDEO:
+format_in->encoding = MMAL_ENCODING_MP2V;
+av_log(avctx, AV_LOG_DEBUG, "Use MMAL MP2V encoding\n");
+break;
+case AV_CODEC_ID_H264:
+default:
+format_in->encoding = MMAL_ENCODING_H264;
+av_log(avctx, AV_LOG_DEBUG, "Use MMAL H264 encoding\n");
+break;
+}
 format_in->es->video.width = FFALIGN(avctx->width, 32);
 format_in->es->video.height = FFALIGN(avctx->height, 16);
 format_in->es->video.crop.width = avctx->width;
@@ -766,31 +776,44 @@ AVHWAccel ff_h264_mmal_hwaccel = {
 .pix_fmt= AV_PIX_FMT_MMAL,
 };
 
+AVHWAccel ff_mpeg2_mmal_hwaccel = {
+.name   = "mpeg2_mmal",
+.type   = AVMEDIA_TYPE_VIDEO,
+.id = AV_CODEC_ID_MPEG2VIDEO,
+.pix_fmt= AV_PIX_FMT_MMAL,
+};
+
 static const AVOption options[]={
 {"extra_buffers", "extra buffers", offsetof(MMALDecodeContext, 
extra_buffers), AV_OPT_TYPE_INT, {.i64 = 10}, 0, 256, 0},
 {NULL}
 };
 
-static const AVClass ffmmaldec_class = {
-.class_name = "mmaldec",
-.option = options,
-.version= LIBAVUTIL_VERSION_INT,
-};
-
-AVCodec ff_h264_mmal_decoder = {
-.name   = "h264_mmal",
-.long_name  = NULL_IF_CONFIG_SMALL("h264 (mmal)"),
-.type   = AVMEDIA_TYPE_VIDEO,
-.id = AV_CODEC_ID_H264,
-.priv_data_size = sizeof(MMALDecodeContext),
-.init   = ffmmal_init_decoder,
-.close  = ffmmal_close_decoder,
-.decode = ffmmal_decode,
-.flush  = ffmmal_flush,
-.priv_class = _class,
-.capabilities   = AV_CODEC_CAP_DELAY,
-.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
-.pix_fmts   = (const enum AVPixelFormat[]) { 

Re: [FFmpeg-devel] [PATCH] mmaldec: Add mpeg2 decoding support

[Julian Scheel]

Am 21.10.2015 um 16:09 schrieb Hendrik Leppkes:

On Wed, Oct 21, 2015 at 3:54 PM, Julian Scheel  wrote:

Register mmaldec as mpeg2 decoder. Supporting mpeg2 in mmaldec is just a
matter of setting the correct MMAL_ENCODING on the input port. To ease the
addition of further supported mmal codecs a macro is introduced to generate
the decoder and decoder class structs.

Signed-off-by: Julian Scheel 
---
  configure  |  3 +++
  libavcodec/Makefile|  1 +
  libavcodec/allcodecs.c |  2 ++
  libavcodec/mmaldec.c   | 71 +-
  4 files changed, 53 insertions(+), 24 deletions(-)

diff --git a/configure b/configure
index 1bbaf7f..a38b290 100755
--- a/configure
+++ b/configure
@@ -2481,6 +2481,9 @@ mpeg2_d3d11va_hwaccel_deps="d3d11va"
  mpeg2_d3d11va_hwaccel_select="mpeg2video_decoder"
  mpeg2_dxva2_hwaccel_deps="dxva2"
  mpeg2_dxva2_hwaccel_select="mpeg2video_decoder"
+mpeg2_mmal_decoder_deps="mmal"
+mpeg2_mmal_hwaccel_deps="mmal"
+mpeg2_mmal_decoder_select="mpeg2video_decoder"
  mpeg2_qsv_hwaccel_deps="libmfx"
  mpeg2_qsv_hwaccel_select="qsvdec_mpeg2"
  mpeg2_vaapi_hwaccel_deps="vaapi"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index af93f8a..f85fc18 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -370,6 +370,7 @@ OBJS-$(CONFIG_MPEG1VIDEO_DECODER)  += mpeg12dec.o 
mpeg12.o mpeg12data.o
  OBJS-$(CONFIG_MPEG1VIDEO_ENCODER)  += mpeg12enc.o mpeg12.o
  OBJS-$(CONFIG_MPEG2VIDEO_DECODER)  += mpeg12dec.o mpeg12.o mpeg12data.o
  OBJS-$(CONFIG_MPEG2VIDEO_ENCODER)  += mpeg12enc.o mpeg12.o
+OBJS-$(CONFIG_MPEG2_MMAL_DECODER)  += mmaldec.o
  OBJS-$(CONFIG_MPEG2_QSV_DECODER)   += qsvdec_mpeg2.o
  OBJS-$(CONFIG_MPEG2_QSV_ENCODER)   += qsvenc_mpeg2.o
  OBJS-$(CONFIG_MPEG4_DECODER)   += xvididct.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d62bec7..7279620 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -97,6 +97,7 @@ void avcodec_register_all(void)
  REGISTER_HWACCEL(MPEG2_XVMC,mpeg2_xvmc);
  REGISTER_HWACCEL(MPEG2_D3D11VA, mpeg2_d3d11va);
  REGISTER_HWACCEL(MPEG2_DXVA2,   mpeg2_dxva2);
+REGISTER_HWACCEL(MPEG2_MMAL,mpeg2_mmal);
  REGISTER_HWACCEL(MPEG2_QSV, mpeg2_qsv);
  REGISTER_HWACCEL(MPEG2_VAAPI,   mpeg2_vaapi);
  REGISTER_HWACCEL(MPEG2_VDPAU,   mpeg2_vdpau);
@@ -238,6 +239,7 @@ void avcodec_register_all(void)
  REGISTER_DECODER(MPEG_VDPAU,mpeg_vdpau);
  REGISTER_DECODER(MPEG1_VDPAU,   mpeg1_vdpau);
  #endif
+REGISTER_DECODER(MPEG2_MMAL,mpeg2_mmal);
  REGISTER_DECODER(MPEG2_CRYSTALHD,   mpeg2_crystalhd);
  REGISTER_DECODER(MPEG2_QSV, mpeg2_qsv);
  REGISTER_DECODER(MSA1,  msa1);
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 13cc191..7db90d2 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -350,7 +350,17 @@ static av_cold int ffmmal_init_decoder(AVCodecContext 
*avctx)

  format_in = decoder->input[0]->format;
  format_in->type = MMAL_ES_TYPE_VIDEO;
-format_in->encoding = MMAL_ENCODING_H264;
+switch (avctx->codec_id) {
+case AV_CODEC_ID_MPEG2VIDEO:
+format_in->encoding = MMAL_ENCODING_MP2V;
+av_log(avctx, AV_LOG_ERROR, "Use MP2V encoding!\n");
+break;
+case AV_CODEC_ID_H264:
+default:
+format_in->encoding = MMAL_ENCODING_H264;
+av_log(avctx, AV_LOG_ERROR, "Use H264 encoding!\n");
+break;
+}


These log messages are probably not meant to be in there anymore, not
as error anyway? :)


Gah, you're right of course. I'll send v2.


  format_in->es->video.width = FFALIGN(avctx->width, 32);
  format_in->es->video.height = FFALIGN(avctx->height, 16);
  format_in->es->video.crop.width = avctx->width;
@@ -766,31 +776,44 @@ AVHWAccel ff_h264_mmal_hwaccel = {
  .pix_fmt= AV_PIX_FMT_MMAL,
  };

+AVHWAccel ff_mpeg2_mmal_hwaccel = {
+.name   = "mpeg2_mmal",
+.type   = AVMEDIA_TYPE_VIDEO,
+.id = AV_CODEC_ID_MPEG2VIDEO,
+.pix_fmt= AV_PIX_FMT_MMAL,
+};
+
  static const AVOption options[]={
  {"extra_buffers", "extra buffers", offsetof(MMALDecodeContext, 
extra_buffers), AV_OPT_TYPE_INT, {.i64 = 10}, 0, 256, 0},
  {NULL}
  };

-static const AVClass ffmmaldec_class = {
-.class_name = "mmaldec",
-.option = options,
-.version= LIBAVUTIL_VERSION_INT,
-};
-
-AVCodec ff_h264_mmal_decoder = {
-.name   = "h264_mmal",
-.long_name  = NULL_IF_CONFIG_SMALL("h264 (mmal)"),
-.type   = AVMEDIA_TYPE_VIDEO,
-.id = AV_CODEC_ID_H264,
-.priv_data_size = sizeof(MMALDecodeContext),
-.init   = ffmmal_init_decoder,
-.close  = ffmmal_close_decoder,
-.decode = ffmmal_decode,
-.flush  = ffmmal_flush,
-.priv_class = 

Re: [FFmpeg-devel] [PATCH] mmaldec: Set the output pix_fmt after detecting format

[Julian Scheel]

Am 21.10.2015 um 16:18 schrieb wm4:

On Wed, 21 Oct 2015 16:07:08 +0200
Hendrik Leppkes  wrote:


On Wed, Oct 21, 2015 at 3:55 PM, Julian Scheel  wrote:

Wait for the first decoded frame to be returned by mmal before setting
pix_fmt. This is important for avformat probing to work properly as it is one
of the criterions to decide whether to decode a frame or not for probing.

Signed-off-by: Julian Scheel 
---
  libavcodec/mmaldec.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 7db90d2..429990a 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -338,11 +338,6 @@ static av_cold int ffmmal_init_decoder(AVCodecContext 
*avctx)
  return AVERROR(ENOSYS);
  }

-if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
-return ret;
-
-avctx->pix_fmt = ret;
-
  if ((status = mmal_component_create(MMAL_COMPONENT_DEFAULT_VIDEO_DECODER, 
>decoder)))
  goto fail;

@@ -678,6 +673,11 @@ static int ffmmal_read_frame(AVCodecContext *avctx, 
AVFrame *frame, int *got_fra

  av_log(avctx, AV_LOG_INFO, "Changing output format.\n");

+if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
+return ret;
+
+avctx->pix_fmt = ret;
+
  if ((status = mmal_port_disable(decoder->output[0])))
  goto done;



pix_fmt is already used by the decoder before this point to decide if
mmal surfaces or memory buffers are to be used, changing it afterwards
will not have the same effect as doing it in init.


Oh, you're right. It's used in ffmal_update_format(), so this patch can
only work if the decoder sends MMAL_EVENT_FORMAT_CHANGED on init, or if
the entire decoding init is delayed and not done in AVCodec.init.


I think it would be sufficient to query the pix_fmt via ff_get_format in 
ffmal_update_format instead of using avctx->pix_fmt. The other paramters 
should be changeable without disabling the port. But this should be 
tested probably :)
Regarding the question if MMAL_EVENT_FORMAT_CHANGED will be sent by the 
decoder in any case I have opened an issue for clarification: 
https://github.com/raspberrypi/firmware/issues/489


-Julian

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

Re: [FFmpeg-devel] [PATCH] avformat/electronicarts: support ADPCM PSX

[Peter Ross]

On Wed, Oct 21, 2015 at 11:14:02PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavformat/electronicarts.c | 19 +++
>  1 file changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
> index c0b6d6e..12eec80 100644
> --- a/libavformat/electronicarts.c
> +++ b/libavformat/electronicarts.c
> @@ -86,6 +86,8 @@ typedef struct EaDemuxContext {
>  int sample_rate;
>  int num_channels;
>  int num_samples;
> +
> +int platform;
>  } EaDemuxContext;

all looks okay
tested with psx samples

> @@ -653,7 +664,7 @@ static int ea_read_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  case SEND_TAG:
>  case SEEN_TAG:
>  while (!avio_feof(pb)) {
> -if (avio_rl32(pb)) {
> +if (avio_rl32(pb) == SCHl_TAG) {
>  avio_skip(pb, -4);
>  break;
>  }

seems unrelated to demuxing files containing ADPCM PSX audio?

also note, this case block is triggered by several different versions of 
elecontric arts files
'end audio stream tags' (SEAD, 1SNx, SCxLl). but when with this hunk applied, 
the loop only ends early
if 'SCHl_TAG' is reached.

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


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

[FFmpeg-devel] [PATCH 00/11] MXF decoder fixes/improvements.

[Alexis Ballier]

Main patch is patch 4/11 fixing 2 tickets.

Patches 5+ are not very useful by themselves but since I wrote the code
for them trying to understand the issue, I thought I'd just send them anyway.
Those can be dropped without any problem.

Alexis Ballier (11):
  libavformat/mxfdec.c: klv_read_packet: Properly check
klv_decode_ber_length return value.
  libavformat/mxfdec.c: cosmetics: Add missing space after '?' in log
message.
  libavformat/mxfdec.c: Report dark metadata keys only when they match
no parser at all, not everytime they fail to match one.
  libavformat/mxfdec.c: Try to increment current edit before rejecting a
klv that spans onto next edit unit.
  libavformat/mxfdec.c: Fix typo in named struct definition.
  libavformat/mxfdec.c: Parse source clip data_definition_ul.
  libavformat/mxfdec.c: Parse timecode component data_definition_ul and
duration.
  libavformat/mxfdec.c: Parse track position.
  libavformat/mxfdec.c: Parse index table segment slice_count.
  libavformat/mxfdec.c: Parse index table segment DeltaEntryArray.
  libavformat/mxfdec.c: Log unknown metadata tags. This should help in
seeing missing features.

 libavformat/mxfdec.c | 106 +++
 1 file changed, 98 insertions(+), 8 deletions(-)

-- 
2.6.2

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

[FFmpeg-devel] [PATCH 08/11] libavformat/mxfdec.c: Parse track position.

[Alexis Ballier]

---
 libavformat/mxfdec.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 2b776f6..5c224ef 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -161,6 +161,7 @@ typedef struct {
 int intra_only;
 uint64_t sample_count;
 int64_t original_duration; /* st->duration in SampleRate/EditRate units */
+int64_t position;
 } MXFTrack;
 
 typedef struct MXFDescriptor {
@@ -793,6 +794,9 @@ static int mxf_read_track(void *arg, AVIOContext *pb, int 
tag, int size, UID uid
 track->edit_rate.num = avio_rb32(pb);
 track->edit_rate.den = avio_rb32(pb);
 break;
+case 0x4b02:
+track->position = avio_rb64(pb);
+break;
 case 0x4803:
 avio_read(pb, track->sequence_ref, 16);
 break;
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 06/11] libavformat/mxfdec.c: Parse source clip data_definition_ul.

[Alexis Ballier]

---
 libavformat/mxfdec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index e16c678..1320fad 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -722,6 +722,9 @@ static int mxf_read_source_clip(void *arg, AVIOContext *pb, 
int tag, int size, U
 {
 MXFStructuralComponent *source_clip = arg;
 switch(tag) {
+case 0x0201:
+avio_read(pb, source_clip->data_definition_ul, 16);
+break;
 case 0x0202:
 source_clip->duration = avio_rb64(pb);
 break;
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 07/11] libavformat/mxfdec.c: Parse timecode component data_definition_ul and duration.

[Alexis Ballier]

---
 libavformat/mxfdec.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 1320fad..2b776f6 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -121,6 +121,8 @@ typedef struct MXFSequence {
 typedef struct MXFTimecodeComponent {
 UID uid;
 enum MXFMetadataSetType type;
+UID data_definition_ul;
+int64_t duration;
 int drop_frame;
 int start_frame;
 struct AVRational rate;
@@ -747,6 +749,12 @@ static int mxf_read_timecode_component(void *arg, 
AVIOContext *pb, int tag, int
 {
 MXFTimecodeComponent *mxf_timecode = arg;
 switch(tag) {
+case 0x0201:
+avio_read(pb, mxf_timecode->data_definition_ul, 16);
+break;
+case 0x0202:
+mxf_timecode->duration = avio_rb64(pb);
+break;
 case 0x1501:
 mxf_timecode->start_frame = avio_rb64(pb);
 break;
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] mmaldec: Set the output pix_fmt after detecting format

[Julian Scheel]

Am 21.10.2015 um 17:24 schrieb wm4:

On Wed, 21 Oct 2015 17:15:14 +0200
Julian Scheel  wrote:


Am 21.10.2015 um 16:18 schrieb wm4:

On Wed, 21 Oct 2015 16:07:08 +0200
Hendrik Leppkes  wrote:


On Wed, Oct 21, 2015 at 3:55 PM, Julian Scheel  wrote:

Wait for the first decoded frame to be returned by mmal before setting
pix_fmt. This is important for avformat probing to work properly as it is one
of the criterions to decide whether to decode a frame or not for probing.

Signed-off-by: Julian Scheel 
---
   libavcodec/mmaldec.c | 10 +-
   1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 7db90d2..429990a 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -338,11 +338,6 @@ static av_cold int ffmmal_init_decoder(AVCodecContext 
*avctx)
   return AVERROR(ENOSYS);
   }

-if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
-return ret;
-
-avctx->pix_fmt = ret;
-
   if ((status = mmal_component_create(MMAL_COMPONENT_DEFAULT_VIDEO_DECODER, 
>decoder)))
   goto fail;

@@ -678,6 +673,11 @@ static int ffmmal_read_frame(AVCodecContext *avctx, 
AVFrame *frame, int *got_fra

   av_log(avctx, AV_LOG_INFO, "Changing output format.\n");

+if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
+return ret;
+
+avctx->pix_fmt = ret;
+
   if ((status = mmal_port_disable(decoder->output[0])))
   goto done;



pix_fmt is already used by the decoder before this point to decide if
mmal surfaces or memory buffers are to be used, changing it afterwards
will not have the same effect as doing it in init.


Oh, you're right. It's used in ffmal_update_format(), so this patch can
only work if the decoder sends MMAL_EVENT_FORMAT_CHANGED on init, or if
the entire decoding init is delayed and not done in AVCodec.init.


I think it would be sufficient to query the pix_fmt via ff_get_format in
ffmal_update_format instead of using avctx->pix_fmt. The other paramters
should be changeable without disabling the port. But this should be
tested probably :)
Regarding the question if MMAL_EVENT_FORMAT_CHANGED will be sent by the
decoder in any case I have opened an issue for clarification:
https://github.com/raspberrypi/firmware/issues/489


ffmal_update_format() is also called in the init function. Isn't this what
you're trying to avoid?


Well yes, probably we could just skip that call. Can you possibly test 
if that works without breaking your opaque use case?


-Julian


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

[FFmpeg-devel] [PATCH 11/11] libavformat/mxfdec.c: Log unknown metadata tags. This should help in seeing missing features.

[Alexis Ballier]

---
 libavformat/mxfdec.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 020294d..606afe6 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -727,6 +727,8 @@ static int mxf_read_content_storage(void *arg, AVIOContext 
*pb, int tag, int siz
 av_log(mxf->fc, AV_LOG_VERBOSE, "Multiple packages_refs\n");
 av_free(mxf->packages_refs);
 return mxf_read_strong_ref_array(pb, >packages_refs, 
>packages_count);
+default:
+av_log(mxf->fc, AV_LOG_DEBUG, "%s: Unknown tag 0x%x\n", __FUNCTION__, 
tag);
 }
 return 0;
 }
@@ -752,6 +754,8 @@ static int mxf_read_source_clip(void *arg, AVIOContext *pb, 
int tag, int size, U
 case 0x1102:
 source_clip->source_track_id = avio_rb32(pb);
 break;
+default:
+av_log(NULL, AV_LOG_DEBUG, "%s: Unknown tag 0x%x\n", __FUNCTION__, 
tag);
 }
 return 0;
 }
@@ -775,6 +779,8 @@ static int mxf_read_timecode_component(void *arg, 
AVIOContext *pb, int tag, int
 case 0x1503:
 mxf_timecode->drop_frame = avio_r8(pb);
 break;
+default:
+av_log(NULL, AV_LOG_DEBUG, "%s: Unknown tag 0x%x\n", __FUNCTION__, 
tag);
 }
 return 0;
 }
@@ -786,6 +792,8 @@ static int mxf_read_pulldown_component(void *arg, 
AVIOContext *pb, int tag, int
 case 0x0d01:
 avio_read(pb, mxf_pulldown->input_segment_ref, 16);
 break;
+default:
+av_log(NULL, AV_LOG_DEBUG, "%s: Unknown tag 0x%x\n", __FUNCTION__, 
tag);
 }
 return 0;
 }
@@ -810,6 +818,8 @@ static int mxf_read_track(void *arg, AVIOContext *pb, int 
tag, int size, UID uid
 case 0x4803:
 avio_read(pb, track->sequence_ref, 16);
 break;
+default:
+av_log(NULL, AV_LOG_DEBUG, "%s: Unknown tag 0x%x\n", __FUNCTION__, 
tag);
 }
 return 0;
 }
@@ -830,6 +840,8 @@ static int mxf_read_sequence(void *arg, AVIOContext *pb, 
int tag, int size, UID
 case 0x1001:
 return mxf_read_strong_ref_array(pb, 
>structural_components_refs,
  
>structural_components_count);
+default:
+av_log(NULL, AV_LOG_DEBUG, "%s: Unknown tag 0x%x\n", __FUNCTION__, 
tag);
 }
 return 0;
 }
@@ -844,6 +856,8 @@ static int mxf_read_essence_group(void *arg, AVIOContext 
*pb, int tag, int size,
 case 0x0501:
 return mxf_read_strong_ref_array(pb, 
_group->structural_components_refs,
  
_group->structural_components_count);
+default:
+av_log(NULL, AV_LOG_DEBUG, "%s: Unknown tag 0x%x\n", __FUNCTION__, 
tag);
 }
 return 0;
 }
@@ -903,6 +917,8 @@ static int mxf_read_package(void *arg, AVIOContext *pb, int 
tag, int size, UID u
 case 0x4406:
 return mxf_read_strong_ref_array(pb, >comment_refs,
  >comment_count);
+default:
+av_log(NULL, AV_LOG_DEBUG, "%s: Unknown tag 0x%x\n", __FUNCTION__, 
tag);
 }
 return 0;
 }
@@ -995,6 +1011,8 @@ static int mxf_read_index_table_segment(void *arg, 
AVIOContext *pb, int tag, int
 segment->index_duration = avio_rb64(pb);
 av_log(NULL, AV_LOG_TRACE, "IndexDuration %"PRId64"\n", 
segment->index_duration);
 break;
+default:
+av_log(NULL, AV_LOG_DEBUG, "%s: Unknown tag 0x%x\n", __FUNCTION__, 
tag);
 }
 return 0;
 }
@@ -1132,6 +1150,8 @@ static int mxf_read_tagged_value(void *arg, AVIOContext 
*pb, int tag, int size,
 return mxf_read_utf16be_string(pb, size, _value->name);
 case 0x5003:
 return mxf_read_indirect_value(tagged_value, pb, size);
+default:
+av_log(NULL, AV_LOG_DEBUG, "%s: Unknown tag 0x%x\n", __FUNCTION__, 
tag);
 }
 return 0;
 }
@@ -2270,6 +2290,8 @@ static int mxf_read_identification_metadata(void *arg, 
AVIOContext *pb, int tag,
 case 0x3C0A:
 SET_UID_METADATA(pb, "uid", uid, str);
 break;
+default:
+av_log(mxf->fc, AV_LOG_DEBUG, "%s: Unknown tag 0x%x\n", __FUNCTION__, 
tag);
 }
 return 0;
 }
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 10/11] libavformat/mxfdec.c: Parse index table segment DeltaEntryArray.

[Alexis Ballier]

---
 libavformat/mxfdec.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 75858fc..020294d 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -192,6 +192,12 @@ typedef struct MXFDescriptor {
 enum AVPixelFormat pix_fmt;
 } MXFDescriptor;
 
+typedef struct MXFDeltaEntry {
+int8_t pos_table_index;
+uint8_t slice;
+uint32_t element_delta;
+} MXFDeltaEntry;
+
 typedef struct MXFIndexTableSegment {
 UID uid;
 enum MXFMetadataSetType type;
@@ -206,6 +212,8 @@ typedef struct MXFIndexTableSegment {
 int *flag_entries;
 uint64_t *stream_offset_entries;
 int nb_index_entries;
+uint32_t nb_delta_entries;
+MXFDeltaEntry* delta_entry_array;
 } MXFIndexTableSegment;
 
 typedef struct MXFPackage {
@@ -333,6 +341,7 @@ static void mxf_free_metadataset(MXFMetadataSet **ctx, int 
freectx)
 av_freep(>temporal_offset_entries);
 av_freep(>flag_entries);
 av_freep(>stream_offset_entries);
+av_freep(>delta_entry_array);
 default:
 break;
 }
@@ -924,6 +933,28 @@ static int mxf_read_index_entry_array(AVIOContext *pb, 
MXFIndexTableSegment *seg
 return 0;
 }
 
+static int mxf_read_delta_entry_array(AVIOContext *pb, MXFIndexTableSegment 
*segment)
+{
+uint32_t length;
+unsigned int i;
+
+segment->nb_delta_entries = avio_rb32(pb);
+
+length = avio_rb32(pb);
+
+if (!(segment->delta_entry_array = av_calloc(segment->nb_delta_entries, 
sizeof(*segment->delta_entry_array
+return AVERROR(ENOMEM);
+
+for (i = 0; i < segment->nb_delta_entries; i++) {
+segment->delta_entry_array[i].pos_table_index = avio_r8(pb);
+segment->delta_entry_array[i].slice   = avio_r8(pb);
+segment->delta_entry_array[i].element_delta   = avio_rb32(pb);
+avio_skip(pb, length - 6);
+}
+
+return 0;
+}
+
 static int mxf_read_index_table_segment(void *arg, AVIOContext *pb, int tag, 
int size, UID uid, int64_t klv_offset)
 {
 MXFIndexTableSegment *segment = arg;
@@ -944,6 +975,9 @@ static int mxf_read_index_table_segment(void *arg, 
AVIOContext *pb, int tag, int
 segment->slice_count = avio_r8(pb);
 av_log(NULL, AV_LOG_TRACE, "Slice Count %u\n", segment->slice_count);
 break;
+case 0x3F09:
+av_log(NULL, AV_LOG_TRACE, "DeltaEntryArray found\n");
+return mxf_read_delta_entry_array(pb, segment);
 case 0x3F0A:
 av_log(NULL, AV_LOG_TRACE, "IndexEntryArray found\n");
 return mxf_read_index_entry_array(pb, segment);
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 09/11] libavformat/mxfdec.c: Parse index table segment slice_count.

[Alexis Ballier]

---
 libavformat/mxfdec.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 5c224ef..75858fc 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -198,6 +198,7 @@ typedef struct MXFIndexTableSegment {
 int edit_unit_byte_count;
 int index_sid;
 int body_sid;
+uint8_t slice_count;
 AVRational index_edit_rate;
 uint64_t index_start_position;
 uint64_t index_duration;
@@ -939,6 +940,10 @@ static int mxf_read_index_table_segment(void *arg, 
AVIOContext *pb, int tag, int
 segment->body_sid = avio_rb32(pb);
 av_log(NULL, AV_LOG_TRACE, "BodySID %d\n", segment->body_sid);
 break;
+case 0x3F08:
+segment->slice_count = avio_r8(pb);
+av_log(NULL, AV_LOG_TRACE, "Slice Count %u\n", segment->slice_count);
+break;
 case 0x3F0A:
 av_log(NULL, AV_LOG_TRACE, "IndexEntryArray found\n");
 return mxf_read_index_entry_array(pb, segment);
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 01/11] libavformat/mxfdec.c: klv_read_packet: Properly check klv_decode_ber_length return value.

[Alexis Ballier]

klv_decode_ber_length cannot return -1, but can return AVERROR_INVALIDDATA.
Store its return value in a signed integer (instead of unsigned 
KLVPacket.length) and forward the error appropriately.
---
 libavformat/mxfdec.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 00d420b..94a953b 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -366,13 +366,15 @@ static int mxf_read_sync(AVIOContext *pb, const uint8_t 
*key, unsigned size)
 
 static int klv_read_packet(KLVPacket *klv, AVIOContext *pb)
 {
+int64_t len;
 if (!mxf_read_sync(pb, mxf_klv_key, 4))
 return AVERROR_INVALIDDATA;
 klv->offset = avio_tell(pb) - 4;
 memcpy(klv->key, mxf_klv_key, 4);
 avio_read(pb, klv->key + 4, 12);
-klv->length = klv_decode_ber_length(pb);
-return klv->length == -1 ? -1 : 0;
+len = klv_decode_ber_length(pb);
+klv->length = FFMAX(len, 0);
+return FFMIN(len, 0);
 }
 
 static int mxf_get_stream_index(AVFormatContext *s, KLVPacket *klv)
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 02/11] libavformat/mxfdec.c: cosmetics: Add missing space after '?' in log message.

[Alexis Ballier]

---
 libavformat/mxfdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 94a953b..0ae7ce6 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2959,7 +2959,7 @@ static int mxf_read_packet_old(AVFormatContext *s, 
AVPacket *pkt)
 /* if this check is hit then it's possible OPAtom was treated 
as OP1a
  * truncate the packet since it's probably very large (>2 GiB 
is common) */
 avpriv_request_sample(s,
-  "OPAtom misinterpreted as OP1a?"
+  "OPAtom misinterpreted as OP1a? "
   "KLV for edit unit %i extending into "
   "next edit unit",
   mxf->current_edit_unit);
-- 
2.6.2

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

Re: [FFmpeg-devel] forcing ints to be 64 bits, possible new FATE client idea

[James Darnley]

On 2015-10-21 12:18, wm4 wrote:
> with size_t/ptrdiff_t
> being 128 bit, and a new "long long long int" type (I swear, they will
> do it, even if that type name looks horrible).

Please no!  Just require a C99 style uint128_t/int128_t type.



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

Re: [FFmpeg-devel] forcing ints to be 64 bits, possible new FATE client idea

[James Darnley]

On 2015-10-21 14:44, Clément Bœsch wrote:
> On Wed, Oct 21, 2015 at 06:00:21AM -0400, Ganesh Ajjanagadde wrote:
> [...]
>> why don't you spend 5 minutes trying to outline to beginners like me
>> what is "actually important" in your view?
>>
> 
> According to the first 100 answers of the survey, the majority of the
> users want... speed optimisation above anything. I can't give more info
> for now, I'll need to pay to get the stats taking into account all votes.

I know you just said you can't give more detail but can I ask this: did
these people asking for more speed say where they want it?




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

[FFmpeg-devel] [PATCH 05/11] libavformat/mxfdec.c: Fix typo in named struct definition.

[Alexis Ballier]

typedef struct MXFTrack { ... } MXFTimecodeComponent; -> typedef struct 
MXFTimecodeComponent { ... } MXFTimecodeComponent;
---
 libavformat/mxfdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 526eca6..e16c678 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -118,7 +118,7 @@ typedef struct MXFSequence {
 uint8_t origin;
 } MXFSequence;
 
-typedef struct MXFTrack {
+typedef struct MXFTimecodeComponent {
 UID uid;
 enum MXFMetadataSetType type;
 int drop_frame;
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 04/11] libavformat/mxfdec.c: Try to increment current edit before rejecting a klv that spans onto next edit unit.

[Alexis Ballier]

Some files such as those from tickets #2817 & #2776 claim to have constant edit 
unit size but,
in fact, have some of them that are smaller. This confuses the demuxer that 
tries to infer the
current edit unit from the position in the file. By trying to increment the 
current edit unit
before rejecting the packet for this reason, we try to make it fit into its 
proper edit unit,
which fixes demuxing of those files while preserving the check for misprobed
OpAtom files.
Seeking is not accurate but the files provide no way to properly find the 
relevant edit unit.

Fixes tickets #2817 & #2776.
---
 libavformat/mxfdec.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 593604e..526eca6 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2956,6 +2956,18 @@ static int mxf_read_packet_old(AVFormatContext *s, 
AVPacket *pkt)
 next_ofs = mxf_set_current_edit_unit(mxf, klv.offset);
 
 if (next_ofs >= 0 && next_klv > next_ofs) {
+/* Samples from tickets #2817 and #2776 claim to have
+ * constant edit unit size. However, some of them are smaller.
+ * Just after those smaller edit units, klv.offset is still in
+ * the same edit unit according to the computations from the
+ * constant edit unit size. If the klv finishes after, the next
+ * check would truncate the packet and prevent proper demuxing.
+ * Try to increment the current edit unit before doing that. */
+mxf->current_edit_unit++;
+next_ofs = mxf_set_current_edit_unit(mxf, klv.offset);
+}
+
+if (next_ofs >= 0 && next_klv > next_ofs) {
 /* if this check is hit then it's possible OPAtom was treated 
as OP1a
  * truncate the packet since it's probably very large (>2 GiB 
is common) */
 avpriv_request_sample(s,
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 03/11] libavformat/mxfdec.c: Report dark metadata keys only when they match no parser at all, not everytime they fail to match one.

[Alexis Ballier]

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

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 0ae7ce6..593604e 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2767,13 +2767,13 @@ static int mxf_read_header(AVFormatContext *s)
 if ((ret = mxf_parse_klv(mxf, klv, metadata->read, 
metadata->ctx_size, metadata->type)) < 0)
 goto fail;
 break;
-} else {
-av_log(s, AV_LOG_VERBOSE, "Dark key " PRIxUID "\n",
-   UID_ARG(klv.key));
 }
 }
-if (!metadata->read)
+if (!metadata->read) {
+av_log(s, AV_LOG_VERBOSE, "Dark key " PRIxUID "\n",
+UID_ARG(klv.key));
 avio_skip(s->pb, klv.length);
+}
 }
 /* FIXME avoid seek */
 if (!essence_offset)  {
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] mmaldec: Set the output pix_fmt after detecting format

[Hendrik Leppkes]

On Wed, Oct 21, 2015 at 3:55 PM, Julian Scheel  wrote:
> Wait for the first decoded frame to be returned by mmal before setting
> pix_fmt. This is important for avformat probing to work properly as it is one
> of the criterions to decide whether to decode a frame or not for probing.
>
> Signed-off-by: Julian Scheel 
> ---
>  libavcodec/mmaldec.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
> index 7db90d2..429990a 100644
> --- a/libavcodec/mmaldec.c
> +++ b/libavcodec/mmaldec.c
> @@ -338,11 +338,6 @@ static av_cold int ffmmal_init_decoder(AVCodecContext 
> *avctx)
>  return AVERROR(ENOSYS);
>  }
>
> -if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
> -return ret;
> -
> -avctx->pix_fmt = ret;
> -
>  if ((status = 
> mmal_component_create(MMAL_COMPONENT_DEFAULT_VIDEO_DECODER, >decoder)))
>  goto fail;
>
> @@ -678,6 +673,11 @@ static int ffmmal_read_frame(AVCodecContext *avctx, 
> AVFrame *frame, int *got_fra
>
>  av_log(avctx, AV_LOG_INFO, "Changing output format.\n");
>
> +if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
> +return ret;
> +
> +avctx->pix_fmt = ret;
> +
>  if ((status = mmal_port_disable(decoder->output[0])))
>  goto done;
>

pix_fmt is already used by the decoder before this point to decide if
mmal surfaces or memory buffers are to be used, changing it afterwards
will not have the same effect as doing it in init.

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

Re: [FFmpeg-devel] [PATCH] mmaldec: Set the output pix_fmt after detecting format

[wm4]

On Wed, 21 Oct 2015 17:15:14 +0200
Julian Scheel  wrote:

> Am 21.10.2015 um 16:18 schrieb wm4:
> > On Wed, 21 Oct 2015 16:07:08 +0200
> > Hendrik Leppkes  wrote:
> >  
> >> On Wed, Oct 21, 2015 at 3:55 PM, Julian Scheel  wrote:  
> >>> Wait for the first decoded frame to be returned by mmal before setting
> >>> pix_fmt. This is important for avformat probing to work properly as it is 
> >>> one
> >>> of the criterions to decide whether to decode a frame or not for probing.
> >>>
> >>> Signed-off-by: Julian Scheel 
> >>> ---
> >>>   libavcodec/mmaldec.c | 10 +-
> >>>   1 file changed, 5 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
> >>> index 7db90d2..429990a 100644
> >>> --- a/libavcodec/mmaldec.c
> >>> +++ b/libavcodec/mmaldec.c
> >>> @@ -338,11 +338,6 @@ static av_cold int 
> >>> ffmmal_init_decoder(AVCodecContext *avctx)
> >>>   return AVERROR(ENOSYS);
> >>>   }
> >>>
> >>> -if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
> >>> -return ret;
> >>> -
> >>> -avctx->pix_fmt = ret;
> >>> -
> >>>   if ((status = 
> >>> mmal_component_create(MMAL_COMPONENT_DEFAULT_VIDEO_DECODER, 
> >>> >decoder)))
> >>>   goto fail;
> >>>
> >>> @@ -678,6 +673,11 @@ static int ffmmal_read_frame(AVCodecContext *avctx, 
> >>> AVFrame *frame, int *got_fra
> >>>
> >>>   av_log(avctx, AV_LOG_INFO, "Changing output format.\n");
> >>>
> >>> +if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
> >>> +return ret;
> >>> +
> >>> +avctx->pix_fmt = ret;
> >>> +
> >>>   if ((status = mmal_port_disable(decoder->output[0])))
> >>>   goto done;
> >>>  
> >>
> >> pix_fmt is already used by the decoder before this point to decide if
> >> mmal surfaces or memory buffers are to be used, changing it afterwards
> >> will not have the same effect as doing it in init.  
> >
> > Oh, you're right. It's used in ffmal_update_format(), so this patch can
> > only work if the decoder sends MMAL_EVENT_FORMAT_CHANGED on init, or if
> > the entire decoding init is delayed and not done in AVCodec.init.  
> 
> I think it would be sufficient to query the pix_fmt via ff_get_format in 
> ffmal_update_format instead of using avctx->pix_fmt. The other paramters 
> should be changeable without disabling the port. But this should be 
> tested probably :)
> Regarding the question if MMAL_EVENT_FORMAT_CHANGED will be sent by the 
> decoder in any case I have opened an issue for clarification: 
> https://github.com/raspberrypi/firmware/issues/489

ffmal_update_format() is also called in the init function. Isn't this what
you're trying to avoid?


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

Re: [FFmpeg-devel] [PATCH] vc1dsp: Port ff_vc1_put_ver_16b_shift2_mmx to yasm

[Christophe Gisquet]

Hi,

2015-10-18 2:47 GMT+02:00 Timothy Gu :
> This function is only used within other inline asm functions, hence the
> HAVE_MMX_INLINE guard. Per recent discussions, we should not worry about
> the performance of inline asm-only builds.

On a quick glance, looks good.

> The conversion process has to start _somewhere_...

True.

> +.loop:
> +movh   m2, [srcq]
> +add  srcq, strideq
> +movh   m3, [srcq]
> +punpcklbw  m2, m0
> +punpcklbw  m3, m0
> +SHIFT2_LINE 0, 1, 2, 3, 4
> +SHIFT2_LINE24, 2, 3, 4, 1
> +SHIFT2_LINE48, 3, 4, 1, 2
> +SHIFT2_LINE72, 4, 1, 2, 3
> +SHIFT2_LINE96, 1, 2, 3, 4
> +SHIFT2_LINE   120, 2, 3, 4, 1
> +SHIFT2_LINE   144, 3, 4, 1, 2
> +SHIFT2_LINE   168, 4, 1, 2, 3
> +sub  srcq, stride_9minus4
> +add  dstq, 8
> +dec i
> +jnz .loop

The following remarks are for potential later work and food for thought.

I'm the first offender, but that loop expands to ~100 instructions. I
don't know what others may have as an opinion on this, but that might
be a tad bit. So maybe specializing for particular shift and round
values (if possible, I don't remember) would be better.

Then there's the fact the 16-wide blocks are currently handled as 2x8
(iirc), that would suggest doing part of this in C.

On the other hand, idcts are not yet implemented, and there are h/w
decoders doing a better job of decoding vc1, so it may be a waste of
time (hence why I myself never did all of this).

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

Re: [FFmpeg-devel] [PATCH] mmaldec: Set the output pix_fmt after detecting format

[wm4]

On Wed, 21 Oct 2015 18:48:42 +0200
Julian Scheel  wrote:

> Am 21.10.2015 um 17:24 schrieb wm4:
> > On Wed, 21 Oct 2015 17:15:14 +0200
> > Julian Scheel  wrote:
> >  
> >> Am 21.10.2015 um 16:18 schrieb wm4:  
> >>> On Wed, 21 Oct 2015 16:07:08 +0200
> >>> Hendrik Leppkes  wrote:
> >>>  
>  On Wed, Oct 21, 2015 at 3:55 PM, Julian Scheel  wrote:  
> > Wait for the first decoded frame to be returned by mmal before setting
> > pix_fmt. This is important for avformat probing to work properly as it 
> > is one
> > of the criterions to decide whether to decode a frame or not for 
> > probing.
> >
> > Signed-off-by: Julian Scheel 
> > ---
> >libavcodec/mmaldec.c | 10 +-
> >1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
> > index 7db90d2..429990a 100644
> > --- a/libavcodec/mmaldec.c
> > +++ b/libavcodec/mmaldec.c
> > @@ -338,11 +338,6 @@ static av_cold int 
> > ffmmal_init_decoder(AVCodecContext *avctx)
> >return AVERROR(ENOSYS);
> >}
> >
> > -if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
> > -return ret;
> > -
> > -avctx->pix_fmt = ret;
> > -
> >if ((status = 
> > mmal_component_create(MMAL_COMPONENT_DEFAULT_VIDEO_DECODER, 
> > >decoder)))
> >goto fail;
> >
> > @@ -678,6 +673,11 @@ static int ffmmal_read_frame(AVCodecContext 
> > *avctx, AVFrame *frame, int *got_fra
> >
> >av_log(avctx, AV_LOG_INFO, "Changing output format.\n");
> >
> > +if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 
> > 0)
> > +return ret;
> > +
> > +avctx->pix_fmt = ret;
> > +
> >if ((status = mmal_port_disable(decoder->output[0])))
> >goto done;
> >  
> 
>  pix_fmt is already used by the decoder before this point to decide if
>  mmal surfaces or memory buffers are to be used, changing it afterwards
>  will not have the same effect as doing it in init.  
> >>>
> >>> Oh, you're right. It's used in ffmal_update_format(), so this patch can
> >>> only work if the decoder sends MMAL_EVENT_FORMAT_CHANGED on init, or if
> >>> the entire decoding init is delayed and not done in AVCodec.init.  
> >>
> >> I think it would be sufficient to query the pix_fmt via ff_get_format in
> >> ffmal_update_format instead of using avctx->pix_fmt. The other paramters
> >> should be changeable without disabling the port. But this should be
> >> tested probably :)
> >> Regarding the question if MMAL_EVENT_FORMAT_CHANGED will be sent by the
> >> decoder in any case I have opened an issue for clarification:
> >> https://github.com/raspberrypi/firmware/issues/489  
> >
> > ffmal_update_format() is also called in the init function. Isn't this what
> > you're trying to avoid?  
> 
> Well yes, probably we could just skip that call. Can you possibly test 
> if that works without breaking your opaque use case?

It's needed for decoder init.

But I'm pretty sure it'd work for me if decoder init were delayed until
the first AVCodec.decode/ffmmal_decode call. (But I'd resist if the
first init were to happen any time later - makes it harder to fallback
to software decoding if mmal doesn't work.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mmaldec: Set the output pix_fmt after detecting format

[Julian Scheel]

On 21.10.15 19:11, wm4 wrote:

On Wed, 21 Oct 2015 18:48:42 +0200
Julian Scheel  wrote:


Am 21.10.2015 um 17:24 schrieb wm4:

On Wed, 21 Oct 2015 17:15:14 +0200
Julian Scheel  wrote:


Am 21.10.2015 um 16:18 schrieb wm4:

On Wed, 21 Oct 2015 16:07:08 +0200
Hendrik Leppkes  wrote:


On Wed, Oct 21, 2015 at 3:55 PM, Julian Scheel  wrote:

Wait for the first decoded frame to be returned by mmal before setting
pix_fmt. This is important for avformat probing to work properly as it is one
of the criterions to decide whether to decode a frame or not for probing.

Signed-off-by: Julian Scheel 
---
libavcodec/mmaldec.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 7db90d2..429990a 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -338,11 +338,6 @@ static av_cold int ffmmal_init_decoder(AVCodecContext 
*avctx)
return AVERROR(ENOSYS);
}

-if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
-return ret;
-
-avctx->pix_fmt = ret;
-
if ((status = mmal_component_create(MMAL_COMPONENT_DEFAULT_VIDEO_DECODER, 
>decoder)))
goto fail;

@@ -678,6 +673,11 @@ static int ffmmal_read_frame(AVCodecContext *avctx, 
AVFrame *frame, int *got_fra

av_log(avctx, AV_LOG_INFO, "Changing output format.\n");

+if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
+return ret;
+
+avctx->pix_fmt = ret;
+
if ((status = mmal_port_disable(decoder->output[0])))
goto done;



pix_fmt is already used by the decoder before this point to decide if
mmal surfaces or memory buffers are to be used, changing it afterwards
will not have the same effect as doing it in init.


Oh, you're right. It's used in ffmal_update_format(), so this patch can
only work if the decoder sends MMAL_EVENT_FORMAT_CHANGED on init, or if
the entire decoding init is delayed and not done in AVCodec.init.


I think it would be sufficient to query the pix_fmt via ff_get_format in
ffmal_update_format instead of using avctx->pix_fmt. The other paramters
should be changeable without disabling the port. But this should be
tested probably :)
Regarding the question if MMAL_EVENT_FORMAT_CHANGED will be sent by the
decoder in any case I have opened an issue for clarification:
https://github.com/raspberrypi/firmware/issues/489


ffmal_update_format() is also called in the init function. Isn't this what
you're trying to avoid?


Well yes, probably we could just skip that call. Can you possibly test
if that works without breaking your opaque use case?


It's needed for decoder init.


Right, a part of it is needed.


But I'm pretty sure it'd work for me if decoder init were delayed until
the first AVCodec.decode/ffmmal_decode call. (But I'd resist if the
first init were to happen any time later - makes it harder to fallback
to software decoding if mmal doesn't work.)


That should be ok. I should be able to test that tomorrow.

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_ssim: Add support for writing stats to stdout

[Paul B Mahol]

On 10/21/15, Tobias Rapp  wrote:
> Analogous to my previous patch to vf_psnr.c the attached patch
> implements writing SSIM frame stats to standard output if the filename
> is "-".
>
> Regards,
> Tobias
>

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

Re: [FFmpeg-devel] Encoding with QSV at an API level.

[Paul Knopf]

I just realized that I was also getting an error on the stdout.

[h264_qsv @ 00c7e6d8e680] Specified pixel format yuv420p is
invalid or not supported


On Wed, Oct 21, 2015 at 3:13 PM, Paul Knopf 
wrote:

> Hey guys,
>
> Is there an example somewhere, using the "h264_qsv" encoder at an API
> level?
>
> Let's say I have an application that encodes and muxes a file to mp4,
> using libx264. Is it possible to just switch encoders? Will other things
> have to change, like pixel formats?
>
> I switched the encoders just like this.
>
> // old (libx264)
> //AVCodec* codec = avcodec_find_encoder(AV_CODEC_ID_H264);
> // new (Intel Quick Sync)
> AVCodec* codec = avcodec_find_encoder_by_name("h264_qsv");
>
>
> However, when calling avcodec_encode_video2,I get an access violation.
>
> Am I doing this wrong?
>
> I posted by question on StackOverflow as well for better visibility.
>
> http://stackoverflow.com/questions/33267213/ffmpeg-encoding-with-intel-quick-sync-throwing-access-violation-reading-locati
>
> --
> Thanks!
>
> ~Paul
>



-- 
Thanks!

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

[FFmpeg-devel] Encoding with QSV at an API level.

[Paul Knopf]

Hey guys,

Is there an example somewhere, using the "h264_qsv" encoder at an API level?

Let's say I have an application that encodes and muxes a file to mp4, using
libx264. Is it possible to just switch encoders? Will other things have to
change, like pixel formats?

I switched the encoders just like this.

// old (libx264)
//AVCodec* codec = avcodec_find_encoder(AV_CODEC_ID_H264);
// new (Intel Quick Sync)
AVCodec* codec = avcodec_find_encoder_by_name("h264_qsv");


However, when calling avcodec_encode_video2,I get an access violation.

Am I doing this wrong?

I posted by question on StackOverflow as well for better visibility.
http://stackoverflow.com/questions/33267213/ffmpeg-encoding-with-intel-quick-sync-throwing-access-violation-reading-locati

-- 
Thanks!

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

Re: [FFmpeg-devel] [PATCH] huffyuvencdsp: Add ff_diff_bytes_{sse2, avx2}

[Timothy Gu]

On Wed, Oct 21, 2015 at 10:32 AM Timothy Gu  wrote:

> On Tue, Oct 20, 2015 at 7:36 PM James Almer  wrote:
>
>> On 10/20/2015 10:32 PM, Timothy Gu wrote:
>>
> > +; mov type used for src1q, dstq, first reg, second reg
>> > +%macro DIFF_BYTES_LOOP_CORE 4
>> > +%if regsize != 16
>>
>> %if mmsize != 16
>>
>> By checking regsize you're using the SSE2 version in the AVX2 xmm loop.
>> Check
>> for mmsize instead, which it's always 32 since you used INIT_YMM.
>>
>
> Fixed locally.
>

Reviewed by Henrik on IRC and pushed.

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_ssim: Add support for writing stats to stdout

[Michael Niedermayer]

On Wed, Oct 21, 2015 at 09:35:39PM +0200, Paul B Mahol wrote:
> On 10/21/15, Tobias Rapp  wrote:
> > Analogous to my previous patch to vf_psnr.c the attached patch
> > implements writing SSIM frame stats to standard output if the filename
> > is "-".
> >
> > Regards,
> > Tobias
> >
> 
> lgtm

applied

thanks

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

It is what and why we do it that matters, not just one of them.


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

Re: [FFmpeg-devel] [PATCH 02/11] libavformat/mxfdec.c: cosmetics: Add missing space after '?' in log message.

[Tomas Härdin]

On Wed, 2015-10-21 at 18:00 +0200, Alexis Ballier wrote:
> ---
>  libavformat/mxfdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 94a953b..0ae7ce6 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -2959,7 +2959,7 @@ static int mxf_read_packet_old(AVFormatContext *s, 
> AVPacket *pkt)
>  /* if this check is hit then it's possible OPAtom was 
> treated as OP1a
>   * truncate the packet since it's probably very large (>2 
> GiB is common) */
>  avpriv_request_sample(s,
> -  "OPAtom misinterpreted as OP1a?"
> +  "OPAtom misinterpreted as OP1a? "
>"KLV for edit unit %i extending into "
>"next edit unit",
>mxf->current_edit_unit);

Obviously fine

/Tomas


signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Encoding with QSV at an API level.

[Hendrik Leppkes]

On Wed, Oct 21, 2015 at 9:42 PM, Paul Knopf  wrote:
> I just realized that I was also getting an error on the stdout.
>
> [h264_qsv @ 00c7e6d8e680] Specified pixel format yuv420p is
> invalid or not supported
>

Which probably means you also get an error return from one of the
initialization functions which you didn't check.
In any case, QSV encoding wants NV12 video, not YUV420P.

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

[FFmpeg-devel] [PATCH] avformat/electronicarts: support ADPCM PSX

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavformat/electronicarts.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
index c0b6d6e..12eec80 100644
--- a/libavformat/electronicarts.c
+++ b/libavformat/electronicarts.c
@@ -86,6 +86,8 @@ typedef struct EaDemuxContext {
 int sample_rate;
 int num_channels;
 int num_samples;
+
+int platform;
 } EaDemuxContext;
 
 static uint32_t read_arbitrary(AVIOContext *pb)
@@ -255,6 +257,8 @@ static int process_audio_header_elements(AVFormatContext *s)
 return 0;
 }
 
+if (ea->audio_codec == AV_CODEC_ID_NONE && ea->platform == 0x01)
+ea->audio_codec = AV_CODEC_ID_ADPCM_PSX;
 if (ea->sample_rate == -1)
 ea->sample_rate = revision == 3 ? 48000 : 22050;
 
@@ -387,10 +391,10 @@ static int process_ea_header(AVFormatContext *s)
 blockid = avio_rl32(pb);
 if (blockid == GSTR_TAG) {
 avio_skip(pb, 4);
-} else if ((blockid & 0x) != PT00_TAG) {
-avpriv_request_sample(s, "unknown SCHl headerid");
-return 0;
+} else if ((blockid & 0xFF) != (PT00_TAG & 0xFF)) {
+blockid = avio_rl32(pb);
 }
+ea->platform = (blockid >> 16) & 0xFF;
 err = process_audio_header_elements(s);
 break;
 
@@ -600,6 +604,10 @@ static int ea_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 num_samples = avio_rl32(pb);
 avio_skip(pb, 8);
 chunk_size -= 12;
+} else if (ea->audio_codec == AV_CODEC_ID_ADPCM_PSX) {
+num_samples = avio_rl32(pb);
+avio_skip(pb, 4);
+chunk_size -= 8;
 }
 
 if (partial_packet) {
@@ -639,6 +647,9 @@ static int ea_read_packet(AVFormatContext *s, AVPacket *pkt)
 case AV_CODEC_ID_MP3:
 pkt->duration = num_samples;
 break;
+case AV_CODEC_ID_ADPCM_PSX:
+pkt->duration = chunk_size / (16 * ea->num_channels) * 28;
+break;
 default:
 pkt->duration = chunk_size / (ea->bytes * ea->num_channels);
 }
@@ -653,7 +664,7 @@ static int ea_read_packet(AVFormatContext *s, AVPacket *pkt)
 case SEND_TAG:
 case SEEN_TAG:
 while (!avio_feof(pb)) {
-if (avio_rl32(pb)) {
+if (avio_rl32(pb) == SCHl_TAG) {
 avio_skip(pb, -4);
 break;
 }
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH 01/11] libavformat/mxfdec.c: klv_read_packet: Properly check klv_decode_ber_length return value.

[Tomas Härdin]

On Wed, 2015-10-21 at 18:00 +0200, Alexis Ballier wrote:
> klv_decode_ber_length cannot return -1, but can return AVERROR_INVALIDDATA.
> Store its return value in a signed integer (instead of unsigned 
> KLVPacket.length) and forward the error appropriately.
> ---
>  libavformat/mxfdec.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 00d420b..94a953b 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -366,13 +366,15 @@ static int mxf_read_sync(AVIOContext *pb, const uint8_t 
> *key, unsigned size)
>  
>  static int klv_read_packet(KLVPacket *klv, AVIOContext *pb)
>  {
> +int64_t len;
>  if (!mxf_read_sync(pb, mxf_klv_key, 4))
>  return AVERROR_INVALIDDATA;
>  klv->offset = avio_tell(pb) - 4;
>  memcpy(klv->key, mxf_klv_key, 4);
>  avio_read(pb, klv->key + 4, 12);
> -klv->length = klv_decode_ber_length(pb);
> -return klv->length == -1 ? -1 : 0;
> +len = klv_decode_ber_length(pb);
> +klv->length = FFMAX(len, 0);
> +return FFMIN(len, 0);
>  }

Can't klv_read_packet() return int64_t instead?

/Tomas


signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 04/11] libavformat/mxfdec.c: Try to increment current edit before rejecting a klv that spans onto next edit unit.

[Tomas Härdin]

On Wed, 2015-10-21 at 18:00 +0200, Alexis Ballier wrote:
> Some files such as those from tickets #2817 & #2776 claim to have constant 
> edit unit size but,
> in fact, have some of them that are smaller. This confuses the demuxer that 
> tries to infer the
> current edit unit from the position in the file. By trying to increment the 
> current edit unit
> before rejecting the packet for this reason, we try to make it fit into its 
> proper edit unit,
> which fixes demuxing of those files while preserving the check for misprobed
> OpAtom files.
> Seeking is not accurate but the files provide no way to properly find the 
> relevant edit unit.
> 
> Fixes tickets #2817 & #2776.
> ---
>  libavformat/mxfdec.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 593604e..526eca6 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -2956,6 +2956,18 @@ static int mxf_read_packet_old(AVFormatContext *s, 
> AVPacket *pkt)
>  next_ofs = mxf_set_current_edit_unit(mxf, klv.offset);
>  
>  if (next_ofs >= 0 && next_klv > next_ofs) {
> +/* Samples from tickets #2817 and #2776 claim to have
> + * constant edit unit size. However, some of them are 
> smaller.

What does "them" refer to here? The edit units or the KLVs?

> + * Just after those smaller edit units,

Right, the edit units. Maybe rework the grammar slightly.

> + * Just after those smaller edit units, klv.offset is still 
> in
> + * the same edit unit according to the computations from the
> + * constant edit unit size. If the klv finishes after, the 
> next
> + * check would truncate the packet and prevent proper 
> demuxing.
> + * Try to increment the current edit unit before doing that. 
> */

Let's see if I understand this correctly. For say EUBC = 10, there can
still be KLVs that are some size larger than 10, but smaller than 2*EUBC
= 20? So that the next edit unit would extend past the end of the KLV,
and thus be bogus?

  KLV: |header|---|header|--|
Edit unit:|0123456789|bogus<10|  |0123456789|bgs|

IIRC with MXF the bogus parts should still count as part of the essence
stream. Maybe I'm missing something.

> +mxf->current_edit_unit++;
> +next_ofs = mxf_set_current_edit_unit(mxf, klv.offset);

I feel like this should be more of an explicit check, else maybe it can
miss edit units for some corner cases?

Hm-hm.. I'm noticing I'm very confused. This is very typical of MXF.
I'll take another look at this in the morning.

/Tomas


signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] libavformat/mxfenc.c: Fix segfault when writing an audio packet when there has not been a video one.

[Tomas Härdin]

On Tue, 2015-10-20 at 16:43 +0200, Marton Balint wrote:
> On Mon, 19 Oct 2015, Tomas Härdin wrote:
> 
> > On Mon, 2015-10-19 at 11:40 +0200, Alexis Ballier wrote:
> >> On Mon, 19 Oct 2015 10:30:00 +0200
> >> Michael Niedermayer  wrote:
> >>
> >>> On Fri, Oct 16, 2015 at 10:42:32AM +0200, Alexis Ballier wrote:
>  This happens when writing the trailer of a file containing audio
>  but that has not muxed any video packet. Fixes ticket #4817.
> 
>  
> >>>
> >>> from IRC:
> >>>  maybe it should print a warning that there has been no
> >>> video?
> >>
> >> maybe, but what would be the right condition ? just this case ? or when
> >> writing any edit unit without video? or... ?
> >> I haven't been able to find clear references on this (well, those smpte
> >> specs I googled aren't esp. easy to read either), but e.g. the muxer
> >> refuses to mux without exactly one video stream, so maybe, an empty
> >> video stream is also an error; I don't know
> >
> > I'm not particularly fond of second-guessing these kinds of things. D-10
> > is really anal about what constitutes a legal file, so it's probably
> > best not to write anything if something seems amiss. In the end, the
> > real test for correctness is whether the output works with all gear for
> > your particular use case. But segfaults are important to fix, so I'm not
> > too concerned here. Plus my main concern is mxfdec, not mxfenc.
> >
> 
> Why not simply return error and print an error explaining "An audio packet 
> was muxed before a video, this is not supported."
> 
> Segfault -> error is much better than segfault -> possibly broken file.

Yes, simply bailing out is infinitely better than segfaulting. It's also
the more conservative approach, which I am for

/Tomas


signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Nvidia nevec presets

[Rifat Maswadeh]

Thanks for all , if you add "*Streaming*" *Presets* To Nvidia Nevec
 Presets , like this :

Automatic
Low Latency
Low Latency 2Pass
HQ Low Latency 2Pass
Lossless
HP lossless

Thanks


-- 


*Best Regards  ,*
*Rifat Maswadeh*
*Technical Support Department.*
*Zaytona For **Communications.*



*RamallahBeware of false knowledge; it is more dangerous than ignorance.*
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: drop 2 suffix from avpriv_ac3_parse_header2

[Andreas Cadhalpun]

On 21.10.2015 01:46, Michael Niedermayer wrote:
> On Wed, Oct 21, 2015 at 12:36:59AM +0200, Andreas Cadhalpun wrote:
>> avpriv_ac3_parse_header was removed in commit 3dfb643.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/ac3_parser.c | 4 ++--
>>  libavcodec/ac3_parser.h | 2 +-
>>  libavcodec/ac3dec.c | 2 +-
>>  libavformat/ac3dec.c| 2 +-
>>  libavformat/movenc.c| 4 ++--
>>  5 files changed, 7 insertions(+), 7 deletions(-)
> 
> LGTM

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] avcodec: rename avpriv_color_frame to ff_color_frame

[Andreas Cadhalpun]

On 21.10.2015 11:48, Michael Niedermayer wrote:
> On Wed, Oct 14, 2015 at 01:50:33AM +0200, Andreas Cadhalpun wrote:
>> It is only used inside libavcodec.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/h264_slice.c | 2 +-
>>  libavcodec/internal.h   | 2 +-
>>  libavcodec/utils.c  | 2 +-
>>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> if noone intends to use it outside libavcodec then LGTM

This hasn't happened in the past two years, so it's unlikely to be needed
anytime soon. Thus pushed.

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

Re: [FFmpeg-devel] [PATCH 03/11] libavformat/mxfdec.c: Report dark metadata keys only when they match no parser at all, not everytime they fail to match one.

[Michael Niedermayer]

On Wed, Oct 21, 2015 at 11:31:48PM +0200, Tomas Härdin wrote:
> On Wed, 2015-10-21 at 18:00 +0200, Alexis Ballier wrote:
> > ---
> >  libavformat/mxfdec.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index 0ae7ce6..593604e 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -2767,13 +2767,13 @@ static int mxf_read_header(AVFormatContext *s)
> >  if ((ret = mxf_parse_klv(mxf, klv, metadata->read, 
> > metadata->ctx_size, metadata->type)) < 0)
> >  goto fail;
> >  break;
> > -} else {
> > -av_log(s, AV_LOG_VERBOSE, "Dark key " PRIxUID "\n",
> > -   UID_ARG(klv.key));
> >  }
> >  }
> > -if (!metadata->read)
> > +if (!metadata->read) {
> > +av_log(s, AV_LOG_VERBOSE, "Dark key " PRIxUID "\n",
> > +UID_ARG(klv.key));
> >  avio_skip(s->pb, klv.length);
> > +}
> >  }
> >  /* FIXME avoid seek */
> >  if (!essence_offset)  {
> 
> Seems fine

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH 02/11] libavformat/mxfdec.c: cosmetics: Add missing space after '?' in log message.

[Michael Niedermayer]

On Wed, Oct 21, 2015 at 11:31:45PM +0200, Tomas Härdin wrote:
> On Wed, 2015-10-21 at 18:00 +0200, Alexis Ballier wrote:
> > ---
> >  libavformat/mxfdec.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index 94a953b..0ae7ce6 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -2959,7 +2959,7 @@ static int mxf_read_packet_old(AVFormatContext *s, 
> > AVPacket *pkt)
> >  /* if this check is hit then it's possible OPAtom was 
> > treated as OP1a
> >   * truncate the packet since it's probably very large (>2 
> > GiB is common) */
> >  avpriv_request_sample(s,
> > -  "OPAtom misinterpreted as OP1a?"
> > +  "OPAtom misinterpreted as OP1a? "
> >"KLV for edit unit %i extending into 
> > "
> >"next edit unit",
> >mxf->current_edit_unit);
> 
> Obviously fine

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH] Don't needlessly reinitialize ff_cos_## tables.

[Dale Curtis]

On Tue, Oct 20, 2015 at 11:50 PM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:
>
> the last element to be written should be checked, so that if
> initialization is done by 2 threads at the same time, neither can
> return from this function without initialization having finished
>
> also the race detectors are broken if they complain about cases where
> a variable that has value a is set to value a, that cannot be part of
> a race, not even if a is written byte per byte instead of atomically
> unless theres something iam missing
> Is this something that can be fixed or disabled on the side of the
> race detectors?
> It might reduce false positives in FFmpeg and potentially other
> tools.
>

We can suppress it, which I think is more reasonable then the overhead it'd
take to make this "race" go away. I notice the sin tables are initialized
within the fft context so there's no "race." Is there a reason the cosine
tables aren't done this way?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] huffyuvencdsp: Add ff_diff_bytes_{sse2, avx2}

[Timothy Gu]

On Tue, Oct 20, 2015 at 7:36 PM James Almer  wrote:

> On 10/20/2015 10:32 PM, Timothy Gu wrote:
> > +; mov type used for src1q, dstq, first reg, second reg
> > +%macro DIFF_BYTES_LOOP_CORE 4
> > +%if regsize != 16
>
> %if mmsize != 16
>
> By checking regsize you're using the SSE2 version in the AVX2 xmm loop.
> Check
> for mmsize instead, which it's always 32 since you used INIT_YMM.
>

Fixed locally.

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

Re: [FFmpeg-devel] [PATCH] mmaldec: Fix avpriv_atomic_get usage

[Michael Niedermayer]

On Wed, Oct 21, 2015 at 11:04:39AM +0200, wm4 wrote:
> On Wed, 21 Oct 2015 09:00:33 +0200
> Julian Scheel  wrote:
> 
> > There is no avpriv_atomic_get, instead avpriv_atomic_int_get is to be used 
> > for
> > integers. This fixes building mmaldec.
> > 
> > Signed-off-by: Julian Scheel 
> > ---
> >  libavcodec/mmaldec.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
> > index bb8f17b..13cc191 100644
> > --- a/libavcodec/mmaldec.c
> > +++ b/libavcodec/mmaldec.c
> > @@ -165,7 +165,7 @@ static void ffmmal_stop_decoder(AVCodecContext *avctx)
> >  }
> >  ctx->waiting_buffers_tail = NULL;
> >  
> > -av_assert0(avpriv_atomic_get(>packets_buffered) == 0);
> > +av_assert0(avpriv_atomic_int_get(>packets_buffered) == 0);
> >  
> >  ctx->frames_output = ctx->eos_received = ctx->eos_sent = 
> > ctx->packets_sent = ctx->extradata_sent = 0;
> >  }
> 
> Looks good. My original patch used assert(), which I now realized was
> unfortunately completely disabled.

applied

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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/electronicarts: fix demuxing of certain .eam files

[Peter Ross]

On Mon, Oct 19, 2015 at 11:35:15AM +0200, Paul B Mahol wrote:
> Such files have empty gaps between chunks.
> 
> Signed-off-by: Paul B Mahol 
> ---
>  libavformat/electronicarts.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
> index 5d21d49..c0b6d6e 100644
> --- a/libavformat/electronicarts.c
> +++ b/libavformat/electronicarts.c
> @@ -652,7 +652,14 @@ static int ea_read_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  case SCEl_TAG:
>  case SEND_TAG:
>  case SEEN_TAG:
> -ret = AVERROR(EIO);
> +while (!avio_feof(pb)) {
> +if (avio_rl32(pb)) {
> +avio_skip(pb, -4);
> +break;
> +}
> +}
> +if (avio_feof(pb))
> +ret = AVERROR_EOF;
>  packet_read = 1;
>  break;
>  

LGTM. Tested with samples from NFS8U2.

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


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

[FFmpeg-devel] [PATCH] libavformat/electronicarts: also demux mpeg audio layer 2

[Peter Ross]

Signed-off-by: Peter Ross 

http://wiki.multimedia.cx/index.php?title=Electronic_Arts_SCxl
---
 libavformat/electronicarts.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
index 5d21d49..335a635 100644
--- a/libavformat/electronicarts.c
+++ b/libavformat/electronicarts.c
@@ -237,6 +237,7 @@ static int process_audio_header_elements(AVFormatContext *s)
 return 0;
 }
 break;
+case 15:
 case 16:
 ea->audio_codec = AV_CODEC_ID_MP3;
 break;
-- 
2.1.4

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


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

Re: [FFmpeg-devel] [PATCH] vc1dsp: Port ff_vc1_put_ver_16b_shift2_mmx to yasm

[Timothy Gu]

On Wed, Oct 21, 2015 at 10:46 AM Christophe Gisquet <
christophe.gisq...@gmail.com> wrote:

> 2015-10-18 2:47 GMT+02:00 Timothy Gu :
> > This function is only used within other inline asm functions, hence the
> > HAVE_MMX_INLINE guard. Per recent discussions, we should not worry about
> > the performance of inline asm-only builds.
>
> On a quick glance, looks good.
>

FATE passes on Linux, both 64-bit and 32-bit, so pushed. Will find out
about WIN64 soon enough.

[...]

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

[FFmpeg-devel] [PATCH] ffmpeg: fix ffmpeg.h trailing whitespace

[Marton Balint]

How this passed through the commit hook?

Signed-off-by: Marton Balint 
---
 ffmpeg.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ffmpeg.h b/ffmpeg.h
index 5722816..8c232f3 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -273,7 +273,7 @@ typedef struct InputStream {
 int   wrap_correction_done;
 
 int64_t filter_in_rescale_delta_last;
-
+
 int64_t min_pts; /* pts with the smallest value in a current stream */
 int64_t max_pts; /* pts with the higher value in a current stream */
 int64_t nb_samples; /* number of samples in the last decoded audio frame 
before looping */
@@ -352,7 +352,7 @@ typedef struct InputFile {
  at the moment when looping happens */
 AVRational time_base; /* time base of the duration */
 int64_t input_ts_offset;
-
+
 int64_t ts_offset;
 int64_t last_ts;
 int64_t start_time;   /* user-specified start time in AV_TIME_BASE or 
AV_NOPTS_VALUE */
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCHv2 1/5] ffmpeg: log failed av_write_trailer

[Marton Balint]

On Mon, 19 Oct 2015, Michael Niedermayer wrote:


On Sun, Oct 18, 2015 at 12:07:34PM +0200, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
 ffmpeg.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 36a68fb..252bc0d 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -4104,7 +4104,9 @@ static int transcode(void)
 /* write the trailer if needed and close file */
 for (i = 0; i < nb_output_files; i++) {
 os = output_files[i]->ctx;
-av_write_trailer(os);
+if ((ret = av_write_trailer(os)) < 0) {
+av_log(NULL, AV_LOG_ERROR, "Error writing trailer of %s: %s", 
os->filename, av_err2str(ret));
+}
 }


LGTM

thanks


Applied, thanks.

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

Re: [FFmpeg-devel] [PATCH 2/5] ffmpeg: exit on av_write_trailer failure if exit_on_error is set

[Marton Balint]

On Sun, 18 Oct 2015, Michael Niedermayer wrote:


On Sun, Oct 18, 2015 at 12:38:51AM +0200, Michael Niedermayer wrote:

On Sun, Oct 18, 2015 at 12:24:04AM +0200, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
 ffmpeg.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ffmpeg.c b/ffmpeg.c
index 95f7e2f..94dfb04 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -4106,6 +4106,8 @@ static int transcode(void)
 os = output_files[i]->ctx;
 if ((ret = av_write_trailer(os)) < 0) {
 av_log(NULL, AV_LOG_ERROR, "Error writing trailer: %s", 
av_err2str(ret));
+if (exit_on_error)
+exit_program(1);


i wonder if ffmpeg should attempt to write all files trailers before
exiting


I don't think it matters much, if exit_on_error is set, it means the user 
wants failure if anything suspicous is going on, he will usually not care 
about his outputs if any of them is bad...


Can be changed later if somebody finds this useful.



either way this LGTM


Applied as it is, thanks.

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

Re: [FFmpeg-devel] [PATCH 3/5] ffmpeg: factorize checking decoder result

[Marton Balint]

On Sun, 18 Oct 2015, Michael Niedermayer wrote:

On Sun, Oct 18, 2015 at 12:24:05AM +0200, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
 ffmpeg.c | 27 ---
 1 file changed, 12 insertions(+), 15 deletions(-)


LGTM

thanks


Applied, thanks.

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

Re: [FFmpeg-devel] [PATCHv2 4/5] ffmpeg: exit on corrupt packets or decoded frames if exit_on_error flag is present

[Marton Balint]

On Mon, 19 Oct 2015, Michael Niedermayer wrote:


On Mon, Oct 19, 2015 at 01:57:31AM +0200, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
 ffmpeg.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)


should be ok


Applied, thanks.

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

Re: [FFmpeg-devel] [PATCH] avutil/wchar_filename: add av_warn_unused_result

[Ganesh Ajjanagadde]

On Thu, Oct 15, 2015 at 8:01 PM, Ganesh Ajjanagadde
 wrote:
> Current code is fine, this just adds robustness.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/wchar_filename.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h
> index c553c46..2ade321 100644
> --- a/libavutil/wchar_filename.h
> +++ b/libavutil/wchar_filename.h
> @@ -23,6 +23,7 @@
>  #include 
>  #include "mem.h"
>
> +av_warn_unused_result
>  static inline int utf8towchar(const char *filename_utf8, wchar_t 
> **filename_w)
>  {
>  int num_chars;
> --
> 2.6.1
>

ping - anyone willing to review this (and the other
av_warn_unused_result patches)?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/electronicarts: also demux mpeg audio layer 2

[Paul B Mahol]

On 10/22/15, Peter Ross  wrote:
> Signed-off-by: Peter Ross 
>
> http://wiki.multimedia.cx/index.php?title=Electronic_Arts_SCxl
> ---
>  libavformat/electronicarts.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
> index 5d21d49..335a635 100644
> --- a/libavformat/electronicarts.c
> +++ b/libavformat/electronicarts.c
> @@ -237,6 +237,7 @@ static int process_audio_header_elements(AVFormatContext
> *s)
>  return 0;
>  }
>  break;
> +case 15:
>  case 16:
>  ea->audio_codec = AV_CODEC_ID_MP3;
>  break;
> --
> 2.1.4
>
> -- Peter
> (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
>

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

Re: [FFmpeg-devel] [PATCH] Don't needlessly reinitialize ff_cos_## tables.

[Michael Niedermayer]

On Tue, Oct 20, 2015 at 04:57:49PM -0700, Dale Curtis wrote:
> Minor waste and more annoyingly triggers race detectors when the
> re-initialization happens across multiple threads. cos(0) == 1 and by
> default statics initialize to 0, so this check is safe.
> 
> Signed-off-by: Dale Curtis 
> ---
>  libavcodec/fft_template.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/fft_template.c b/libavcodec/fft_template.c
> index 23ea453..2165ed0 100644
> --- a/libavcodec/fft_template.c
> +++ b/libavcodec/fft_template.c
> @@ -92,6 +92,8 @@ av_cold void ff_init_ff_cos_tabs(int index)
>  int m = 1<  double freq = 2*M_PI/m;
>  FFTSample *tab = FFT_NAME(ff_cos_tabs)[index];
> +if (tab[0])
> +return;

the last element to be written should be checked, so that if
initialization is done by 2 threads at the same time, neither can
return from this function without initialization having finished

also the race detectors are broken if they complain about cases where
a variable that has value a is set to value a, that cannot be part of
a race, not even if a is written byte per byte instead of atomically
unless theres something iam missing
Is this something that can be fixed or disabled on the side of the
race detectors?
It might reduce false positives in FFmpeg and potentially other
tools.

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

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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

[FFmpeg-devel] [PATCH] mmaldec: Fix avpriv_atomic_get usage

[Julian Scheel]

There is no avpriv_atomic_get, instead avpriv_atomic_int_get is to be used for
integers. This fixes building mmaldec.

Signed-off-by: Julian Scheel 
---
 libavcodec/mmaldec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index bb8f17b..13cc191 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -165,7 +165,7 @@ static void ffmmal_stop_decoder(AVCodecContext *avctx)
 }
 ctx->waiting_buffers_tail = NULL;
 
-av_assert0(avpriv_atomic_get(>packets_buffered) == 0);
+av_assert0(avpriv_atomic_int_get(>packets_buffered) == 0);
 
 ctx->frames_output = ctx->eos_received = ctx->eos_sent = ctx->packets_sent 
= ctx->extradata_sent = 0;
 }
-- 
2.6.0


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

Re: [FFmpeg-devel] [PATCH] rtsp protocol : teardown packet not sent

[Nicolas Adenis-Lamarre]

>> Any I/O can cause delay. When the user close the window, they want it to
>> close immediately, not in five seconds.
Can you confirm that the problem is blocking io, and more generally
blocking system calls more than just io ? (i mean, we must take no risk to
have to wait, versus doing some non blocking io)
tearing is just a packet to send. No answer has to be waited. And if it's
not done, it's not dramatic, it's just better.
Sending the message in a non blocking manner could be accepted by ffmpeg
team ? I thing it's a very short io, sending just to the linux net stack a
packet. (no network wait). It seems to fail only if the net stack is
already filled as far as i understand.

http://linux.die.net/man/2/send
*: send man pageMSG_DONTWAIT* (since Linux 2.2) Enables nonblocking
operation; if the operation would block, *EAGAIN* or *EWOULDBLOCK* is
returned (this can also be enabled using the *O_NONBLOCK* flag with
the *F_SETFL
fcntl*(2)).)

I don't understand why the close must be done before the windows closure.
Why not closing the window first, then close the protocol (but being sure
it will not stuck for ever).

>> if the server does not take it into account, blame it for being stupid.
I agree the server is stupid. However, if one does, i guess it's based on a
software available to many places.
And the server programmers would tell i don't respect the protocol. But i
definitively agree with that point.

>> All this is necessary because there are various causes for blocking; if
>> ffplay is stuck waiting for more data in the middle of a packet header
but
>> the network went down, interrupting the I/O is the only solution.
tearing packet is not a packet for which you have to wait something in
feedback. (it's only a write ; and i think it's possible to make it non
blocking generating an EAGAIN to ignore or to test a second time before
giving up.)

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

Re: [FFmpeg-devel] forcing ints to be 64 bits, possible new FATE client idea

[Ganesh Ajjanagadde]

On Wed, Oct 21, 2015 at 1:24 AM, Timothy Gu  wrote:
> On Tue, Oct 20, 2015 at 7:09 PM Ganesh Ajjanagadde  wrote:
>
>> Hi all,
>>
>> It is known that there exist at least certain parts of the codebase
>> that do not work correctly if ints are 64 bits. One of them I noticed
>> was in avutil/intmath.h: ff_ctz_c does not compute the right thing if
>> int is 64 bits. This is true both before and after the De-Bruijn
>> optimization.
>>
>> A more interesting (and serious) question is whether FATE is broken if
>> int's are 64 bits. I did some digging, and found the following from
>> "The Definitive Guide to GCC" - On GCC prior to 4.x, there was a flag
>> -mint64, documented as follows (see e.g
>> https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc.pdf):
>> "Force int and long types to be 64 bits wide. See -mlong32 for an
>> explanation of the default and the way that the pointer size is
>> determined".
>>
>> This should be helpful in setting up a FATE client to test (and
>> possibly fix) bad code that assumed int = 32 bits. I myself can't
>> easily run such an outdated GCC, but I noticed a bunch of clients
>> running GCC < 4.0 where this may be set up.
>>
>
> For lack of milder wording, this is a terrible idea.
>
> FATE is set up, not to test every single possible combination of compiler,
> compiler flags, and operating system, but to make sure FFmpeg works on the
> ones people actually use. There are already not many people using GCC 3,
> and the addition of a flag that completely changes the API is nowhere near
> realistic.

Int being 64 bits is not as unrealistic as one can expect. Sure, right
now we have no such platform. However, computer architecture people
definitely do talk seriously about moving to 128 bit (or wider)
architectures. On the GCC/Glibc mailing lists, people do discuss these
things every now and then. Furthermore, how does this change the API?
On an int = 64 bits platform (with all libraries built accordingly),
people would still call/pass in int's when they are needed, right?

>
> Sometimes it's necessary to draw a line between "what's written in ISO/IEC
> 9899" and "real world."

I admit it is "theoretical" at the moment, but Michael did express
some interest in testing this idea, suggesting some level of
consideration in FFmpeg. In the "real world", a lot of "undefined
behavior" has well defined, consistent semantics on all platforms we
care about. For instance, negative left shifts are handled by both GCC
and clang in the same way. Does that mean we should just ignore it?
Not by any means. FFmpeg cares about portability and robustness, with
good reason.

In other words: I recall Nicolas mentioning that FFmpeg could do with
using width specific types more liberally. If I see a patch which
causes additional potential trouble if/when int's become 64 bits, I
will raise the point.

>
> Plus Mark's point on technical possibility of it (thank GOD GCC didn't do
> something as crazy as this on other platforms).

Indeed, it is very fortunate that GCC does not do this on other
platforms. That does not change whether we should test it or not.

>
> Timothy
> ___
> 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][RFC] avcodec: disallow hwaccel with frame threads

[Hendrik Leppkes]

On Wed, Oct 21, 2015 at 11:44 AM, Gwenole Beauchesne  wrote:
> 2015-10-21 11:27 GMT+02:00 Hendrik Leppkes :
>> On Sat, Oct 17, 2015 at 9:28 PM, Hendrik Leppkes  wrote:
>>> On Sat, Oct 17, 2015 at 9:27 PM, Hendrik Leppkes  
>>> wrote:
 ---
  libavcodec/utils.c | 6 ++
  1 file changed, 6 insertions(+)

>>>
>>> Above patch is submitted as an RFC, however I strongly believe its the
>>> only way to keep hwaccels sane in the future.
>>> There are several known problems when a hwaccel is used with frame
>>> threading, at least with DXVA2, ranging from simple image corruption
>>> to crashes in the GPU drivers.
>>>
>>> All the problems essentially come down to two factors:
>>>
>>> (1) while avcodec tries to prevent simultaneous access from different
>>> threads, it cannot control user code.
>>> As a API user you have no chance to avoid simultaneous access to the
>>> hardware surfaces with frame threading, because as soon as avcodec
>>> hands you a decoded surface,
>>> it'll already have started working on the next one. This is a common
>>> source for image corruption, as the decoder may fail to get a
>>> reference frame if its currently
>>> locked by the user code.
>>>
>>> This issue is not really fixable, other than introducing a mutex
>>> around every call that the user code would have to lock as well.
>>> API break and making hwaccel even more complex to use.
>>>
>>> (2) decoders often have had (or still have) trouble initializing the
>>> hwaccel properly with multiple threads, which can result in multiple
>>> threads re-creating the hwaccel
>>> and disrupting decoding, or even crashing in the driver.
>>>
>>> While this is in theory fixable inside the decoders in question, it
>>> can lead to quite a bit of complexity, which should be avoided.
>>>
>>> We should not be offering a mode that is known to be broken and even
>>> crash (even if the crash is not in our code).
>>> On top of that, frame threading with hwaccel does not actually improve
>>> the speed at all, if anything it might be slightly slower, and will
>>> definitely use more GPU memory.
>>>
>>> The only reason this combination even exists is because API users
>>> insisted on it, and it was then added without properly taking the
>>> consequences into account.
>>>
>>> There is an easy solution to keep using frame threads with software
>>> decoding while using a hwaccel otherwise - its used by myself, by mpv
>>> and by Kodi - simply re-open the decoder with the new threading flags.
>>> Its really not a lot of work, and keeps the code sane and the decoding 
>>> reliable.
>>>
>>
>> No further comments? No thoughts? No-one that would object if I were
>> to push the proposed patch?
>
> Fine with me.
>
> Probably add a link to your ffmpeg-devel message since it provides all
> the necessary rationale behind this?
>

I might condense it down a bit and include it in the commit message,
links have a habit of dying.

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

Re: [FFmpeg-devel] forcing ints to be 64 bits, possible new FATE client idea

[Carl Eugen Hoyos]

Ganesh Ajjanagadde  mit.edu> writes:

> Since you seem to be an "expert" on what things 
> affect this decade, why don't you spend 5 minutes 
> trying to outline to beginners like me what is 
> "actually important" in your view?

Important is whatever you want to work on.
That can be DTS-XLL or any random ticket or a 
new format or a new decoder or a new filter.

But if the new format or the new decoder is an 
invention of you it is less likely to find fans 
(but see a64).

(And consider to remember that if people do not 
comment it does not always mean they agree, so 
don't shoot those who do comment even if you 
don't like it.)

Carl Eugen

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

Re: [FFmpeg-devel] forcing ints to be 64 bits, possible new FATE client idea

[Ganesh Ajjanagadde]

On Wed, Oct 21, 2015 at 6:18 AM, wm4  wrote:
> On Wed, 21 Oct 2015 06:00:21 -0400
> Ganesh Ajjanagadde  wrote:
>
>> I don't "expect support" from anyone. Frankly, I have dealt with
>> enough mud from you, who seems to take great pleasure in criticizing
>> or otherwise derailing every patch/discussion of mine to not care
>> about things either way - if you don't want me, just say the word, and
>> I will be gone. And your own stance on this point is not even clear -
>> GCC 20 is not going to hit the shelves this decade.
>
> Nobody is throwing mud at you. But your patches are mostly
> "theoretical" changes, often without much proof that they are really
> necessary, or cosmetic changes. While many of these changes are quite
> ok and actually improve the code base a bit, they also generate a LOT
> of traffic and discussion. This can be exhausting, especially if you
> have to care about other things. So yes, it's all kind of noisy and
> annoying. Sorry.

No problem - thanks for speaking up.

>
> This doesn't mean you should go away, or that we don't want you, or
> that you should stop doing what you do. On the opposite, I think you're
> a promising new developer, and you should definitely stay.
>
> Maybe you should feel encouraged to get on the next level. For example,
> you could enter the fuzzing-security-bugs business, or the
> rewrite-inline-asm-as-yasm business. Or pick anything that looks
> interesting to you; you already have enough experience with this project
> that you will find your way. You will learn new useful things, and the
> result will be useful for everyone. It should also be more fun than
> fixing theoretical standards issues.

Got it.

>
>> Since you seem to be an "expert" on what things affect this decade,
>> why don't you spend 5 minutes trying to outline to beginners like me
>> what is "actually important" in your view?
>
> Important is fixing bugs that actually could affect people right now.
> I do agree that ffmpeg should follow standards, and that code assuming
> sizeof(int)==4 is buggy and should be fixed. But is it important enough
> that we should go and turn around every single line of code? Or,
> alternatively, depend on an ancient compiler, and work through
> potentially hundreds of FATE failures? And only because someone _could_
> decide that new architectures will use 64 bit ints? I don't think so.

Ok, I will send patches if I see issues while working on some other
thing, but not do a mass cleanup. Thanks.

>
> The likeliness of this happening is very low anyway. Just look at
> Windows: they decided that even the "long" type should remain 32 bit,
> because making it 64 bit (like on Unix) would break way too much code.
> The most likely scenario is that a 128 bit architecture will have the
> same types and sizes as 64 bit systems, just with size_t/ptrdiff_t
> being 128 bit, and a new "long long long int" type (I swear, they will
> do it, even if that type name looks horrible).

> ___
> 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][RFC] avcodec: disallow hwaccel with frame threads

[Gwenole Beauchesne]

2015-10-21 11:27 GMT+02:00 Hendrik Leppkes :
> On Sat, Oct 17, 2015 at 9:28 PM, Hendrik Leppkes  wrote:
>> On Sat, Oct 17, 2015 at 9:27 PM, Hendrik Leppkes  wrote:
>>> ---
>>>  libavcodec/utils.c | 6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>
>> Above patch is submitted as an RFC, however I strongly believe its the
>> only way to keep hwaccels sane in the future.
>> There are several known problems when a hwaccel is used with frame
>> threading, at least with DXVA2, ranging from simple image corruption
>> to crashes in the GPU drivers.
>>
>> All the problems essentially come down to two factors:
>>
>> (1) while avcodec tries to prevent simultaneous access from different
>> threads, it cannot control user code.
>> As a API user you have no chance to avoid simultaneous access to the
>> hardware surfaces with frame threading, because as soon as avcodec
>> hands you a decoded surface,
>> it'll already have started working on the next one. This is a common
>> source for image corruption, as the decoder may fail to get a
>> reference frame if its currently
>> locked by the user code.
>>
>> This issue is not really fixable, other than introducing a mutex
>> around every call that the user code would have to lock as well.
>> API break and making hwaccel even more complex to use.
>>
>> (2) decoders often have had (or still have) trouble initializing the
>> hwaccel properly with multiple threads, which can result in multiple
>> threads re-creating the hwaccel
>> and disrupting decoding, or even crashing in the driver.
>>
>> While this is in theory fixable inside the decoders in question, it
>> can lead to quite a bit of complexity, which should be avoided.
>>
>> We should not be offering a mode that is known to be broken and even
>> crash (even if the crash is not in our code).
>> On top of that, frame threading with hwaccel does not actually improve
>> the speed at all, if anything it might be slightly slower, and will
>> definitely use more GPU memory.
>>
>> The only reason this combination even exists is because API users
>> insisted on it, and it was then added without properly taking the
>> consequences into account.
>>
>> There is an easy solution to keep using frame threads with software
>> decoding while using a hwaccel otherwise - its used by myself, by mpv
>> and by Kodi - simply re-open the decoder with the new threading flags.
>> Its really not a lot of work, and keeps the code sane and the decoding 
>> reliable.
>>
>
> No further comments? No thoughts? No-one that would object if I were
> to push the proposed patch?

Fine with me.

Probably add a link to your ffmpeg-devel message since it provides all
the necessary rationale behind this?

Thanks,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] forcing ints to be 64 bits, possible new FATE client idea

[Ganesh Ajjanagadde]

On Wed, Oct 21, 2015 at 5:31 AM, Hendrik Leppkes  wrote:
> On Wed, Oct 21, 2015 at 11:10 AM, Ganesh Ajjanagadde  wrote:
>> On Wed, Oct 21, 2015 at 1:24 AM, Timothy Gu  wrote:
>>> On Tue, Oct 20, 2015 at 7:09 PM Ganesh Ajjanagadde  wrote:
>>>
 Hi all,

 It is known that there exist at least certain parts of the codebase
 that do not work correctly if ints are 64 bits. One of them I noticed
 was in avutil/intmath.h: ff_ctz_c does not compute the right thing if
 int is 64 bits. This is true both before and after the De-Bruijn
 optimization.

 A more interesting (and serious) question is whether FATE is broken if
 int's are 64 bits. I did some digging, and found the following from
 "The Definitive Guide to GCC" - On GCC prior to 4.x, there was a flag
 -mint64, documented as follows (see e.g
 https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc.pdf):
 "Force int and long types to be 64 bits wide. See -mlong32 for an
 explanation of the default and the way that the pointer size is
 determined".

 This should be helpful in setting up a FATE client to test (and
 possibly fix) bad code that assumed int = 32 bits. I myself can't
 easily run such an outdated GCC, but I noticed a bunch of clients
 running GCC < 4.0 where this may be set up.

>>>
>>> For lack of milder wording, this is a terrible idea.
>>>
>>> FATE is set up, not to test every single possible combination of compiler,
>>> compiler flags, and operating system, but to make sure FFmpeg works on the
>>> ones people actually use. There are already not many people using GCC 3,
>>> and the addition of a flag that completely changes the API is nowhere near
>>> realistic.
>>
>> Int being 64 bits is not as unrealistic as one can expect. Sure, right
>> now we have no such platform. However, computer architecture people
>> definitely do talk seriously about moving to 128 bit (or wider)
>> architectures. On the GCC/Glibc mailing lists, people do discuss these
>> things every now and then. Furthermore, how does this change the API?
>> On an int = 64 bits platform (with all libraries built accordingly),
>> people would still call/pass in int's when they are needed, right?
>>
>>>
>>> Sometimes it's necessary to draw a line between "what's written in ISO/IEC
>>> 9899" and "real world."
>>
>> I admit it is "theoretical" at the moment, but Michael did express
>> some interest in testing this idea, suggesting some level of
>> consideration in FFmpeg. In the "real world", a lot of "undefined
>> behavior" has well defined, consistent semantics on all platforms we
>> care about. For instance, negative left shifts are handled by both GCC
>> and clang in the same way. Does that mean we should just ignore it?
>> Not by any means. FFmpeg cares about portability and robustness, with
>> good reason.
>>
>
> I think an important point to remember is that we have plenty of areas
> that could use improvement right now, on platforms relevant today.
> We don't need to keep ourselves busy worrying about some theoretical
> future system that may or may not exist in a decade or so.
>
> If you want to waste your time on that, noone is going to stop you,
> just don't expect much support from other developers, whose time may
> be much better spent on things affecting this decade.

I don't "expect support" from anyone. Frankly, I have dealt with
enough mud from you, who seems to take great pleasure in criticizing
or otherwise derailing every patch/discussion of mine to not care
about things either way - if you don't want me, just say the word, and
I will be gone. And your own stance on this point is not even clear -
GCC 20 is not going to hit the shelves this decade.

Since you seem to be an "expert" on what things affect this decade,
why don't you spend 5 minutes trying to outline to beginners like me
what is "actually important" in your view?

>
> - Hendrik
> ___
> 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] forcing ints to be 64 bits, possible new FATE client idea

[wm4]

On Wed, 21 Oct 2015 06:00:21 -0400
Ganesh Ajjanagadde  wrote:

> I don't "expect support" from anyone. Frankly, I have dealt with
> enough mud from you, who seems to take great pleasure in criticizing
> or otherwise derailing every patch/discussion of mine to not care
> about things either way - if you don't want me, just say the word, and
> I will be gone. And your own stance on this point is not even clear -
> GCC 20 is not going to hit the shelves this decade.

Nobody is throwing mud at you. But your patches are mostly
"theoretical" changes, often without much proof that they are really
necessary, or cosmetic changes. While many of these changes are quite
ok and actually improve the code base a bit, they also generate a LOT
of traffic and discussion. This can be exhausting, especially if you
have to care about other things. So yes, it's all kind of noisy and
annoying. Sorry.

This doesn't mean you should go away, or that we don't want you, or
that you should stop doing what you do. On the opposite, I think you're
a promising new developer, and you should definitely stay.

Maybe you should feel encouraged to get on the next level. For example,
you could enter the fuzzing-security-bugs business, or the
rewrite-inline-asm-as-yasm business. Or pick anything that looks
interesting to you; you already have enough experience with this project
that you will find your way. You will learn new useful things, and the
result will be useful for everyone. It should also be more fun than
fixing theoretical standards issues.

> Since you seem to be an "expert" on what things affect this decade,
> why don't you spend 5 minutes trying to outline to beginners like me
> what is "actually important" in your view?

Important is fixing bugs that actually could affect people right now.
I do agree that ffmpeg should follow standards, and that code assuming
sizeof(int)==4 is buggy and should be fixed. But is it important enough
that we should go and turn around every single line of code? Or,
alternatively, depend on an ancient compiler, and work through
potentially hundreds of FATE failures? And only because someone _could_
decide that new architectures will use 64 bit ints? I don't think so.

The likeliness of this happening is very low anyway. Just look at
Windows: they decided that even the "long" type should remain 32 bit,
because making it 64 bit (like on Unix) would break way too much code.
The most likely scenario is that a 128 bit architecture will have the
same types and sizes as 64 bit systems, just with size_t/ptrdiff_t
being 128 bit, and a new "long long long int" type (I swear, they will
do it, even if that type name looks horrible).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] aacdec: fix strict prototype warning

[Hendrik Leppkes]

Function protoypes without arguments require a void argument in C,
instead of an empty list.
---
 libavcodec/aacdec_template.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index aabd3f0..c279510 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -1065,7 +1065,7 @@ static void reset_predictor_group(PredictorState *ps, int 
group_num)
 
 static void aacdec_init(AACContext *ac);
 
-static av_cold void aac_static_table_init()
+static av_cold void aac_static_table_init(void)
 {
 AAC_INIT_VLC_STATIC( 0, 304);
 AAC_INIT_VLC_STATIC( 1, 270);
-- 
2.5.3.windows.1

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

Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads

[Hendrik Leppkes]

On Sat, Oct 17, 2015 at 9:28 PM, Hendrik Leppkes  wrote:
> On Sat, Oct 17, 2015 at 9:27 PM, Hendrik Leppkes  wrote:
>> ---
>>  libavcodec/utils.c | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>
> Above patch is submitted as an RFC, however I strongly believe its the
> only way to keep hwaccels sane in the future.
> There are several known problems when a hwaccel is used with frame
> threading, at least with DXVA2, ranging from simple image corruption
> to crashes in the GPU drivers.
>
> All the problems essentially come down to two factors:
>
> (1) while avcodec tries to prevent simultaneous access from different
> threads, it cannot control user code.
> As a API user you have no chance to avoid simultaneous access to the
> hardware surfaces with frame threading, because as soon as avcodec
> hands you a decoded surface,
> it'll already have started working on the next one. This is a common
> source for image corruption, as the decoder may fail to get a
> reference frame if its currently
> locked by the user code.
>
> This issue is not really fixable, other than introducing a mutex
> around every call that the user code would have to lock as well.
> API break and making hwaccel even more complex to use.
>
> (2) decoders often have had (or still have) trouble initializing the
> hwaccel properly with multiple threads, which can result in multiple
> threads re-creating the hwaccel
> and disrupting decoding, or even crashing in the driver.
>
> While this is in theory fixable inside the decoders in question, it
> can lead to quite a bit of complexity, which should be avoided.
>
> We should not be offering a mode that is known to be broken and even
> crash (even if the crash is not in our code).
> On top of that, frame threading with hwaccel does not actually improve
> the speed at all, if anything it might be slightly slower, and will
> definitely use more GPU memory.
>
> The only reason this combination even exists is because API users
> insisted on it, and it was then added without properly taking the
> consequences into account.
>
> There is an easy solution to keep using frame threads with software
> decoding while using a hwaccel otherwise - its used by myself, by mpv
> and by Kodi - simply re-open the decoder with the new threading flags.
> Its really not a lot of work, and keeps the code sane and the decoding 
> reliable.
>

No further comments? No thoughts? No-one that would object if I were
to push the proposed patch?

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

Re: [FFmpeg-devel] forcing ints to be 64 bits, possible new FATE client idea

[Hendrik Leppkes]

On Wed, Oct 21, 2015 at 11:10 AM, Ganesh Ajjanagadde  wrote:
> On Wed, Oct 21, 2015 at 1:24 AM, Timothy Gu  wrote:
>> On Tue, Oct 20, 2015 at 7:09 PM Ganesh Ajjanagadde  wrote:
>>
>>> Hi all,
>>>
>>> It is known that there exist at least certain parts of the codebase
>>> that do not work correctly if ints are 64 bits. One of them I noticed
>>> was in avutil/intmath.h: ff_ctz_c does not compute the right thing if
>>> int is 64 bits. This is true both before and after the De-Bruijn
>>> optimization.
>>>
>>> A more interesting (and serious) question is whether FATE is broken if
>>> int's are 64 bits. I did some digging, and found the following from
>>> "The Definitive Guide to GCC" - On GCC prior to 4.x, there was a flag
>>> -mint64, documented as follows (see e.g
>>> https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc.pdf):
>>> "Force int and long types to be 64 bits wide. See -mlong32 for an
>>> explanation of the default and the way that the pointer size is
>>> determined".
>>>
>>> This should be helpful in setting up a FATE client to test (and
>>> possibly fix) bad code that assumed int = 32 bits. I myself can't
>>> easily run such an outdated GCC, but I noticed a bunch of clients
>>> running GCC < 4.0 where this may be set up.
>>>
>>
>> For lack of milder wording, this is a terrible idea.
>>
>> FATE is set up, not to test every single possible combination of compiler,
>> compiler flags, and operating system, but to make sure FFmpeg works on the
>> ones people actually use. There are already not many people using GCC 3,
>> and the addition of a flag that completely changes the API is nowhere near
>> realistic.
>
> Int being 64 bits is not as unrealistic as one can expect. Sure, right
> now we have no such platform. However, computer architecture people
> definitely do talk seriously about moving to 128 bit (or wider)
> architectures. On the GCC/Glibc mailing lists, people do discuss these
> things every now and then. Furthermore, how does this change the API?
> On an int = 64 bits platform (with all libraries built accordingly),
> people would still call/pass in int's when they are needed, right?
>
>>
>> Sometimes it's necessary to draw a line between "what's written in ISO/IEC
>> 9899" and "real world."
>
> I admit it is "theoretical" at the moment, but Michael did express
> some interest in testing this idea, suggesting some level of
> consideration in FFmpeg. In the "real world", a lot of "undefined
> behavior" has well defined, consistent semantics on all platforms we
> care about. For instance, negative left shifts are handled by both GCC
> and clang in the same way. Does that mean we should just ignore it?
> Not by any means. FFmpeg cares about portability and robustness, with
> good reason.
>

I think an important point to remember is that we have plenty of areas
that could use improvement right now, on platforms relevant today.
We don't need to keep ourselves busy worrying about some theoretical
future system that may or may not exist in a decade or so.

If you want to waste your time on that, noone is going to stop you,
just don't expect much support from other developers, whose time may
be much better spent on things affecting this decade.

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

Re: [FFmpeg-devel] [PATCH] avcodec: rename avpriv_color_frame to ff_color_frame

[Michael Niedermayer]

On Wed, Oct 14, 2015 at 01:50:33AM +0200, Andreas Cadhalpun wrote:
> It is only used inside libavcodec.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/h264_slice.c | 2 +-
>  libavcodec/internal.h   | 2 +-
>  libavcodec/utils.c  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

if noone intends to use it outside libavcodec then LGTM

thx

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] forcing ints to be 64 bits, possible new FATE client idea

[Ganesh Ajjanagadde]

On Wed, Oct 21, 2015 at 6:10 AM, Carl Eugen Hoyos  wrote:
> Ganesh Ajjanagadde  mit.edu> writes:
>
>> Since you seem to be an "expert" on what things
>> affect this decade, why don't you spend 5 minutes
>> trying to outline to beginners like me what is
>> "actually important" in your view?
>
> Important is whatever you want to work on.
> That can be DTS-XLL or any random ticket or a
> new format or a new decoder or a new filter.

Then by definition the int = 64 bits is something that has some
importance. The fact that Michael asked about it, and I am interested
to some (minor) degree confirms this according to your definition.

>
> But if the new format or the new decoder is an
> invention of you it is less likely to find fans
> (but see a64).
>
> (And consider to remember that if people do not
> comment it does not always mean they agree, so
> don't shoot those who do comment even if you
> don't like it.)

I have not "shot" anybody, just paid back in the same manner of tone.
I will refrain from it in future, thanks.

>
> Carl Eugen
>
> ___
> 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] Added QSV based VPP filter

[Sven Dueking]

> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> von Moritz Barsnick
> Gesendet: Mittwoch, 14. Oktober 2015 11:23
> An: FFmpeg development discussions and patches
> Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
> 
> On Wed, Oct 14, 2015 at 10:07:04 +0200, Sven Dueking wrote:
> > The attached patches adds the VPP as filter module to FFMpeg.
> > Looking forward to get feedback.
> 
> doc/filters.texi?
> 
> (Sorry, those who know what vpp is might get along fine with this, but
> I couldn't even quicky find out...)

Hi Moritz,

Documentation attached. Is it ok to provide this as separate file ? 

Thanks for checking.

Best,
Sven
> 
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


ffmpeg-qsv_vpp.texi
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads

[wm4]

On Wed, 21 Oct 2015 11:53:46 +0200
Hendrik Leppkes  wrote:

> On Wed, Oct 21, 2015 at 11:44 AM, Gwenole Beauchesne  
> wrote:
> > 2015-10-21 11:27 GMT+02:00 Hendrik Leppkes :  
> >> On Sat, Oct 17, 2015 at 9:28 PM, Hendrik Leppkes  
> >> wrote:  
> >>> On Sat, Oct 17, 2015 at 9:27 PM, Hendrik Leppkes  
> >>> wrote:  
>  ---
>   libavcodec/utils.c | 6 ++
>   1 file changed, 6 insertions(+)
>   
> >>>
> >>> Above patch is submitted as an RFC, however I strongly believe its the
> >>> only way to keep hwaccels sane in the future.
> >>> There are several known problems when a hwaccel is used with frame
> >>> threading, at least with DXVA2, ranging from simple image corruption
> >>> to crashes in the GPU drivers.
> >>>
> >>> All the problems essentially come down to two factors:
> >>>
> >>> (1) while avcodec tries to prevent simultaneous access from different
> >>> threads, it cannot control user code.
> >>> As a API user you have no chance to avoid simultaneous access to the
> >>> hardware surfaces with frame threading, because as soon as avcodec
> >>> hands you a decoded surface,
> >>> it'll already have started working on the next one. This is a common
> >>> source for image corruption, as the decoder may fail to get a
> >>> reference frame if its currently
> >>> locked by the user code.
> >>>
> >>> This issue is not really fixable, other than introducing a mutex
> >>> around every call that the user code would have to lock as well.
> >>> API break and making hwaccel even more complex to use.
> >>>
> >>> (2) decoders often have had (or still have) trouble initializing the
> >>> hwaccel properly with multiple threads, which can result in multiple
> >>> threads re-creating the hwaccel
> >>> and disrupting decoding, or even crashing in the driver.
> >>>
> >>> While this is in theory fixable inside the decoders in question, it
> >>> can lead to quite a bit of complexity, which should be avoided.
> >>>
> >>> We should not be offering a mode that is known to be broken and even
> >>> crash (even if the crash is not in our code).
> >>> On top of that, frame threading with hwaccel does not actually improve
> >>> the speed at all, if anything it might be slightly slower, and will
> >>> definitely use more GPU memory.
> >>>
> >>> The only reason this combination even exists is because API users
> >>> insisted on it, and it was then added without properly taking the
> >>> consequences into account.
> >>>
> >>> There is an easy solution to keep using frame threads with software
> >>> decoding while using a hwaccel otherwise - its used by myself, by mpv
> >>> and by Kodi - simply re-open the decoder with the new threading flags.
> >>> Its really not a lot of work, and keeps the code sane and the decoding 
> >>> reliable.
> >>>  
> >>
> >> No further comments? No thoughts? No-one that would object if I were
> >> to push the proposed patch?  
> >
> > Fine with me.
> >
> > Probably add a link to your ffmpeg-devel message since it provides all
> > the necessary rationale behind this?
> >  
> 
> I might condense it down a bit and include it in the commit message,
> links have a habit of dying.

Yeah, there's plenty of free space in the commit message field.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat: implement SChannel SSP TLS protocol

[Hendrik Leppkes]

This implementation does not support TLS listen sockets and loading
CA/Certs from files.

The Windows API does not support loading PEM certs, and would either
require a manual loader or instead be limited to loading Windows PFX
certificates

TLS listen sockets would have to be implemented quite separately, as many
of the APIs are different for server-mode (as opposed to client mode).
---

Because of the limitations in comparison to OpenSSL or GnuTLS,
we might make this implementation not active by default, if someone feels
like thats a better course of action.


 configure  |  20 +-
 libavformat/Makefile   |   1 +
 libavformat/allformats.c   |   1 +
 libavformat/tls.h  |   2 +-
 libavformat/tls_schannel.c | 601 +
 5 files changed, 621 insertions(+), 4 deletions(-)
 create mode 100644 libavformat/tls_schannel.c

diff --git a/configure b/configure
index 5e7ded1..6b9b99c 100755
--- a/configure
+++ b/configure
@@ -280,6 +280,8 @@ External library support:
   --enable-opengl  enable OpenGL rendering [no]
   --enable-openssl enable openssl, needed for https support
if gnutls is not used [no]
+  --disable-schannel   disable SChannel SSP, needed for TLS support on
+   Windows if openssl and gnutls are not used 
[autodetect]
   --disable-sdldisable sdl [autodetect]
   --disable-securetransport disable Secure Transport, needed for TLS support
on OSX if openssl and gnutls are not used 
[autodetect]
@@ -1465,6 +1467,7 @@ EXTERNAL_LIBRARY_LIST="
 opencl
 opengl
 openssl
+schannel
 sdl
 securetransport
 x11grab
@@ -2754,13 +2757,15 @@ sctp_protocol_deps="struct_sctp_event_subscribe"
 sctp_protocol_select="network"
 srtp_protocol_select="rtp_protocol"
 tcp_protocol_select="network"
-tls_gnutls_protocol_deps="gnutls !tls_securetransport_protocol"
+tls_gnutls_protocol_deps="gnutls !tls_schannel_protocol 
!tls_securetransport_protocol"
 tls_gnutls_protocol_select="tcp_protocol"
-tls_openssl_protocol_deps="openssl !tls_securetransport_protocol 
!tls_gnutls_protocol"
+tls_openssl_protocol_deps="openssl !tls_schannel_protocol 
!tls_securetransport_protocol !tls_gnutls_protocol"
 tls_openssl_protocol_select="tcp_protocol"
+tls_schannel_protocol_deps="schannel"
+tls_schannel_protocol_select="tcp_protocol"
 tls_securetransport_protocol_deps="securetransport"
 tls_securetransport_protocol_select="tcp_protocol"
-tls_protocol_deps_any="tls_securetransport_protocol tls_gnutls_protocol 
tls_openssl_protocol"
+tls_protocol_deps_any="tls_schannel_protocol tls_securetransport_protocol 
tls_gnutls_protocol tls_openssl_protocol"
 udp_protocol_select="network"
 udplite_protocol_select="network"
 unix_protocol_deps="sys_un_h"
@@ -5501,6 +5506,15 @@ disabled securetransport || { check_func 
SecIdentityCreate "-Wl,-framework,CoreF
 check_lib2 "Security/SecureTransport.h Security/Security.h" 
"SSLCreateContext SecItemImport" "-Wl,-framework,CoreFoundation 
-Wl,-framework,Security" &&
 enable securetransport; }
 
+if ! disabled schannel; then
+check_cc <
+#include 
+int main(void) { InitializeSecurityContext(NULL, NULL, NULL, 0, 0, 0, NULL, 0, 
NULL, NULL, NULL, NULL); return 0; }
+EOF
+fi
+
 makeinfo --version > /dev/null 2>&1 && enable makeinfo  || disable makeinfo
 enabled makeinfo \
 && [ 0$(makeinfo --version | grep "texinfo" | sed 
's/.*texinfo[^0-9]*\([0-9]*\)\..*/\1/') -ge 5 ] \
diff --git a/libavformat/Makefile b/libavformat/Makefile
index ded2d54..b2d6057 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -535,6 +535,7 @@ OBJS-$(CONFIG_SUBFILE_PROTOCOL)  += subfile.o
 OBJS-$(CONFIG_TCP_PROTOCOL)  += tcp.o
 OBJS-$(CONFIG_TLS_GNUTLS_PROTOCOL)   += tls_gnutls.o tls.o
 OBJS-$(CONFIG_TLS_OPENSSL_PROTOCOL)  += tls_openssl.o tls.o
+OBJS-$(CONFIG_TLS_SCHANNEL_PROTOCOL) += tls_schannel.o tls.o
 OBJS-$(CONFIG_TLS_SECURETRANSPORT_PROTOCOL) += tls_securetransport.o tls.o
 OBJS-$(CONFIG_UDP_PROTOCOL)  += udp.o
 OBJS-$(CONFIG_UDPLITE_PROTOCOL)  += udp.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 40fea8e..dad2644 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -387,6 +387,7 @@ void av_register_all(void)
 REGISTER_PROTOCOL(SRTP, srtp);
 REGISTER_PROTOCOL(SUBFILE,  subfile);
 REGISTER_PROTOCOL(TCP,  tcp);
+REGISTER_PROTOCOL(TLS_SCHANNEL, tls_schannel);
 REGISTER_PROTOCOL(TLS_SECURETRANSPORT, tls_securetransport);
 REGISTER_PROTOCOL(TLS_GNUTLS,   tls_gnutls);
 REGISTER_PROTOCOL(TLS_OPENSSL,  tls_openssl);
diff --git a/libavformat/tls.h b/libavformat/tls.h
index 2a36f34..0326ef7 100644
--- a/libavformat/tls.h
+++ b/libavformat/tls.h
@@ -26,7 +26,7 @@
 #include "url.h"
 #include "libavutil/opt.h"
 
-#define CONFIG_TLS_PROTOCOL 

Re: [FFmpeg-devel] Trac Outage - Notification of planned works

[Kieran Kunhya]

Please note this is tonight - Don't say you weren't told!

Kieran

On 9 October 2015 at 07:37, Kieran Kunhya  wrote:
> Hello,
>
> Please note there will be a trac outage owing to the rerouting of fibre as
> part of the London Underground extension.
>
> Regards,
> Kieran Kunhya
>
> -- Forwarded message -
>
>
>
> Hello,
>
> There is going to be a loss of service at some point during the time frame
> stated below whilst Virgin complete the maintenance work. This is a
> diversionary job. The cable needs to be run because of the Northern line
> extension project in Kennington, London.
>
> Planned Work Start (Local UK): 22/10/2015 00:01
>
> Planned Work End (Local UK): 22/10/2015 06:01
>
> During the first hour of the change and up to the maximum time stated below
> you will experience a service outage. For the remainder of the change window
> your service is at risk and should the need arise, Virgin will take down
> your service to resolve any issues.
>
> If you have any queries, please contact the Support Team at
> supp...@venus.co.uk or call 0207 240 5858.
>
> Best Regards,
>
> Erik
>
> --
>
> Erikas Francas
>
> Venus Business Communications Ltd
>
> 25-27 Oxford St, London W1D 2DW
>
>  VENUS
>
> 020 7240 5858
>
> www.venus.co.uk
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] forcing ints to be 64 bits, possible new FATE client idea

[Clément Bœsch]

On Wed, Oct 21, 2015 at 06:00:21AM -0400, Ganesh Ajjanagadde wrote:
[...]
> why don't you spend 5 minutes trying to outline to beginners like me
> what is "actually important" in your view?
> 

According to the first 100 answers of the survey, the majority of the
users want... speed optimisation above anything. I can't give more info
for now, I'll need to pay to get the stats taking into account all votes.

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] aacdec: fix strict prototype warning

[Paul B Mahol]

On 10/21/15, Hendrik Leppkes  wrote:
> Function protoypes without arguments require a void argument in C,
> instead of an empty list.
> ---
>  libavcodec/aacdec_template.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> index aabd3f0..c279510 100644
> --- a/libavcodec/aacdec_template.c
> +++ b/libavcodec/aacdec_template.c
> @@ -1065,7 +1065,7 @@ static void reset_predictor_group(PredictorState *ps,
> int group_num)
>
>  static void aacdec_init(AACContext *ac);
>
> -static av_cold void aac_static_table_init()
> +static av_cold void aac_static_table_init(void)
>  {
>  AAC_INIT_VLC_STATIC( 0, 304);
>  AAC_INIT_VLC_STATIC( 1, 270);
> --
> 2.5.3.windows.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

[FFmpeg-devel] [PATCH] avfilter/vf_ssim: Add support for writing stats to stdout

[Tobias Rapp]

Analogous to my previous patch to vf_psnr.c the attached patch 
implements writing SSIM frame stats to standard output if the filename 
is "-".


Regards,
Tobias
>From 55077db04d9d843b25b560b8c4cee8924064e443 Mon Sep 17 00:00:00 2001
From: Tobias Rapp 
Date: Tue, 20 Oct 2015 15:34:36 +0200
Subject: [PATCH] avfilter/vf_ssim: Add support for writing stats to stdout

---
 doc/filters.texi  | 3 ++-
 libavfilter/vf_ssim.c | 6 --
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 4edc4f3..0712b6f 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10220,7 +10220,8 @@ The description of the accepted parameters follows.
 @table @option
 @item stats_file, f
 If specified the filter will use the named file to save the SSIM of
-each individual frame.
+each individual frame. When filename equals "-" the data is sent to
+standard output.
 @end table
 
 The file printed if @var{stats_file} is selected, contains a sequence of
diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c
index 5cd9361..b23d447 100644
--- a/libavfilter/vf_ssim.c
+++ b/libavfilter/vf_ssim.c
@@ -223,7 +223,9 @@ static av_cold int init(AVFilterContext *ctx)
 {
 SSIMContext *s = ctx->priv;
 
-if (s->stats_file_str) {
+if (!strcmp(s->stats_file_str, "-")) {
+s->stats_file = stdout;
+} else if (s->stats_file_str) {
 s->stats_file = fopen(s->stats_file_str, "w");
 if (!s->stats_file) {
 int err = AVERROR(errno);
@@ -354,7 +356,7 @@ static av_cold void uninit(AVFilterContext *ctx)
 
 ff_dualinput_uninit(>dinput);
 
-if (s->stats_file)
+if (s->stats_file && s->stats_file != stdout)
 fclose(s->stats_file);
 
 av_freep(>temp);
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] pixblockdsp: Use memcpy for get_pixels_16_c

[Michael Niedermayer]

On Tue, Oct 20, 2015 at 01:20:03PM -0700, Timothy Gu wrote:
> Before:
>   15543 decicycles in get_pixels, 4193214 runs,   1090 skips
> After:
>5713 decicycles in get_pixels, 8387564 runs,   1044 skips
> ---
>  libavcodec/pixblockdsp.c  | 36 ++-
>  libavcodec/pixblockdsp_template.c | 40 
> ---
>  2 files changed, 31 insertions(+), 45 deletions(-)
>  delete mode 100644 libavcodec/pixblockdsp_template.c
> 
> diff --git a/libavcodec/pixblockdsp.c b/libavcodec/pixblockdsp.c
> index 322e1dd..0f23d8a 100644
> --- a/libavcodec/pixblockdsp.c
> +++ b/libavcodec/pixblockdsp.c
> @@ -23,12 +23,38 @@
>  #include "avcodec.h"
>  #include "pixblockdsp.h"
>  
> -#define BIT_DEPTH 16
> -#include "pixblockdsp_template.c"
> -#undef BIT_DEPTH
> +static void get_pixels_16_c(int16_t *av_restrict block, const uint8_t 
> *pixels,
> +ptrdiff_t line_size)
> +{
> +memcpy(block + 0 * 8, pixels + 0 * line_size, sizeof(int16_t) * 8);
> +memcpy(block + 1 * 8, pixels + 1 * line_size, sizeof(int16_t) * 8);
> +memcpy(block + 2 * 8, pixels + 2 * line_size, sizeof(int16_t) * 8);
> +memcpy(block + 3 * 8, pixels + 3 * line_size, sizeof(int16_t) * 8);
> +memcpy(block + 4 * 8, pixels + 4 * line_size, sizeof(int16_t) * 8);
> +memcpy(block + 5 * 8, pixels + 5 * line_size, sizeof(int16_t) * 8);
> +memcpy(block + 6 * 8, pixels + 6 * line_size, sizeof(int16_t) * 8);
> +memcpy(block + 7 * 8, pixels + 7 * line_size, sizeof(int16_t) * 8);

AV_COPY128(U)


> +}
> +
> +static void get_pixels_8_c(int16_t *av_restrict block, const uint8_t *pixels,
> +   ptrdiff_t line_size)
> +{
> +int i;
>  
> -#define BIT_DEPTH 8
> -#include "pixblockdsp_template.c"
> +/* read the pixels */
> +for (i = 0; i < 8; i++) {
> +block[0] = pixels[0];
> +block[1] = pixels[1];
> +block[2] = pixels[2];
> +block[3] = pixels[3];
> +block[4] = pixels[4];
> +block[5] = pixels[5];
> +block[6] = pixels[6];
> +block[7] = pixels[7];

AV_COPY64(U)

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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

Re: [FFmpeg-devel] [PATCH] Don't needlessly reinitialize ff_cos_## tables.

[wm4]

On Tue, 20 Oct 2015 16:57:49 -0700
Dale Curtis  wrote:

> Minor waste and more annoyingly triggers race detectors when the
> re-initialization happens across multiple threads. cos(0) == 1 and by
> default statics initialize to 0, so this check is safe.
> 
> Signed-off-by: Dale Curtis 
> ---
>  libavcodec/fft_template.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/fft_template.c b/libavcodec/fft_template.c
> index 23ea453..2165ed0 100644
> --- a/libavcodec/fft_template.c
> +++ b/libavcodec/fft_template.c
> @@ -92,6 +92,8 @@ av_cold void ff_init_ff_cos_tabs(int index)
>  int m = 1<  double freq = 2*M_PI/m;
>  FFTSample *tab = FFT_NAME(ff_cos_tabs)[index];
> +if (tab[0])
> +return;
>  for(i=0; i<=m/4; i++)
>  tab[i] = FIX15(cos(i*freq));
>  for(i=1; ihttp://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] forcing ints to be 64 bits, possible new FATE client idea

[Ganesh Ajjanagadde]

On Wed, Oct 21, 2015 at 1:14 AM, Mark Harris  wrote:
> On Tue, Oct 20, 2015 at 7:08 PM, Ganesh Ajjanagadde  wrote:
>> Hi all,
>>
>> It is known that there exist at least certain parts of the codebase
>> that do not work correctly if ints are 64 bits. One of them I noticed
>> was in avutil/intmath.h: ff_ctz_c does not compute the right thing if
>> int is 64 bits. This is true both before and after the De-Bruijn
>> optimization.
>>
>> A more interesting (and serious) question is whether FATE is broken if
>> int's are 64 bits. I did some digging, and found the following from
>> "The Definitive Guide to GCC" - On GCC prior to 4.x, there was a flag
>> -mint64, documented as follows (see e.g
>> https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc.pdf):
>> "Force int and long types to be 64 bits wide. See -mlong32 for an
>> explanation of the default and the way that the pointer size is
>> determined".
>>
>> This should be helpful in setting up a FATE client to test (and
>> possibly fix) bad code that assumed int = 32 bits. I myself can't
>> easily run such an outdated GCC, but I noticed a bunch of clients
>> running GCC < 4.0 where this may be set up.
>
> This option was only valid on MIPS targets, not on x86_64 or other
> common platforms.  It produced code that was incompatible with the
> ABI, which made it not very useful if you want to link with system
> libraries.  It was therefore removed.
>
> Although it would be possible to modify gcc to add a new x86_64 target
> where int is 64 bits, you would probably have the same ABI issues
> because libc and other system libraries would be assuming a 32-bit
> int.

Well, can't you make the whole platform use 64 bit ints, e.g building
libc and other system libraries from source to use 64 bit ints? Please
note that this is just to get a more complete understanding, not
necessarily that this should be done.

>
>>
>> Regards,
>> Ganesh
> ___
> 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