Re: [FFmpeg-devel] [PATCH] af_volumedetect: Work with sample formats other than s16/s16p

2016-08-13 Thread Paul B Mahol 
On Saturday, August 13, 2016, Burt P  wrote:

> The histogram will still only be shown for s16 and s16p.
>
> Signed-off-by: Burt P >
> ---
>  libavfilter/af_volumedetect.c | 133 ++
> 
>  1 file changed, 121 insertions(+), 12 deletions(-)
>
> diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
> index 4815bcc..3ee664f 100644
> --- a/libavfilter/af_volumedetect.c
> +++ b/libavfilter/af_volumedetect.c
> @@ -24,6 +24,8 @@
>  #include "avfilter.h"
>  #include "internal.h"
>
> +#define USE_OLD_VERSION 0  /* 0 or 1 */
> +
>  typedef struct {
>  /**
>   * Number of samples at each PCM value.
> @@ -31,18 +33,38 @@ typedef struct {
>   * The extra element is there for symmetry.
>   */
>  uint64_t histogram[0x10001];
> +int use_hist;
> +int sformat;
> +double peak;
> +double power;
> +uint64_t nb_samples;
>  } VolDetectContext;
>
>  static int query_formats(AVFilterContext *ctx)
>  {
> -static const enum AVSampleFormat sample_fmts[] = {
> -AV_SAMPLE_FMT_S16,
> -AV_SAMPLE_FMT_S16P,
> -AV_SAMPLE_FMT_NONE
> +static const enum AVSampleFormat sample_fmts[][11] = {
> +{ /* [0]: USE_OLD_VERSION = 0 */
> +AV_SAMPLE_FMT_S16,
> +AV_SAMPLE_FMT_S16P,
> +AV_SAMPLE_FMT_U8,
> +AV_SAMPLE_FMT_U8P,
> +AV_SAMPLE_FMT_S32,
> +AV_SAMPLE_FMT_S32P,
> +AV_SAMPLE_FMT_FLT,
> +AV_SAMPLE_FMT_FLTP,
> +AV_SAMPLE_FMT_DBL,
> +AV_SAMPLE_FMT_DBLP,
> +AV_SAMPLE_FMT_NONE
> +},
> +{ /* [1]: USE_OLD_VERSION = 1 */
> +AV_SAMPLE_FMT_S16,
> +AV_SAMPLE_FMT_S16P,
> +AV_SAMPLE_FMT_NONE
> +},
>  };
>  AVFilterFormats *formats;
>
> -if (!(formats = ff_make_format_list(sample_fmts)))
> +if (!(formats = ff_make_format_list(sample_fmts[USE_OLD_VERSION])))
>  return AVERROR(ENOMEM);
>  return ff_set_common_formats(ctx, formats);
>  }
> @@ -56,22 +78,70 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *samples)
>  int nb_channels = av_get_channel_layout_nb_channels(layout);
>  int nb_planes   = nb_channels;
>  int plane, i;
> -int16_t *pcm;
> +uint8_t *pcm;
> +int sample_size;
> +double sample;
> +
> +vd->sformat = inlink->format;
>
>  if (!av_sample_fmt_is_planar(samples->format)) {
>  nb_samples *= nb_channels;
>  nb_planes = 1;
>  }
>  for (plane = 0; plane < nb_planes; plane++) {
> -pcm = (int16_t *)samples->extended_data[plane];
> -for (i = 0; i < nb_samples; i++)
> -vd->histogram[pcm[i] + 0x8000]++;
> +pcm = samples->extended_data[plane];
> +sample_size = 0;
> +for (i = 0; i < nb_samples; i++) {
> +switch (inlink->format) {
> +case AV_SAMPLE_FMT_S16:
> +case AV_SAMPLE_FMT_S16P:
> +vd->histogram[*(int16_t*)pcm + 0x8000]++;
> +vd->use_hist = 1;
> +sample_size = sizeof(int16_t);
> +sample = (double)*(int16_t*)pcm;
> +sample /= 0x8000;
> +case AV_SAMPLE_FMT_U8:
> +case AV_SAMPLE_FMT_U8P:
> +if (!sample_size) {
> +sample_size = sizeof(uint8_t);
> +sample = (double)(*pcm);
> +sample -= 0x80;
> +sample /= 0x80;
> +}
> +case AV_SAMPLE_FMT_S32:
> +case AV_SAMPLE_FMT_S32P:
> +if (!sample_size) {
> +sample_size = sizeof(int32_t);
> +sample = (double)*(int32_t*)pcm;
> +sample /= 0x8000U;
> +}
> +case AV_SAMPLE_FMT_FLT:
> +case AV_SAMPLE_FMT_FLTP:
> +if (!sample_size) {
> +sample_size = sizeof(float);
> +sample = (double)*(float*)pcm;
> +}
> +case AV_SAMPLE_FMT_DBL:
> +case AV_SAMPLE_FMT_DBLP:
> +if (!sample_size) {
> +sample_size = sizeof(double);
> +sample = *(double*)pcm;
> +}
> +sample = fabs(sample);
> +vd->peak = FFMAX(vd->peak, sample);
> +vd->power += (sample*sample);
> +vd->nb_samples++;
> +}
> +av_assert0(sample_size != 0);
> +pcm += sample_size;
> +}
>  }
>
>  return ff_filter_frame(inlink->dst->outputs[0], samples);
>  }
>
>  #define MAX_DB 91
> +#define VERY_SMALL 0.0001
>
>  static inline double logdb(uint64_t v)
>  {
> @@ -88,9 +158,13 @@ static void print_stat

Re: [FFmpeg-devel] [PATCH]configure: Check arc4random() header definition

2016-08-13 Thread Paul B Mahol 
On 8/13/16, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch fixes Cygwin default compilation.
>
> Please comment, Carl Eugen
>

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

Re: [FFmpeg-devel] [PATCH] af_volumedetect: Work with sample formats other than s16/s16p

2016-08-13 Thread Nicolas George 
Le septidi 27 thermidor, an CCXXIV, Burt P a écrit :
> The histogram will still only be shown for s16 and s16p.
> 
> Signed-off-by: Burt P 
> ---
>  libavfilter/af_volumedetect.c | 133 
> ++
>  1 file changed, 121 insertions(+), 12 deletions(-)

Did you benchmark the original s16 case? The main point of this filter is
that it is fast. With these changes, I see switches inside inner loops, and
I am afraid it becomes less fast.

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 v3 1/2] avcodec/bsf: Set EOF flag only in pkt == NULL

2016-08-13 Thread Michael Niedermayer 
On Tue, Jul 26, 2016 at 12:40:07PM +0200, sebechlebsky...@gmail.com wrote:
> From: Jan Sebechlebsky 
> 
> Set BSF EOF flag only if pkt == NULL in av_bsf_send_packet().
> 
> Signed-off-by: Jan Sebechlebsky 

applied

thanks

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH v3 2/2] avcodec/bsf: Forbid packet without payload in av_bsf_send_packet

2016-08-13 Thread Michael Niedermayer 
On Tue, Jul 26, 2016 at 12:40:08PM +0200, sebechlebsky...@gmail.com wrote:
> From: Jan Sebechlebsky 
> 
> Signed-off-by: Jan Sebechlebsky 
> ---
>  libavcodec/avcodec.h | 3 ++-
>  libavcodec/bsf.c | 3 +++
>  2 files changed, 5 insertions(+), 1 deletion(-)

applied

thanks

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

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


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

Re: [FFmpeg-devel] [PATCH] af_volumedetect: Work with sample formats other than s16/s16p

2016-08-13 Thread Paul B Mahol 
On 8/13/16, Nicolas George  wrote:
> Le septidi 27 thermidor, an CCXXIV, Burt P a écrit :
>> The histogram will still only be shown for s16 and s16p.
>>
>> Signed-off-by: Burt P 
>> ---
>>  libavfilter/af_volumedetect.c | 133
>> ++
>>  1 file changed, 121 insertions(+), 12 deletions(-)
>
> Did you benchmark the original s16 case? The main point of this filter is
> that it is fast. With these changes, I see switches inside inner loops, and
> I am afraid it becomes less fast.

Also, swresample already does what converting code do, but faster.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Compile using bash in Win10 anniversary?

2016-08-13 Thread Timo Rothenpieler 
On 8/12/2016 8:12 PM, Dan Haddix wrote:
> Can you cross compile ffmpeg for Windows using the new bash built in to Win10 
> anniversary? I'm currently using MinGW but it seems like it might be easier 
> to use the built in bash if possible. However I tried a basic build, using 
> the same commands I do in MinGW, and it fails. So I assume there is something 
> I need to do or setup to make it work, but I'm not sure what as my knowledge 
> of Linux is very limited. (I followed a guide to setup MinGW)

The bash for windows contains a full and native Ubuntu userland.
So if you compile ffmpeg in there, you end up with an ELF binary for
Linux, just as if you'd have compiled on an actual Ubuntu Linux.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] doc/bsfs: Fix bsf options divider in documentation

2016-08-13 Thread Michael Niedermayer 
On Thu, Jul 28, 2016 at 06:18:12PM +0200, sebechlebsky...@gmail.com wrote:
> From: Jan Sebechlebsky 
> 
> The actual implementation uses ':' divider, not '/' as
> documented.
> 
> Signed-off-by: Jan Sebechlebsky 
> ---
>  doc/bitstream_filters.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thx

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

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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

Re: [FFmpeg-devel] [PATCH] avcodec/utils: only warn when passed invalid lowres value

2016-08-13 Thread Carl Eugen Hoyos 
Hi!

2016-08-05 0:35 GMT+02:00 Aman Gupta :
> From: Aman Gupta 
>
> This makes it easier to use the lowres option when dealing with input
> files in different codecs. If the codec doesn't support lowres=1 for
> instance, it will throw a warning and use lowres=0 instead of erroring
> out completely.

Was this a regression?

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

Re: [FFmpeg-devel] [PATCH v2]Support QT b64a ARGB64 rawvideo

2016-08-13 Thread Carl Eugen Hoyos 
Hi!

2016-08-11 18:45 GMT+02:00 Paul B Mahol :
> On 8/9/16, Carl Eugen Hoyos  wrote:

>> Will fix locally, any other comments?
>>
>
> No, LGTM if works.

Patch applied, thank you!

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

Re: [FFmpeg-devel] [PATCH]configure: Check arc4random() header definition

2016-08-13 Thread Carl Eugen Hoyos 
2016-08-13 10:02 GMT+02:00 Paul B Mahol :
> On 8/13/16, Carl Eugen Hoyos  wrote:
>> Attached patch fixes Cygwin default compilation.

> LGTM

Patch applied.

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_signalstats: add >8 bit depth support

2016-08-13 Thread Carl Eugen Hoyos 
Hi!

2016-08-11 18:33 GMT+02:00 Paul B Mahol :
> Updated patches attached.

Sorry, still only being curious:
Is there a reason why YUV is supported but YUVA is not?

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

Re: [FFmpeg-devel] [PATCH 2/5] avcodec/bsf: Add ff_bsf_get_packet_ref() function

2016-08-13 Thread Michael Niedermayer 
On Thu, Jul 28, 2016 at 06:18:13PM +0200, sebechlebsky...@gmail.com wrote:
> From: Jan Sebechlebsky 
> 
> Use of this function can save unnecessary malloc operation
> in bitstream filter.
> 
> Signed-off-by: Jan Sebechlebsky 
> ---
>  libavcodec/bsf.c | 16 
>  libavcodec/bsf.h | 11 +++
>  2 files changed, 27 insertions(+)

applied

thx

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_signalstats: add >8 bit depth support

2016-08-13 Thread Paul B Mahol 
On 8/13/16, Carl Eugen Hoyos  wrote:
> Hi!
>
> 2016-08-11 18:33 GMT+02:00 Paul B Mahol :
>> Updated patches attached.
>
> Sorry, still only being curious:
> Is there a reason why YUV is supported but YUVA is not?

Mostly because there is no alpha stats gathered and it is easy to
ignore alpha plane.

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

[FFmpeg-devel] [PATCH][WIP] avfilter: add surroundscope filter

2016-08-13 Thread Paul B Mahol 
Hi,

patch attached.


0001-avfilter-add-surroundscope-filter.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/mmaldec.c: add interlaced_frame and format struct to AVFrame for deinterlacing]

2016-08-13 Thread Jens Ziller 
Am Freitag, den 12.08.2016, 17:12 +0200 schrieb Michael Niedermayer:
> On Sun, Jul 31, 2016 at 07:09:26PM +0200, Jens Ziller wrote:
> > 
> > Am Sonntag, den 31.07.2016, 16:33 +0100 schrieb Mark Thompson:
> > > 
> > > On 31/07/16 15:51, Jens Ziller wrote:
> > > > 
> > > > 
> > > > Am Samstag, den 30.07.2016, 17:30 +0100 schrieb Mark Thompson:
> [...]
> > 
> > > 
> > > Consider this sequence, where we want to decode a single image
> > > and
> > > then do something with it:
> > > 
> > > open decoder
> > > decode frame
> > > close decoder
> > > open 
> > > give it the frame we got from the decoder
> > > 
> > > To me that looks like it will invoke undefined behaviour
> > > (segfault or
> > > read garbage) when trying to access data[2] in the second
> > > component,
> > > because the pointer appears to be to the MMAL_ES_FORMAT_T in the
> > > MMAL_PORT_T on the decoder which we just destroyed.  If not,
> > > where is
> > > the reference which keeps that pointer valid living?
> > With MMAL decoder it works:
> > 
> > - configure decoder
> > - send many frames (in my tests between 5 and 20+) to decoder
> > - decoder give MMAL_ES_FORMAT_T
> > - configure decoder output port with given struct <- here we have
> > the
> > pointer
> > - decoder send the first decoded frame
> > 
> > The struct lives before the first frame is available. Decode a
> > single
> > frame is a spezial thing. The MMAL decoder is not made for this.
> > 
> > A
> > local copy from format struct make no sense for me.
> well, it makes sense to us for the code to work and not have
> undefined
> behavior.
> Please correct me if iam wrong but Hendrik, Mark and me are saying
> the same thing more or less, i think you should change the patch
> 
> also additionally, its nice if we can keep data[0..2] available for
> the raw 3 YUV planes, it might one day somewhere be nice to download
> the raw data into [0..2], using up the 2nd for this struct is not
> pretty
For YUV planes AV_PIX_FMT_YUV420P are the better choice
not AV_PIX_FMT_MMAL. 
But you have me convinced that I write a new patch, test it and send it
to the ml.

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

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-08-13 Thread Davinder Singh 
On Thu, Aug 11, 2016 at 12:10 AM Davinder Singh  wrote:

> [...]
>
> latest changes:
https://github.com/dsmudhar/FFmpeg/blob/dev/libavfilter/vf_minterpolate.c
uses shared motion estimation code now, added options, improved vsbmc
i tried to make filter options as flexible as possible so that multiple
algorithms are be supported.

@Ronald:
have a look:
https://github.com/dsmudhar/FFmpeg/blob/dev/libavfilter/motion_estimation.c
i think if penalty factor can be moved into cost function, motion
estimation can be shared with encoders. we can start work on this after
GSoC?

TODO:
frame border motion estimation.
add scene change threshold. roughness check doesn't work so well and
introduce artifacts.
add docs.


> here's another idea: dynamic block size selection for MC-FRUC
> since it's not video encoding, using 16x16 block with fixed search window
> may not work same for all resolution videos. what if we automatic resize
> block depending on resolution? like if 16x16, P=20 works fine for 1280x720
> video, we can scale it according to width, e.g for 1920x1080 which 1.5x
> 1280, we use 24x24 block and also scale P accordingly? i haven't tested it
> yet though.
>

i tested this. quality was improved with 1080p but not with smaller
resolution.

I tried to scale best settings of 720p. UMH. 1080p same video.
scale nothing: mb16 p18
stddev:1.16 PSNR: 46.80 MAXDIFF:  197 bytes:1085529600/1073088000
scale search window: mb16, p27
stddev:1.21 PSNR: 46.47 MAXDIFF:  193 bytes:1085529600/1073088000
scale both: mb24 p18
stddev:1.14 PSNR: 46.93 MAXDIFF:  181 bytes:1085529600/1073088000

ESA
mb16 p16:
stddev:1.18 PSNR: 46.65 MAXDIFF:  181 bytes:1085529600/1073088000
mb24 p24:
stddev:1.16 PSNR: 46.77 MAXDIFF:  181 bytes:1085529600/1073088000

640p ESA
m16 p16:
stddev:1.01 PSNR: 47.97 MAXDIFF:  160 bytes:119577600/118540800
scale p: mb16 p8:
stddev:1.02 PSNR: 47.95 MAXDIFF:  148 bytes:119577600/118540800
scale both: m8 p8:
stddev:1.05 PSNR: 47.63 MAXDIFF:  187 bytes:119577600/118540800

i think quality can be further improved, generated test window weights were
not perfect.
should i keep this feature? since block-size won't be log2 int, that will
break vsbmc which use quadtree division for smaller blocks.


> [1]: JVT-F017.pdf by Z Chen 
>


On Thu, Aug 11, 2016 at 9:09 PM Paul B Mahol  wrote:

> Could you please squash your commits and attach patches that add
> vf_mestimate
> and vf_minterpolate filters?
>

patch attached.


0001-added-motion-estimation-and-interpolation-filters.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/http: add support for content_type option in listen mode

2016-08-13 Thread Moritz Barsnick 
On Wed, Aug 10, 2016 at 21:18:00 +0200, Moritz Barsnick wrote:
> Instead of silently ignoring the content_type option in listen mode,
> apply its value to the provided "Content-Type:" header.
> 
> Signed-off-by: Moritz Barsnick 
> ---
>  doc/protocols.texi | 2 +-
>  libavformat/http.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

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

Re: [FFmpeg-devel] [PATCH] libavformat/http: add support for content_type option in listen mode

2016-08-13 Thread Nicolas George 
Le quartidi 24 thermidor, an CCXXIV, Moritz Barsnick a écrit :
> Instead of silently ignoring the content_type option in listen mode,
> apply its value to the provided "Content-Type:" header.
> 
> Signed-off-by: Moritz Barsnick 
> ---
>  doc/protocols.texi | 2 +-
>  libavformat/http.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Looks ok, but I do not maintain that file.

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] [GSoC] Motion Interpolation

2016-08-13 Thread Paul B Mahol 
On 8/13/16, Davinder Singh  wrote:
>
> patch attached.
>

Please add EPZS to minterpolate.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-08-13 Thread Paul B Mahol 
On 8/13/16, Paul B Mahol  wrote:
> On 8/13/16, Davinder Singh  wrote:
>>
>> patch attached.
>>
>
> Please add EPZS to minterpolate.
>

Also, why is there no code for scene change detection?
If scene changes abruptly it will give bad frame.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-08-13 Thread Davinder Singh 
On Sat, Aug 13, 2016 at 7:28 PM Paul B Mahol  wrote:

> On 8/13/16, Davinder Singh  wrote:
> >
> > patch attached.
> >
>
> Please add EPZS to minterpolate.
>

added.
https://github.com/dsmudhar/FFmpeg/commit/1ad40c3f405625075b93dde71a749593dc64f0e3


> ___
> 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] [GSoC] Motion Interpolation

2016-08-13 Thread Davinder Singh 
On Sat, Aug 13, 2016 at 8:05 PM Paul B Mahol  wrote:

> On 8/13/16, Paul B Mahol  wrote:
> > On 8/13/16, Davinder Singh  wrote:
> >>
> >> patch attached.
> >>
> >
> > Please add EPZS to minterpolate.
> >
>
> Also, why is there no code for scene change detection?

If scene changes abruptly it will give bad frame.
>

none of paper had scene change detection. any idea how can i add it?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] aacenc: add a faster version of twoloop as the "fast" coder

2016-08-13 Thread Rostislav Pehlivanov 
On 7 August 2016 at 00:51, Rostislav Pehlivanov  wrote:

> Does nothing fancy but still sounds very decent at 128kbps.
> Still room to improve by bringing in the low pass and PNS management
> from the main big twoloop which should improve its quality but not
> sacrifice that much speed.
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/aaccoder.c | 154 ++
> +---
>  1 file changed, 134 insertions(+), 20 deletions(-)
>
> diff --git a/libavcodec/aaccoder.c b/libavcodec/aaccoder.c
> index bca1f59..edf29f4 100644
> --- a/libavcodec/aaccoder.c
> +++ b/libavcodec/aaccoder.c
> @@ -396,34 +396,148 @@ static void search_for_quantizers_fast(AVCodecContext
> *avctx, AACEncContext *s,
> SingleChannelElement *sce,
> const float lambda)
>  {
> -int i, w, w2, g;
> -int minq = 255;
> -
> -memset(sce->sf_idx, 0, sizeof(sce->sf_idx));
> +int start = 0, i, w, w2, g;
> +int destbits = avctx->bit_rate * 1024.0 / avctx->sample_rate /
> avctx->channels * (lambda / 120.f);
> +float dists[128] = { 0 }, uplims[128] = { 0 };
> +float maxvals[128];
> +int fflag, minscaler;
> +int its  = 0;
> +int allz = 0;
> +float minthr = INFINITY;
> +
> +// for values above this the decoder might end up in an endless loop
> +// due to always having more bits than what can be encoded.
> +destbits = FFMIN(destbits, 5800);
> +//XXX: some heuristic to determine initial quantizers will reduce
> search time
> +//determine zero bands and upper limits
>  for (w = 0; w < sce->ics.num_windows; w += sce->ics.group_len[w]) {
> -for (g = 0; g < sce->ics.num_swb; g++) {
> +start = 0;
> +for (g = 0;  g < sce->ics.num_swb; g++) {
> +int nz = 0;
> +float uplim = 0.0f, energy = 0.0f;
>  for (w2 = 0; w2 < sce->ics.group_len[w]; w2++) {
>  FFPsyBand *band = &s->psy.ch[s->cur_channel].
> psy_bands[(w+w2)*16+g];
> -if (band->energy <= band->threshold) {
> -sce->sf_idx[(w+w2)*16+g] = 218;
> +uplim += band->threshold;
> +energy += band->energy;
> +if (band->energy <= band->threshold || band->threshold ==
> 0.0f) {
>  sce->zeroes[(w+w2)*16+g] = 1;
> -} else {
> -sce->sf_idx[(w+w2)*16+g] = av_clip(SCALE_ONE_POS -
> SCALE_DIV_512 + log2f(band->threshold), 80, 218);
> -sce->zeroes[(w+w2)*16+g] = 0;
> +continue;
>  }
> -minq = FFMIN(minq, sce->sf_idx[(w+w2)*16+g]);
> +nz = 1;
>  }
> +uplims[w*16+g] = uplim *512;
> +sce->band_type[w*16+g] = 0;
> +sce->zeroes[w*16+g] = !nz;
> +if (nz)
> +minthr = FFMIN(minthr, uplim);
> +allz |= nz;
> +start += sce->ics.swb_sizes[g];
>  }
>  }
> -for (i = 0; i < 128; i++) {
> -sce->sf_idx[i] = 140;
> -//av_clip(sce->sf_idx[i], minq, minq + SCALE_MAX_DIFF - 1);
> +for (w = 0; w < sce->ics.num_windows; w += sce->ics.group_len[w]) {
> +for (g = 0;  g < sce->ics.num_swb; g++) {
> +if (sce->zeroes[w*16+g]) {
> +sce->sf_idx[w*16+g] = SCALE_ONE_POS;
> +continue;
> +}
> +sce->sf_idx[w*16+g] = SCALE_ONE_POS +
> FFMIN(log2f(uplims[w*16+g]/minthr)*4,59);
> +}
>  }
> -//set the same quantizers inside window groups
> -for (w = 0; w < sce->ics.num_windows; w += sce->ics.group_len[w])
> -for (g = 0;  g < sce->ics.num_swb; g++)
> -for (w2 = 1; w2 < sce->ics.group_len[w]; w2++)
> -sce->sf_idx[(w+w2)*16+g] = sce->sf_idx[w*16+g];
> +
> +if (!allz)
> +return;
> +abs_pow34_v(s->scoefs, sce->coeffs, 1024);
> +ff_quantize_band_cost_cache_init(s);
> +
> +for (w = 0; w < sce->ics.num_windows; w += sce->ics.group_len[w]) {
> +start = w*128;
> +for (g = 0;  g < sce->ics.num_swb; g++) {
> +const float *scaled = s->scoefs + start;
> +maxvals[w*16+g] = find_max_val(sce->ics.group_len[w],
> sce->ics.swb_sizes[g], scaled);
> +start += sce->ics.swb_sizes[g];
> +}
> +}
> +
> +//perform two-loop search
> +//outer loop - improve quality
> +do {
> +int tbits, qstep;
> +minscaler = sce->sf_idx[0];
> +//inner loop - quantize spectrum to fit into given number of bits
> +qstep = its ? 1 : 32;
> +do {
> +int prev = -1;
> +tbits = 0;
> +for (w = 0; w < sce->ics.num_windows; w +=
> sce->ics.group_len[w]) {
> +start = w*128;
> +for (g = 0;  g < sce->ics.num_swb; g++) {
> +const float *coefs = sce->coeffs +

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-08-13 Thread Michael Niedermayer 
On Sat, Aug 13, 2016 at 03:51:17PM +, Davinder Singh wrote:
> On Sat, Aug 13, 2016 at 8:05 PM Paul B Mahol  wrote:
> 
> > On 8/13/16, Paul B Mahol  wrote:
> > > On 8/13/16, Davinder Singh  wrote:
> > >>
> > >> patch attached.
> > >>
> > >
> > > Please add EPZS to minterpolate.
> > >
> >
> > Also, why is there no code for scene change detection?
> 
> If scene changes abruptly it will give bad frame.
> >
> 

> none of paper had scene change detection. any idea how can i add it?

the motion estimation should already produce a "matching score" of some
kind for every block, its sum is probably a good indication how
similar frames are
the sum probably would need to be compared to some meassure of variance
for the frame so near black frames dont get better matches
a bit like a correlation coefficient
you can also look at
git grep scene libavcodec/mpegvideo* libavcodec/motion_es*

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

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


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

Re: [FFmpeg-devel] [PATCH] af_volumedetect: Work with sample formats other than s16/s16p

2016-08-13 Thread Burt P. 
Thanks, I will use astats instead.

On Sat, Aug 13, 2016 at 4:23 AM, Paul B Mahol  wrote:
> On 8/13/16, Nicolas George  wrote:
>> Le septidi 27 thermidor, an CCXXIV, Burt P a écrit :
>>> The histogram will still only be shown for s16 and s16p.
>>>
>>> Signed-off-by: Burt P 
>>> ---
>>>  libavfilter/af_volumedetect.c | 133
>>> ++
>>>  1 file changed, 121 insertions(+), 12 deletions(-)
>>
>> Did you benchmark the original s16 case? The main point of this filter is
>> that it is fast. With these changes, I see switches inside inner loops, and
>> I am afraid it becomes less fast.
>
> Also, swresample already does what converting code do, but faster.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



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

Re: [FFmpeg-devel] [PATCH] af_volumedetect: Work with sample formats other than s16/s16p

2016-08-13 Thread Paul B Mahol 
On Saturday, August 13, 2016, Burt P.  wrote:

> Thanks, I will use astats instead.
>
>
You could add dB scalling to astats metadata.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] af_volumedetect: Work with sample formats other than s16/s16p

2016-08-13 Thread Burt P. 
On Sat, Aug 13, 2016 at 4:23 AM, Paul B Mahol  wrote:
>
> Also, swresample already does what converting code do, but faster.

Doing the conversion in the filter itself instead of using the
auto-inserted conversion filter is that the original data is left
completely untouched.
Using astats, the sample format is converted to DBL for the astats
filter and everything after.
I can't risk anything affecting the LSB of the input or the HDCD code
may be disrupted.


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

Re: [FFmpeg-devel] [PATCH] af_volumedetect: Work with sample formats other than s16/s16p

2016-08-13 Thread Paul B Mahol 
On Saturday, August 13, 2016, Burt P.  wrote:

> On Sat, Aug 13, 2016 at 4:23 AM, Paul B Mahol  > wrote:
> >
> > Also, swresample already does what converting code do, but faster.
>
> Doing the conversion in the filter itself instead of using the
> auto-inserted conversion filter is that the original data is left
> completely untouched.
> Using astats, the sample format is converted to DBL for the astats
> filter and everything after.
> I can't risk anything affecting the LSB of the input or the HDCD code
> may be disrupted.




Integer mode could be easily added. Doesn't dbl hold enough bits?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-08-13 Thread Michael Niedermayer 
On Sat, Aug 13, 2016 at 12:18:56PM +, Davinder Singh wrote:
> On Thu, Aug 11, 2016 at 12:10 AM Davinder Singh  wrote:
> 
> > [...]
> >
> > latest changes:
> https://github.com/dsmudhar/FFmpeg/blob/dev/libavfilter/vf_minterpolate.c
> uses shared motion estimation code now, added options, improved vsbmc
> i tried to make filter options as flexible as possible so that multiple
> algorithms are be supported.
> 
> @Ronald:
> have a look:
> https://github.com/dsmudhar/FFmpeg/blob/dev/libavfilter/motion_estimation.c
> i think if penalty factor can be moved into cost function, motion
> estimation can be shared with encoders. we can start work on this after
> GSoC?
> 
> TODO:
> frame border motion estimation.
> add scene change threshold. roughness check doesn't work so well and
> introduce artifacts.
> add docs.
> 
> 
> > here's another idea: dynamic block size selection for MC-FRUC
> > since it's not video encoding, using 16x16 block with fixed search window
> > may not work same for all resolution videos. what if we automatic resize
> > block depending on resolution? like if 16x16, P=20 works fine for 1280x720
> > video, we can scale it according to width, e.g for 1920x1080 which 1.5x
> > 1280, we use 24x24 block and also scale P accordingly? i haven't tested it
> > yet though.
> >
> 
> i tested this. quality was improved with 1080p but not with smaller
> resolution.
> 
> I tried to scale best settings of 720p. UMH. 1080p same video.
> scale nothing: mb16 p18
> stddev:1.16 PSNR: 46.80 MAXDIFF:  197 bytes:1085529600/1073088000
> scale search window: mb16, p27
> stddev:1.21 PSNR: 46.47 MAXDIFF:  193 bytes:1085529600/1073088000
> scale both: mb24 p18
> stddev:1.14 PSNR: 46.93 MAXDIFF:  181 bytes:1085529600/1073088000
> 
> ESA
> mb16 p16:
> stddev:1.18 PSNR: 46.65 MAXDIFF:  181 bytes:1085529600/1073088000
> mb24 p24:
> stddev:1.16 PSNR: 46.77 MAXDIFF:  181 bytes:1085529600/1073088000
> 
> 640p ESA
> m16 p16:
> stddev:1.01 PSNR: 47.97 MAXDIFF:  160 bytes:119577600/118540800
> scale p: mb16 p8:
> stddev:1.02 PSNR: 47.95 MAXDIFF:  148 bytes:119577600/118540800
> scale both: m8 p8:
> stddev:1.05 PSNR: 47.63 MAXDIFF:  187 bytes:119577600/118540800
> 
> i think quality can be further improved, generated test window weights were
> not perfect.
> should i keep this feature? since block-size won't be log2 int, that will
> break vsbmc which use quadtree division for smaller blocks.
> 
> 
> > [1]: JVT-F017.pdf by Z Chen 
> >
> 
> 
> On Thu, Aug 11, 2016 at 9:09 PM Paul B Mahol  wrote:
> 
> > Could you please squash your commits and attach patches that add
> > vf_mestimate
> > and vf_minterpolate filters?
> >
> 
> patch attached.

>  doc/filters.texi|   25 
>  libavfilter/Makefile|2 
>  libavfilter/allfilters.c|2 
>  libavfilter/motion_estimation.c |  451 +
>  libavfilter/motion_estimation.h |   76 ++
>  libavfilter/vf_mestimate.c  |  376 +++
>  libavfilter/vf_minterpolate.c   | 1332 
> 
>  7 files changed, 2264 insertions(+)
> c09f35d9a5d564abb4dc3227872fd757c493ccb0  
> 0001-added-motion-estimation-and-interpolation-filters.patch
> From 19fa6a20f017bf4712ca8a63126e59552efdeb9c Mon Sep 17 00:00:00 2001
> From: dsmudhar 
> Date: Sat, 2 Apr 2016 23:33:17 +0530
> Subject: [PATCH] added motion estimation and interpolation filters

this builds with some compiler warnings, please fix them

here gcc produces:
libavfilter/vf_mestimate.c: In function ‘filter_frame’:
libavfilter/vf_mestimate.c:147:15: warning: unused variable ‘mv_y’ 
[-Wunused-variable]
libavfilter/vf_mestimate.c:147:9: warning: unused variable ‘mv_x’ 
[-Wunused-variable]
libavfilter/vf_minterpolate.c:1166:22: warning: "VSBMC_T1" is not defined 
[-Wundef]
libavfilter/vf_minterpolate.c: In function ‘search_mv’:
libavfilter/vf_minterpolate.c:417:15: warning: unused variable ‘mb_i’ 
[-Wunused-variable]
libavfilter/vf_minterpolate.c: In function ‘bilateral_me’:
libavfilter/vf_minterpolate.c:476:9: warning: unused variable ‘count’ 
[-Wunused-variable]
libavfilter/vf_minterpolate.c:475:9: warning: unused variable ‘changed’ 
[-Wunused-variable]
libavfilter/vf_minterpolate.c:474:15: warning: unused variable ‘mv_y’ 
[-Wunused-variable]
libavfilter/vf_minterpolate.c:474:9: warning: unused variable ‘mv_x’ 
[-Wunused-variable]
libavfilter/vf_minterpolate.c: In function ‘var_size_bme’:
libavfilter/vf_minterpolate.c:563:5: warning: ISO C90 forbids mixed 
declarations and code [-Wdeclaration-after-statement]
libavfilter/vf_minterpolate.c:563:15: warning: unused variable ‘T’ 
[-Wunused-variable]
libavfilter/vf_minterpolate.c: In function ‘inject_frame’:
libavfilter/vf_minterpolate.c:700:23: warning: variable ‘frame’ set but not 
used [-Wunused-but-set-variable]
libavfilter/vf_minterpolate.c: In function ‘interpolate’:
libavfilter/vf_minterpolate.c:1179:13: warning: ISO C90 forbids mixed 
declarations