[FFmpeg-devel] [PATCH] Add support for RockChip Media Process Platform

2017-09-09 Thread LongChair . 
From: LongChair 

This adds hardware decoding for h264 / HEVC / VP8 using MPP Rockchip API.
Will return frames holding an AVDRMFrameDescriptor struct in buf[0] that allows 
drm / dmabuf usage.
Was tested on RK3288 (TinkerBoard) and RK3328.

Changes from Previous patch :
- Frame colorspace info is now filled.
- Frame interlacing is now filled (Note : currently had a bug in mpp which will 
be fixed soon by rockchip, will set the frame to progressive).
- hw_frame_context returns none as format for the rockchip specific 10 bits.
- Added support for MPEG4 codec
- Added support for VP9 codec.
- the ION format has been kept for MPP init (rather than DRM) as this is the 
only one working right, using DRM format will cause assertions upon close.
- Other minor comments have been taken into account
---
 Changelog  |   1 +
 configure  |  16 ++
 libavcodec/Makefile|   5 +
 libavcodec/allcodecs.c |   5 +
 libavcodec/rkmppdec.c  | 584 +
 5 files changed, 611 insertions(+)
 create mode 100644 libavcodec/rkmppdec.c

diff --git a/Changelog b/Changelog
index 189a803..ccf78b2 100644
--- a/Changelog
+++ b/Changelog
@@ -44,6 +44,7 @@ version :
 - drop deprecated qtkit input device (use avfoundation instead)
 - despill video filter
 - haas audio filter
+- Rockchip MPP hardware decoding
 
 version 3.3:
 - CrystalHD decoder moved to new decode API
diff --git a/configure b/configure
index 3ba27c5..cbff908 100755
--- a/configure
+++ b/configure
@@ -314,6 +314,7 @@ External library support:
   --disable-nvenc  disable Nvidia video encoding code [autodetect]
   --enable-omx enable OpenMAX IL code [no]
   --enable-omx-rpi enable OpenMAX IL code for Raspberry Pi [no]
+  --enable-rkmpp   enable Rockchip Media Process Platform code [no]
   --disable-vaapi  disable Video Acceleration API (mainly Unix/Intel) 
code [autodetect]
   --disable-vdadisable Apple Video Decode Acceleration code 
[autodetect]
   --disable-vdpau  disable Nvidia Video Decode and Presentation API 
for Unix code [autodetect]
@@ -1545,6 +1546,7 @@ EXTERNAL_LIBRARY_VERSION3_LIST="
 libopencore_amrnb
 libopencore_amrwb
 libvo_amrwbenc
+rkmpp
 "
 
 EXTERNAL_LIBRARY_GPLV3_LIST="
@@ -2774,6 +2776,8 @@ h264_qsv_decoder_deps="libmfx"
 h264_qsv_decoder_select="h264_mp4toannexb_bsf h264_parser qsvdec 
h264_qsv_hwaccel"
 h264_qsv_encoder_deps="libmfx"
 h264_qsv_encoder_select="qsvenc"
+h264_rkmpp_decoder_deps="rkmpp"
+h264_rkmpp_decoder_select="h264_mp4toannexb_bsf"
 h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264"
 h264_vaapi_encoder_select="vaapi_encode golomb"
 h264_vda_decoder_deps="vda"
@@ -2789,6 +2793,8 @@ hevc_qsv_decoder_deps="libmfx"
 hevc_qsv_decoder_select="hevc_mp4toannexb_bsf hevc_parser qsvdec 
hevc_qsv_hwaccel"
 hevc_qsv_encoder_deps="libmfx"
 hevc_qsv_encoder_select="hevcparse qsvenc"
+hevc_rkmpp_decoder_deps="rkmpp"
+hevc_rkmpp_decoder_select="hevc_mp4toannexb_bsf"
 hevc_vaapi_encoder_deps="VAEncPictureParameterBufferHEVC"
 hevc_vaapi_encoder_select="vaapi_encode golomb"
 mjpeg_cuvid_decoder_deps="cuda cuvid"
@@ -2812,6 +2818,7 @@ mpeg4_cuvid_decoder_deps="cuda cuvid"
 mpeg4_mediacodec_decoder_deps="mediacodec"
 mpeg4_mmal_decoder_deps="mmal"
 mpeg4_omx_encoder_deps="omx"
+mpeg4_rkmpp_decoder_deps="rkmpp"
 mpeg4_vdpau_decoder_deps="vdpau"
 mpeg4_vdpau_decoder_select="mpeg4_decoder"
 mpeg_vdpau_decoder_deps="vdpau"
@@ -2828,10 +2835,12 @@ vp8_cuvid_decoder_deps="cuda cuvid"
 vp8_mediacodec_decoder_deps="mediacodec"
 vp8_qsv_decoder_deps="libmfx"
 vp8_qsv_decoder_select="qsvdec vp8_qsv_hwaccel vp8_parser"
+vp8_rkmpp_decoder_deps="rkmpp"
 vp8_vaapi_encoder_deps="VAEncPictureParameterBufferVP8"
 vp8_vaapi_encoder_select="vaapi_encode"
 vp9_cuvid_decoder_deps="cuda cuvid"
 vp9_mediacodec_decoder_deps="mediacodec"
+vp9_rkmpp_decoder_deps="rkmpp"
 vp9_vaapi_encoder_deps="VAEncPictureParameterBufferVP9"
 vp9_vaapi_encoder_select="vaapi_encode"
 wmv3_crystalhd_decoder_select="crystalhd"
@@ -6032,6 +6041,13 @@ enabled openssl   && { use_pkg_config openssl 
openssl/ssl.h OPENSSL_init
check_lib openssl openssl/ssl.h 
SSL_library_init -lssl32 -leay32 ||
check_lib openssl openssl/ssl.h 
SSL_library_init -lssl -lcrypto -lws2_32 -lgdi32 ||
die "ERROR: openssl not found"; }
+enabled rkmpp && { { require_pkg_config rockchip_mpp 
rockchip/rk_mpi.h mpp_create ||
+ die "ERROR : Rockchip MPP was not found."; } 
&&
+   { check_func_headers rockchip/rk_mpi_cmd.h 
"MPP_DEC_GET_FREE_PACKET_SLOT_COUNT" ||
+ die "ERROR: Rockchip MPP is outdated, please 
get a more recent one."; } &&
+   { enabled libdrm ||
+ die "ERROR: rkmpp requires --enable-libdrm"; }
+

Re: [FFmpeg-devel] [PATCH 1/7] lavf: add cue sheet demuxer

2017-09-09 Thread Paul B Mahol 
On 8/2/17, Rodger Combs  wrote:
> ---
>  Changelog|   2 +
>  doc/demuxers.texi|  17 
>  libavformat/Makefile |   1 +
>  libavformat/allformats.c |   1 +
>  libavformat/cuedec.c | 246
> +++
>  libavformat/version.h|   2 +-
>  6 files changed, 268 insertions(+), 1 deletion(-)
>  create mode 100644 libavformat/cuedec.c
>

What is status of this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_mpeg2: fix frame rate calc error when use, time_base.

2017-09-09 Thread Mark Thompson 
On 06/09/17 04:14, Jun Zhao wrote:
> From a6f3aaa9c1ff6d35d19eef587a49c04916fceca1 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Tue, 5 Sep 2017 23:07:15 -0400
> Subject: [PATCH] lavc/vaapi_encode_mpeg2: fix frame rate calc error when use
>  time_base.
> 
> fix frame rate calc error when use time_base.
> 
> Signed-off-by: Yun Zhou 
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/vaapi_encode_mpeg2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vaapi_encode_mpeg2.c b/libavcodec/vaapi_encode_mpeg2.c
> index fbddfa5d5a..dc918884e8 100644
> --- a/libavcodec/vaapi_encode_mpeg2.c
> +++ b/libavcodec/vaapi_encode_mpeg2.c
> @@ -208,7 +208,7 @@ static int 
> vaapi_encode_mpeg2_init_sequence_params(AVCodecContext *avctx)
>  if (avctx->framerate.num > 0 && avctx->framerate.den > 0)
>  vseq->frame_rate = (float)avctx->framerate.num / 
> avctx->framerate.den;
>  else
> -vseq->frame_rate = (float)avctx->time_base.num / 
> avctx->time_base.den;
> +vseq->frame_rate = (float)avctx->time_base.den / 
> avctx->time_base.num;
>  
>  vseq->aspect_ratio_information = 1;
>  vseq->vbv_buffer_size = avctx->rc_buffer_size / (16 * 1024);
> -- 
> 2.11.0
> 

LGTM, applied.

(I can't find anything which actually reads this field, though - the MPEG-2 
encoder in the i965 driver only supports CQP.  Is there?)

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

Re: [FFmpeg-devel] [V5 1/4] lavc/vaapi_encode: Change the slice/parameter buffers to dynamic alloc.

2017-09-09 Thread Mark Thompson 
On 06/09/17 03:35, Jun Zhao wrote:
> On 2017/8/28 20:28, Mark Thompson wrote:
>> On 24/08/17 02:13, Jun Zhao wrote:
>>> V5: - In h265_vaapi encoder, when setting slice number > max slice number
>>>   supported by driver, report error and return. Same as h264_vaapi.
>>> - Clean the logic when setting first_slice_segment_in_pic_flags  
>>> V4: - Change the array malloc function.
>>> - Clean the pointless condition check when free the memory.
>>>
>>> V3: - Making pic->slices be VAAPIEncodeSlice* instead of
>>> VAAPIEncodeSlice**. - Fix resource (vaBuffer) lead when realloc
>>> pic->param_buffers fail. - Adjust max_slices location in
>>> VAAPIEncodeContext. - Re-work distributing the macro-blocks for
>>> multi-slices function. V2: - Change the slice/parameter buffers to
>>> dynamic alloc and split the mutil-slice support for AVC/HEVC.
>>>
>>>
>>> From a1078385915d53ec94559ed897eb253e537d1f65 Mon Sep 17 00:00:00 2001
>>> From: Jun Zhao 
>>> Date: Mon, 31 Jul 2017 22:46:23 -0400
>>> Subject: [V5 1/4] lavc/vaapi_encode: Change the slice/parameter buffers to
>>>  dynamic alloc.
>>>
>>> Change the slice/parameter buffers to be allocated dynamically.
>>>
>>> Signed-off-by: Wang, Yi A 
>>> Signed-off-by: Jun Zhao 
>>> ---
>>>  libavcodec/vaapi_encode.c | 44 
>>>  libavcodec/vaapi_encode.h |  6 ++
>>>  2 files changed, 34 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
>>> index 22114bedbe..f49e0e3b91 100644
>>> --- a/libavcodec/vaapi_encode.c
>>> +++ b/libavcodec/vaapi_encode.c
>>> @@ -36,13 +36,18 @@ static int 
>>> vaapi_encode_make_packed_header(AVCodecContext *avctx,
>>>  VAAPIEncodeContext *ctx = avctx->priv_data;
>>>  VAStatus vas;
>>>  VABufferID param_buffer, data_buffer;
>>> +VABufferID *tmp;
>>>  VAEncPackedHeaderParameterBuffer params = {
>>>  .type = type,
>>>  .bit_length = bit_len,
>>>  .has_emulation_bytes = 1,
>>>  };
>>>  
>>> -av_assert0(pic->nb_param_buffers + 2 <= MAX_PARAM_BUFFERS);
>>> +tmp = av_realloc_array(pic->param_buffers, sizeof(*tmp), 
>>> pic->nb_param_buffers + 2);
>>> +if (!tmp) {
>>> +return AVERROR(ENOMEM);
>>> +}
>>> +pic->param_buffers = tmp;
>>>  
>>>  vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
>>>   VAEncPackedHeaderParameterBufferType,
>>> @@ -77,9 +82,14 @@ static int vaapi_encode_make_param_buffer(AVCodecContext 
>>> *avctx,
>>>  {
>>>  VAAPIEncodeContext *ctx = avctx->priv_data;
>>>  VAStatus vas;
>>> +VABufferID *tmp;
>>>  VABufferID buffer;
>>>  
>>> -av_assert0(pic->nb_param_buffers + 1 <= MAX_PARAM_BUFFERS);
>>> +tmp = av_realloc_array(pic->param_buffers, sizeof(*tmp), 
>>> pic->nb_param_buffers + 1);
>>> +if (!tmp) {
>>> +return AVERROR(ENOMEM);
>>> +}
>>> +pic->param_buffers = tmp;
>>>  
>>>  vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
>>>   type, len, 1, data, &buffer);
>>> @@ -313,15 +323,14 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
>>>  }
>>>  }
>>>  
>>> -av_assert0(pic->nb_slices <= MAX_PICTURE_SLICES);
>>> +pic->slices = av_mallocz_array(pic->nb_slices, sizeof(*pic->slices));
>>> +if (!pic->slices) {
>>> +err = AVERROR(ENOMEM);
>>> +goto fail;
>>> +}
>>>  for (i = 0; i < pic->nb_slices; i++) {
>>> -slice = av_mallocz(sizeof(*slice));
>>> -if (!slice) {
>>> -err = AVERROR(ENOMEM);
>>> -goto fail;
>>> -}
>>> +slice = &pic->slices[i];
>>>  slice->index = i;
>>> -pic->slices[i] = slice;
>>>  
>>>  if (ctx->codec->slice_params_size > 0) {
>>>  slice->codec_slice_params = 
>>> av_mallocz(ctx->codec->slice_params_size);
>>> @@ -425,8 +434,16 @@ fail_with_picture:
>>>  fail:
>>>  for(i = 0; i < pic->nb_param_buffers; i++)
>>>  vaDestroyBuffer(ctx->hwctx->display, pic->param_buffers[i]);
>>> +for (i = 0; i < pic->nb_slices; i++) {
>>> +if (pic->slices) {
>>> +av_freep(&pic->slices[i].priv_data);
>>> +av_freep(&pic->slices[i].codec_slice_params);
>>> +}
>>> +}
>>>  fail_at_end:
>>>  av_freep(&pic->codec_picture_params);
>>> +av_freep(&pic->param_buffers);
>>> +av_freep(&pic->slices);
>>>  av_frame_free(&pic->recon_image);
>>>  av_buffer_unref(&pic->output_buffer_ref);
>>>  pic->output_buffer = VA_INVALID_ID;
>>> @@ -535,15 +552,18 @@ static int vaapi_encode_free(AVCodecContext *avctx,
>>>  vaapi_encode_discard(avctx, pic);
>>>  
>>>  for (i = 0; i < pic->nb_slices; i++) {
>>> -av_freep(&pic->slices[i]->priv_data);
>>> -av_freep(&pic->slices[i]->codec_slice_params);
>>> -av_freep(&pic->slices[i]);
>>> +if (pic->slices) {
>>> +av_freep(&pic->slices[i].priv_data);
>>>

Re: [FFmpeg-devel] [PATCH V6] lavfi/scale_vaapi: add denoise/sharpness support.

2017-09-09 Thread Mark Thompson 
On 04/08/17 08:25, Jun Zhao wrote:
> V6 : - Re-work with current scale_vaapi and double check i965 have fix the 
> sharpness issue.
>https://bugs.freedesktop.org/show_bug.cgi?id=96988
> v5 : - fix the commit message as review(Mark Thompson and Moritz Barsnick)
>  - change the magic filter numbers 8 with VAProcFilterCount
>  - check multiple filters because multiple filters aren't supported in
>the driver now
> v4 : - fix sharpless typo(sharpless -> sharpness)
>  - when don't support denoise/sharpness, report the error and return
>  - fix denoise/sharpness params buffer leak in error handle
> v3 : fix sharpless mapping issue
> v2 : fix filter support flag check logic issue
> 

I still think this approach splicing it into the scale filter is an ugly hack 
(as the previous time it was submitted), and that the standalone filter (as I 
wrote a proof-of-concept for last time) would be more sensible.

(Though if everyone else really thinks that this is a good idea then I won't 
protest that hard.)

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

Re: [FFmpeg-devel] [V5 1/4] lavc/vaapi_encode: Change the slice/parameter buffers to dynamic alloc.

2017-09-09 Thread Mark Thompson 
On 09/09/17 11:28, Mark Thompson wrote:
> On 06/09/17 03:35, Jun Zhao wrote:
>> On 2017/8/28 20:28, Mark Thompson wrote:
>>> On 24/08/17 02:13, Jun Zhao wrote:
 V5: - In h265_vaapi encoder, when setting slice number > max slice number
   supported by driver, report error and return. Same as h264_vaapi.
 - Clean the logic when setting first_slice_segment_in_pic_flags  
 V4: - Change the array malloc function.
 - Clean the pointless condition check when free the memory.

 V3: - Making pic->slices be VAAPIEncodeSlice* instead of
 VAAPIEncodeSlice**. - Fix resource (vaBuffer) lead when realloc
 pic->param_buffers fail. - Adjust max_slices location in
 VAAPIEncodeContext. - Re-work distributing the macro-blocks for
 multi-slices function. V2: - Change the slice/parameter buffers to
 dynamic alloc and split the mutil-slice support for AVC/HEVC.


 From a1078385915d53ec94559ed897eb253e537d1f65 Mon Sep 17 00:00:00 2001
 From: Jun Zhao 
 Date: Mon, 31 Jul 2017 22:46:23 -0400
 Subject: [V5 1/4] lavc/vaapi_encode: Change the slice/parameter buffers to
  dynamic alloc.

 Change the slice/parameter buffers to be allocated dynamically.

 Signed-off-by: Wang, Yi A 
 Signed-off-by: Jun Zhao 
 ---
  libavcodec/vaapi_encode.c | 44 
 
  libavcodec/vaapi_encode.h |  6 ++
  2 files changed, 34 insertions(+), 16 deletions(-)

 diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
 index 22114bedbe..f49e0e3b91 100644
 --- a/libavcodec/vaapi_encode.c
 +++ b/libavcodec/vaapi_encode.c
 @@ -36,13 +36,18 @@ static int 
 vaapi_encode_make_packed_header(AVCodecContext *avctx,
  VAAPIEncodeContext *ctx = avctx->priv_data;
  VAStatus vas;
  VABufferID param_buffer, data_buffer;
 +VABufferID *tmp;
  VAEncPackedHeaderParameterBuffer params = {
  .type = type,
  .bit_length = bit_len,
  .has_emulation_bytes = 1,
  };
  
 -av_assert0(pic->nb_param_buffers + 2 <= MAX_PARAM_BUFFERS);
 +tmp = av_realloc_array(pic->param_buffers, sizeof(*tmp), 
 pic->nb_param_buffers + 2);
 +if (!tmp) {
 +return AVERROR(ENOMEM);
 +}
 +pic->param_buffers = tmp;
  
  vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
   VAEncPackedHeaderParameterBufferType,
 @@ -77,9 +82,14 @@ static int 
 vaapi_encode_make_param_buffer(AVCodecContext *avctx,
  {
  VAAPIEncodeContext *ctx = avctx->priv_data;
  VAStatus vas;
 +VABufferID *tmp;
  VABufferID buffer;
  
 -av_assert0(pic->nb_param_buffers + 1 <= MAX_PARAM_BUFFERS);
 +tmp = av_realloc_array(pic->param_buffers, sizeof(*tmp), 
 pic->nb_param_buffers + 1);
 +if (!tmp) {
 +return AVERROR(ENOMEM);
 +}
 +pic->param_buffers = tmp;
  
  vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
   type, len, 1, data, &buffer);
 @@ -313,15 +323,14 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
  }
  }
  
 -av_assert0(pic->nb_slices <= MAX_PICTURE_SLICES);
 +pic->slices = av_mallocz_array(pic->nb_slices, sizeof(*pic->slices));
 +if (!pic->slices) {
 +err = AVERROR(ENOMEM);
 +goto fail;
 +}
  for (i = 0; i < pic->nb_slices; i++) {
 -slice = av_mallocz(sizeof(*slice));
 -if (!slice) {
 -err = AVERROR(ENOMEM);
 -goto fail;
 -}
 +slice = &pic->slices[i];
  slice->index = i;
 -pic->slices[i] = slice;
  
  if (ctx->codec->slice_params_size > 0) {
  slice->codec_slice_params = 
 av_mallocz(ctx->codec->slice_params_size);
 @@ -425,8 +434,16 @@ fail_with_picture:
  fail:
  for(i = 0; i < pic->nb_param_buffers; i++)
  vaDestroyBuffer(ctx->hwctx->display, pic->param_buffers[i]);
 +for (i = 0; i < pic->nb_slices; i++) {
 +if (pic->slices) {
 +av_freep(&pic->slices[i].priv_data);
 +av_freep(&pic->slices[i].codec_slice_params);
 +}
 +}
  fail_at_end:
  av_freep(&pic->codec_picture_params);
 +av_freep(&pic->param_buffers);
 +av_freep(&pic->slices);
  av_frame_free(&pic->recon_image);
  av_buffer_unref(&pic->output_buffer_ref);
  pic->output_buffer = VA_INVALID_ID;
 @@ -535,15 +552,18 @@ static int vaapi_encode_free(AVCodecContext *avctx,
  vaapi_encode_discard(avctx, pic);
  
  for (i = 0; i < pic->nb_slices; i++) {
 -av_freep(&pic->slices[i]->priv_data);
 -av_freep

Re: [FFmpeg-devel] [PATCH] Add support for RockChip Media Process Platform

2017-09-09 Thread Mark Thompson 
On 09/09/17 08:00, LongChair . wrote:
> From: LongChair 
> 
> This adds hardware decoding for h264 / HEVC / VP8 using MPP Rockchip API.
> Will return frames holding an AVDRMFrameDescriptor struct in buf[0] that 
> allows drm / dmabuf usage.
> Was tested on RK3288 (TinkerBoard) and RK3328.
> 
> Changes from Previous patch :
> - Frame colorspace info is now filled.
> - Frame interlacing is now filled (Note : currently had a bug in mpp which 
> will be fixed soon by rockchip, will set the frame to progressive).
> - hw_frame_context returns none as format for the rockchip specific 10 bits.
> - Added support for MPEG4 codec
> - Added support for VP9 codec.
> - the ION format has been kept for MPP init (rather than DRM) as this is the 
> only one working right, using DRM format will cause assertions upon close.
> - Other minor comments have been taken into account
> ---

Patch looks pretty good now (some minor issues below); mainly I've been testing 
it.


Is VP9 supported by the RK3288?  Trying to use it (both 8- and 10-bit) I get:

[ 5110.660270] rk-vcodec ff9a.vpu-service: can not find -22 buffer in list
[ 5110.666094] rk-vcodec ff9a.vpu-service: reg 28 fd 4 ion map iommu failed
[ 5110.673203] rk-vcodec ff9a.vpu-service: can not find -22 buffer in list
[ 5110.679026] rk_vcodec: reg_init:1242: error: translate reg address failed, 
dumping regs
[ 5110.683991] Unhandled fault: page domain fault (0x01b) at 0x81817360
[ 5110.688851] pgd = ec7e4000
[ 5110.693709] [81817360] *pgd=2a81c831, *pte=3a4f675f, *ppte=3a4f6c7f
... lots of dump ...
[ 5111.257947] Process mpp_dec_parser (pid: 14424, stack limit = 0xdd85a218)
... lots of dump ...
[ 5111.362078] [] (reg_init) from [] 
(vpu_service_ioctl+0x298/0x744)
[ 5111.367023] [] (vpu_service_ioctl) from [] 
(do_vfs_ioctl+0x5b0/0x690)
[ 5111.371974] [] (do_vfs_ioctl) from [] 
(SyS_ioctl+0x5c/0x84)
[ 5111.376956] [] (SyS_ioctl) from [] 
(ret_fast_syscall+0x0/0x3c)
[ 5111.381917] Code: e51b3108 e1a02006 e51b00e0 e1a01007 (e7933106) 
[ 5111.386917] ---[ end trace 866a2bbc379f58ce ]---
[ 5115.649373] rk-vcodec ff9a.vpu-service: closed

The ffmpeg process then has to be killed.

If VP9 isn't supported, can we determine that somehow and not try to decode at 
all?

I can't get MPEG-4 part 2 to work either.  I get a lot of timeouts, then maybe 
a lot of green frames?  (Tried a few files.)

H.264, H.265 and VP8 still work for me.


The output for H.264 (didn't look at others carefully here) seems to be missing 
some frames.  For example, if I decode , there 
should be 17 frames in the output, but h264_rkmpp only gives me 4.

Running:

./ffmpeg_g -y -c:v h264_rkmpp -i ~/test/NL1_Sony_D.jsv -an -vf 
hwdownload,format=nv12,format=yuv420p out_hw.yuv
./ffmpeg_g -y -i ~/test/NL1_Sony_D.jsv -an out_sw.yuv

$ ls -l out_*
-rw-r--r-- 1 linaro linaro 152064 Sep  9 12:45 out_hw.yuv
-rw-r--r-- 1 linaro linaro 646272 Sep  9 12:44 out_sw.yuv

The missing frames seem to be the ones at the beginning of the stream:

$ cmp out_sw.yuv out_hw.yuv 
out_sw.yuv out_hw.yuv differ: byte 1, line 1
$ cmp out_sw.yuv out_hw.yuv 494208 0
$ 

>  Changelog  |   1 +
>  configure  |  16 ++
>  libavcodec/Makefile|   5 +
>  libavcodec/allcodecs.c |   5 +
>  libavcodec/rkmppdec.c  | 584 
> +
>  5 files changed, 611 insertions(+)
>  create mode 100644 libavcodec/rkmppdec.c
> 
> diff --git a/Changelog b/Changelog
> index 189a803..ccf78b2 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -44,6 +44,7 @@ version :
>  - drop deprecated qtkit input device (use avfoundation instead)
>  - despill video filter
>  - haas audio filter
> +- Rockchip MPP hardware decoding
>  
>  version 3.3:
>  - CrystalHD decoder moved to new decode API
> diff --git a/configure b/configure
> index 3ba27c5..cbff908 100755
> --- a/configure
> +++ b/configure
> @@ -314,6 +314,7 @@ External library support:
>--disable-nvenc  disable Nvidia video encoding code [autodetect]
>--enable-omx enable OpenMAX IL code [no]
>--enable-omx-rpi enable OpenMAX IL code for Raspberry Pi [no]
> +  --enable-rkmpp   enable Rockchip Media Process Platform code [no]
>--disable-vaapi  disable Video Acceleration API (mainly 
> Unix/Intel) code [autodetect]
>--disable-vdadisable Apple Video Decode Acceleration code 
> [autodetect]
>--disable-vdpau  disable Nvidia Video Decode and Presentation API 
> for Unix code [autodetect]
> @@ -1545,6 +1546,7 @@ EXTERNAL_LIBRARY_VERSION3_LIST="
>  libopencore_amrnb
>  libopencore_amrwb
>  libvo_amrwbenc
> +rkmpp
>  "
>  
>  EXTERNAL_LIBRARY_GPLV3_LIST="
> @@ -2774,6 +2776,8 @@ h264_qsv_decoder_deps="libmfx"
>  h264_qsv_decoder_select="h264_mp4toannexb_bsf h264_parser qsvdec 
> h264_qsv_hwaccel"
>  h264_qsv_encoder_deps="libmfx"
>  h264_qsv_encoder_select="qsvenc"
> +h264_rkmpp_decoder_deps="rkmpp"
> +h264_rkmpp_decoder_select="h264_mp4toannexb_bsf"
>

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter/vf_zoompan: fix specific corner case when no frame was ever requested from input

2017-09-09 Thread Paul B Mahol 
On 9/7/17, Nicolas George  wrote:
> Le primidi 21 fructidor, an CCXXV, Paul B Mahol a ecrit :
>> ffmpeg -lavfi
>> "testsrc2,trim=end_frame=1,zoompan=z='min(zoom+0.0015,1.5)':d=700:x='iw/2-(iw/zoom/2)':y='ih/2-(ih/zoom/2)'"
>> -f framecrc -
>>
>> Should output 700 frames and not 1 frame.
>
> It does. So my patch is valid. Will push soon unless I see a complete
> console output proving it is not.

When amerge filter will be improved?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vp9: Add tile threading support

2017-09-09 Thread Michael Niedermayer 
On Fri, Sep 08, 2017 at 04:02:49AM +0700, Ilia Valiakhmetov wrote:
> Signed-off-by: Ilia Valiakhmetov 
> 
> v8:
> ---
>  libavcodec/vp9.c | 665 
> ++-
>  libavcodec/vp9_mc_template.c | 202 ++---
>  libavcodec/vp9block.c| 522 -
>  libavcodec/vp9dec.h  | 103 ---
>  libavcodec/vp9mvs.c  |  97 ---
>  libavcodec/vp9prob.c |  64 ++---
>  libavcodec/vp9recon.c| 153 +-
>  7 files changed, 1051 insertions(+), 755 deletions(-)

This breaks build
make distclean ; ./configure --disable-pthreads && make -j12

...
libavcodec/libavcodec.a(vp9.o): In function `vp9_decode_frame':
libavcodec/vp9.c:1631: undefined reference to 
`ff_slice_thread_execute_with_mainfunc'


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

[FFmpeg-devel] [PATCH] avcodec/dirac_vlc: limit res_bits in APPEND_RESIDUE()

2017-09-09 Thread Michael Niedermayer 
Fixes: runtime error: left shift of 1073741838 by 1 places cannot be 
represented in type 'int32_t' (aka 'int')
Fixes: 3279/clusterfuzz-testcase-minimized-4564805744590848

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

diff --git a/libavcodec/dirac_vlc.c b/libavcodec/dirac_vlc.c
index bd37f31f46..bb525f89d8 100644
--- a/libavcodec/dirac_vlc.c
+++ b/libavcodec/dirac_vlc.c
@@ -37,7 +37,7 @@
 
 #define APPEND_RESIDUE(N, M)   
\
 N  |= M >> (N ## _bits);   
\
-N ## _bits +=  (M ## _bits)
+N ## _bits  = (N ## _bits + (M ## _bits)) & 63
 
 int ff_dirac_golomb_read_32bit(DiracGolombLUT *lut_ctx, const uint8_t *buf,
int bytes, uint8_t *_dst, int coeffs)
@@ -56,9 +56,6 @@ int ff_dirac_golomb_read_32bit(DiracGolombLUT *lut_ctx, const 
uint8_t *buf,
 if ((c_idx + 1) > coeffs)
 return c_idx;
 
-if (res_bits >= RSIZE_BITS)
-res_bits = res = 0;
-
 /* res_bits is a hint for better branch prediction */
 if (res_bits && l->sign) {
 int32_t coeff = 1;
@@ -99,9 +96,6 @@ int ff_dirac_golomb_read_16bit(DiracGolombLUT *lut_ctx, const 
uint8_t *buf,
 if ((c_idx + 1) > coeffs)
 return c_idx;
 
-if (res_bits >= RSIZE_BITS)
-res_bits = res = 0;
-
 if (res_bits && l->sign) {
 int32_t coeff = 1;
 APPEND_RESIDUE(res, l->preamble);
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/scpr: optimize shift loop.

2017-09-09 Thread Derek Buitenhuis 
On 9/8/2017 11:15 PM, James Almer wrote:
> It reads eight bytes at a time if the buffer is sufficiently aligned,
> then finishes reading the remaining bytes one at a time.
> If the buffer is unaligned, it reads everything one byte at a time like
> it used to.
> 
> See ff_h2645_extract_rbsp() and add_bytes_c() for another example of
> this optimization.

So put a comment, or at least put it in the commit message.

It isn't exactly straightforward; it's like reading Hex Rays output.

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

Re: [FFmpeg-devel] [PATCH] avformat/mux: stop delaying writing the header

2017-09-09 Thread Michael Niedermayer 
On Thu, Sep 07, 2017 at 04:17:24PM -0300, James Almer wrote:
> There's no need to wait for the first packet of every stream now that
> every bitstream filter behaves as intended.
> 
> Signed-off-by: James Almer 
> ---
> What should we do with the AVFMT_FLAG_AUTO_BSF flag? Do we deprecate
> it and force the automatic insertion of muxer-required bitstream
> filters now that the generic muxing code will always behave the same,
> or keep it to give the user a choice to apply said bitstream filters?
> I ask because some filters, like vp9_superframe, are necessary to
> avoid creating broken files, so it's not wise to allow the user to
> disable it.
> It would also go in line with AVCodec.bsfs, which is essentially a
> non-optional (for reasons made obvious in fa1749dd34) autobsf at the
> codec level instead of container level.
> 

> The change to fate-rgb24-mkv is a regression that can be prevented by
> committing https://ffmpeg.org/pipermail/ffmpeg-devel/2017-May/211311.html
> or a similar solution, maybe using avformat_init_output(), to make sure
> ffmpeg.c sets AVCodecParameters->field_order for the output stream before
> calling avformat_write_header().

i do see differences in other mkv output, i assume these are also from
field_order

one example
./ffmpeg -copyts -ss 11 -i ~/tickets/2263/2263-slow-ss.mkv -vframes 3 moon.mkv

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

[FFmpeg-devel] [PATCH] vp9: fix compilation with threading disabled.

2017-09-09 Thread Ronald S. Bultje 
---
 libavcodec/vp9.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index a71045e..499f357 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -1599,7 +1599,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 s->td[i].uveob[1] = s->td[i].uveob_base[1];
 }
 
-if (avctx->active_thread_type == FF_THREAD_SLICE) {
+if (HAVE_THREADS && avctx->active_thread_type == FF_THREAD_SLICE) {
 int tile_row, tile_col;
 
 assert(!pass);
-- 
2.8.1

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

Re: [FFmpeg-devel] [PATCH] avformat/mux: stop delaying writing the header

2017-09-09 Thread James Almer 
On 9/9/2017 12:41 PM, Michael Niedermayer wrote:
> On Thu, Sep 07, 2017 at 04:17:24PM -0300, James Almer wrote:
>> There's no need to wait for the first packet of every stream now that
>> every bitstream filter behaves as intended.
>>
>> Signed-off-by: James Almer 
>> ---
>> What should we do with the AVFMT_FLAG_AUTO_BSF flag? Do we deprecate
>> it and force the automatic insertion of muxer-required bitstream
>> filters now that the generic muxing code will always behave the same,
>> or keep it to give the user a choice to apply said bitstream filters?
>> I ask because some filters, like vp9_superframe, are necessary to
>> avoid creating broken files, so it's not wise to allow the user to
>> disable it.
>> It would also go in line with AVCodec.bsfs, which is essentially a
>> non-optional (for reasons made obvious in fa1749dd34) autobsf at the
>> codec level instead of container level.
>>
> 
>> The change to fate-rgb24-mkv is a regression that can be prevented by
>> committing https://ffmpeg.org/pipermail/ffmpeg-devel/2017-May/211311.html
>> or a similar solution, maybe using avformat_init_output(), to make sure
>> ffmpeg.c sets AVCodecParameters->field_order for the output stream before
>> calling avformat_write_header().
> 
> i do see differences in other mkv output, i assume these are also from
> field_order
> 
> one example
> ./ffmpeg -copyts -ss 11 -i ~/tickets/2263/2263-slow-ss.mkv -vframes 3 moon.mkv

Yes, as i said, the solution for this could be making ffmpeg.c use
avformat_init_output() and only call avformat_write_header() after the
output codecpar is "complete".
That being said, ffmpeg.c changing output codecpar->field_order based on
some heuristics like it's currently doing is weird. Or at least wrong in
its current form (There are different patches to change this, and even
suggestions to reimplement the field_order enum values in other threads).
See https://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/215669.html
and https://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/215698.html

I have a set of about 50 patches implementing AVOutputFormat.init() on
most if not all of the remaining muxers for this purpose. I can either
send them to the ml or push them to some repo, to avoid the email spam.
However you prefer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vp9: fix compilation with threading disabled.

2017-09-09 Thread gh0st 
This also fixes the warning.

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

diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index a71045e..f940d60 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -88,7 +88,7 @@ static void vp9_await_tile_progress(VP9Context *s, int
field, int n) {
 pthread_mutex_unlock(&s->progress_mutex);
 }
 #else
-static void vp9_free_entries(VP9Context *s) {}
+static void vp9_free_entries(AVCodecContext *avctx) {}
 static int vp9_alloc_entries(AVCodecContext *avctx, int n) { return 0; }
 static void vp9_report_tile_progress(VP9Context *s, int field, int n) {}
 static void vp9_await_tile_progress(VP9Context *s, int field, int n) {}
@@ -1599,7 +1599,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 s->td[i].uveob[1] = s->td[i].uveob_base[1];
 }

-if (avctx->active_thread_type == FF_THREAD_SLICE) {
+if (HAVE_THREADS && avctx->active_thread_type == FF_THREAD_SLICE) {
 int tile_row, tile_col;

 assert(!pass);
-- 
2.8.3


On Sat, Sep 9, 2017 at 11:13 PM, Ronald S. Bultje 
wrote:

> ---
>  libavcodec/vp9.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index a71045e..499f357 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -1599,7 +1599,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  s->td[i].uveob[1] = s->td[i].uveob_base[1];
>  }
>
> -if (avctx->active_thread_type == FF_THREAD_SLICE) {
> +if (HAVE_THREADS && avctx->active_thread_type == FF_THREAD_SLICE)
> {
>  int tile_row, tile_col;
>
>  assert(!pass);
> --
> 2.8.1
>
> ___
> 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] avcodec/dirac_vlc: limit res_bits in APPEND_RESIDUE()

2017-09-09 Thread Michael Niedermayer 
On Sat, Sep 09, 2017 at 03:51:45PM +0200, Michael Niedermayer wrote:
> Fixes: runtime error: left shift of 1073741838 by 1 places cannot be 
> represented in type 'int32_t' (aka 'int')
> Fixes: 3279/clusterfuzz-testcase-minimized-4564805744590848
> 
> Suggested-by: 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/dirac_vlc.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)

applied with changes suggested by atomnuker

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

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/scpr: optimize shift loop.

2017-09-09 Thread Michael Niedermayer 
On Sat, Sep 09, 2017 at 03:11:00PM +0100, Derek Buitenhuis wrote:
> On 9/8/2017 11:15 PM, James Almer wrote:
> > It reads eight bytes at a time if the buffer is sufficiently aligned,
> > then finishes reading the remaining bytes one at a time.
> > If the buffer is unaligned, it reads everything one byte at a time like
> > it used to.
> > 
> > See ff_h2645_extract_rbsp() and add_bytes_c() for another example of
> > this optimization.
> 
> So put a comment, or at least put it in the commit message.
> 
> It isn't exactly straightforward; it's like reading Hex Rays output.

ill repost the patch with comments

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

[FFmpeg-devel] [PATCH] avcodec/scpr: optimize shift loop.

2017-09-09 Thread Michael Niedermayer 
Speeds code up from 50sec to 15sec

Fixes Timeout
Fixes: 3242/clusterfuzz-testcase-5811951672229888

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

diff --git a/libavcodec/scpr.c b/libavcodec/scpr.c
index 37fbe7a106..cbe1bc40d9 100644
--- a/libavcodec/scpr.c
+++ b/libavcodec/scpr.c
@@ -826,8 +826,19 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 if (ret < 0)
 return ret;
 
+// scale up each sample by 8
 for (y = 0; y < avctx->height; y++) {
-for (x = 0; x < avctx->width * 4; x++) {
+// If the image is sufficiently aligned, compute 8 samples at once
+if (!(((uintptr_t)dst) & 7)) {
+uint64_t *dst64 = (uint64_t *)dst;
+int w = avctx->width>>1;
+for (x = 0; x < w; x++) {
+dst64[x] = (dst64[x] << 3) & 0xFCFCFCFCFCFCFCFCULL;
+}
+x *= 8;
+} else
+x = 0;
+for (; x < avctx->width * 4; x++) {
 dst[x] = dst[x] << 3;
 }
 dst += frame->linesize[0];
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH] vp9: fix compilation with threading disabled.

2017-09-09 Thread Michael Niedermayer 
On Sat, Sep 09, 2017 at 12:13:01PM -0400, Ronald S. Bultje wrote:
> ---
>  libavcodec/vp9.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

works

thanks

[...]
-- 
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] [PATCH] vp9: fix compilation with threading disabled.

2017-09-09 Thread Michael Niedermayer 
On Sat, Sep 09, 2017 at 11:24:12PM +0700, gh0st wrote:
> This also fixes the warning.
> 
> ---
>  libavcodec/vp9.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index a71045e..f940d60 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -88,7 +88,7 @@ static void vp9_await_tile_progress(VP9Context *s, int
> field, int n) {

This is corrupted by newlines

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

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


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

Re: [FFmpeg-devel] [PATCH] vp9: fix compilation with threading disabled.

2017-09-09 Thread gh0st 
Hm, I don't understand, what exactly is the problem? It applies fine for me.

On Sun, Sep 10, 2017 at 1:27 AM, Michael Niedermayer  wrote:

> On Sat, Sep 09, 2017 at 11:24:12PM +0700, gh0st wrote:
> > This also fixes the warning.
> >
> > ---
> >  libavcodec/vp9.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > index a71045e..f940d60 100644
> > --- a/libavcodec/vp9.c
> > +++ b/libavcodec/vp9.c
> > @@ -88,7 +88,7 @@ static void vp9_await_tile_progress(VP9Context *s, int
> > field, int n) {
>
> This is corrupted by newlines
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Observe your enemies, for they first find out your faults. -- Antisthenes
>
> ___
> 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] avcodec/scpr: optimize shift loop.

2017-09-09 Thread Brian Matherly 


On 9/9/2017 1:27 PM, Michael Niedermayer wrote:

+// If the image is sufficiently aligned, compute 8 samples at once
+if (!(((uintptr_t)dst) & 7)) {
+uint64_t *dst64 = (uint64_t *)dst;
+int w = avctx->width>>1;
+for (x = 0; x < w; x++) {
+dst64[x] = (dst64[x] << 3) & 0xFCFCFCFCFCFCFCFCULL;
+}
+x *= 8;
+} else
+x = 0;
+for (; x < avctx->width * 4; x++) {
  dst[x] = dst[x] << 3;
  }


Forgive me if I'm not understanding the code correctly, but couldn't you 
always apply the optimization if you align the first (up to) 7 samples?


Pseudocode:

uint64_t *dst64 = (uint64_t *)dst;
int w = avctx->width>>1;
x=0
// compute un-aligned beginning samples
for (; x < (avctx->width * 4) && (((uintptr_t)dst) & 7); x++) {
dst[x] = dst[x] << 3;
}
// compute aligned samples
for (; x < w; x+=8) {
dst64[x] = (dst64[x] << 3) & 0xFCFCFCFCFCFCFCFCULL;
}
x -= 8;
// compute un-aligned ending samples
for (; x < avctx->width * 4; x++) {
dst[x] = dst[x] << 3;
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vp9: fix compilation with threading disabled.

2017-09-09 Thread Michael Niedermayer 
On Sun, Sep 10, 2017 at 01:42:15AM +0700, gh0st wrote:
> Hm, I don't understand, what exactly is the problem? It applies fine for me.

The patch on the mailing list is corrupted by a newline produced
by something in the mail handling, likely on your side.
If you take the patch you sent, its very likely fine, the patch once
it got throgh all mail handling is not


> 
> On Sun, Sep 10, 2017 at 1:27 AM, Michael Niedermayer  > wrote:
> 
> > On Sat, Sep 09, 2017 at 11:24:12PM +0700, gh0st wrote:
> > > This also fixes the warning.
> > >
> > > ---
> > >  libavcodec/vp9.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > > index a71045e..f940d60 100644
> > > --- a/libavcodec/vp9.c
> > > +++ b/libavcodec/vp9.c
> > > @@ -88,7 +88,7 @@ static void vp9_await_tile_progress(VP9Context *s, int
> > > field, int n) {
> >
> > This is corrupted by newlines
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Observe your enemies, for they first find out your faults. -- Antisthenes
> >
> > ___
> > 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

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



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

Re: [FFmpeg-devel] [PATCH] avcodec/scpr: optimize shift loop.

2017-09-09 Thread Michael Niedermayer 
On Sat, Sep 09, 2017 at 04:37:52PM -0500, Brian Matherly wrote:
> 
> On 9/9/2017 1:27 PM, Michael Niedermayer wrote:
> >+// If the image is sufficiently aligned, compute 8 samples at 
> >once
> >+if (!(((uintptr_t)dst) & 7)) {
> >+uint64_t *dst64 = (uint64_t *)dst;
> >+int w = avctx->width>>1;
> >+for (x = 0; x < w; x++) {
> >+dst64[x] = (dst64[x] << 3) & 0xFCFCFCFCFCFCFCFCULL;
> >+}
> >+x *= 8;
> >+} else
> >+x = 0;
> >+for (; x < avctx->width * 4; x++) {
> >  dst[x] = dst[x] << 3;
> >  }
> 
> Forgive me if I'm not understanding the code correctly, but couldn't
> you always apply the optimization if you align the first (up to) 7
> samples?

yes, thats possible, it would be optimizing a case that probably
never occurs in practice though.

If people want, i can add code to handle misaligned cases ?

thx

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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

Re: [FFmpeg-devel] [PATCH] avcodec/scpr: optimize shift loop.

2017-09-09 Thread James Almer 
On 9/9/2017 7:47 PM, Michael Niedermayer wrote:
> On Sat, Sep 09, 2017 at 04:37:52PM -0500, Brian Matherly wrote:
>>
>> On 9/9/2017 1:27 PM, Michael Niedermayer wrote:
>>> +// If the image is sufficiently aligned, compute 8 samples at 
>>> once
>>> +if (!(((uintptr_t)dst) & 7)) {
>>> +uint64_t *dst64 = (uint64_t *)dst;
>>> +int w = avctx->width>>1;
>>> +for (x = 0; x < w; x++) {
>>> +dst64[x] = (dst64[x] << 3) & 0xFCFCFCFCFCFCFCFCULL;
>>> +}
>>> +x *= 8;
>>> +} else
>>> +x = 0;
>>> +for (; x < avctx->width * 4; x++) {
>>>  dst[x] = dst[x] << 3;
>>>  }
>>
>> Forgive me if I'm not understanding the code correctly, but couldn't
>> you always apply the optimization if you align the first (up to) 7
>> samples?
> 
> yes, thats possible, it would be optimizing a case that probably
> never occurs in practice though.
> 
> If people want, i can add code to handle misaligned cases ?

No, frame->data[0] should always be sufficiently aligned.
I hadn't even looked what dst pointed to, hence my original comment
about this change potentially not have an effect in all cases.

It's ok as is, no need to make it anymore complex.

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

[FFmpeg-devel] [PATCH 3/3] avcodec/clearvideo: Only output a frame if one is coded in the packet

2017-09-09 Thread Michael Niedermayer 
Fixes: Timeout (183 ms instead of about 20 sec)
Fixes: 3147/clusterfuzz-testcase-4870592182353920

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

diff --git a/libavcodec/clearvideo.c b/libavcodec/clearvideo.c
index a9fa0228bd..067942a131 100644
--- a/libavcodec/clearvideo.c
+++ b/libavcodec/clearvideo.c
@@ -290,11 +290,6 @@ static int clv_decode_frame(AVCodecContext *avctx, void 
*data,
 }
 
 frame_type = bytestream2_get_byte(&gb);
-if ((ret = ff_reget_buffer(avctx, c->pic)) < 0)
-return ret;
-
-c->pic->key_frame = frame_type & 0x20 ? 1 : 0;
-c->pic->pict_type = frame_type & 0x20 ? AV_PICTURE_TYPE_I : 
AV_PICTURE_TYPE_P;
 
 if (frame_type & 0x2) {
 if (buf_size < c->mb_width * c->mb_height) {
@@ -302,6 +297,12 @@ static int clv_decode_frame(AVCodecContext *avctx, void 
*data,
 return AVERROR_INVALIDDATA;
 }
 
+if ((ret = ff_reget_buffer(avctx, c->pic)) < 0)
+return ret;
+
+c->pic->key_frame = frame_type & 0x20 ? 1 : 0;
+c->pic->pict_type = frame_type & 0x20 ? AV_PICTURE_TYPE_I : 
AV_PICTURE_TYPE_P;
+
 bytestream2_get_be32(&gb); // frame size;
 c->ac_quant= bytestream2_get_byte(&gb);
 c->luma_dc_quant   = 32;
@@ -323,13 +324,13 @@ static int clv_decode_frame(AVCodecContext *avctx, void 
*data,
 mb_ret = ret;
 }
 }
-} else {
-}
 
-if ((ret = av_frame_ref(data, c->pic)) < 0)
-return ret;
+if ((ret = av_frame_ref(data, c->pic)) < 0)
+return ret;
 
-*got_frame = 1;
+*got_frame = 1;
+} else {
+}
 
 return mb_ret < 0 ? mb_ret : buf_size;
 }
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 2/3] avcodec/hevcdsp_template: Fix undefined shift in put_hevc_pel_bi_w_pixels

2017-09-09 Thread Michael Niedermayer 
Fixes: runtime error: left shift of negative value -95
Fixes: 3077/clusterfuzz-testcase-minimized-4684917524922368

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

diff --git a/libavcodec/hevcdsp_template.c b/libavcodec/hevcdsp_template.c
index 25f1a81202..75763ce85e 100644
--- a/libavcodec/hevcdsp_template.c
+++ b/libavcodec/hevcdsp_template.c
@@ -593,7 +593,7 @@ static void FUNC(put_hevc_pel_bi_w_pixels)(uint8_t *_dst, 
ptrdiff_t _dststride,
 ox1 = ox1 * (1 << (BIT_DEPTH - 8));
 for (y = 0; y < height; y++) {
 for (x = 0; x < width; x++) {
-dst[x] = av_clip_pixel(( (src[x] << (14 - BIT_DEPTH)) * wx1 + 
src2[x] * wx0 + ((ox0 + ox1 + 1) << log2Wd)) >> (log2Wd + 1));
+dst[x] = av_clip_pixel(( (src[x] << (14 - BIT_DEPTH)) * wx1 + 
src2[x] * wx0 + (ox0 + ox1 + 1) * (1 << log2Wd)) >> (log2Wd + 1));
 }
 src  += srcstride;
 dst  += dststride;
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 1/3] avcodec/diracdec: Fix overflow in DC computation

2017-09-09 Thread Michael Niedermayer 
Fixes: runtime error: signed integer overflow: 11896 + 2147483646 cannot be 
represented in type 'int'
Fixes: 3053/clusterfuzz-testcase-minimized-6355082062856192

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

diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index f2aed6057d..0abb8b0599 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -1421,7 +1421,7 @@ static void decode_block_params(DiracContext *s, 
DiracArith arith[8], DiracBlock
 if (!block->ref) {
 pred_block_dc(block, stride, x, y);
 for (i = 0; i < 3; i++)
-block->u.dc[i] += dirac_get_arith_int(arith+1+i, CTX_DC_F1, 
CTX_DC_DATA);
+block->u.dc[i] += (unsigned)dirac_get_arith_int(arith+1+i, 
CTX_DC_F1, CTX_DC_DATA);
 return;
 }
 
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH] vp9: fix compilation with threading disabled.

2017-09-09 Thread Ronald S. Bultje 
Hi,

On Sat, Sep 9, 2017 at 2:26 PM, Michael Niedermayer 
wrote:

> On Sat, Sep 09, 2017 at 12:13:01PM -0400, Ronald S. Bultje wrote:
> > ---
> >  libavcodec/vp9.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> works
>
> thanks


Doesn't actually work for me, for some reason --disable-pthreads also
removes the #include , causing pthread_*_t to not be defined.
New patch (little more invasive, sadly) sent that works for me after some
testing...

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

[FFmpeg-devel] [PATCH] vp9: fix compilation with threading disabled.

2017-09-09 Thread Ronald S. Bultje 
---
 libavcodec/vp9.c| 15 +--
 libavcodec/vp9dec.h |  2 ++
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index a71045e..f626f81 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -88,10 +88,8 @@ static void vp9_await_tile_progress(VP9Context *s, int 
field, int n) {
 pthread_mutex_unlock(&s->progress_mutex);
 }
 #else
-static void vp9_free_entries(VP9Context *s) {}
+static void vp9_free_entries(AVCodecContext *avctx) {}
 static int vp9_alloc_entries(AVCodecContext *avctx, int n) { return 0; }
-static void vp9_report_tile_progress(VP9Context *s, int field, int n) {}
-static void vp9_await_tile_progress(VP9Context *s, int field, int n) {}
 #endif
 
 static void vp9_frame_unref(AVCodecContext *avctx, VP9Frame *f)
@@ -1343,7 +1341,7 @@ static int decode_tiles(AVCodecContext *avctx,
 return 0;
 }
 
-
+#if HAVE_THREADS
 static av_always_inline
 int decode_tiles_mt(AVCodecContext *avctx, void *tdata, int jobnr,
   int threadnr)
@@ -1451,7 +1449,7 @@ int loopfilter_proc(AVCodecContext *avctx)
 }
 return 0;
 }
-
+#endif
 
 static int vp9_decode_frame(AVCodecContext *avctx, void *frame,
 int *got_frame, AVPacket *pkt)
@@ -1583,10 +1581,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
 ff_thread_finish_setup(avctx);
 }
 
+#if HAVE_THREADS
 if (avctx->active_thread_type & FF_THREAD_SLICE) {
 for (i = 0; i < s->sb_rows; i++)
 atomic_store(&s->entries[i], 0);
 }
+#endif
 
 do {
 for (i = 0; i < s->active_tile_cols; i++) {
@@ -1599,6 +1599,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 s->td[i].uveob[1] = s->td[i].uveob_base[1];
 }
 
+#if HAVE_THREADS
 if (avctx->active_thread_type == FF_THREAD_SLICE) {
 int tile_row, tile_col;
 
@@ -1629,7 +1630,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 
 ff_slice_thread_execute_with_mainfunc(avctx, decode_tiles_mt, 
loopfilter_proc, s->td, NULL, s->s.h.tiling.tile_cols);
-} else {
+} else
+#endif
+{
 ret = decode_tiles(avctx, data, size);
 if (ret < 0)
 return ret;
diff --git a/libavcodec/vp9dec.h b/libavcodec/vp9dec.h
index 15e0122..96c0e43 100644
--- a/libavcodec/vp9dec.h
+++ b/libavcodec/vp9dec.h
@@ -98,9 +98,11 @@ typedef struct VP9Context {
 VP56RangeCoder c;
 int pass, active_tile_cols;
 
+#if HAVE_THREADS
 pthread_mutex_t progress_mutex;
 pthread_cond_t progress_cond;
 atomic_int *entries;
+#endif
 
 uint8_t ss_h, ss_v;
 uint8_t last_bpp, bpp_index, bytesperpixel;
-- 
2.8.1

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

[FFmpeg-devel] [PATCH] libavformat/avidec: subtitle stream disable some non-interleaved process

2017-09-09 Thread tiejun.peng 
non-interleaved process call avio_seek frequently, it will cause some 
performance issues especially in network play scene, such as http/ftp protocol.

Signed-off-by: tiejun.peng 
---
 libavformat/avidec.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index b8a31dc..0220ea1 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -1520,7 +1520,8 @@ resync:
 }
 ast->seek_pos= 0;
 
-if (!avi->non_interleaved && st->nb_index_entries>1 && 
avi->index_loaded>1) {
+/* subtitle stream no need the next process, because subtitle's 
pkt->dts is always 0 */
+if (!avi->non_interleaved && st->nb_index_entries>1 && 
avi->index_loaded>1 && st->codecpar->codec_type != AVMEDIA_TYPE_SUBTITLE) {
 int64_t dts= av_rescale_q(pkt->dts, st->time_base, AV_TIME_BASE_Q);
 
 if (avi->dts_max - dts > 2*AV_TIME_BASE) {
@@ -1646,6 +1647,10 @@ static int check_stream_max_drift(AVFormatContext *s)
 AVStream *st = s->streams[i];
 AVIStream *ast = st->priv_data;
 int n = st->nb_index_entries;
+/* when stream is subtitle, don't change min_dts, because subtitle 
stream's dts is always 0 */
+if (st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE)
+continue;
+
 while (idx[i] < n && st->index_entries[idx[i]].pos < pos)
 idx[i]++;
 if (idx[i] < n) {
@@ -1661,6 +1666,10 @@ static int check_stream_max_drift(AVFormatContext *s)
 AVStream *st = s->streams[i];
 AVIStream *ast = st->priv_data;
 
+/* when stream is subtitle, don't change max_dts, because subtitle 
stream's dts is always 0 */
+if (st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE)
+continue;
+
 if (idx[i] && min_dts != INT64_MAX / 2) {
 int64_t dts;
 dts = av_rescale_q(st->index_entries[idx[i] - 1].timestamp /
-- 
2.7.4



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

[FFmpeg-devel] [PATCH] add missing ignore files

2017-09-09 Thread Jesse Liu 
---
 doc/examples/.gitignore | 1 +
 libavcodec/tests/.gitignore | 1 +
 libavutil/tests/.gitignore  | 1 +
 3 files changed, 3 insertions(+)

diff --git a/doc/examples/.gitignore b/doc/examples/.gitignore
index 6bd9dc1508..154c8415f6 100644
--- a/doc/examples/.gitignore
+++ b/doc/examples/.gitignore
@@ -10,6 +10,7 @@
 /filtering_audio
 /filtering_video
 /http_multiclient
+/hw_decode
 /metadata
 /muxing
 /pc-uninstalled
diff --git a/libavcodec/tests/.gitignore b/libavcodec/tests/.gitignore
index 31947bf9bb..7f9e3825b6 100644
--- a/libavcodec/tests/.gitignore
+++ b/libavcodec/tests/.gitignore
@@ -1,6 +1,7 @@
 /avfft
 /avpacket
 /cabac
+/celp_math
 /dct
 /fft
 /fft-fixed
diff --git a/libavutil/tests/.gitignore b/libavutil/tests/.gitignore
index a88cd97e50..8ede070887 100644
--- a/libavutil/tests/.gitignore
+++ b/libavutil/tests/.gitignore
@@ -34,6 +34,7 @@
 /pca
 /pixdesc
 /pixelutils
+/pixfmt_best
 /random_seed
 /rational
 /ripemd
-- 
2.11.0

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

[FFmpeg-devel] Confusion over temporal filters.

2017-09-09 Thread Richard Ling 
I'm thinking of adding a temporal filter (one that relies on context from
previous frames), and I've realised I'm a bit confused about how they
should work.

Say I open a file with ffplay and let it play up to frame 100.  Then I open
the same file with another instance of ffplay and seek directly to frame
100.  It seems to me that frame 100 should look the same in both cases.
Put another way, a specific set of filters, applied to a specific file,
should completely define what every frame of that file looks like.  Seeking
around in the file should not change that.  Is that right (in principle)?

So, looking at some of the existing temporal filters (eg. deflicker), I
don't think that is what happens.  They filter based on the frames
previously passed to the filter, and if the user seeks over a bunch of
frames, the filter will see frames as consecutive that are not actually
consecutive in the file, so it will give a different result.  Also, looking
at the API, I can't see a way to get the behaviour I expect.  I can't see a
way for a filter to ask its inputs for a frame from a different (specific)
time.  Is that right?

If my understanding is wrong, please let me know!

If my undersanding is correct, then I guess my questions are:
(1) is this behaviour a known issue (or a deliberate design choice)?
(2) is it OK for new temporal filters to keep the same behaviour as
existing ones -- that is, they will give different results when seeking
happens, compared to sequential processing?  If so I'll just do the same
thing for my filter.

Thanks in advance for your thoughts.
R
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Confusion over temporal filters.

2017-09-09 Thread Paul B Mahol 
On 9/10/17, Richard Ling  wrote:
> I'm thinking of adding a temporal filter (one that relies on context from
> previous frames), and I've realised I'm a bit confused about how they
> should work.
>
> Say I open a file with ffplay and let it play up to frame 100.  Then I open
> the same file with another instance of ffplay and seek directly to frame
> 100.  It seems to me that frame 100 should look the same in both cases.
> Put another way, a specific set of filters, applied to a specific file,
> should completely define what every frame of that file looks like.  Seeking
> around in the file should not change that.  Is that right (in principle)?
>
> So, looking at some of the existing temporal filters (eg. deflicker), I
> don't think that is what happens.  They filter based on the frames
> previously passed to the filter, and if the user seeks over a bunch of
> frames, the filter will see frames as consecutive that are not actually
> consecutive in the file, so it will give a different result.  Also, looking
> at the API, I can't see a way to get the behaviour I expect.  I can't see a
> way for a filter to ask its inputs for a frame from a different (specific)
> time.  Is that right?
>
> If my understanding is wrong, please let me know!
>
> If my undersanding is correct, then I guess my questions are:
> (1) is this behaviour a known issue (or a deliberate design choice)?

Both. There is no seeking in lavfi (yet).

> (2) is it OK for new temporal filters to keep the same behaviour as
> existing ones -- that is, they will give different results when seeking
> happens, compared to sequential processing?  If so I'll just do the same
> thing for my filter.

Yes, its OK.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel