[FFmpeg-devel] [PATCH] avformat/hlsenc: support http method for hls fmp4

[Steven Liu]

fix ticket: 7160

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index c27a66ea79..09478e7c45 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2147,6 +2147,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 int range_length = 0;
 uint8_t *buffer = NULL;
 VariantStream *vs = NULL;
+AVDictionary *options = NULL;
 
 for (i = 0; i < hls->nb_varstreams; i++) {
 vs = >var_streams[i];
@@ -2272,7 +2273,8 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 }
 vs->size = range_length;
 } else {
-ret = hlsenc_io_open(s, >out, vs->avf->url, NULL);
+set_http_options(s, , hls);
+ret = hlsenc_io_open(s, >out, vs->avf->url, );
 if (ret < 0) {
 av_log(s, AV_LOG_ERROR, "Failed to open file '%s'\n",
vs->avf->url);
-- 
2.15.1



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

Re: [FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper

[Steven Liu]

> On 28 Apr 2018, at 03:37, wm4  wrote:
> 
> From: wm4 
> 
> This can "demux" .vpy files.
> 
> Some minor code copied from other LGPL parts of FFmpeg.
> 
> Possibly support VS compat pixel formats.
> 
> TODO:
> - check whether VS can change format midstream
> - test vfr mode, return proper timestamps when using it
> - drop "lib" prefix?
> ---
> configure|   4 +
> libavformat/Makefile |   1 +
> libavformat/allformats.c |   1 +
> libavformat/libvapoursynth.c | 379 +++
> 4 files changed, 385 insertions(+)
> create mode 100644 libavformat/libvapoursynth.c
> 
> diff --git a/configure b/configure
> index 9fa1665496..17e46c5daa 100755
> --- a/configure
> +++ b/configure
> @@ -265,6 +265,7 @@ External library support:
>if openssl or gnutls is not used [no]
>   --enable-libtwolame  enable MP2 encoding via libtwolame [no]
>   --enable-libv4l2 enable libv4l2/v4l-utils [no]
> +  --enable-libvapoursynth  enable VapourSynth demuxer [no]
>   --enable-libvidstab  enable video stabilization using vid.stab [no]
>   --enable-libvmaf enable vmaf filter via libvmaf [no]
>   --enable-libvo-amrwbenc  enable AMR-WB encoding via libvo-amrwbenc [no]
> @@ -1712,6 +1713,7 @@ EXTERNAL_LIBRARY_LIST="
> libtheora
> libtwolame
> libv4l2
> +libvapoursynth
> libvorbis
> libvpx
> libwavpack
> @@ -3068,6 +3070,7 @@ libspeex_encoder_deps="libspeex"
> libspeex_encoder_select="audio_frame_queue"
> libtheora_encoder_deps="libtheora"
> libtwolame_encoder_deps="libtwolame"
> +libvapoursynth_demuxer_deps="libvapoursynth"
> libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
> libvorbis_decoder_deps="libvorbis"
> libvorbis_encoder_deps="libvorbis libvorbisenc"
> @@ -6041,6 +6044,7 @@ enabled libtwolame&& require libtwolame 
> twolame.h twolame_init -ltwolame
>  { check_lib libtwolame twolame.h 
> twolame_encode_buffer_float32_interleaved -ltwolame ||
>die "ERROR: libtwolame must be installed and 
> version must be >= 0.3.10"; }
> enabled libv4l2   && require_pkg_config libv4l2 libv4l2 libv4l2.h 
> v4l2_ioctl
> +enabled libvapoursynth&& require_pkg_config libvapoursynth "vapoursynth 
> >= 42" VapourSynth.h getVapourSynthAPI && require_pkg_config libvapoursynth 
> "vapoursynth-script >= 42" VSScript.h vsscript_init || die "ERROR: 
> vapoursynth or vsscript not found";
> enabled libvidstab&& require_pkg_config libvidstab "vidstab >= 0.98" 
> vid.stab/libvidstab.h vsMotionDetectInit
> enabled libvmaf   && require_pkg_config libvmaf "libvmaf >= 0.6.2" 
> libvmaf.h compute_vmaf
> enabled libvo_amrwbenc&& require libvo_amrwbenc vo-amrwbenc/enc_if.h 
> E_IF_init -lvo-amrwbenc
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 3eeca5091d..731b7ac714 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -570,6 +570,7 @@ OBJS-$(CONFIG_LIBRTMPTE_PROTOCOL)+= librtmp.o
> OBJS-$(CONFIG_LIBSRT_PROTOCOL)   += libsrt.o
> OBJS-$(CONFIG_LIBSSH_PROTOCOL)   += libssh.o
> OBJS-$(CONFIG_LIBSMBCLIENT_PROTOCOL) += libsmbclient.o
> +OBJS-$(CONFIG_LIBVAPOURSYNTH_DEMUXER)+= libvapoursynth.o
> 
> # protocols I/O
> OBJS-$(CONFIG_ASYNC_PROTOCOL)+= async.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index d582778b3b..67f6c4339c 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -482,6 +482,7 @@ extern AVOutputFormat ff_chromaprint_muxer;
> extern AVInputFormat  ff_libgme_demuxer;
> extern AVInputFormat  ff_libmodplug_demuxer;
> extern AVInputFormat  ff_libopenmpt_demuxer;
> +extern AVInputFormat  ff_libvapoursynth_demuxer;
> 
> #include "libavformat/muxer_list.c"
> #include "libavformat/demuxer_list.c"
> diff --git a/libavformat/libvapoursynth.c b/libavformat/libvapoursynth.c
> new file mode 100644
> index 00..95699e81d2
> --- /dev/null
> +++ b/libavformat/libvapoursynth.c
> @@ -0,0 +1,379 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +/**
> +* @file
> +* VapourSynth demuxer
> +*
> +* 

Re: [FFmpeg-devel] [PATCH] avcodec/x86/hpeldsp: fix half pel interpolation

[Michael Niedermayer]

On Fri, Apr 27, 2018 at 04:47:13PM +0200, Jerome Borsboom wrote:
> The assembly optimized half pel interpolation in some cases rounds the
> interpolated value when no rounding is requested. The result is a off by one
> error when one of the pixel values is zero.
> 
> Signed-off-by: Jerome Borsboom 
> ---
> In the put_no_rnd_pixels functions, the psubusb instruction subtracts one 
> from each
> unsigned byte to correct for the rouding that the PAVGB instruction performs. 
> The psubusb
> instruction, however, uses saturation when the value does not fit in the 
> operand type,
> i.e. an unsigned byte. In this particular case, this means that when the 
> value of a pixel
> is 0, the psubusb instruction will return 0 instead of -1 as this value does 
> not fit in
> an unsigned byte and is saturated to 0. The result is that the interpolated 
> value is not
> corrected for the rounding that PAVGB performs and that the result will be 
> off by one.
> 
> The corrections below solved the issues for me, but I do not a lot of 
> experience in optimizing
> assembly. A good check for the correctness of the solution might be 
> advisable. Furthermore,
> I have not checked the other assembly, but there may be more cases where the 
> psubusb
> instruction does not provide the desired results. A good check by the 
> owner/maintainer of
> the assembly code might be appropriate.
> 
>  libavcodec/x86/hpeldsp.asm | 38 --
>  1 file changed, 32 insertions(+), 6 deletions(-)

This patch is not correct.

this code is not used if AV_CODEC_FLAG_BITEXACT is set, because it is
not bit exact ...

Also the case where the off by 1 error occurs is a rare corner case,
Compared to the errors introduced by the IDCT this is not significant

If you want to optimize the bit exact version, feel free to do so.
It may be faster to use xor -1 before and after avg for this though

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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

Re: [FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper

[James Almer]

On 4/27/2018 4:37 PM, wm4 wrote:
> From: wm4 
> 
> This can "demux" .vpy files.
> 
> Some minor code copied from other LGPL parts of FFmpeg.
> 
> Possibly support VS compat pixel formats.
> 
> TODO:
> - check whether VS can change format midstream
> - test vfr mode, return proper timestamps when using it
> - drop "lib" prefix?
> ---
>  configure|   4 +
>  libavformat/Makefile |   1 +
>  libavformat/allformats.c |   1 +
>  libavformat/libvapoursynth.c | 379 
> +++
>  4 files changed, 385 insertions(+)
>  create mode 100644 libavformat/libvapoursynth.c
> 
> diff --git a/configure b/configure
> index 9fa1665496..17e46c5daa 100755
> --- a/configure
> +++ b/configure
> @@ -265,6 +265,7 @@ External library support:
> if openssl or gnutls is not used [no]
>--enable-libtwolame  enable MP2 encoding via libtwolame [no]
>--enable-libv4l2 enable libv4l2/v4l-utils [no]
> +  --enable-libvapoursynth  enable VapourSynth demuxer [no]
>--enable-libvidstab  enable video stabilization using vid.stab [no]
>--enable-libvmaf enable vmaf filter via libvmaf [no]
>--enable-libvo-amrwbenc  enable AMR-WB encoding via libvo-amrwbenc [no]
> @@ -1712,6 +1713,7 @@ EXTERNAL_LIBRARY_LIST="
>  libtheora
>  libtwolame
>  libv4l2
> +libvapoursynth
>  libvorbis
>  libvpx
>  libwavpack
> @@ -3068,6 +3070,7 @@ libspeex_encoder_deps="libspeex"
>  libspeex_encoder_select="audio_frame_queue"
>  libtheora_encoder_deps="libtheora"
>  libtwolame_encoder_deps="libtwolame"
> +libvapoursynth_demuxer_deps="libvapoursynth"
>  libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
>  libvorbis_decoder_deps="libvorbis"
>  libvorbis_encoder_deps="libvorbis libvorbisenc"
> @@ -6041,6 +6044,7 @@ enabled libtwolame&& require libtwolame 
> twolame.h twolame_init -ltwolame
>   { check_lib libtwolame twolame.h 
> twolame_encode_buffer_float32_interleaved -ltwolame ||
> die "ERROR: libtwolame must be installed and 
> version must be >= 0.3.10"; }
>  enabled libv4l2   && require_pkg_config libv4l2 libv4l2 libv4l2.h 
> v4l2_ioctl
> +enabled libvapoursynth&& require_pkg_config libvapoursynth "vapoursynth 
> >= 42" VapourSynth.h getVapourSynthAPI &&

> require_pkg_config libvapoursynth "vapoursynth-script >= 42" VSScript.h 
> vsscript_init || die "ERROR: vapoursynth or vsscript not found";

die() is needed only with test_pkg_config and check_pkg_config, not
require_pkg_config.

And seeing that vapoursynth-script.pc depends on vapoursynth.pc, you can
simplify all this by only checking for vapoursynth-script.

>  enabled libvidstab&& require_pkg_config libvidstab "vidstab >= 0.98" 
> vid.stab/libvidstab.h vsMotionDetectInit
>  enabled libvmaf   && require_pkg_config libvmaf "libvmaf >= 0.6.2" 
> libvmaf.h compute_vmaf
>  enabled libvo_amrwbenc&& require libvo_amrwbenc vo-amrwbenc/enc_if.h 
> E_IF_init -lvo-amrwbenc
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 3eeca5091d..731b7ac714 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -570,6 +570,7 @@ OBJS-$(CONFIG_LIBRTMPTE_PROTOCOL)+= librtmp.o
>  OBJS-$(CONFIG_LIBSRT_PROTOCOL)   += libsrt.o
>  OBJS-$(CONFIG_LIBSSH_PROTOCOL)   += libssh.o
>  OBJS-$(CONFIG_LIBSMBCLIENT_PROTOCOL) += libsmbclient.o
> +OBJS-$(CONFIG_LIBVAPOURSYNTH_DEMUXER)+= libvapoursynth.o
>  
>  # protocols I/O
>  OBJS-$(CONFIG_ASYNC_PROTOCOL)+= async.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index d582778b3b..67f6c4339c 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -482,6 +482,7 @@ extern AVOutputFormat ff_chromaprint_muxer;
>  extern AVInputFormat  ff_libgme_demuxer;
>  extern AVInputFormat  ff_libmodplug_demuxer;
>  extern AVInputFormat  ff_libopenmpt_demuxer;
> +extern AVInputFormat  ff_libvapoursynth_demuxer;
>  
>  #include "libavformat/muxer_list.c"
>  #include "libavformat/demuxer_list.c"
> diff --git a/libavformat/libvapoursynth.c b/libavformat/libvapoursynth.c
> new file mode 100644
> index 00..95699e81d2
> --- /dev/null
> +++ b/libavformat/libvapoursynth.c
> @@ -0,0 +1,379 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General 

Re: [FFmpeg-devel] [PATCH 1/3] avformat/utils: function to get the formatted ntp time

[Michael Niedermayer]

On Fri, Apr 27, 2018 at 08:00:23AM +, Dixit, Vishwanath wrote:
> 
> 
> On 4/27/18 5:15 AM, Michael Niedermayer wrote:
> > On Thu, Apr 26, 2018 at 11:05:59AM +, Dixit, Vishwanath wrote:
> >>
> >>
> >> On 4/26/18 1:04 AM, Michael Niedermayer wrote:
> >>> On Tue, Apr 24, 2018 at 02:46:56PM +0530, vdi...@akamai.com wrote:
>  From: Vishwanath Dixit 
> 
>  This utility function creates 64-bit NTP time format as per the RFC
>  5905.
>  A simple explaination of 64-bit NTP time format is here
>  http://www.beaglesoft.com/Manual/page53.htm
>  ---
>   libavformat/internal.h |  8 
>   libavformat/utils.c| 20 
>   2 files changed, 28 insertions(+)
> 
>  diff --git a/libavformat/internal.h b/libavformat/internal.h
>  index 3582682..e9f758f 100644
>  --- a/libavformat/internal.h
>  +++ b/libavformat/internal.h
>  @@ -240,6 +240,14 @@ void ff_read_frame_flush(AVFormatContext *s);
>   uint64_t ff_ntp_time(void);
>   
>   /**
>  + * Get the NTP time stamp formatted as per the RFC-5905.
>  + *
>  + * @param ntp_time NTP time in micro seconds (since NTP epoch)
>  + * @return the formatted NTP time stamp
>  + */
>  +uint64_t ff_time_ntp_format(uint64_t ntp_time);
>  +
>  +/**
>    * Append the media-specific SDP fragment for the media stream c
>    * to the buffer buff.
>    *
>  diff --git a/libavformat/utils.c b/libavformat/utils.c
>  index c25eab4..b59d426 100644
>  --- a/libavformat/utils.c
>  +++ b/libavformat/utils.c
>  @@ -4637,6 +4637,26 @@ uint64_t ff_ntp_time(void)
>   return (av_gettime() / 1000) * 1000 + NTP_OFFSET_US;
>   }
>   
>  +uint64_t ff_time_ntp_format(uint64_t ntp_time)
>  +{
>  +uint64_t ntp_ts, frac_part;
>  +uint32_t sec, usec;
>  +
>  +//current ntp time in seconds and micro seconds
> >>>
>  +sec = ntp_time / 100;
> >>>
> >>> This can be truncated
> >> Yes, but the truncated part is not getting discarded, as the following 
> >> line is taking care of that. Please correct me if I have not understood 
> >> what you have intended to say here.
> >
> > ok, correcting you then :)
> > sec is 32bit
> > not all values of "ntp_time / 100;" fit in 32bit
> > there is no check for this it just produces a wrong result
> Yes, you are right. But, I can use only the LS 32bits of the result in the 
> following code. It is a limitation of 64-bit NTP time format and the issue is 
> going to occur in 2036. Not sure how to handle it here. At most, I can print 
> a warning message when the result gets truncated. Could you please suggest 
> any alternative option?

i cant make it work after 2036 as that seems what the design is limited at.
But the error can be detected and handled

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] libavutil/encryption_info: Allow multiple init info.

[Jacob Trimble]

On Fri, Apr 27, 2018 at 10:33 AM, Jacob Trimble  wrote:
> On Mon, Apr 23, 2018 at 11:03 AM, Jacob Trimble  wrote:
>> While integrating my encryption info changes, I noticed a problem with
>> the init info structs.  I implemented them as side-data on the Stream.
>> But this means there can only be one per stream.  However, there can
>> be multiple 'pssh' atoms in a single stream (e.g. for key rotation or
>> multiple key systems). (sorry for not noticing sooner)
>>
>> Attached is a patch to fix this by making the init info a
>> singly-linked-list.  It is ABI compatible and is still easy to use and
>> understand.  The alternative would be to break ABI and have the
>> side-data methods return an array of pointers.  I could do that
>> instead if that is preferable.
>
> Ping

Noticed a bug, fixed.
From 50ec8ed80687134ecb9e74c45336e920d9e28666 Mon Sep 17 00:00:00 2001
From: Jacob Trimble 
Date: Mon, 23 Apr 2018 10:33:58 -0700
Subject: [PATCH] libavutil/encryption_info: Allow multiple init info.

It is possible for there to be multiple encryption init info structure.
For example, to support multiple key systems or in key rotation.  This
changes the AVEncryptionInitInfo struct to be a linked list so there
can be multiple structs without breaking ABI.

Signed-off-by: Jacob Trimble 
---
 libavutil/encryption_info.c | 156 +++-
 libavutil/encryption_info.h |   5 ++
 2 files changed, 107 insertions(+), 54 deletions(-)

diff --git a/libavutil/encryption_info.c b/libavutil/encryption_info.c
index 20a752d6b4..2329d94f12 100644
--- a/libavutil/encryption_info.c
+++ b/libavutil/encryption_info.c
@@ -160,13 +160,16 @@ uint8_t *av_encryption_info_add_side_data(const AVEncryptionInfo *info, size_t *
 }
 
 // The format of the AVEncryptionInitInfo side data:
-// u32be system_id_size
-// u32be num_key_ids
-// u32be key_id_size
-// u32be data_size
-// u8[system_id_size] system_id
-// u8[key_id_size][num_key_id] key_ids
-// u8[data_size] data
+// u32be init_info_count
+// {
+//   u32be system_id_size
+//   u32be num_key_ids
+//   u32be key_id_size
+//   u32be data_size
+//   u8[system_id_size] system_id
+//   u8[key_id_size][num_key_id] key_ids
+//   u8[data_size] data
+// }[init_info_count]
 
 #define FF_ENCRYPTION_INIT_INFO_EXTRA 16
 
@@ -215,6 +218,7 @@ void av_encryption_init_info_free(AVEncryptionInitInfo *info)
 for (i = 0; i < info->num_key_ids; i++) {
 av_free(info->key_ids[i]);
 }
+av_encryption_init_info_free(info->next);
 av_free(info->system_id);
 av_free(info->key_ids);
 av_free(info->data);
@@ -225,71 +229,115 @@ void av_encryption_init_info_free(AVEncryptionInitInfo *info)
 AVEncryptionInitInfo *av_encryption_init_info_get_side_data(
 const uint8_t *side_data, size_t side_data_size)
 {
-AVEncryptionInitInfo *info;
-uint64_t system_id_size, num_key_ids, key_id_size, data_size, i;
-
-if (!side_data || side_data_size < FF_ENCRYPTION_INIT_INFO_EXTRA)
-return NULL;
-
-system_id_size = AV_RB32(side_data);
-num_key_ids = AV_RB32(side_data + 4);
-key_id_size = AV_RB32(side_data + 8);
-data_size = AV_RB32(side_data + 12);
-
-// UINT32_MAX + UINT32_MAX + UINT32_MAX * UINT32_MAX == UINT64_MAX
-if (side_data_size - FF_ENCRYPTION_INIT_INFO_EXTRA < system_id_size + data_size + num_key_ids * key_id_size)
-return NULL;
+AVEncryptionInitInfo *ret = NULL, *info;
+uint64_t system_id_size, num_key_ids, key_id_size, data_size, i, j;
+uint64_t init_info_count;
 
-info = av_encryption_init_info_alloc(system_id_size, num_key_ids, key_id_size, data_size);
-if (!info)
+if (!side_data || side_data_size < 4)
 return NULL;
 
-memcpy(info->system_id, side_data + 16, system_id_size);
-side_data += system_id_size + 16;
-for (i = 0; i < num_key_ids; i++) {
-  memcpy(info->key_ids[i], side_data, key_id_size);
-  side_data += key_id_size;
+init_info_count = AV_RB32(side_data);
+side_data += 4;
+side_data_size -= 4;
+for (i = 0; i < init_info_count; i++) {
+  if (side_data_size < FF_ENCRYPTION_INIT_INFO_EXTRA) {
+  av_encryption_init_info_free(ret);
+  return NULL;
+  }
+
+  system_id_size = AV_RB32(side_data);
+  num_key_ids = AV_RB32(side_data + 4);
+  key_id_size = AV_RB32(side_data + 8);
+  data_size = AV_RB32(side_data + 12);
+
+  // UINT32_MAX + UINT32_MAX + UINT32_MAX * UINT32_MAX == UINT64_MAX
+  if (side_data_size - FF_ENCRYPTION_INIT_INFO_EXTRA < system_id_size + data_size + num_key_ids * key_id_size) {
+  av_encryption_init_info_free(ret);
+  return NULL;
+  }
+  side_data += FF_ENCRYPTION_INIT_INFO_EXTRA;
+  side_data_size -= FF_ENCRYPTION_INIT_INFO_EXTRA;
+
+  info = av_encryption_init_info_alloc(system_id_size, num_key_ids, key_id_size, data_size);
+  if 

[FFmpeg-devel] [PATCH 2/2] avcodec/cbs_h2645: create a reference to the existing buffer when decomposing slice units

[James Almer]

Signed-off-by: James Almer 
---
 libavcodec/cbs_h2645.c | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 5585831cf6..5e5598f377 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -776,15 +776,10 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext 
*ctx,
 }
 
 slice->data_size = len - pos / 8;
-slice->data_ref  = av_buffer_alloc(slice->data_size +
-   AV_INPUT_BUFFER_PADDING_SIZE);
+slice->data_ref  = av_buffer_ref(unit->data_ref);
 if (!slice->data_ref)
 return AVERROR(ENOMEM);
-slice->data = slice->data_ref->data;
-memcpy(slice->data,
-   unit->data + pos / 8, slice->data_size);
-memset(slice->data + slice->data_size, 0,
-   AV_INPUT_BUFFER_PADDING_SIZE);
+slice->data = unit->data + pos / 8;
 slice->data_bit_start = pos % 8;
 }
 break;
@@ -946,15 +941,10 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext 
*ctx,
 }
 
 slice->data_size = len - pos / 8;
-slice->data_ref  = av_buffer_alloc(slice->data_size +
-   AV_INPUT_BUFFER_PADDING_SIZE);
+slice->data_ref  = av_buffer_ref(unit->data_ref);
 if (!slice->data_ref)
 return AVERROR(ENOMEM);
-slice->data = slice->data_ref->data;
-memcpy(slice->data,
-   unit->data + pos / 8, slice->data_size);
-memset(slice->data + slice->data_size, 0,
-   AV_INPUT_BUFFER_PADDING_SIZE);
+slice->data = unit->data + pos / 8;
 slice->data_bit_start = pos % 8;
 }
 break;
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH] avfilter: add amplify filter

[Carl Eugen Hoyos]

2018-04-28 0:56 GMT+02:00, Paul B Mahol :

> +static int query_formats(AVFilterContext *ctx)
> +{
> +static const enum AVPixelFormat pixel_fmts[] = {
> +AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY9,
> +AV_PIX_FMT_GRAY10, AV_PIX_FMT_GRAY12,
> +AV_PIX_FMT_GRAY16,
> +AV_PIX_FMT_YUV410P, AV_PIX_FMT_YUV411P,
> +AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P,
> +AV_PIX_FMT_YUV440P, AV_PIX_FMT_YUV444P,
> +AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P,
> +AV_PIX_FMT_YUVJ440P, AV_PIX_FMT_YUVJ444P,
> +AV_PIX_FMT_YUVJ411P,
> +AV_PIX_FMT_YUV420P9, AV_PIX_FMT_YUV422P9, AV_PIX_FMT_YUV444P9,
> +AV_PIX_FMT_YUV420P10, AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV444P10,
> +AV_PIX_FMT_YUV440P10,
> +AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV420P12,
> +AV_PIX_FMT_YUV440P12,
> +AV_PIX_FMT_YUV444P14, AV_PIX_FMT_YUV422P14, AV_PIX_FMT_YUV420P14,
> +AV_PIX_FMT_YUV420P16, AV_PIX_FMT_YUV422P16, AV_PIX_FMT_YUV444P16,
> +AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP9, AV_PIX_FMT_GBRP10,
> +AV_PIX_FMT_GBRP12, AV_PIX_FMT_GBRP14, AV_PIX_FMT_GBRP16,

Just curious:
Why is this necessary / why did the original code not work?

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

[FFmpeg-devel] [PATCH] fftools/ffmpeg: change fps progress log message to show two decimal digits

[André Camargo]

Useful when transcoding videos at 29.97 fps because delivers a more accurate 
result for monitoring.
---
 fftools/ffmpeg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 4dbe72186d..565b2c6dab 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1696,7 +1696,7 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 av_bprintf(, "frame=%5d fps=%3.*f q=%3.1f ",
  frame_number, fps < 9.95, fps, q);
 av_bprintf(_script, "frame=%d\n", frame_number);
-av_bprintf(_script, "fps=%.1f\n", fps);
+av_bprintf(_script, "fps=%.2f\n", fps);
 av_bprintf(_script, "stream_%d_%d_q=%.1f\n",
ost->file_index, ost->index, q);
 if (is_last_report)
-- 
2.13.5 (Apple Git-94)

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

[FFmpeg-devel] [PATCH] avfilter: add amplify filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  24 
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_amplify.c | 290 +++
 4 files changed, 316 insertions(+)
 create mode 100644 libavfilter/vf_amplify.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 44e0801f9c..48a13d7791 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5187,6 +5187,30 @@ input reaches end of stream. This will cause problems if 
your encoding
 pipeline drops frames. If you're trying to apply an image as an
 overlay to a video stream, consider the @var{overlay} filter instead.
 
+@section amplify
+
+Amplify differences between current pixel and pixels of adjacent frames in
+same pixel location.
+
+This filter accepts the following options:
+
+@table @option
+@item radius
+Set frame radius. Default is 2. Allowed range is from 1 to 63.
+For example radius of 3 will instruct filter to calculate average of 7 frames.
+
+@item factor
+Set factor to amplify difference. Default is 2. Allowed range is from 0 to 
65535.
+
+@item threshold
+Set threshold for difference amplification. Any differrence greater or equal to
+this value will not alter source pixel. Default is 10.
+Allowed range is from 0 to 65535.
+
+@item planes
+Set which planes to filter. Default is all. Allowed range is from 0 to 15.
+@end table
+
 @section ass
 
 Same as the @ref{subtitles} filter, except that it doesn't require libavcodec
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 7f8317c2f2..3454f25e7d 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -138,6 +138,7 @@ OBJS-$(CONFIG_ANULLSINK_FILTER)  += 
asink_anullsink.o
 # video filters
 OBJS-$(CONFIG_ALPHAEXTRACT_FILTER)   += vf_extractplanes.o
 OBJS-$(CONFIG_ALPHAMERGE_FILTER) += vf_alphamerge.o
+OBJS-$(CONFIG_AMPLIFY_FILTER)+= vf_amplify.o
 OBJS-$(CONFIG_ASS_FILTER)+= vf_subtitles.o
 OBJS-$(CONFIG_ATADENOISE_FILTER) += vf_atadenoise.o
 OBJS-$(CONFIG_AVGBLUR_FILTER)+= vf_avgblur.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 35e12d595f..d958f9b2da 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -132,6 +132,7 @@ extern AVFilter ff_asink_anullsink;
 
 extern AVFilter ff_vf_alphaextract;
 extern AVFilter ff_vf_alphamerge;
+extern AVFilter ff_vf_amplify;
 extern AVFilter ff_vf_ass;
 extern AVFilter ff_vf_atadenoise;
 extern AVFilter ff_vf_avgblur;
diff --git a/libavfilter/vf_amplify.c b/libavfilter/vf_amplify.c
new file mode 100644
index 00..8e8c2ebd20
--- /dev/null
+++ b/libavfilter/vf_amplify.c
@@ -0,0 +1,290 @@
+/*
+ * Copyright (c) 2018 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/imgutils.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct AmplifyContext {
+const AVClass *class;
+const AVPixFmtDescriptor *desc;
+int radius;
+float factor;
+float threshold;
+int planes;
+
+int nb_inputs;
+int nb_frames;
+
+int depth;
+int max;
+int nb_planes;
+int linesize[4];
+int height[4];
+
+AVFrame **frames;
+} AmplifyContext;
+
+static int query_formats(AVFilterContext *ctx)
+{
+static const enum AVPixelFormat pixel_fmts[] = {
+AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY9,
+AV_PIX_FMT_GRAY10, AV_PIX_FMT_GRAY12,
+AV_PIX_FMT_GRAY16,
+AV_PIX_FMT_YUV410P, AV_PIX_FMT_YUV411P,
+AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P,
+AV_PIX_FMT_YUV440P, AV_PIX_FMT_YUV444P,
+AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P,
+AV_PIX_FMT_YUVJ440P, AV_PIX_FMT_YUVJ444P,
+AV_PIX_FMT_YUVJ411P,
+AV_PIX_FMT_YUV420P9, AV_PIX_FMT_YUV422P9, AV_PIX_FMT_YUV444P9,
+AV_PIX_FMT_YUV420P10, AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV444P10,
+AV_PIX_FMT_YUV440P10,
+AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV420P12,
+AV_PIX_FMT_YUV440P12,
+AV_PIX_FMT_YUV444P14, AV_PIX_FMT_YUV422P14, 

[FFmpeg-devel] [PATCH] avcodec/cbs_mpeg2: create a reference to the existing buffer when decomposing slice units

[James Almer]

Signed-off-by: James Almer 
---
 libavcodec/cbs_mpeg2.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 989daf0a4d..8ca47061fe 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -191,16 +191,11 @@ static int cbs_mpeg2_read_unit(CodedBitstreamContext *ctx,
 len = unit->data_size;
 
 slice->data_size = len - pos / 8;
-slice->data_ref  = av_buffer_alloc(slice->data_size +
-   AV_INPUT_BUFFER_PADDING_SIZE);
+slice->data_ref  = av_buffer_ref(unit->data_ref);
 if (!slice->data_ref)
 return AVERROR(ENOMEM);
-slice->data = slice->data_ref->data;
+slice->data = unit->data + pos / 8;
 
-memcpy(slice->data,
-   unit->data + pos / 8, slice->data_size);
-memset(slice->data + slice->data_size, 0,
-   AV_INPUT_BUFFER_PADDING_SIZE);
 slice->data_bit_start = pos % 8;
 
 } else {
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH] swresample/arm: avoid conditional branch to PLT in THUMB-2.

[Rahul Chaudhry]

It was reported on github that this patch causes build errors with xcode:
  
https://github.com/FFmpeg/FFmpeg/commit/b22db4f465c9adb2cf1489e04f7b65ef6bb55b8b#commitcomment-28725295

The attached patch fixes the build errors by renaming the labels. This time
I've tested it with clang from xcode on a MacBook to verify that the build
works.

Thanks,
Rahul


On Thu, Apr 19, 2018 at 11:06 AM, Michael Niedermayer
 wrote:
> On Wed, Apr 18, 2018 at 04:40:28PM -0700, Rahul Chaudhry wrote:
>> On Wed, Apr 18, 2018 at 3:46 PM, Michael Niedermayer
>>  wrote:
>> > please make sure this works on apple based arm (unless you know it works)
>> > (ive tested qemu linux based)
>> >
>> > Also please add a commit message
>>
>> If by 'apple based arm' you mean llvm/clang assembler, then yes, I've 
>> verified
>> that the assembly works with armv7a-cros-linux-gnueabi-clang (version 7.0.0).
>>
>> Updated patch with new commit message is attached.
>>
>> Thanks,
>> Rahul
>
>> From 2e3318acf266b519e98b680102a07196d6ddbf93 Mon Sep 17 00:00:00 2001
>> From: Rahul Chaudhry 
>> Date: Wed, 18 Apr 2018 16:29:39 -0700
>> Subject: [PATCH] swresample/arm: remove unintentional relocation.
>
> ok, will apply
>
> thx
From a58b726947cc22081d899894036fa01933dfac0a Mon Sep 17 00:00:00 2001
From: Rahul Chaudhry 
Date: Fri, 27 Apr 2018 13:49:52 -0700
Subject: [PATCH] swresample/arm: rename labels to fix xcode build error

---
 libswresample/arm/audio_convert_neon.S | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git libswresample/arm/audio_convert_neon.S 
libswresample/arm/audio_convert_neon.S
index 
7729514701d3a02d04146f24cd9b12b11548ac64..085d50aafa5cf364e357d251a3986fad55643589
 100644
--- libswresample/arm/audio_convert_neon.S
+++ libswresample/arm/audio_convert_neon.S
@@ -22,7 +22,7 @@
 #include "libavutil/arm/asm.S"
 
 function swri_oldapi_conv_flt_to_s16_neon, export=1
-_swri_oldapi_conv_flt_to_s16_neon:
+.L_swri_oldapi_conv_flt_to_s16_neon:
 subsr2,  r2,  #8
 vld1.32 {q0}, [r1,:128]!
 vcvt.s32.f32q8,  q0,  #31
@@ -67,7 +67,7 @@ _swri_oldapi_conv_flt_to_s16_neon:
 endfunc
 
 function swri_oldapi_conv_fltp_to_s16_2ch_neon, export=1
-_swri_oldapi_conv_fltp_to_s16_2ch_neon:
+.L_swri_oldapi_conv_fltp_to_s16_2ch_neon:
 ldm r1,  {r1, r3}
 subsr2,  r2,  #8
 vld1.32 {q0}, [r1,:128]!
@@ -135,8 +135,8 @@ function swri_oldapi_conv_fltp_to_s16_nch_neon, export=1
 cmp r3,  #2
 itt lt
 ldrlt   r1,  [r1]
-blt _swri_oldapi_conv_flt_to_s16_neon
-beq _swri_oldapi_conv_fltp_to_s16_2ch_neon
+blt .L_swri_oldapi_conv_flt_to_s16_neon
+beq .L_swri_oldapi_conv_fltp_to_s16_2ch_neon
 
 push{r4-r8, lr}
 cmp r3,  #4
-- 
2.13.5

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

[FFmpeg-devel] [PATCH 2/3] avcodec/wavpack: Fix integer overflow in wv_unpack_stereo()

[Michael Niedermayer]

Fixes: runtime error: signed integer overflow: 2147483531 + 16384 cannot be 
represented in type 'int'
Fixes: 
6615/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-5165715515506688

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

diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index 0e40b29879..22a2c83a30 100644
--- a/libavcodec/wavpack.c
+++ b/libavcodec/wavpack.c
@@ -452,7 +452,7 @@ static inline int wv_unpack_stereo(WavpackFrameContext *s, 
GetBitContext *gb,
 if (type != AV_SAMPLE_FMT_S16P)
 R2 = R + ((s->decorr[i].weightB * (int64_t)L2 + 512) >> 
10);
 else
-R2 = R + ((int)(s->decorr[i].weightB * (unsigned)L2 + 512) 
>> 10);
+R2 = R + (unsigned)((int)(s->decorr[i].weightB * 
(unsigned)L2 + 512) >> 10);
 UPDATE_WEIGHT_CLIP(s->decorr[i].weightB, s->decorr[i].delta, 
L2, R);
 R= R2;
 s->decorr[i].samplesA[0] = R;
-- 
2.17.0

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

[FFmpeg-devel] [PATCH 3/3] avcodec/wavpack: Fix integer overflow in DEC_MED() / INC_MED()

[Michael Niedermayer]

Fixes: runtime error: signed integer overflow: 2147483637 + 128 cannot be 
represented in type 'int'
Fixes: 
6701/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-5358324934508544

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

diff --git a/libavcodec/wavpack.h b/libavcodec/wavpack.h
index 3ae601f914..6caad038e9 100644
--- a/libavcodec/wavpack.h
+++ b/libavcodec/wavpack.h
@@ -99,8 +99,8 @@ typedef struct WvChannel {
 
 // macros for manipulating median values
 #define GET_MED(n) ((c->median[n] >> 4) + 1)
-#define DEC_MED(n) c->median[n] -= ((c->median[n] + (128 >> (n)) - 2) / (128 
>> (n))) * 2U
-#define INC_MED(n) c->median[n] += ((c->median[n] + (128 >> (n))) / (128 
>> (n))) * 5U
+#define DEC_MED(n) c->median[n] -= ((int)(c->median[n] + (128U >> (n)) - 2) / 
(128 >> (n))) * 2U
+#define INC_MED(n) c->median[n] += ((int)(c->median[n] + (128U >> (n))) / 
(128 >> (n))) * 5U
 
 // macros for applying weight
 #define UPDATE_WEIGHT_CLIP(weight, delta, samples, in) \
-- 
2.17.0

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

[FFmpeg-devel] [PATCH 1/3] avcodec/g2meet: Check RGB upper limit

[Michael Niedermayer]

Fixes: runtime error: left shift of 1876744317 by 16 places cannot be 
represented in type 'int'
Fixes: 
6799/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-5115274731716608

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

diff --git a/libavcodec/g2meet.c b/libavcodec/g2meet.c
index b409dae813..105a40278f 100644
--- a/libavcodec/g2meet.c
+++ b/libavcodec/g2meet.c
@@ -556,7 +556,7 @@ static uint32_t epic_decode_pixel_pred(ePICContext *dc, int 
x, int y,
 B = ((pred >> B_shift) & 0xFF) - TOSIGNED(delta);
 }
 
-if (R<0 || G<0 || B<0) {
+if (R<0 || G<0 || B<0 || R > 255 || G > 255 || B > 255) {
 av_log(NULL, AV_LOG_ERROR, "RGB %d %d %d is out of range\n", R, G, B);
 return 0;
 }
-- 
2.17.0

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

[FFmpeg-devel] [PATCH] avformat: add vapoursynth wrapper

[wm4]

From: wm4 

This can "demux" .vpy files.

Some minor code copied from other LGPL parts of FFmpeg.

Possibly support VS compat pixel formats.

TODO:
- check whether VS can change format midstream
- test vfr mode, return proper timestamps when using it
- drop "lib" prefix?
---
 configure|   4 +
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/libvapoursynth.c | 379 +++
 4 files changed, 385 insertions(+)
 create mode 100644 libavformat/libvapoursynth.c

diff --git a/configure b/configure
index 9fa1665496..17e46c5daa 100755
--- a/configure
+++ b/configure
@@ -265,6 +265,7 @@ External library support:
if openssl or gnutls is not used [no]
   --enable-libtwolame  enable MP2 encoding via libtwolame [no]
   --enable-libv4l2 enable libv4l2/v4l-utils [no]
+  --enable-libvapoursynth  enable VapourSynth demuxer [no]
   --enable-libvidstab  enable video stabilization using vid.stab [no]
   --enable-libvmaf enable vmaf filter via libvmaf [no]
   --enable-libvo-amrwbenc  enable AMR-WB encoding via libvo-amrwbenc [no]
@@ -1712,6 +1713,7 @@ EXTERNAL_LIBRARY_LIST="
 libtheora
 libtwolame
 libv4l2
+libvapoursynth
 libvorbis
 libvpx
 libwavpack
@@ -3068,6 +3070,7 @@ libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
 libtheora_encoder_deps="libtheora"
 libtwolame_encoder_deps="libtwolame"
+libvapoursynth_demuxer_deps="libvapoursynth"
 libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
 libvorbis_decoder_deps="libvorbis"
 libvorbis_encoder_deps="libvorbis libvorbisenc"
@@ -6041,6 +6044,7 @@ enabled libtwolame&& require libtwolame twolame.h 
twolame_init -ltwolame
  { check_lib libtwolame twolame.h 
twolame_encode_buffer_float32_interleaved -ltwolame ||
die "ERROR: libtwolame must be installed and 
version must be >= 0.3.10"; }
 enabled libv4l2   && require_pkg_config libv4l2 libv4l2 libv4l2.h 
v4l2_ioctl
+enabled libvapoursynth&& require_pkg_config libvapoursynth "vapoursynth >= 
42" VapourSynth.h getVapourSynthAPI && require_pkg_config libvapoursynth 
"vapoursynth-script >= 42" VSScript.h vsscript_init || die "ERROR: vapoursynth 
or vsscript not found";
 enabled libvidstab&& require_pkg_config libvidstab "vidstab >= 0.98" 
vid.stab/libvidstab.h vsMotionDetectInit
 enabled libvmaf   && require_pkg_config libvmaf "libvmaf >= 0.6.2" 
libvmaf.h compute_vmaf
 enabled libvo_amrwbenc&& require libvo_amrwbenc vo-amrwbenc/enc_if.h 
E_IF_init -lvo-amrwbenc
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 3eeca5091d..731b7ac714 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -570,6 +570,7 @@ OBJS-$(CONFIG_LIBRTMPTE_PROTOCOL)+= librtmp.o
 OBJS-$(CONFIG_LIBSRT_PROTOCOL)   += libsrt.o
 OBJS-$(CONFIG_LIBSSH_PROTOCOL)   += libssh.o
 OBJS-$(CONFIG_LIBSMBCLIENT_PROTOCOL) += libsmbclient.o
+OBJS-$(CONFIG_LIBVAPOURSYNTH_DEMUXER)+= libvapoursynth.o
 
 # protocols I/O
 OBJS-$(CONFIG_ASYNC_PROTOCOL)+= async.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d582778b3b..67f6c4339c 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -482,6 +482,7 @@ extern AVOutputFormat ff_chromaprint_muxer;
 extern AVInputFormat  ff_libgme_demuxer;
 extern AVInputFormat  ff_libmodplug_demuxer;
 extern AVInputFormat  ff_libopenmpt_demuxer;
+extern AVInputFormat  ff_libvapoursynth_demuxer;
 
 #include "libavformat/muxer_list.c"
 #include "libavformat/demuxer_list.c"
diff --git a/libavformat/libvapoursynth.c b/libavformat/libvapoursynth.c
new file mode 100644
index 00..95699e81d2
--- /dev/null
+++ b/libavformat/libvapoursynth.c
@@ -0,0 +1,379 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+* @file
+* VapourSynth demuxer
+*
+* Synthesizes vapour (?)
+*/
+
+#include 
+#include 
+
+#include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
+#include "libavutil/eval.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "avformat.h"
+#include 

Re: [FFmpeg-devel] studio mpeg4 samples

[Paul B Mahol]

On 4/27/18, Michael Niedermayer  wrote:
> Hi
>
> It seems fate does not test studio mpeg4
> as id like to optimize the code and also fix several issues which were
> found by fuzzing. fate tests would be useful
>
> Can someone add fate tests? or
> where can i find samples to test (preferrably fully) the current
> implementation ?
>
> thanks
>
> --
> 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
>
>

They are linked in relevant trac ticket.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] studio mpeg4 samples

[Michael Niedermayer]

Hi

It seems fate does not test studio mpeg4
as id like to optimize the code and also fix several issues which were
found by fuzzing. fate tests would be useful

Can someone add fate tests? or
where can i find samples to test (preferrably fully) the current 
implementation ?

thanks

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

Re: [FFmpeg-devel] GSOC 2018 qualification task.

[Michael Niedermayer]

Hi

On Fri, Apr 20, 2018 at 10:35:05AM +0530, ANURAG SINGH IIT BHU wrote:
> Hello Sir,
> 
> I do understand that just 56 lines were inserted but sir 621 lines were
> deleted which were of no use for hellosubs and it included functons like
> expand_text(), expand_function() and other which were being called by the
> drawtext filter but not needed by the hellosubs filter as the text and
> operation to perform was predetermined. So sir skipping unnecessary
> functions should make the code a bit faster.
> 

> I am really looking forward to build my project proposal of speech to text
> subtitle generation filter under your guidance and contribute to ffmpeg as
> it will be helpful for a large number of users,and it is an important
> opportunity for me as a student as well. I am dedicated to learn and I am
> confident that with your guidance we can do it.

If you want to work on this outside GSOC, you are certainly welcome to do so
and i would be happy to mentor it

Thanks

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

[FFmpeg-devel] [PATCH] avfilter: add amplify filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  19 
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_amplify.c | 269 +++
 4 files changed, 290 insertions(+)
 create mode 100644 libavfilter/vf_amplify.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 44e0801f9c..75981ad06d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5187,6 +5187,25 @@ input reaches end of stream. This will cause problems if 
your encoding
 pipeline drops frames. If you're trying to apply an image as an
 overlay to a video stream, consider the @var{overlay} filter instead.
 
+@section amplify
+
+Amplify differences between current pixel and pixels of adjacent frames and
+same pixel location.
+
+This filter accepts the following options:
+
+@table @option
+@item radius
+Set frame radius. Default is 2. Allowed range is from 1 to 63.
+For example radius of 3 will instruct filter to average 7 frames.
+
+@item factor
+Set factor to amplify difference. Default is 2. Allowed range is from 0 to 100.
+
+@item planes
+Set which planes to filter. Default is all. Allowed range is from 0 to 15.
+@end table
+
 @section ass
 
 Same as the @ref{subtitles} filter, except that it doesn't require libavcodec
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 7f8317c2f2..3454f25e7d 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -138,6 +138,7 @@ OBJS-$(CONFIG_ANULLSINK_FILTER)  += 
asink_anullsink.o
 # video filters
 OBJS-$(CONFIG_ALPHAEXTRACT_FILTER)   += vf_extractplanes.o
 OBJS-$(CONFIG_ALPHAMERGE_FILTER) += vf_alphamerge.o
+OBJS-$(CONFIG_AMPLIFY_FILTER)+= vf_amplify.o
 OBJS-$(CONFIG_ASS_FILTER)+= vf_subtitles.o
 OBJS-$(CONFIG_ATADENOISE_FILTER) += vf_atadenoise.o
 OBJS-$(CONFIG_AVGBLUR_FILTER)+= vf_avgblur.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 35e12d595f..d958f9b2da 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -132,6 +132,7 @@ extern AVFilter ff_asink_anullsink;
 
 extern AVFilter ff_vf_alphaextract;
 extern AVFilter ff_vf_alphamerge;
+extern AVFilter ff_vf_amplify;
 extern AVFilter ff_vf_ass;
 extern AVFilter ff_vf_atadenoise;
 extern AVFilter ff_vf_avgblur;
diff --git a/libavfilter/vf_amplify.c b/libavfilter/vf_amplify.c
new file mode 100644
index 00..8d85ce7182
--- /dev/null
+++ b/libavfilter/vf_amplify.c
@@ -0,0 +1,269 @@
+/*
+ * Copyright (c) 2018 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/imgutils.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct AmplifyContext {
+const AVClass *class;
+const AVPixFmtDescriptor *desc;
+int radius;
+float factor;
+int planes;
+
+int nb_inputs;
+int nb_frames;
+
+int depth;
+int max;
+int nb_planes;
+int linesize[4];
+int height[4];
+
+AVFrame **frames;
+} AmplifyContext;
+
+static int query_formats(AVFilterContext *ctx)
+{
+AVFilterFormats *pix_fmts = NULL;
+int fmt, ret;
+
+for (fmt = 0; av_pix_fmt_desc_get(fmt); fmt++) {
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(fmt);
+if (!(desc->flags & AV_PIX_FMT_FLAG_PAL ||
+  desc->flags & AV_PIX_FMT_FLAG_HWACCEL ||
+  desc->flags & AV_PIX_FMT_FLAG_BITSTREAM ||
+  !(desc->flags & AV_PIX_FMT_FLAG_PLANAR)) &&
+(ret = ff_add_format(_fmts, fmt)) < 0)
+return ret;
+}
+
+return ff_set_common_formats(ctx, pix_fmts);
+}
+
+static av_cold int init(AVFilterContext *ctx)
+{
+AmplifyContext *s = ctx->priv;
+
+s->nb_inputs = s->radius * 2 + 1;
+
+s->frames = av_calloc(s->nb_inputs, sizeof(*s->frames));
+if (!s->frames)
+return AVERROR(ENOMEM);
+
+return 0;
+}
+
+typedef struct ThreadData {
+AVFrame **in, *out;
+} ThreadData;
+
+static int amplify_frames(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
+{
+AmplifyContext *s = ctx->priv;
+ThreadData 

Re: [FFmpeg-devel] [PATCH 2/2] ffmpeg: handling copyts use case in progress report computation

[Michael Niedermayer]

On Thu, Apr 26, 2018 at 10:34:00AM +0530, vdi...@akamai.com wrote:
> From: Vishwanath Dixit 
> 
> Progress report computation functionality was assuming the first
> PTS value to be zero, but, when 'copyts' is enalbed, the first PTS
> can be any big number. This was eventually causing display of
> weird statistics during execution of an ffmpeg command. To overcome
> this issue, the actual first PTS value has to be considered.
> ---
>  fftools/ffmpeg.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index d9bb78a..9b71525 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -1646,7 +1646,7 @@ static void print_report(int is_last_report, int64_t 
> timer_start, int64_t cur_ti
>  int frame_number, vid, i;
>  double bitrate;
>  double speed;
> -int64_t pts = INT64_MIN + 1;
> +int64_t pts = INT64_MIN + 1, first_pts = INT64_MAX;
>  static int64_t last_time = -1;
>  static int qp_histogram[52];
>  int hours, mins, secs, us;
> @@ -1744,6 +1744,11 @@ static void print_report(int is_last_report, int64_t 
> timer_start, int64_t cur_ti
>  }
>  vid = 1;
>  }
> +
> +/* Find the first written PTS among all the output streams */
> +first_pts = FFMIN(first_pts, av_rescale_q(ost->first_pts,
> +  ost->enc_ctx->time_base,
> +  AV_TIME_BASE_Q));
>  /* compute min output value */
>  if (av_stream_get_end_pts(ost->st) != AV_NOPTS_VALUE)
>  pts = FFMAX(pts, av_rescale_q(av_stream_get_end_pts(ost->st),
> @@ -1752,6 +1757,7 @@ static void print_report(int is_last_report, int64_t 
> timer_start, int64_t cur_ti
>  nb_frames_drop += ost->last_dropped;
>  }
>  
> +pts -= first_pts;
>  secs = FFABS(pts) / AV_TIME_BASE;
>  us = FFABS(pts) % AV_TIME_BASE;
>  mins = secs / 60;

there is a check later for pts to be equal AV_NOPTS_VALUE
that will not work with a "first pts" offset

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


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

Re: [FFmpeg-devel] [PATCH] avcodec/x86/hpeldsp: fix half pel interpolation

[Henrik Gramner]

On Fri, Apr 27, 2018 at 4:47 PM, Jerome Borsboom
 wrote:
> In the put_no_rnd_pixels functions, the psubusb instruction subtracts one 
> from each
> unsigned byte to correct for the rouding that the PAVGB instruction performs. 
> The psubusb
> instruction, however, uses saturation when the value does not fit in the 
> operand type,
> i.e. an unsigned byte. In this particular case, this means that when the 
> value of a pixel
> is 0, the psubusb instruction will return 0 instead of -1 as this value does 
> not fit in
> an unsigned byte and is saturated to 0. The result is that the interpolated 
> value is not
> corrected for the rounding that PAVGB performs and that the result will be 
> off by one.

Looks correct. You could put it in a macro though instead of
duplicating the code, e.g.

%macro PAVGB_NO_RND 4 ; dst/src1, src2, tmp, pb_1
pxor %3, %1, %2
pand %3, %4
PAVGB%1, %2
psubb%1, %3
%endmacro
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] fftools/ffmpeg: Add system time and real time to benchmarking.

[Mark Wachsler]

The -benchmark and -benchmark_all options now show user, system, and real time,
instead of just user time.
---
 fftools/ffmpeg.c | 49 +++-
 1 file changed, 36 insertions(+), 13 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 4dbe72186d..4036058591 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -120,8 +120,14 @@ const char *const forced_keyframes_const_names[] = {
 NULL
 };
 
+typedef struct BenchmarkTimeStamps {
+int64_t real_usec;
+int64_t user_usec;
+int64_t sys_usec;
+} BenchmarkTimeStamps;
+
 static void do_video_stats(OutputStream *ost, int frame_size);
-static int64_t getutime(void);
+static BenchmarkTimeStamps get_benchmark_time_stamps(void);
 static int64_t getmaxrss(void);
 static int ifilter_has_all_input_formats(FilterGraph *fg);
 
@@ -133,7 +139,7 @@ static int64_t decode_error_stat[2];
 
 static int want_sdp = 1;
 
-static int current_time;
+static BenchmarkTimeStamps current_time;
 AVIOContext *progress_avio = NULL;
 
 static uint8_t *subtitle_out;
@@ -653,7 +659,7 @@ static void abort_codec_experimental(AVCodec *c, int 
encoder)
 static void update_benchmark(const char *fmt, ...)
 {
 if (do_benchmark_all) {
-int64_t t = getutime();
+BenchmarkTimeStamps t = get_benchmark_time_stamps();
 va_list va;
 char buf[1024];
 
@@ -661,7 +667,11 @@ static void update_benchmark(const char *fmt, ...)
 va_start(va, fmt);
 vsnprintf(buf, sizeof(buf), fmt, va);
 va_end(va);
-av_log(NULL, AV_LOG_INFO, "bench: %8"PRIu64" %s \n", t - 
current_time, buf);
+av_log(NULL, AV_LOG_INFO,
+   "bench: %8" PRIu64 " user %8" PRIu64 " sys %8" PRIu64 " 
real %s \n",
+   t.user_usec - current_time.user_usec,
+   t.sys_usec - current_time.sys_usec,
+   t.real_usec - current_time.real_usec, buf);
 }
 current_time = t;
 }
@@ -4715,23 +4725,31 @@ static int transcode(void)
 return ret;
 }
 
-
-static int64_t getutime(void)
+static BenchmarkTimeStamps get_benchmark_time_stamps(void)
 {
+BenchmarkTimeStamps time_stamps;
+time_stamps.real_usec = av_gettime_relative();
 #if HAVE_GETRUSAGE
 struct rusage rusage;
 
 getrusage(RUSAGE_SELF, );
-return (rusage.ru_utime.tv_sec * 100LL) + rusage.ru_utime.tv_usec;
+time_stamps.user_usec =
+(rusage.ru_utime.tv_sec * 100LL) + rusage.ru_utime.tv_usec;
+time_stamps.sys_usec =
+(rusage.ru_stime.tv_sec * 100LL) + rusage.ru_stime.tv_usec;
 #elif HAVE_GETPROCESSTIMES
 HANDLE proc;
 FILETIME c, e, k, u;
 proc = GetCurrentProcess();
 GetProcessTimes(proc, , , , );
-return ((int64_t) u.dwHighDateTime << 32 | u.dwLowDateTime) / 10;
+time_stamps.user_usec =
+((int64_t)u.dwHighDateTime << 32 | u.dwLowDateTime) / 10;
+time_stamps.sys_usec =
+((int64_t)k.dwHighDateTime << 32 | k.dwLowDateTime) / 10;
 #else
-return av_gettime_relative();
+time_stamps.user_usec = time_stamps.sys_usec = 0;
 #endif
+return time_stamps;
 }
 
 static int64_t getmaxrss(void)
@@ -4759,7 +4777,7 @@ static void log_callback_null(void *ptr, int level, const 
char *fmt, va_list vl)
 int main(int argc, char **argv)
 {
 int i, ret;
-int64_t ti;
+BenchmarkTimeStamps ti;
 
 init_dynload();
 
@@ -4811,12 +4829,17 @@ int main(int argc, char **argv)
 want_sdp = 0;
 }
 
-current_time = ti = getutime();
+current_time = ti = get_benchmark_time_stamps();
 if (transcode() < 0)
 exit_program(1);
-ti = getutime() - ti;
 if (do_benchmark) {
-av_log(NULL, AV_LOG_INFO, "bench: utime=%0.3fs\n", ti / 100.0);
+current_time = get_benchmark_time_stamps();
+int64_t utime = current_time.user_usec - ti.user_usec;
+int64_t stime = current_time.sys_usec - ti.sys_usec;
+int64_t rtime = current_time.real_usec - ti.real_usec;
+av_log(NULL, AV_LOG_INFO,
+   "bench: utime=%0.3fs stime=%0.3fs rtime=%0.3fs\n",
+   utime / 100.0, stime / 100.0, rtime / 100.0);
 }
 av_log(NULL, AV_LOG_DEBUG, "%"PRIu64" frames successfully decoded, 
%"PRIu64" decoding errors\n",
decode_error_stat[0], decode_error_stat[1]);
-- 
2.17.0.441.gb46fe60e1d-goog

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

Re: [FFmpeg-devel] libavutil/encryption_info: Allow multiple init info.

[Jacob Trimble]

On Mon, Apr 23, 2018 at 11:03 AM, Jacob Trimble  wrote:
> While integrating my encryption info changes, I noticed a problem with
> the init info structs.  I implemented them as side-data on the Stream.
> But this means there can only be one per stream.  However, there can
> be multiple 'pssh' atoms in a single stream (e.g. for key rotation or
> multiple key systems). (sorry for not noticing sooner)
>
> Attached is a patch to fix this by making the init info a
> singly-linked-list.  It is ABI compatible and is still easy to use and
> understand.  The alternative would be to break ABI and have the
> side-data methods return an array of pointers.  I could do that
> instead if that is preferable.

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

[FFmpeg-devel] Format fps field of progress report to two decimal digits

[Andre Ribeiro Camargo]

Hello everybody!


Mr. Niedermayer, could you please review the attached patch to ffmpeg.c?

Thanks in advance.


André

AVISO Esta mensagem, incluindo os seus anexos, pode conter informações 
confidenciais destinadas a indivíduo e propósito específicos e é protegida por 
lei. Se você não é o destinatário dessa mensagem, fica desde já notificado de 
que não poderá utilizar, copiar ou divulgar as informações e os conteúdos dos 
documentos. É terminantemente proibida a utilização, acesso, cópia ou 
divulgação não autorizada das informações presentes nesta mensagem.
NOTICE This message, including its attachments, may contain confidential and/or 
privileged information intended for a specific person and/or purpose and is 
protected by law. If you are not the addressee of this message, you shall not 
use, copy or disclose any information herein.
From 6085cdab413c0f95aca567260bf16df09f446531 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A9=20Camargo?= 
Date: Fri, 27 Apr 2018 00:35:31 -0300
Subject: [PATCH] fftools/ffmpeg: change fps progress log message to show two
 decimal digits

Useful when live encoding videos at 29.97 fps because delivers a more accurate result for monitoring.
---
 fftools/ffmpeg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 4dbe72186d..565b2c6dab 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1696,7 +1696,7 @@ static void print_report(int is_last_report, int64_t timer_start, int64_t cur_ti
 av_bprintf(, "frame=%5d fps=%3.*f q=%3.1f ",
  frame_number, fps < 9.95, fps, q);
 av_bprintf(_script, "frame=%d\n", frame_number);
-av_bprintf(_script, "fps=%.1f\n", fps);
+av_bprintf(_script, "fps=%.2f\n", fps);
 av_bprintf(_script, "stream_%d_%d_q=%.1f\n",
ost->file_index, ost->index, q);
 if (is_last_report)
-- 
2.13.5 (Apple Git-94)

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

Re: [FFmpeg-devel] [PATCH] avcodec: remove duplicate prores decoder

[Michael Niedermayer]

On Thu, Apr 26, 2018 at 03:14:08PM +0200, Paul B Mahol wrote:
> Removed slower one, couldn't figure out why it is slower.
> 
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/Makefile |   1 -
>  libavcodec/allcodecs.c  |   1 -
>  libavcodec/proresdec_lgpl.c | 786 
> 
>  3 files changed, 788 deletions(-)
>  delete mode 100644 libavcodec/proresdec_lgpl.c

probably ok

thx


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

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: properly initialize output stream field order

[Michael Niedermayer]

On Thu, Apr 26, 2018 at 04:06:27PM +0200, Tobias Rapp wrote:
> Fixes stream field order written by avformat_write_header when "top"
> option is specified on the command-line.
> 
> Signed-off-by: Tobias Rapp 
> ---
>  fftools/ffmpeg.c | 6 ++
>  1 file changed, 6 insertions(+)

possibly correct

thanks

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

Those who are best at talking, realize last or never when they are wrong.


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

Re: [FFmpeg-devel] [PATCH] Add system and real time to benchmarking.

[Michael Niedermayer]

On Fri, Apr 20, 2018 at 04:21:13PM -0400, Mark Wachsler wrote:
> The -benchmark and -benchmark_all options now show user, system, and real 
> time,
> instead of just user time.
> ---
>  fftools/ffmpeg.c | 50 ++--
>  1 file changed, 36 insertions(+), 14 deletions(-)
> 
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 4dbe72186d..d37171d567 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -120,8 +120,14 @@ const char *const forced_keyframes_const_names[] = {
>  NULL
>  };
>  
> +typedef struct TimeStamps {
> +  int64_t real_usec;
> +  int64_t user_usec;
> +  int64_t sys_usec;
> +} TimeStamps;

indention mismatches the rest of the file

also please use some other name, time stamps exist in many areas
of multimedia. This is benchmarking specific. "Benchmark" should be
part of the name to seperate it from other time uses


> +
>  static void do_video_stats(OutputStream *ost, int frame_size);
> -static int64_t getutime(void);
> +static TimeStamps get_time_stamps(void);
>  static int64_t getmaxrss(void);
>  static int ifilter_has_all_input_formats(FilterGraph *fg);
>  
> @@ -133,7 +139,7 @@ static int64_t decode_error_stat[2];
>  
>  static int want_sdp = 1;
>  
> -static int current_time;
> +static TimeStamps current_time;
>  AVIOContext *progress_avio = NULL;
>  
>  static uint8_t *subtitle_out;
> @@ -653,7 +659,7 @@ static void abort_codec_experimental(AVCodec *c, int 
> encoder)
>  static void update_benchmark(const char *fmt, ...)
>  {
>  if (do_benchmark_all) {
> -int64_t t = getutime();
> +TimeStamps t = get_time_stamps();
>  va_list va;
>  char buf[1024];
>  
> @@ -661,7 +667,11 @@ static void update_benchmark(const char *fmt, ...)
>  va_start(va, fmt);
>  vsnprintf(buf, sizeof(buf), fmt, va);
>  va_end(va);
> -av_log(NULL, AV_LOG_INFO, "bench: %8"PRIu64" %s \n", t - 
> current_time, buf);
> +av_log(NULL, AV_LOG_INFO,
> +   "bench: %8" PRIu64 " user %8" PRIu64 " sys %8" PRIu64 " 
> real %s \n",
> +   t.user_usec - current_time.user_usec,
> +   t.sys_usec - current_time.sys_usec,
> +   t.real_usec - current_time.real_usec, buf);
>  }
>  current_time = t;
>  }

> @@ -4715,23 +4725,30 @@ static int transcode(void)
>  return ret;
>  }
>  
> -
> -static int64_t getutime(void)
> -{
> +static TimeStamps get_time_stamps(void) {
> +  TimeStamps time_stamps;
> +  time_stamps.real_usec = av_gettime_relative();

again, indention mismatches, also the { placement mismatches other functions
(i dont mind really much personally, but some people are sensitive about this)

thx

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

Re: [FFmpeg-devel] [PATCH] configure: deprecate libpostproc and pp filter

[Michael Niedermayer]

On Fri, Apr 27, 2018 at 12:39:13PM +0200, Paul B Mahol wrote:
> On 4/27/18, Michael Niedermayer  wrote:
> > On Fri, Apr 27, 2018 at 02:36:05AM +0200, Michael Niedermayer wrote:
> >> On Fri, Apr 27, 2018 at 12:08:16AM +0100, Josh de Kock wrote:
> >> > The postproc library is only used in a single filter, so should be moved
> >> > into the filter itself if the filter was to stay, but the filter has all
> >> > of its internal filters now in lavfi itself. (Also it's a bit weird to
> >> > have a separate library of filters which is used in a filter in the
> >> > filter library).
> >> > ---
> >> >  configure | 6 --
> >> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> That patch is a bit surprising.
> >> What prompted you to write this ?
> >>
> >> Also, dont you think that before suggesting to deprecate a lib it would
> >> make
> >> sense to talk with the author and maintainer of the library in question ?
> >>
> >> Either way, the first question to ask would be
> >> "why was/is it a seperate library"
> >> I think, you do not know,
> >> And you should understand why things are as they are before suggesting to
> >> deprecate, move or otherwise change them
> >
> > Elaborating on this a bit
> >
> > The first step is to understand the current state of things, why is
> > libpostproc where it is. (it seems noone asked the maintainer / author)
> >
> > after its understood, next is to discuss whats the best thing for the
> > project
> > Some discussion occured on IRC but people neither understood why its in a
> > seperate lib currently nor where anyone who maintains or who wrote it
> > involved
> > in this discussion, making this discussion a bit headless and blind
> > I also think IRC is not ideal for this discussion as only a small subset
> > of people will be there when something is discussed ...
> >
> > Once a consensus is reached what is best to do, that should then be
> > implemented.
> > We have not reached this point nor has anything that was suggested been
> > implemented.
> >
> > The last step then is to deprecate any previous places that are no longer
> > relevant. So this patch is premature, other steps have to be done first
> 
> Libpostproc was removed from Libav, you failed somehow merge that change?
> 
> 
> They moved it to abandoned repo.
> 
> 
> We should not follow that.
> 
> 

> Libpostproc is very small in size and trivial GPL code and all funcionality
> should be moved to pp filter in libavfilter.
> 
> No point to have separate library nobody really uses.

Well, thats one direction it could go.
But still noone asks why its a seperate lib ?

Its long ago and there were multiple reasons, the one still relevant today
is that lossy decompressed moving pictures and images is very widespread.
And postprocessing that often improves its subjective and
objective quality

So there are a lot of applications and libraries which would benefit
from using "postprocessing".

And libavfilter is quite big, a small lib that is just for postprocessing
lossy decompressed video would fit this usecase better.

I think a big problem we had was that alot of software which would benefit from
this code isnt aware of it.
But i may be wrong, libpostproc was never "advertised" by anyone as being
usefull to improve the quality of low bitrate videos, and jpegs and other
similar lossy compression schemes.

I dont know what is the best way forward but simply moving it into
a filter in libavfilter alone seems to make it much harder to use for
many outside ffmpeg.

Of course that can be a great idea together with making libavfilter more
modular. If for example an application which wants to use just one filter
from libavfilter could do this without pulling anything else in not even
most of the core and just use that one filter then moving postproc
into a filter in libavfilter would be possibly even better than having it
in a seperate lib (which is less modular as it would contain multiple
related filters)

Its really a question what people prefer what makes most sense and what 
has volunteers to do the actual work.


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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

Re: [FFmpeg-devel] [PATCH] avcodec/x86/hpeldsp: fix half pel interpolation

[Carl Eugen Hoyos]

2018-04-27 16:47 GMT+02:00, Jerome Borsboom :
> The assembly optimized half pel interpolation in some cases rounds the
> interpolated value when no rounding is requested. The result is a off by one
> error when one of the pixel values is zero.

See also:
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=92415510

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

[FFmpeg-devel] [PATCH] avcodec/x86/hpeldsp: fix half pel interpolation

[Jerome Borsboom]

The assembly optimized half pel interpolation in some cases rounds the
interpolated value when no rounding is requested. The result is a off by one
error when one of the pixel values is zero.

Signed-off-by: Jerome Borsboom 
---
In the put_no_rnd_pixels functions, the psubusb instruction subtracts one from 
each
unsigned byte to correct for the rouding that the PAVGB instruction performs. 
The psubusb
instruction, however, uses saturation when the value does not fit in the 
operand type,
i.e. an unsigned byte. In this particular case, this means that when the value 
of a pixel
is 0, the psubusb instruction will return 0 instead of -1 as this value does 
not fit in
an unsigned byte and is saturated to 0. The result is that the interpolated 
value is not
corrected for the rounding that PAVGB performs and that the result will be off 
by one.

The corrections below solved the issues for me, but I do not a lot of 
experience in optimizing
assembly. A good check for the correctness of the solution might be advisable. 
Furthermore,
I have not checked the other assembly, but there may be more cases where the 
psubusb
instruction does not provide the desired results. A good check by the 
owner/maintainer of
the assembly code might be appropriate.

 libavcodec/x86/hpeldsp.asm | 38 --
 1 file changed, 32 insertions(+), 6 deletions(-)

diff --git a/libavcodec/x86/hpeldsp.asm b/libavcodec/x86/hpeldsp.asm
index ce5d7a4e28..bae2ba9880 100644
--- a/libavcodec/x86/hpeldsp.asm
+++ b/libavcodec/x86/hpeldsp.asm
@@ -145,10 +145,16 @@ cglobal put_no_rnd_pixels8_x2, 4,5
 mova m1, [r1+1]
 mova m3, [r1+r2+1]
 add  r1, r4
-psubusb  m0, m6
-psubusb  m2, m6
+mova m4, m0
+pxor m4, m1
+pand m4, m6
 PAVGBm0, m1
+psubbm0, m4
+mova m4, m2
+pxor m4, m3
+pand m4, m6
 PAVGBm2, m3
+psubbm2, m4
 mova   [r0], m0
 mova[r0+r2], m2
 mova m0, [r1]
@@ -157,10 +163,16 @@ cglobal put_no_rnd_pixels8_x2, 4,5
 mova m3, [r1+r2+1]
 add  r0, r4
 add  r1, r4
-psubusb  m0, m6
-psubusb  m2, m6
+mova m4, m0
+pxor m4, m1
+pand m4, m6
 PAVGBm0, m1
+psubbm0, m4
+mova m4, m2
+pxor m4, m3
+pand m4, m6
 PAVGBm2, m3
+psubbm2, m4
 mova   [r0], m0
 mova[r0+r2], m2
 add  r0, r4
@@ -227,18 +239,32 @@ cglobal put_no_rnd_pixels8_y2, 4,5
 mova m1, [r1+r2]
 mova m2, [r1+r4]
 add  r1, r4
-psubusb  m1, m6
+mova m3, m0
+pxor m3, m1
+pand m3, m6
 PAVGBm0, m1
+psubbm0, m3
+mova m3, m1
+pxor m3, m2
+pand m3, m6
 PAVGBm1, m2
+psubbm1, m3
 mova[r0+r2], m0
 mova[r0+r4], m1
 mova m1, [r1+r2]
 mova m0, [r1+r4]
 add  r0, r4
 add  r1, r4
-psubusb  m1, m6
+mova m3, m2
+pxor m3, m1
+pand m3, m6
 PAVGBm2, m1
+psubbm2, m3
+mova m3, m1
+pxor m3, m0
+pand m3, m6
 PAVGBm1, m0
+psubbm1, m3
 mova[r0+r2], m2
 mova[r0+r4], m1
 add  r0, r4
-- 
2.13.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: deprecate libpostproc and pp filter

[Carl Eugen Hoyos]

2018-04-27 14:40 GMT+02:00, Jean-Baptiste Kempf :
> Hello,
>
> On Fri, 27 Apr 2018, at 12:39, Paul B Mahol wrote:
>> No point to have separate library nobody really uses.
>
> VLC uses libprostproc, but we see many crashes in it

Please point us to the bug reports.

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

[FFmpeg-devel] [PATCH] avfilter/vf_overlay: add slice threading

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavfilter/vf_overlay.c | 257 ---
 1 file changed, 175 insertions(+), 82 deletions(-)

diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index c6a6ac82f3..d46804125e 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
@@ -40,6 +40,10 @@
 #include "framesync.h"
 #include "video.h"
 
+typedef struct ThreadData {
+AVFrame *dst, *src;
+} ThreadData;
+
 static const char *const var_names[] = {
 "main_w","W", ///< width  of the mainvideo
 "main_h","H", ///< height of the mainvideo
@@ -124,7 +128,7 @@ typedef struct OverlayContext {
 
 AVExpr *x_pexpr, *y_pexpr;
 
-void (*blend_image)(AVFilterContext *ctx, AVFrame *dst, const AVFrame 
*src, int x, int y);
+int (*blend_slice)(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs);
 } OverlayContext;
 
 static av_cold void uninit(AVFilterContext *ctx)
@@ -406,7 +410,7 @@ static int config_output(AVFilterLink *outlink)
 static av_always_inline void blend_image_packed_rgb(AVFilterContext *ctx,
AVFrame *dst, const AVFrame *src,
int main_has_alpha, int x, int y,
-   int is_straight)
+   int is_straight, int jobnr, int nb_jobs)
 {
 OverlayContext *s = ctx->priv;
 int i, imax, j, jmax;
@@ -425,13 +429,19 @@ static av_always_inline void 
blend_image_packed_rgb(AVFilterContext *ctx,
 const int sb = s->overlay_rgba_map[B];
 const int sa = s->overlay_rgba_map[A];
 const int sstep = s->overlay_pix_step[0];
+int slice_start, slice_end;
 uint8_t *S, *sp, *d, *dp;
 
 i = FFMAX(-y, 0);
-sp = src->data[0] + i * src->linesize[0];
-dp = dst->data[0] + (y+i) * dst->linesize[0];
+imax = FFMIN(-y + dst_h, src_h);
 
-for (imax = FFMIN(-y + dst_h, src_h); i < imax; i++) {
+slice_start = (imax * jobnr) / nb_jobs;
+slice_end = (imax * (jobnr+1)) / nb_jobs;
+
+sp = src->data[0] + (i + slice_start) * src->linesize[0];
+dp = dst->data[0] + (y + i + slice_start) * dst->linesize[0];
+
+for (i = i + slice_start; i < slice_end; i++) {
 j = FFMAX(-x, 0);
 S = sp + j * sstep;
 d = dp + (x+j) * dstep;
@@ -495,7 +505,9 @@ static av_always_inline void blend_plane(AVFilterContext 
*ctx,
  int dst_offset,
  int dst_step,
  int straight,
- int yuv)
+ int yuv,
+ int jobnr,
+ int nb_jobs)
 {
 int src_wp = AV_CEIL_RSHIFT(src_w, hsub);
 int src_hp = AV_CEIL_RSHIFT(src_h, vsub);
@@ -505,16 +517,22 @@ static av_always_inline void blend_plane(AVFilterContext 
*ctx,
 int xp = x>>hsub;
 uint8_t *s, *sp, *d, *dp, *dap, *a, *da, *ap;
 int jmax, j, k, kmax;
+int slice_start, slice_end;
 
 j = FFMAX(-yp, 0);
-sp = src->data[i] + j * src->linesize[i];
+jmax = FFMIN(-yp + dst_hp, src_hp);
+
+slice_start = (jmax * jobnr) / nb_jobs;
+slice_end = ((jmax * (jobnr+1)) / nb_jobs);
+
+sp = src->data[i] + slice_start * src->linesize[i];
 dp = dst->data[dst_plane]
-  + (yp+j)* dst->linesize[dst_plane]
+  + (yp + slice_start) * dst->linesize[dst_plane]
   + dst_offset;
-ap = src->data[3] + (j<linesize[3];
-dap = dst->data[3] + ((yp+j) << vsub) * dst->linesize[3];
+ap = src->data[3] + (slice_start << vsub) * src->linesize[3];
+dap = dst->data[3] + ((yp + slice_start) << vsub) * dst->linesize[3];
 
-for (jmax = FFMIN(-yp + dst_hp, src_hp); j < jmax; j++) {
+for (j = slice_start; j < slice_end; j++) {
 k = FFMAX(-xp, 0);
 d = dp + (xp+k) * dst_step;
 s = sp + k;
@@ -621,7 +639,8 @@ static av_always_inline void 
blend_image_yuv(AVFilterContext *ctx,
  int hsub, int vsub,
  int main_has_alpha,
  int x, int y,
- int is_straight)
+ int is_straight,
+ int jobnr, int nb_jobs)
 {
 OverlayContext *s = ctx->priv;
 const int src_w = src->width;
@@ -630,11 +649,14 @@ static av_always_inline void 
blend_image_yuv(AVFilterContext *ctx,
 const int dst_h = dst->height;
 
 blend_plane(ctx, dst, src, src_w, src_h, dst_w, dst_h, 0, 0,   0, x, 
y, main_has_alpha,
-s->main_desc->comp[0].plane, s->main_desc->comp[0].offset, 
s->main_desc->comp[0].step, is_straight, 1);
+

Re: [FFmpeg-devel] [PATCH] configure: deprecate libpostproc and pp filter

[Paul B Mahol]

On 4/27/18, Jean-Baptiste Kempf  wrote:
> Hello,
>
> On Fri, 27 Apr 2018, at 12:39, Paul B Mahol wrote:
>> No point to have separate library nobody really uses.
>
> VLC uses libprostproc, but we see many crashes in it, and the usefulness is
> not very obvious/visible depending on the codec.

Crashes? Have you reported such cases?

>
> A general library/filter to "smooth" would be very very welcome.

There are numerous filters in lavfi that "smooth" stuff.

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

Re: [FFmpeg-devel] [PATCH] configure: deprecate libpostproc and pp filter

[Jean-Baptiste Kempf]

Hello,

On Fri, 27 Apr 2018, at 12:39, Paul B Mahol wrote:
> No point to have separate library nobody really uses.

VLC uses libprostproc, but we see many crashes in it, and the usefulness is not 
very obvious/visible depending on the codec.

A general library/filter to "smooth" would be very very welcome.

Thx.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: deprecate libpostproc and pp filter

[Nicolas George]

Paul B Mahol (2018-04-27):
> Perhaps you forgot, but I removed libmpcodecs + wrapper.

Yes, but you also spend time writing (probably) useful code.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] configure: deprecate libpostproc and pp filter

[Paul B Mahol]

On 4/27/18, Nicolas George  wrote:
> Paul B Mahol (2018-04-27):
>> Libpostproc was removed from Libav, you failed somehow merge that change?
>
> Many useful things were removed from libav.
>
> I find somewhat disturbing the amount of time and effort that some
> people (not you) spend trying to remove harmless code instead of
> producing useful new code.

Perhaps you forgot, but I removed libmpcodecs + wrapper.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] fix cuCtxPushCurrent signature

[Timo Rothenpieler]

applied



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

Re: [FFmpeg-devel] [PATCH] configure: deprecate libpostproc and pp filter

[Nicolas George]

Paul B Mahol (2018-04-27):
> Libpostproc was removed from Libav, you failed somehow merge that change?

Many useful things were removed from libav.

I find somewhat disturbing the amount of time and effort that some
people (not you) spend trying to remove harmless code instead of
producing useful new code.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] checkasm/hevc_mc : add hevc_mc for checkasm

[Yingming Fan]

Thank you for your review.

> On Apr 17, 2018, at 15:29, Shengbin Meng  > wrote:
> 
> 
> 
>> On Apr 9, 2018, at 10:12, Yingming Fan > > wrote:
>> 
>> From: Yingming Fan >
>> 
>> ---
>> Hi, there.
>> I plane to submit our arm32 neon codes for qpel and epel.
>> While before this i will submit hevc_mc checkasm codes.
>> This hevc_mc checkasm codes check every qpel and epel function, including 8 
>> 10 and 12 bit.
>> Passed test by using 'checkasm --test=hevc_mc' under Linux x86_64 MacOS 
>> x86_64 and Linux arm64 platform.
>> Also passed FATE test. 
>> 
>> tests/checkasm/Makefile   |   2 +-
>> tests/checkasm/checkasm.c |   1 +
>> tests/checkasm/checkasm.h |   1 +
>> tests/checkasm/hevc_mc.c  | 547 
>> ++
>> tests/fate/checkasm.mak   |   1 +
>> 5 files changed, 551 insertions(+), 1 deletion(-)
>> create mode 100644 tests/checkasm/hevc_mc.c
>> 
>> diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
>> index 0233d2f989..e6c94cd676 100644
>> --- a/tests/checkasm/Makefile
>> +++ b/tests/checkasm/Makefile
>> @@ -23,7 +23,7 @@ AVCODECOBJS-$(CONFIG_EXR_DECODER)   += exrdsp.o
>> AVCODECOBJS-$(CONFIG_HUFFYUV_DECODER)   += huffyuvdsp.o
>> AVCODECOBJS-$(CONFIG_JPEG2000_DECODER)  += jpeg2000dsp.o
>> AVCODECOBJS-$(CONFIG_PIXBLOCKDSP)   += pixblockdsp.o
>> -AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o 
>> hevc_sao.o
>> +AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o 
>> hevc_sao.o hevc_mc.o
>> AVCODECOBJS-$(CONFIG_UTVIDEO_DECODER)   += utvideodsp.o
>> AVCODECOBJS-$(CONFIG_V210_ENCODER)  += v210enc.o
>> AVCODECOBJS-$(CONFIG_VP9_DECODER)   += vp9dsp.o
>> diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
>> index 20ce56932f..b95efc674d 100644
>> --- a/tests/checkasm/checkasm.c
>> +++ b/tests/checkasm/checkasm.c
>> @@ -117,6 +117,7 @@ static const struct {
>>{ "hevc_add_res", checkasm_check_hevc_add_res },
>>{ "hevc_idct", checkasm_check_hevc_idct },
>>{ "hevc_sao", checkasm_check_hevc_sao },
>> +{ "hevc_mc", checkasm_check_hevc_mc },
>>#endif
>>#if CONFIG_HUFFYUV_DECODER
>>{ "huffyuvdsp", checkasm_check_huffyuvdsp },
>> diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
>> index dcab74de06..5a4a612da7 100644
>> --- a/tests/checkasm/checkasm.h
>> +++ b/tests/checkasm/checkasm.h
>> @@ -58,6 +58,7 @@ void checkasm_check_h264qpel(void);
>> void checkasm_check_hevc_add_res(void);
>> void checkasm_check_hevc_idct(void);
>> void checkasm_check_hevc_sao(void);
>> +void checkasm_check_hevc_mc(void);
>> void checkasm_check_huffyuvdsp(void);
>> void checkasm_check_jpeg2000dsp(void);
>> void checkasm_check_llviddsp(void);
>> diff --git a/tests/checkasm/hevc_mc.c b/tests/checkasm/hevc_mc.c
>> new file mode 100644
>> index 00..018f322c11
>> --- /dev/null
>> +++ b/tests/checkasm/hevc_mc.c
>> @@ -0,0 +1,547 @@
>> +/*
>> + * Copyright (c) 2018 Yingming Fan > >
>> + *
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along
>> + * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
>> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
>> + */
>> +
>> +#include 
>> +
>> +#include "libavutil/intreadwrite.h"
>> +
>> +#include "libavcodec/avcodec.h"
>> +
>> +#include "libavcodec/hevcdsp.h"
>> +
>> +#include "checkasm.h"
>> +
>> +static const uint32_t pixel_mask[3] = { 0x, 0x03ff03ff, 0x0fff0fff 
>> };
>> +static const uint32_t idx_width_map[8][2] = {{1, 4}, {3, 8}, {4, 12}, {5, 
>> 16}, {6, 24}, {7, 32}, {8, 48}, {9, 64}};
> Why not include block width 2 and 6? I notice that there are already some 
> optimization code for that.

I find there are no width 2 and 6 in x86 asm codes, so i remove 2 and 6.
After your remind i find neon codes have 2 and 6.
I will fix this in patch v2.

> 
>> +#define SIZEOF_PIXEL ((bit_depth + 7) / 8)
>> +#define PIXEL_STRIDE (AV_INPUT_BUFFER_PADDING_SIZE + MAX_PB_SIZE + 
>> AV_INPUT_BUFFER_PADDING_SIZE)
>> +#define BUF_SIZE ((MAX_PB_SIZE+4+4) * PIXEL_STRIDE * 2)
>> +
>> +#define randomize_buffers(buf0, buf1, size) \
>> +do {  

Re: [FFmpeg-devel] [PATCH] configure: deprecate libpostproc and pp filter

[Paul B Mahol]

On 4/27/18, Michael Niedermayer  wrote:
> On Fri, Apr 27, 2018 at 02:36:05AM +0200, Michael Niedermayer wrote:
>> On Fri, Apr 27, 2018 at 12:08:16AM +0100, Josh de Kock wrote:
>> > The postproc library is only used in a single filter, so should be moved
>> > into the filter itself if the filter was to stay, but the filter has all
>> > of its internal filters now in lavfi itself. (Also it's a bit weird to
>> > have a separate library of filters which is used in a filter in the
>> > filter library).
>> > ---
>> >  configure | 6 --
>> >  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> That patch is a bit surprising.
>> What prompted you to write this ?
>>
>> Also, dont you think that before suggesting to deprecate a lib it would
>> make
>> sense to talk with the author and maintainer of the library in question ?
>>
>> Either way, the first question to ask would be
>> "why was/is it a seperate library"
>> I think, you do not know,
>> And you should understand why things are as they are before suggesting to
>> deprecate, move or otherwise change them
>
> Elaborating on this a bit
>
> The first step is to understand the current state of things, why is
> libpostproc where it is. (it seems noone asked the maintainer / author)
>
> after its understood, next is to discuss whats the best thing for the
> project
> Some discussion occured on IRC but people neither understood why its in a
> seperate lib currently nor where anyone who maintains or who wrote it
> involved
> in this discussion, making this discussion a bit headless and blind
> I also think IRC is not ideal for this discussion as only a small subset
> of people will be there when something is discussed ...
>
> Once a consensus is reached what is best to do, that should then be
> implemented.
> We have not reached this point nor has anything that was suggested been
> implemented.
>
> The last step then is to deprecate any previous places that are no longer
> relevant. So this patch is premature, other steps have to be done first

Libpostproc was removed from Libav, you failed somehow merge that change?


They moved it to abandoned repo.


We should not follow that.


Libpostproc is very small in size and trivial GPL code and all funcionality
should be moved to pp filter in libavfilter.

No point to have separate library nobody really uses.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: deprecate libpostproc and pp filter

[Michael Niedermayer]

On Fri, Apr 27, 2018 at 02:36:05AM +0200, Michael Niedermayer wrote:
> On Fri, Apr 27, 2018 at 12:08:16AM +0100, Josh de Kock wrote:
> > The postproc library is only used in a single filter, so should be moved 
> > into the filter itself if the filter was to stay, but the filter has all of 
> > its internal filters now in lavfi itself. (Also it's a bit weird to have a 
> > separate library of filters which is used in a filter in the filter 
> > library).
> > ---
> >  configure | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> That patch is a bit surprising.
> What prompted you to write this ?
> 
> Also, dont you think that before suggesting to deprecate a lib it would make
> sense to talk with the author and maintainer of the library in question ?
> 
> Either way, the first question to ask would be
> "why was/is it a seperate library"
> I think, you do not know, 
> And you should understand why things are as they are before suggesting to
> deprecate, move or otherwise change them

Elaborating on this a bit

The first step is to understand the current state of things, why is 
libpostproc where it is. (it seems noone asked the maintainer / author)

after its understood, next is to discuss whats the best thing for the project
Some discussion occured on IRC but people neither understood why its in a
seperate lib currently nor where anyone who maintains or who wrote it involved
in this discussion, making this discussion a bit headless and blind
I also think IRC is not ideal for this discussion as only a small subset
of people will be there when something is discussed ...

Once a consensus is reached what is best to do, that should then be implemented.
We have not reached this point nor has anything that was suggested been
implemented.

The last step then is to deprecate any previous places that are no longer
relevant. So this patch is premature, other steps have to be done first

Thanks


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

[FFmpeg-devel] [PATCH 1/1] fix cuCtxPushCurrent signature

[Daniel Oberhoff]

---
 include/ffnvcodec/dynlink_cuda.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/ffnvcodec/dynlink_cuda.h b/include/ffnvcodec/dynlink_cuda.h
index 2cc50bb..82c5fe3 100644
--- a/include/ffnvcodec/dynlink_cuda.h
+++ b/include/ffnvcodec/dynlink_cuda.h
@@ -108,7 +108,7 @@ typedef CUresult CUDAAPI tcuDeviceGetName(char *name, int 
len, CUdevice dev);
 typedef CUresult CUDAAPI tcuDeviceComputeCapability(int *major, int *minor, 
CUdevice dev);
 typedef CUresult CUDAAPI tcuCtxCreate_v2(CUcontext *pctx, unsigned int flags, 
CUdevice dev);
 typedef CUresult CUDAAPI tcuCtxSetLimit(CUlimit limit, size_t value);
-typedef CUresult CUDAAPI tcuCtxPushCurrent_v2(CUcontext *pctx);
+typedef CUresult CUDAAPI tcuCtxPushCurrent_v2(CUcontext pctx);
 typedef CUresult CUDAAPI tcuCtxPopCurrent_v2(CUcontext *pctx);
 typedef CUresult CUDAAPI tcuCtxDestroy_v2(CUcontext ctx);
 typedef CUresult CUDAAPI tcuMemAlloc_v2(CUdeviceptr *dptr, size_t bytesize);
-- 
2.14.3 (Apple Git-98)

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

[FFmpeg-devel] [PATCH 0/1] fix cuCtxPushCurrent signature

[Daniel Oberhoff]

passes silently in c but fails to compile under c++ if used right

Daniel Oberhoff (1):
  fix cuCtxPushCurrent signature

 include/ffnvcodec/dynlink_cuda.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.14.3 (Apple Git-98)

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

Re: [FFmpeg-devel] [PATCH v2 3/3] avformat/dashenc: Set mp4 as the default format for VP9

[Michael Niedermayer]

On Fri, Apr 27, 2018 at 04:33:27AM +, Jeyapal, Karthick wrote:
> 
> 
> On 4/27/18 4:26 AM, Michael Niedermayer wrote:
> > On Fri, Apr 27, 2018 at 12:35:42AM +0300, Jan Ekström wrote:
> >> On Thu, Apr 26, 2018 at 12:00 PM, Jeyapal, Karthick  
> >> wrote:
> >>>
> >>>
> >>> On 4/23/18 11:40 AM, Karthick J wrote:
>  From: Karthick Jeyapal 
> 
>  There is a separate muxer(webmdashenc.c) for supporting VP9+webm output 
>  in DASH.
>  Hence in this muxer we will focus on supporting VP9 in MP4
>  Have verified playout support of VP9+MP4 in Chrome and Firefox.
>  ---
>   libavformat/dashenc.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
> 
>  diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>  index a5f58d4..211ef23 100644
>  --- a/libavformat/dashenc.c
>  +++ b/libavformat/dashenc.c
>  @@ -959,11 +959,10 @@ static int dash_init(AVFormatContext *s)
>   if (!ctx)
>   return AVERROR(ENOMEM);
> 
>  -// choose muxer based on codec: webm for VP8/9 and opus, mp4 
>  otherwise
>  +// choose muxer based on codec: webm for VP8 and opus, mp4 
>  otherwise
>   // note: os->format_name is also used as part of the mimetype 
>  of the
>   //   representation, e.g. video/
>   if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP8 ||
>  -s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP9 ||
>   s->streams[i]->codecpar->codec_id == AV_CODEC_ID_OPUS ||
>   s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VORBIS) {
>   snprintf(os->format_name, sizeof(os->format_name), "webm");
> >>>
> >>> Pushed the patchset
> >>>
> >>
> >> Hi,
> >>
> >> First of all, I would prefer the patch to actually mention what it is
> >> doing. It is removing the webm override from the muxer for VP9. There
> >> is as far as I know no option to switch between modes in current git,
> >> so the commit message is blindly misleading at best and just plain
> >> trying to look harmless (in order to get a free pass) if taken the
> >> wrong way. Not saying you meant it that way, but the commit message
> >> does not say what it does as far as I can see.
> >>
> >> Also the patch does not mention the reason why it is doing this other
> >> than the fact that there's a separate webm DASH muxer. That is true,
> >> but the real reason you were switching this default is because the
> >> WebM mode does not work. Now, fixing segfaults is good. And, for the
> >> record, I actually agree with the change since with the profile string
> >> it works in dash.js on various browsers (Firefox, Chromium, Edge).
> >>
> >> But begesus... If it is done like this you might as well be honest and
> >> just remove the WebM mode! Because right now you left it there to
> >> segfault for VP8, Opus, Vorbis. Another alternative would have been to
> >> apply the small change to Rodger Combs's patch
> >> (https://patchwork.ffmpeg.org/patch/7984/), which you even commented
> >> on before! Maybe it still doesn't work in browsers, but at least it
> >> would have gotten to that point.
> >>
> >> Really, I am thankful that you are contributing, but I really do not
> >> want to see things like these after long days of work when I have not
> >> noticed or wasn't able to write a long reply. You waited for two days,
> >> and pushed without reviews even though I had shown interest in the
> >> patch in its first iteration. If you are interested in getting quick
> >> comments from someone (including me when I am awake and available),
> >> please join the IRC channel #ffmpeg-devel if only possible. Even if it
> >> is just for pokes and links to patchwork towards someone who has shown
> >> interest to related patches before. I try as much as possible to poke
> >> relevant people when I post patches, and I would prefer it if others
> >> would do that as well. We're not perfect and issues can and do go
> >> through peoples' eyes (esp. if the change set is of the larger size
> >> issues tend to get hidden in plain sight, unfortunately), but let's
> >> try to make this work.
> >>
> >> Best regards,
> >> Jan
> >>
> >> P.S. I am sorry if my way of speech came out bad, it is just past
> >> midnight here and I was trying to get a reply to this written after
> >> noticing this mail.
> >
> > I can confirm that there still is a segfault occuring
> > ./ffmpeg -i ~/fatesamples/fate/fate-suite/vp8/RRSF49-short.webm -c copy 
> > -b:v 2M out.mpd
> >
> > Jeyapal, do you have time to look at these segfaults?
> > ffmpeg should not segfault!
> > Its also very important that no invalid files are generated (just saying so
> > we dont end with a quick segfault fix that then produces bad files)
> We do have a fix from Jan for segfault issue. 
> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/229082.html
> I will test it and push it 

Re: [FFmpeg-devel] Typo in h264_parser.c ?

[John Pilkington]

On 27/04/18 00:47, Mark Thompson wrote:

On 27/04/18 00:33, John Pilkington wrote:

Hi: I haven't previously posted here.

I've been on the mythtv lists since 2005 and wrote a cutting script that I use 
daily on mpeg2video SD recordings from DVB-T; it cuts with Project-X, at 
keyframes.  I have been trying to write a similar script using ffmpeg to cut 
h264-encoded HD recordings from DVB-T2 transmissions in the UK. Internal cuts 
have not been good.

I'm using mythffmpeg version 3.4.1, as incorporated in current mythtv-master, 
in Fedora 26.  Results have been similar with ffmpeg 3.3.7 for x86_64 f26 from 
rpmfusion.

I use a first pass to 'ignore_unknown' streams, and a second to do the cutting. 
During the second pass I have almost always had error reports of 'illegal 
reordering of pic_nums_idc' or 'reference count overflow.'

I reported that and the following details yesterday on the mythtv-devel list, 
and a re-post here has been suggested.

The error reports apparently come from libavcodec/h264_parser.c, lines 186 and 
194.  The numbers in the 'if/else if' combination at lines 182/184 look very 
strange to me:

     unsigned int reordering_of_pic_nums_idc = get_ue_golomb_31(gb);

     if (reordering_of_pic_nums_idc < 3)
     get_ue_golomb_long(gb)
     else if (reordering_of_pic_nums_idc > 3) {

..and libavcodec/golomb.h has this at line 82:

/**
* read unsigned exp golomb code, constraint to a max of 31.
* the return value is undefined if the stored value exceeds 31.
*/
static inline int get_ue_golomb_31(GetBitContext *gb)
{

***I think that the '3' in the 'else if' line in the parser should probably be 
31. ***


No.

This is parsing a reference picture list modification block - see H.264 
, section 7.3.3.1.

Valid meaningful values are 0-2, and 3 ends the list.  Any other value is 
invalid.


I have patched my copy accordingly.  I have seen no bad effects, most of the 
error messages have gone, and the internal cuts are much neater.

It would be great if someone would look to see if this and/or other patches are 
appropriate.  IIUC mythtv won't patch the ffmpeg code that it uses.

I have more test results available if required.


Can you share a short sample showing your problem?

- Mark


Thanks for the speedy reply. I think I've seen this sort of thing in all 
the tests I have done, and there's a link to a sample clip here, with 
other perhaps relevant stuff:  No streams have been removed.


 https://code.mythtv.org/trac/ticket/12010#comment:18

But here's a specific example of results before and after my patch, both 
working on a stripped-to-two-streams file.  Both obviously still have 
problems.   The options in the command line are my current best effort. 
Results are fine except for transients after most cuts.


John

Recording from itv HD DVB-T2 - The Durrells

-
ffmpeg 3.3.7 for x86_64 f26 from rpmfusion.  Not patched.


ionice -c3 ffmpeg -hide_banner -ignore_unknown-ss 1952.3000 
-noaccurate_seek -t 687.6800  -i 
/home/john/SGs/RecsSG2/21605_20180422185800.ts -ignore_unknown -ss 
1952.3000 -t 687.6800  -i /home/john/SGs/RecsSG2/21605_20180422185800.ts 
-map 0:0 -c:v  copy-map 1:1 -c:a  copy-avoid_negative_ts 
make_zero   /mnt/sdb1/TScut_work/21605_20180422185800_25222_004.ts


[h264 @ 0x56030df29d60] mmco: unref short failure
Last message repeated 1 times
[h264 @ 0x56030df29d60] Increasing reorder buffer to 3
[NULL @ 0x56030df29d60] illegal reordering_of_pic_nums_idc 4
[NULL @ 0x56030df29d60] illegal reordering_of_pic_nums_idc 7 



[NULL @ 0x56030df29d60] illegal reordering_of_pic_nums_idc 15 



[NULL @ 0x56030df29d60] reference count 2 overflow 



[NULL @ 0x56030df29d60] reference count 1 overflow 



[NULL @ 0x56030df29d60] illegal reordering_of_pic_nums_idc 6 



[NULL @ 0x56030df29d60] reference count 1 overflow 



[NULL @ 0x56030df29d60] illegal reordering_of_pic_nums_idc 6 



[NULL @ 0x56030df29d60] illegal reordering_of_pic_nums_idc 19 



Input #0, mpegts, from '/home/john/SGs/RecsSG2/21605_20180422185800.ts':
  Duration: 01:05:59.34, start: 1.40, bitrate: 3945 kb/s
  Program 1
Metadata:
  service_name: Service01
  service_provider: FFmpeg
Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), 
yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 
tbr, 90k tbn, 50 tbc
Stream #0:1[0x101](eng): Audio: aac_latm (LC) ([17][0][0][0] / 
0x0011), 48000 Hz, stereo, fltp


---

mythffmpeg version 3.4.1, as incorporated in current mythtv-master, but 
with patch


ionice -c3 mythffmpeg -hide_banner -ignore_unknown-ss 1952.3000 
-noaccurate_seek -t 687.6800  -i 
/home/john/SGs/RecsSG2/21605_20180422185800.ts -ignore_unknown -ss 
1952.3000 -t 687.6800  -i /home/john/SGs/RecsSG2/21605_20180422185800.ts 
-map 0:0 -c:v  copy-map 1:1 -c:a  copy-avoid_negative_ts 

Re: [FFmpeg-devel] [PATCH 15/26] vaapi_encode: Clean up rate control configuration

[Mark Thompson]

On 27/04/18 05:10, Xiang, Haihao wrote:
> On Sun, 2018-04-22 at 16:29 +0100, Mark Thompson wrote:
>> Query which modes are supported and select between VBR and CBR based
>> on that.  Removes all of the codec-specific rate control mode selection
>> code.  Also ensures that target percentage and window size match the
>> target bitrate and RC buffer size in all cases where they are not
>> explicitly specified.
>> ---
>>  doc/encoders.texi   |   2 -
>>  libavcodec/vaapi_encode.c   | 166 
>> ---
>> -
>>  libavcodec/vaapi_encode.h   |   4 +-
>>  libavcodec/vaapi_encode_h264.c  |  12 ---
>>  libavcodec/vaapi_encode_h265.c  |  12 ---
>>  libavcodec/vaapi_encode_mjpeg.c |   3 +-
>>  libavcodec/vaapi_encode_mpeg2.c |   3 +-
>>  libavcodec/vaapi_encode_vp8.c   |  11 ---
>>  libavcodec/vaapi_encode_vp9.c   |  11 ---
>>  9 files changed, 119 insertions(+), 105 deletions(-)
>>
>> ...
>> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
>> index fc83d3db11..6188423935 100644
>> --- a/libavcodec/vaapi_encode.c
>> +++ b/libavcodec/vaapi_encode.c
>> ...
>> vaapi_encode_config_attributes(AVCodecContext *avctx)
>>  static av_cold int vaapi_encode_init_rate_control(AVCodecContext *avctx)
>>  {
>>  VAAPIEncodeContext *ctx = avctx->priv_data;
>> -int rc_bits_per_second;
>> -int rc_target_percentage;
>> -int rc_window_size;
>> -int hrd_buffer_size;
>> -int hrd_initial_buffer_fullness;
>> +int64_t rc_bits_per_second;
>> +int rc_target_percentage;
>> +int rc_window_size;
>> +int64_t hrd_buffer_size;
>> +int64_t hrd_initial_buffer_fullness;
>>  int fr_num, fr_den;
>> +VAConfigAttrib rc_attr = { VAConfigAttribRateControl };
>> +VAStatus vas;
>> +
>> +vas = vaGetConfigAttributes(ctx->hwctx->display,
>> +ctx->va_profile, ctx->va_entrypoint,
>> +_attr, 1);
>> +if (vas != VA_STATUS_SUCCESS) {
>> +av_log(avctx, AV_LOG_ERROR, "Failed to query rate control "
>> +   "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
>> +return AVERROR_EXTERNAL;
>> +}
>>  
>> -if (avctx->bit_rate > INT32_MAX) {
>> -av_log(avctx, AV_LOG_ERROR, "Target bitrate of 2^31 bps or "
>> -   "higher is not supported.\n");
>> +if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
>> +av_log(avctx, AV_LOG_VERBOSE, "Driver does not report any "
>> +   "supported rate control modes: assuming 
>> constant-quality.\n");
>> +ctx->va_rc_mode = VA_RC_CQP;
>> +return 0;
>> +}
>> +if (avctx->flags & AV_CODEC_FLAG_QSCALE ||
>> +avctx->bit_rate <= 0) {
>> +if (rc_attr.value & VA_RC_CQP) {
>> +av_log(avctx, AV_LOG_VERBOSE, "Using constant-quality mode.\n");
>> +ctx->va_rc_mode = VA_RC_CQP;
>> +return 0;
>> +} else {
>> +av_log(avctx, AV_LOG_ERROR, "Driver does not support "
>> +   "constant-quality mode (%#x).\n", rc_attr.value);
>> +return AVERROR(EINVAL);
>> +}
>> +}
>> +
>> +if (!(rc_attr.value & (VA_RC_CBR | VA_RC_VBR))) {
>> +av_log(avctx, AV_LOG_ERROR, "Driver does not support any "
>> +   "bitrate-targetted rate control modes.\n");
>>  return AVERROR(EINVAL);
>>  }
>>  
>> @@ -1320,27 +1323,90 @@ static av_cold int
>> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>>  hrd_buffer_size = avctx->rc_buffer_size;
>>  else
>>  hrd_buffer_size = avctx->bit_rate;
>> -if (avctx->rc_initial_buffer_occupancy)
>> +if (avctx->rc_initial_buffer_occupancy) {
>> +if (avctx->rc_initial_buffer_occupancy > hrd_buffer_size) {
>> +av_log(avctx, AV_LOG_ERROR, "Invalid RC buffer settings: "
>> +   "must have initial buffer size (%d) < "
>> +   "buffer size (%"PRId64").\n",
>> +   avctx->rc_initial_buffer_occupancy, hrd_buffer_size);
>> +return AVERROR(EINVAL);
>> +}
>>  hrd_initial_buffer_fullness = avctx->rc_initial_buffer_occupancy;
>> -else
>> +} else {
>>  hrd_initial_buffer_fullness = hrd_buffer_size * 3 / 4;
>> +}
>> +
>> +if (avctx->rc_max_rate && avctx->rc_max_rate < avctx->bit_rate) {
>> +av_log(avctx, AV_LOG_ERROR, "Invalid bitrate settings: must have "
>> +   "bitrate (%"PRId64") <= maxrate (%"PRId64").\n",
>> +   avctx->bit_rate, avctx->rc_max_rate);
>> +return AVERROR(EINVAL);
>> +}
>> +
>> +if (avctx->rc_max_rate > avctx->bit_rate) {
>> +if (!(rc_attr.value & VA_RC_VBR)) {
>> +av_log(avctx, AV_LOG_WARNING, "Driver does not support "
>> +   "VBR mode (%#x), using CBR mode instead.\n",
>> +   rc_attr.value);
>> +ctx->va_rc_mode = VA_RC_CBR;
>> +} else {
>> + 

Re: [FFmpeg-devel] [PATCH 1/3] avformat/utils: function to get the formatted ntp time

[Dixit, Vishwanath]

On 4/27/18 5:15 AM, Michael Niedermayer wrote:
> On Thu, Apr 26, 2018 at 11:05:59AM +, Dixit, Vishwanath wrote:
>>
>>
>> On 4/26/18 1:04 AM, Michael Niedermayer wrote:
>>> On Tue, Apr 24, 2018 at 02:46:56PM +0530, vdi...@akamai.com wrote:
 From: Vishwanath Dixit 

 This utility function creates 64-bit NTP time format as per the RFC
 5905.
 A simple explaination of 64-bit NTP time format is here
 http://www.beaglesoft.com/Manual/page53.htm
 ---
  libavformat/internal.h |  8 
  libavformat/utils.c| 20 
  2 files changed, 28 insertions(+)

 diff --git a/libavformat/internal.h b/libavformat/internal.h
 index 3582682..e9f758f 100644
 --- a/libavformat/internal.h
 +++ b/libavformat/internal.h
 @@ -240,6 +240,14 @@ void ff_read_frame_flush(AVFormatContext *s);
  uint64_t ff_ntp_time(void);
  
  /**
 + * Get the NTP time stamp formatted as per the RFC-5905.
 + *
 + * @param ntp_time NTP time in micro seconds (since NTP epoch)
 + * @return the formatted NTP time stamp
 + */
 +uint64_t ff_time_ntp_format(uint64_t ntp_time);
 +
 +/**
   * Append the media-specific SDP fragment for the media stream c
   * to the buffer buff.
   *
 diff --git a/libavformat/utils.c b/libavformat/utils.c
 index c25eab4..b59d426 100644
 --- a/libavformat/utils.c
 +++ b/libavformat/utils.c
 @@ -4637,6 +4637,26 @@ uint64_t ff_ntp_time(void)
  return (av_gettime() / 1000) * 1000 + NTP_OFFSET_US;
  }
  
 +uint64_t ff_time_ntp_format(uint64_t ntp_time)
 +{
 +uint64_t ntp_ts, frac_part;
 +uint32_t sec, usec;
 +
 +//current ntp time in seconds and micro seconds
>>>
 +sec = ntp_time / 100;
>>>
>>> This can be truncated
>> Yes, but the truncated part is not getting discarded, as the following line 
>> is taking care of that. Please correct me if I have not understood what you 
>> have intended to say here.
>
> ok, correcting you then :)
> sec is 32bit
> not all values of "ntp_time / 100;" fit in 32bit
> there is no check for this it just produces a wrong result
Yes, you are right. But, I can use only the LS 32bits of the result in the 
following code. It is a limitation of 64-bit NTP time format and the issue is 
going to occur in 2036. Not sure how to handle it here. At most, I can print a 
warning message when the result gets truncated. Could you please suggest any 
alternative option?
>
>
>>>
>>>
 +usec = ntp_time % 100;
 +
 +//encoding in ntp timestamp format
 +frac_part = usec * 0xULL;
 +frac_part /= 100;
 +
 +ntp_ts = (uint64_t) sec;
 +ntp_ts <<= 32;
 +ntp_ts |= frac_part;
 +
 +return ntp_ts;
>>>
>>> this looks similar to what av_rescale does.
>> Not really. This is a unique format as defined in RFC 5905. (please see this 
>> page for high level understanding of this format 
>> http://www.beaglesoft.com/Manual/page53.htm )
>
> it still looks very similar to me. But lets keep your code. if you prefer.
Okay, let's keep the code, otherwise I will not be able to get the expected 
functionality using av_rescale function.
>
> [...]
>
>
> ___
> 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] github

[Tomas Härdin]

fre 2018-04-27 klockan 00:50 +0200 skrev wm4:
> On Thu, 26 Apr 2018 14:41:55 +0200
> Daniel Oberhoff  wrote:
> 
> > > On 26. Apr 2018, at 14:40, wm4  wrote:
> > > 
> > > On Thu, 26 Apr 2018 14:12:14 +0200
> > > Hendrik Leppkes 
> > > > wrote:
> > >   
> > > > On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff
> > > >  wrote:  
> > > > >   
> > > > > > Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff  > > > > > o...@googlemail.com>:
> > > > > > 
> > > > > >   
> > > > > > > Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff  > > > > > > rh...@googlemail.com>:
> > > > > > > 
> > > > > > >   
> > > > > > > > Am 26.04.2018 um 13:52 schrieb Nicolas George  > > > > > > > sup.org>:
> > > > > > > > 
> > > > > > > > Daniel Oberhoff (2018-04-26):  
> > > > > > > > > I was wondering if there is any chance to move
> > > > > > > > > development to github?
> > > > > > > > > I.e. not just mirror, but as primary development
> > > > > > > > > repo, with issues and
> > > > > > > > > pull requests? Would make collaboration a *lot*
> > > > > > > > > easier (think of
> > > > > > > > > submitting a pr instead of having to
> > > > > > > > > generate/format/split patches).  
> > > > > > > > 
> > > > > > > > If development involves working in a web browser a lot,
> > > > > > > > count me out.
> > > > > > > > Can you point me to the command-line  
> > > > > > > 
> > > > > > > https://hub.github.com/hub.1.html  
> > > > > > 
> > > > > > But you can’t really do reviews that way, so the criticism
> > > > > > stands.  
> > > > > 
> > > > > BTW, is there any kind of issue tracking?  
> > > > 
> > > > https://trac.ffmpeg.org/  
> > > 
> > > To be fair, I'd prefer the github issue tracker over TRAC any
> > > day.
> > > Still has the other problems I mentioned.  
> > 
> > gitlab?
> > 
> 
> That would mostly get rid of the centralization argument. But I've
> heard bad things from someone who wanted to setup a private instance
> of
> it. Apparently it has a large number of dependencies, is extremely
> hard
> to deploy (unless you use their docker container), and it's SLOW.
> 
> In fact even gitlab.com seems to have severe performance problems
> occasionally.

Another problem with gitlab is its inability to work without js. Things
like hamburger menus getting in the way, READMEs not displaying and so
on. Just look at https://gitlab.com/explore with js and third party
domains disabled

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