Re: [FFmpeg-devel] [PATCH] h264: make H264ParamSets sps const

[Benoit Fouet]

Hi,

On 23/06/2016 22:37, Michael Niedermayer wrote:

On Thu, Jun 23, 2016 at 03:28:10PM +0200, Benoit Fouet wrote:

Hi,


On 21/06/2016 16:42, Benoit Fouet wrote:

Hi,

On 21/06/2016 16:29, Hendrik Leppkes wrote:

On Tue, Jun 21, 2016 at 4:20 PM, Benoit Fouet
 wrote:

Hi,


On 21/06/2016 14:52, Hendrik Leppkes wrote:

On Tue, Jun 21, 2016 at 2:40 PM, Clément Bœsch  wrote:

On Tue, Jun 21, 2016 at 02:34:33PM +0200, Benoit Fouet wrote:

Hi,

Unless I totally missed something, the FIXME in
H264ParamSets structure
should be fixed by attached patch.

--
Ben

  From 28ae10498f81070539bdb8f40236326743350101 Mon Sep
17 00:00:00 2001
From: Benoit Fouet 
Date: Tue, 21 Jun 2016 14:17:13 +0200
Subject: [PATCH] h264: make H264ParamSets sps const

---
   libavcodec/h264.h   | 3 +--
   libavcodec/h264_slice.c | 2 +-
   2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index c4d2921..b809ee5 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -234,8 +234,7 @@ typedef struct H264ParamSets {
   AVBufferRef *sps_ref;
   /* currently active parameters sets */
   const PPS *pps;
-// FIXME this should properly be const
-SPS *sps;
+const SPS *sps;
   } H264ParamSets;

   /**
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 6e7b940..da7f9dd 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -873,7 +873,7 @@ static enum AVPixelFormat
get_pixel_format(H264Context *h, int force_callback)
   /* export coded and cropped frame dimensions to AVCodecContext */
   static int init_dimensions(H264Context *h)
   {
-SPS *sps = h->ps.sps;
+SPS *sps = (SPS*)h->ps.sps_ref->data;
   int width  = h->width  - (sps->crop_right + sps->crop_left);
   int height = h->height - (sps->crop_top   +
sps->crop_bottom);
   av_assert0(sps->crop_right + sps->crop_left <
(unsigned)h->width);

So it's not actually const, right?


Indeed, the FIXME wasn't just there because someone forgot to write
"const" in front of it, but because it was used in some parts as
not-const.

OK, right... Thanks for reminding me of reading the code better before
sending a patch.

As far as I can see, the only place where this constness is
not preserved is
in the init_dimensions function (in h264_slice), in a dead
part of the code,
as crop is asserted at the beginning of the very same function.
Please correct me if I've missed other places.


If anything the asserts should probably be removed, because bad files
should never be able to trigger assertions, and the existing check
remain.

Well, the SPS "decoder" already takes care of the check (see
ff_h264_decode_seq_parameter_set).
So I could remove the check, because it seems useless, instead of
removing it because "bad things happen", what do you think?


Any objection to this patch now?

iam ok with the patch, maybe give others a bit of time to reply
before applying though


Yeah, I'm in no hurry, I just saw this FIXME in the context of one of 
Mateo's patches.
I was more waiting for some feedback from Hendrik or Clément, anyway, as 
they were the ones raising the points.


--
Ben

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

[FFmpeg-devel] why ffmpeg doesn't support vp9 svc?

[qw]

Hi,

I have one question about vp9. vp9 supports svc encoding/decoding. Why ffmpeg 
doesn't support vp9 svc?

Thanks!

B.R.

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

Re: [FFmpeg-devel] [PATCH] lavc/mediacodec: add hwaccel support

[Matthieu Bouron]

On Thu, Apr 07, 2016 at 02:51:44PM +0200, Matthieu Bouron wrote:
> On Wed, Mar 23, 2016 at 6:16 PM, Matthieu Bouron 
> wrote:
> 
> >
> >
> > On Tue, Mar 22, 2016 at 10:04 AM, Matthieu Bouron <
> > matthieu.bou...@gmail.com> wrote:
> >
> >>
> >>
> >> On Fri, Mar 18, 2016 at 5:50 PM, Matthieu Bouron <
> >> matthieu.bou...@gmail.com> wrote:
> >>
> >>> From: Matthieu Bouron 
> >>>
> >>> ---
> >>>
> >>> Hello,
> >>>
> >>> The following patch add hwaccel support to the mediacodec (h264) decoder
> >>> by allowing
> >>> the user to render the output frames directly on a surface.
> >>>
> >>> In order to do so the user needs to initialize the hwaccel through the
> >>> use of
> >>> av_mediacodec_alloc_context and av_mediacodec_default_init functions.
> >>> The later
> >>> takes a reference to an android/view/Surface as parameter.
> >>>
> >>> If the hwaccel successfully initialize, the decoder output frames pix
> >>> fmt will be
> >>> AV_PIX_FMT_MEDIACODEC. The following snippet of code demonstrate how to
> >>> render
> >>> the frames on the surface:
> >>>
> >>> AVMediaCodecBuffer *buffer = (AVMediaCodecBuffer *)frame->data[3];
> >>> av_mediacodec_release_buffer(buffer, 1);
> >>>
> >>> The last argument of av_mediacodec_release_buffer enable rendering of the
> >>> buffer on the surface (or not if set to 0).
> >>>
> >>> Regarding the internal changes in the mediacodec decoder:
> >>>
> >>> MediaCodec.flush() discards both input and output buffers meaning that if
> >>> MediaCodec.flush() is called all output buffers the user has a reference
> >>> on are
> >>> now invalid (and cannot be used).
> >>> This behaviour does not fit well in the avcodec API.
> >>>
> >>> When the decoder is configured to output software buffers, there is no
> >>> issue as
> >>> the buffers are copied.
> >>>
> >>> Now when the decoder is configured to output to a surface, the user
> >>> might not
> >>> want to render all the frames as fast as the decoder can go and might
> >>> want to
> >>> control *when* the frame are rendered, so we need to make sure that the
> >>> MediaCodec.flush() call is delayed until all the frames the user retains
> >>> has
> >>> been released or rendered.
> >>>
> >>> Delaying the call to MediaCodec.flush() means buffering any inputs that
> >>> come
> >>> the decoder until the user has released/renderer the frame he retains.
> >>>
> >>> This is a limitation of this hwaccel implementation, if the user retains
> >>> a
> >>> frame (a), then issue a flush command to the decoder, the packets he
> >>> feeds to
> >>> the decoder at that point will be queued in the internal decoder packet
> >>> queue
> >>> (until he releases the frame (a)). This scenario leads to a memory usage
> >>> increase to say the least.
> >>>
> >>> Currently there is no limitation on the size of the internal decoder
> >>> packet
> >>> queue but this is something that can be added easily. Then, if the queue
> >>> is
> >>> full, what would be the behaviour of the decoder ? Can it block ? Or
> >>> should it
> >>> returns something like AVERROR(EAGAIN) ?
> >>>
> >>> About the other internal decoder changes I introduced:
> >>>
> >>> The MediaCodecDecContext is now refcounted (using the lavu/atomic api)
> >>> since
> >>> the (hwaccel) frames can be retained by the user, we need to delay the
> >>> destruction of the codec until the user has released all the frames he
> >>> has a
> >>> reference on.
> >>> The reference counter of the MediaCodecDecContext is incremented each
> >>> time an
> >>> (hwaccel) frame is outputted by the decoder and decremented each time a
> >>> (hwaccel) frame is released.
> >>>
> >>> Also, when the decoder is configured to output to a surface the pts that
> >>> are
> >>> given to the MediaCodec API are now rescaled based on the codec_timebase
> >>> as
> >>> those timestamps values are propagated to the frames rendered on the
> >>> surface
> >>> since Android M. Not sure if it's really useful though.
> >>>
> >>> On the performance side:
> >>>
> >>> On a nexus 5, decoding an h264 stream (main profile) 1080p@60fps:
> >>>   - software output + rgba conversion goes at 59~60fps
> >>>   - surface output + render on a surface goes at 100~110fps
> >>>
> >>>
> >> [...]
> >>
> >> Patch updated with the following differences:
> >>   * the public mediacodec api is now always built (not only when
> >> mediacodec is available) (and the build when mediacodec is not available
> >> has been fixed)
> >>   * the documentation of av_mediacodec_release_buffer has been improved a
> >> bit
> >>
> >
> > Patch updated with the following differences:
> >   MediaCodecBuffer->released type is now a volatile int (instead of a int*)
> >   MediaCodecContext->refcount type is now a volatile int (instead of a
> > int*)
> >
> 
> Ping.

Rebased patch attached.

Matthieu
>From b8a63f18eeecc4f52524db75bc5a2cf1d13cbab2 Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Fri, 11 Mar 2016 17:21:04 +0100
Subject: [PATCH] lavc: add mediacodec hwaccel support

---
 config

[FFmpeg-devel] [PATCH] MAINTAINERS: drop people who do not appear in git history > 2013

[Clément Bœsch]

From: Clément Bœsch 

---
 MAINTAINERS | 113 +---
 1 file changed, 8 insertions(+), 105 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index fd87db5..e908def 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -35,17 +35,12 @@ ffserver:
 Commandline utility code:
   cmdutils.c, cmdutils.hMichael Niedermayer
 
-QuickTime faststart:
-  tools/qt-faststart.c  Baptiste Coudurier
-
 
 Miscellaneous Areas
 ===
 
-documentation   Stefano Sabatini, Mike Melanson, 
Timothy Gu, Lou Logan
+documentation   Stefano Sabatini, Timothy Gu, Lou Logan
 project server  Árpád Gereöffy, Michael Niedermayer, 
Reimar Doeffinger, Alexander Strasser
-presets Robert Swain
-metadata subsystem  Aurelien Jacobs
 release management  Michael Niedermayer
 
 
@@ -55,7 +50,7 @@ Communication
 website Deby Barbara Lepage
 fate.ffmpeg.org Timothy Gu
 Trac bug trackerAlexander Strasser, Michael 
Niedermayer, Carl Eugen Hoyos, Lou Logan
-mailing lists   Baptiste Coudurier, Lou Logan
+mailing lists   Lou Logan
 Google+ Paul B Mahol, Michael Niedermayer, 
Alexander Strasser
 Twitter Lou Logan, Reynaldo H. Verdejo Pinochet
 Launchpad   Timothy Gu
@@ -133,29 +128,22 @@ Generic Parts:
 Codecs:
   4xm.c Michael Niedermayer
   8bps.cRoberto Togni
-  8svx.cJaikrishnan Menon
   aacenc*, aaccoder.c   Rostislav Pehlivanov
-  alacenc.c Jaikrishnan Menon
   alsdec.c  Thilo Borgmann
-  ass*  Aurelien Jacobs
   asv*  Michael Niedermayer
   atrac3plus*   Maxim Poliakovski
   bgmc.c, bgmc.hThilo Borgmann
   binkaudio.c   Peter Ross
-  cavs* Stefan Gehrer
   cdxl.cPaul B Mahol
   celp_filters.*Vitor Sessak
   cinepak.c Roberto Togni
   cinepakenc.c  Rl / Aetey G.T. AB
   ccaption_dec.cAnshul Maheshwari
-  cljr  Alex Beregszaszi
   cpia.cStephan Hilb
   crystalhd.c   Philip Langdale
   cscd.cReimar Doeffinger
   cuvid.c   Timo Rothenpieler
   dirac*Rostislav Pehlivanov
-  dnxhd*Baptiste Coudurier
-  dpcm.cMike Melanson
   dss_sp.c  Oleksij Rempel
   dv.c  Roman Shaposhnik
   dvbsubdec.c   Anshul Maheshwari
@@ -164,32 +152,21 @@ Codecs:
   exif.c, exif.hThilo Borgmann
   ffv1* Michael Niedermayer
   ffwavesynth.c Nicolas George
-  flicvideo.c   Mike Melanson
   g722.cMartin Storsjo
   g726.cRoman Shaposhnik
-  gifdec.c  Baptiste Coudurier
   h261* Michael Niedermayer
   h263* Michael Niedermayer
   h264* Loren Merritt, Michael Niedermayer
   hap*  Tom Butterworth
   huffyuv*  Michael Niedermayer, Christophe Gisquet
-  idcinvideo.c  Mike Melanson
-  interplayvideo.c  Mike Melanson
   jni*, ffjni*  Matthieu Bouron
   jpeg2000* Nicolas Bertrand
   jvdec.c   Peter Ross
   lcl*.cRoberto Togni, Reimar Doeffinger
   libcelt_dec.c Nicolas George
-  libdirac* David Conrad
-  libgsm.c  Michel Bardiaux
   libkvazaar.c  Arttu Ylä-Outinen
-  libopenjpeg.c Jaikrishnan Menon
   libopenjpegenc.c  Michael Bradshaw
-  libschroedinger*  David Conrad
-  libtheoraenc.cDavid Conrad
-  libvorbis.c   David Conrad
   libvpx*   James Zern
-  libxavs.c Stefan Gehrer
   libzvbi-teletextd

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: drop people who do not appear in git history > 2013

[Michael Niedermayer]

On Fri, Jun 24, 2016 at 12:31:46PM +0200, Clément Bœsch wrote:
[...]
> @@ -531,29 +441,22 @@ GnuPG Fingerprints of maintainers and contributors
>  Alexander Strasser1C96 78B7 83CB 8AA7 9AF5 D1EB A7D8 A57B A876 
> E58F
>  Anssi Hannula 1A92 FF42 2DD9 8D2E 8AF7 65A9 4278 C520 513D 
> F3CB
>  Ash Hughes694D 43D2 D180 C7C7 6421 ABD3 A641 D0B7 623D 
> 6029
> -Attila Kinali 11F0 F9A6 A1D2 11F6 C745 D10C 6520 BCDD F2DF 
> E765
> -Baptiste Coudurier8D77 134D 20CC 9220 201F C5DB 0AC9 325C 5C1A 
> BAAA
> -Ben Littler   3EE3 3723 E560 3214 A8CD 4DEB 2CDB FCE7 768C 
> 8D2C
>  Benoit Fouet  B22A 4F4F 43EF 636B BB66 FCDC 0023 AE1E 2985 
> 49C8
>  Clément Bœsch 52D0 3A82 D445 F194 DB8B 2B16 87EE 2CB8 F4B8 
> FCF9
>  Daniel Verkamp78A6 07ED 782C 653E C628 B8B9 F0EB 8DD8 2F0E 
> 21C7
>  FFmpeg release signing keyFCF9 86EA 15E6 E293 A564 4F10 B432 2F04 D676 
> 58D8
>  Ganesh AjjanagaddeC96A 848E 97C3 CEA2 AB72 5CE4 45F9 6A2D 3C36 
> FB1B
>  Gwenole Beauchesne2E63 B3A6 3E44 37E2 017D 2704 53C7 6266 B153 
> 99C4
> -Jaikrishnan Menon 61A1 F09F 01C9 2D45 78E1 C862 25DC 8831 AF70 
> D368
>  Jean Delvare  7CA6 9F44 60F1 BDC4 1FD2 C858 A552 6B9B B3CD 
> 4E6A
>  Loren Merritt ABD9 08F4 C920 3F65 D8BE 35D7 1540 DAA7 060F 
> 56DE
>  Lou Logan 7D68 DC73 CBEF EABB 671A B6CF 621C 2E28 82F8 
> DC3A
>  Michael Niedermayer   9FF2 128B 147E F673 0BAD F133 611E C787 040B 
> 0FAB
>  Nicolas George24CE 01CE 9ACC 5CEB 74D8 8D9D B063 D997 36E5 
> 4C93
> -Panagiotis Issaris6571 13A3 33D9 3726 F728 AA98 F643 B12E ECF3 
> E029
>  Peter RossA907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 
> DD6B
>  Philip Langdale   5DC5 8D66 5FBA 3A43 18EC 045E F8D6 B194 6A75 
> 682E
>  Reimar Doeffinger C61D 16E5 9E2C D10C 8958 38A4 0899 A2B9 06D4 
> D9C7
>  Reinhard Tartler  9300 5DC2 7E87 6C37 ED7B CA9A 9808 3544 9453 
> 48A4
>  Reynaldo H. Verdejo Pinochet  6E27 CD34 170C C78E 4D4F 5F40 C18E 077F 3114 
> 452A
> -Robert Swain  EE7A 56EA 4A81 A7B5 2001 A521 67FA 362D A2FC 
> 3E71
> -Sascha Sommer 38A0 F88B 868E 9D3A 97D4 D6A0 E823 706F 1E07 
> 0D3C
>  Stefano Sabatini  0D0B AD6B 5330 BBAD D3D6 6A0C 719C 2839 FC43 
> 2D5F
>  Stephan Hilb  4F38 0B3A 5F39 B99B F505 E562 8D5C 5554 4E17 
> 8863
>  Tiancheng "Timothy" Gu9456 AFC0 814A 8139 E994 8351 7FE6 B095 B582 
> B0D4

please leave the key fingerprints, they serve as means to authenticate
communication and make sense to keep

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

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: drop people who do not appear in git history > 2013

[Michael Niedermayer]

On Fri, Jun 24, 2016 at 12:31:46PM +0200, Clément Bœsch wrote:
> From: Clément Bœsch 
[...]
> @@ -500,16 +416,10 @@ Resamplers:
>  Operating systems / CPU architectures
>  =
>  
> -Alpha   Falk Hueffner
>  MIPSNedeljko Babic

> -Mac OS X / PowerPC  Romain Dolbeau, Guillaume Poirier

i dont know if Guillaume still maintains this but he was active past
2013:
Date: Sun, 24 Aug 2014 21:52:17 +0200
From: Guillaume POIRIER 
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [PATCH/RFC] avutil/pixelutils: port ppc/altivec sad 
functions

[...]
-- 
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] MAINTAINERS: drop people who do not appear in git history > 2013

[Clément Bœsch]

On Fri, Jun 24, 2016 at 01:30:42PM +0200, Michael Niedermayer wrote:
> On Fri, Jun 24, 2016 at 12:31:46PM +0200, Clément Bœsch wrote:
> > From: Clément Bœsch 
> [...]
> > @@ -500,16 +416,10 @@ Resamplers:
> >  Operating systems / CPU architectures
> >  =
> >  
> > -Alpha   Falk Hueffner
> >  MIPSNedeljko Babic
> 
> > -Mac OS X / PowerPC  Romain Dolbeau, Guillaume Poirier
> 
> i dont know if Guillaume still maintains this but he was active past
> 2013:
> Date: Sun, 24 Aug 2014 21:52:17 +0200
> From: Guillaume POIRIER 
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH/RFC] avutil/pixelutils: port ppc/altivec 
> sad functions
> 

I don't see anything in the history;

% git log -i --author=poirier -1
commit 337e3fd990aab76bfcdceb84cd3f62f3e31fa22f
Author: Guillaume Poirier 
Date:   Thu Dec 25 18:27:49 2008 +

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH 02/10] diracdsp: add dequantization SIMD

[Rostislav Pehlivanov]

On 23 June 2016 at 21:01, James Almer  wrote:

> On 6/23/2016 2:06 PM, Rostislav Pehlivanov wrote:
> > Currently unused, to be used in the following commits.
> >
> > Signed-off-by: Rostislav Pehlivanov 
> > ---
> >  libavcodec/diracdsp.c  | 24 
> >  libavcodec/diracdsp.h  |  4 
> >  libavcodec/x86/diracdsp.asm| 41
> +
> >  libavcodec/x86/diracdsp_init.c |  4 +++-
> >  4 files changed, 72 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/diracdsp.c b/libavcodec/diracdsp.c
> > index ab8d149..d0cfd00 100644
> > --- a/libavcodec/diracdsp.c
> > +++ b/libavcodec/diracdsp.c
> > @@ -189,6 +189,27 @@ static void add_rect_clamped_c(uint8_t *dst, const
> uint16_t *src, int stride,
> >  }
> >  }
> >
> > +#define DEQUANT_SUBBAND(PX)
> \
> > +static void dequant_subband_ ## PX ## _c(uint8_t *src, uint8_t *dst,
> ptrdiff_t stride, \
> > + const int qf, const int qs,
> int64_t tot_v, int64_t tot_h) \
>
> Shouldn't this be int (or ptrdiff_t)? Seeing they are int in the
> SliceCoeffs struct introduced by patch 6, i don't see why they
> should be int64_t here. Unless I'm missing something.
>
> > +{
> \
> > +int i, y;
> \
> > +for (y = 0; y < tot_v; y++) {
> \
> > +PX c, sign, *src_r = (PX *)src, *dst_r = (PX *)dst;
> \
> > +for (i = 0; i < tot_h; i++) {
> \
> > +c = *src_r++;
> \
> > +sign = FFSIGN(c)*(!!c);
> \
> > +c = (FFABS(c)*qf + qs) >> 2;
>\
> > +*dst_r++ = c*sign;
>\
> > +}
> \
> > +src += tot_h << (sizeof(PX) >> 1);
>\
> > +dst += stride;
>\
> > +}
> \
> > +}
> > +
> > +DEQUANT_SUBBAND(int16_t)
> > +DEQUANT_SUBBAND(int32_t)
> > +
> >  #define PIXFUNC(PFX, WIDTH)
>  \
> >  c->PFX ## _dirac_pixels_tab[WIDTH>>4][0] = ff_ ## PFX ##
> _dirac_pixels ## WIDTH ## _c; \
> >  c->PFX ## _dirac_pixels_tab[WIDTH>>4][1] = ff_ ## PFX ##
> _dirac_pixels ## WIDTH ## _l2_c; \
> > @@ -214,6 +235,9 @@ av_cold void ff_diracdsp_init(DiracDSPContext *c)
> >  c->biweight_dirac_pixels_tab[1] = biweight_dirac_pixels16_c;
> >  c->biweight_dirac_pixels_tab[2] = biweight_dirac_pixels32_c;
> >
> > +c->dequant_subband[0] = c->dequant_subband[2] =
> dequant_subband_int16_t_c;
> > +c->dequant_subband[1] = c->dequant_subband[3] =
> dequant_subband_int32_t_c;
> > +
> >  PIXFUNC(put, 8);
> >  PIXFUNC(put, 16);
> >  PIXFUNC(put, 32);
> > diff --git a/libavcodec/diracdsp.h b/libavcodec/diracdsp.h
> > index 25a872d..c0ac56b 100644
> > --- a/libavcodec/diracdsp.h
> > +++ b/libavcodec/diracdsp.h
> > @@ -22,6 +22,7 @@
> >  #define AVCODEC_DIRACDSP_H
> >
> >  #include 
> > +#include 
> >
> >  typedef void (*dirac_weight_func)(uint8_t *block, int stride, int
> log2_denom, int weight, int h);
> >  typedef void (*dirac_biweight_func)(uint8_t *dst, const uint8_t *src,
> int stride, int log2_denom, int weightd, int weights, int h);
> > @@ -46,6 +47,9 @@ typedef struct {
> >  void (*add_rect_clamped)(uint8_t *dst/*align 16*/, const uint16_t
> *src/*align 16*/, int stride, const int16_t *idwt/*align 16*/, int
> idwt_stride, int width, int height/*mod 2*/);
> >  void (*add_dirac_obmc[3])(uint16_t *dst, const uint8_t *src, int
> stride, const uint8_t *obmc_weight, int yblen);
> >
> > +/* 0-1: int16_t and int32_t asm/c, 2-3: int16 and int32_t, C only */
> > +void (*dequant_subband[4])(uint8_t *src, uint8_t *dst, ptrdiff_t
> stride, const int qf, const int qs, int64_t tot_v, int64_t tot_h);
> > +
> >  dirac_weight_func weight_dirac_pixels_tab[3];
> >  dirac_biweight_func biweight_dirac_pixels_tab[3];
> >  } DiracDSPContext;
> > diff --git a/libavcodec/x86/diracdsp.asm b/libavcodec/x86/diracdsp.asm
> > index 9db7b67..f743363 100644
> > --- a/libavcodec/x86/diracdsp.asm
> > +++ b/libavcodec/x86/diracdsp.asm
> > @@ -289,6 +289,46 @@ cglobal add_dirac_obmc%1_%2, 6,6,5, dst, src,
> stride, obmc, yblen
> >  RET
> >  %endm
> >
> > +%macro DEQUANT_SUBBAND_32 0
> > +; void dequant_subband_32(uint8_t *src, uint8_t *dst, ptrdiff_t stride,
> const int qf, const int qs, int64_t tot_v, int64_t tot_h)
> > +cglobal dequant_subband_32, 7, 9, 4, src, dst, stride, qf, qs, tot_v,
> tot_h
>
> Again, x86_64 only as is.
>
> > +
> > +movd   m2, qfd
> > +movd   m3, qsd
> > +SPLATD m2
> > +SPLATD m3
> > +negtot_vq
> > +negtot_hq
>
> Same as with put_signed_rect_clamped_10, no reason to neg these.
>
> > +movr7, dstq
> > +movr8, tot_hq
>
> You have qf 

Re: [FFmpeg-devel] [PATCH 01/10] diracdsp: add SIMD for the 10 bit version of put_signed_rect_clamped

[Rostislav Pehlivanov]

On 23 June 2016 at 20:57, James Almer  wrote:

> On 6/23/2016 2:06 PM, Rostislav Pehlivanov wrote:
> > Signed-off-by: Rostislav Pehlivanov 
> > ---
> >  libavcodec/x86/diracdsp.asm| 47
> ++
> >  libavcodec/x86/diracdsp_init.c |  6 ++
> >  2 files changed, 53 insertions(+)
> >
> > diff --git a/libavcodec/x86/diracdsp.asm b/libavcodec/x86/diracdsp.asm
> > index a042413..9db7b67 100644
> > --- a/libavcodec/x86/diracdsp.asm
> > +++ b/libavcodec/x86/diracdsp.asm
> > @@ -22,6 +22,8 @@
> >
> >  SECTION_RODATA
> >  pw_7: times 8 dw 7
> > +convert_to_unsigned_10bit: times 4 dd 0x200
> > +clip_10bit:times 8 dw 0x3ff
> >
> >  cextern pw_3
> >  cextern pw_16
> > @@ -172,6 +174,48 @@ cglobal put_signed_rect_clamped_%1, 5,9,3, dst,
> dst_stride, src, src_stride, w,
> >  RET
> >  %endm
> >
> > +%macro PUT_RECT_10 0
> > +; void put_signed_rect_clamped_10(uint8_t *dst, int dst_stride, const
> uint8_t *src, int src_stride, int width, int height)
> > +cglobal put_signed_rect_clamped_10, 6, 9, 6, dst, dst_stride, src,
> src_stride, w, h
>
> This is x86_64 only. Either add the relevant pre-processor checks here
> and to the init file, or make the necessary changes to make it work
> on x86_32.
> Look at the 8bit version of put_signed_rect_clamped for an example of
> how to deal with this using stack.
>
> > +
> > +neg  wq
> > +neg  hq
>
> Why? You're not using these as part of effective addresses, just as
> counters. Keep them as is and just do sub instead of add in the loops
> below.
> For that matter, you'd need to sign extend these with movsxd before
> negating them, or change the prototype and make them ptrdiff_t instead
> of int.
>
> > +mov  r6, srcq
> > +mov  r7, dstq
> > +mov  r8, wq
> > +pxor m2, m2
> > +mova m3, [clip_10bit]
> > +mova m4, [convert_to_unsigned_10bit]
> > +
> > +.loop_h:
> > +mov  srcq, r6
> > +mov  dstq, r7
> > +mov  wq,   r8
> > +
> > +.loop_w:
> > +movu m0, [srcq+0*mmsize]
> > +movu m1, [srcq+1*mmsize]
> > +
> > +padddm0, m4
> > +padddm1, m4
> > +packusdw m0, m0, m1
> > +CLIPWm0, m2, m3 ; packusdw saturates so it's fine
>
> Would be nice if you could make this work with SSE2 as well.
> There are some examples of packusdw SSE2 emulation in the codebase.
>
> > +
> > +movu [dstq], m0
> > +
> > +add  srcq, 2*mmsize
> > +add  dstq, 1*mmsize
> > +add  wq, 8
> > +jl   .loop_w
> > +
> > +add  r6, src_strideq
> > +add  r7, dst_strideq
> > +add  hq, 1
>
> Make sure to do "sub wd, 8" and "sub hd, 1" after removing the above
> negs if don't change the prototype.
>
> > +jl   .loop_h
> > +
> > +RET
> > +%endm
> > +
> >  %macro ADD_RECT 1
> >  ; void add_rect_clamped(uint8_t *dst, uint16_t *src, int stride,
> int16_t *idwt, int idwt_stride, int width, int height)
> >  cglobal add_rect_clamped_%1, 7,9,3, dst, src, stride, idwt,
> idwt_stride, w, h
> > @@ -263,3 +307,6 @@ ADD_RECT sse2
> >  HPEL_FILTER sse2
> >  ADD_OBMC 32, sse2
> >  ADD_OBMC 16, sse2
> > +
> > +INIT_XMM sse4
> > +PUT_RECT_10
>
> No need to make it a macro if it's going to be a single version.
> If you add a SSE2 one then this would makes sense.
>
> > diff --git a/libavcodec/x86/diracdsp_init.c
> b/libavcodec/x86/diracdsp_init.c
> > index 5fae798..4786eea 100644
> > --- a/libavcodec/x86/diracdsp_init.c
> > +++ b/libavcodec/x86/diracdsp_init.c
> > @@ -46,6 +46,8 @@ void ff_put_rect_clamped_sse2(uint8_t *dst, int
> dst_stride, const int16_t *src,
> >  void ff_put_signed_rect_clamped_mmx(uint8_t *dst, int dst_stride, const
> int16_t *src, int src_stride, int width, int height);
> >  void ff_put_signed_rect_clamped_sse2(uint8_t *dst, int dst_stride,
> const int16_t *src, int src_stride, int width, int height);
> >
> > +void ff_put_signed_rect_clamped_10_sse4(uint8_t *dst, int dst_stride,
> const uint8_t *src, int src_stride, int width, int height);
> > +
> >  #if HAVE_YASM
> >
> >  #define HPEL_FILTER(MMSIZE, EXT)
>  \
> > @@ -184,4 +186,8 @@ void ff_diracdsp_init_x86(DiracDSPContext* c)
> >  c->put_dirac_pixels_tab[2][0] = ff_put_dirac_pixels32_sse2;
> >  c->avg_dirac_pixels_tab[2][0] = ff_avg_dirac_pixels32_sse2;
> >  }
> > +
> > +if (EXTERNAL_SSE4(mm_flags)) {
> > +c->put_signed_rect_clamped[1] =
> ff_put_signed_rect_clamped_10_sse4;
> > +}
> >  }
> >
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Like with the dequant asm, I've attached an amended patch

Thanks
From 86ecebfe70509329d6f5b8a587ae79d19f9c8154 Mon Sep 17 00:00:00 2001
From: Rostislav Pehlivanov 
Date: Thu, 23 Jun 2016 18:06:55 +0100
Subject: [PATCH 1/2] diracdsp: add SIMD for the 10 bit version of
 put_signed_rect_clamped

Signed-off-by: Rostisl

[FFmpeg-devel] [PATCH] fate: add anequalizer test

[Petru Rares Sincraian]

Hi there,


Here is a patch for anequalizer. Soon I will improve the coverage for this test.



Regards,

Petru Rares.
From fe6fbe3a218b8a3eeffa0b6fd64e0f8c8aa2b78d Mon Sep 17 00:00:00 2001
From: Petru Rares Sincraian 
Date: Wed, 22 Jun 2016 12:58:14 +0200
Subject: [PATCH] fate: add anequalizer test

---
 tests/fate/filter-audio.mak   |   6 +
 tests/filtergraphs/anequalizer|   1 +
 tests/ref/fate/filter-anequalizer | 264 ++
 3 files changed, 271 insertions(+)
 create mode 100644 tests/filtergraphs/anequalizer
 create mode 100644 tests/ref/fate/filter-anequalizer

diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index 7c903b7..282834f 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -63,6 +63,12 @@ fate-filter-agate: tests/data/asynth-44100-2.wav
 fate-filter-agate: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
 fate-filter-agate: CMD = framecrc -i $(SRC) -af agate=level_in=10:range=0:threshold=1:ratio=1:attack=1:knee=1:makeup=4
 
+FATE_AFILTER-$(call FILTERDEMDECENCMUX, ANEQUALIZER, WAV, PCM_S16LE, PCM_S16LE, WAV) += fate-filter-anequalizer
+fate-filter-anequalizer: tests/data/asynth-44100-2.wav
+fate-filter-anequalizer: tests/data/filtergraphs/anequalizer
+fate-filter-anequalizer: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
+fate-filter-anequalizer: CMD = framecrc -i $(SRC) -filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/anequalizer
+
 tests/data/hls-list.m3u8: TAG = GEN
 tests/data/hls-list.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
 	$(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
diff --git a/tests/filtergraphs/anequalizer b/tests/filtergraphs/anequalizer
new file mode 100644
index 000..fd4a86f
--- /dev/null
+++ b/tests/filtergraphs/anequalizer
@@ -0,0 +1 @@
+anequalizer='c0 f=200 w=200 g=-80 t=1'
diff --git a/tests/ref/fate/filter-anequalizer b/tests/ref/fate/filter-anequalizer
new file mode 100644
index 000..21c7aaf
--- /dev/null
+++ b/tests/ref/fate/filter-anequalizer
@@ -0,0 +1,264 @@
+#tb 0: 1/44100
+#media_type 0: audio
+#codec_id 0: pcm_s16le
+#sample_rate 0: 44100
+#channel_layout 0: 3
+0,  0,  0, 1024, 4096, 0x8e1bf8e0
+0,   1024,   1024, 1024, 4096, 0xe315f564
+0,   2048,   2048, 1024, 4096, 0x3d0efa98
+0,   3072,   3072, 1024, 4096, 0x5c1bf6b2
+0,   4096,   4096, 1024, 4096, 0xb5b4ff02
+0,   5120,   5120, 1024, 4096, 0xb9b1f4b6
+0,   6144,   6144, 1024, 4096, 0x86e9f411
+0,   7168,   7168, 1024, 4096, 0x36aafbd3
+0,   8192,   8192, 1024, 4096, 0x05d2f63f
+0,   9216,   9216, 1024, 4096, 0x1d95fd16
+0,  10240,  10240, 1024, 4096, 0x4fb0f009
+0,  11264,  11264, 1024, 4096, 0x6a6301c6
+0,  12288,  12288, 1024, 4096, 0x299cfbd8
+0,  13312,  13312, 1024, 4096, 0x2a7ffe8c
+0,  14336,  14336, 1024, 4096, 0xceace509
+0,  15360,  15360, 1024, 4096, 0xd084feec
+0,  16384,  16384, 1024, 4096, 0xd956f613
+0,  17408,  17408, 1024, 4096, 0xf61dfa8c
+0,  18432,  18432, 1024, 4096, 0x6ebcf53e
+0,  19456,  19456, 1024, 4096, 0x8601f9f2
+0,  20480,  20480, 1024, 4096, 0x6a4bf2d9
+0,  21504,  21504, 1024, 4096, 0xb917fc1d
+0,  22528,  22528, 1024, 4096, 0x85cffbca
+0,  23552,  23552, 1024, 4096, 0x80d9f509
+0,  24576,  24576, 1024, 4096, 0xa4acf898
+0,  25600,  25600, 1024, 4096, 0x7614f3c0
+0,  26624,  26624, 1024, 4096, 0x5f3700dc
+0,  27648,  27648, 1024, 4096, 0x4308ef21
+0,  28672,  28672, 1024, 4096, 0x670df4fe
+0,  29696,  29696, 1024, 4096, 0x98d0f24f
+0,  30720,  30720, 1024, 4096, 0xed360be0
+0,  31744,  31744, 1024, 4096, 0xbe10f1eb
+0,  32768,  32768, 1024, 4096, 0xb5d0fac0
+0,  33792,  33792, 1024, 4096, 0x94c1f649
+0,  34816,  34816, 1024, 4096, 0x3617fb9b
+0,  35840,  35840, 1024, 4096, 0x1840f6e6
+0,  36864,  36864, 1024, 4096, 0x0ce8fdfa
+0,  37888,  37888, 1024, 4096, 0xd7c1f4b8
+0,  38912,  38912, 1024, 4096, 0x86e9f411
+0,  39936,  39936, 1024, 4096, 0x36aafbd3
+0,  40960,  40960, 1024, 4096, 0x05d2f63f
+0,  41984,  41984, 1024, 4096, 0x1d95fd16
+0,  43008,  43008, 1024, 4096, 0x4fb0f009
+0,  44032,  44032, 1024, 4096, 0xc6de743e
+0,  45056,  45056, 1024, 4096, 0xe878f6e3
+0,  46080,  46080, 1024, 4096, 0x40c3fdf9
+0,  47104,  47104, 1024, 4096, 0x19def744
+0,  48128,  48128, 1024, 4096, 0x9e3d0016
+0,  49

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: drop people who do not appear in git history > 2013

[Michael Niedermayer]

On Fri, Jun 24, 2016 at 12:31:46PM +0200, Clément Bœsch wrote:
> From: Clément Bœsch 
>
> ---
>  MAINTAINERS | 113 
> +---
>  1 file changed, 8 insertions(+), 105 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fd87db5..e908def 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -35,17 +35,12 @@ ffserver:
>  Commandline utility code:
>cmdutils.c, cmdutils.hMichael Niedermayer
>
> -QuickTime faststart:
> -  tools/qt-faststart.c  Baptiste Coudurier
> -
>
>  Miscellaneous Areas
>  ===
>
> -documentation   Stefano Sabatini, Mike Melanson, 
> Timothy Gu, Lou Logan
> +documentation   Stefano Sabatini, Timothy Gu, Lou 
> Logan
>  project server  Árpád Gereöffy, Michael Niedermayer, 
> Reimar Doeffinger, Alexander Strasser
> -presets Robert Swain
> -metadata subsystem  Aurelien Jacobs
>  release management  Michael Niedermayer
>
>
> @@ -55,7 +50,7 @@ Communication
>  website Deby Barbara Lepage
>  fate.ffmpeg.org Timothy Gu
>  Trac bug trackerAlexander Strasser, Michael 
> Niedermayer, Carl Eugen Hoyos, Lou Logan
> -mailing lists   Baptiste Coudurier, Lou Logan
> +mailing lists   Lou Logan
>  Google+ Paul B Mahol, Michael Niedermayer, 
> Alexander Strasser
>  Twitter Lou Logan, Reynaldo H. Verdejo 
> Pinochet
>  Launchpad   Timothy Gu
> @@ -133,29 +128,22 @@ Generic Parts:
>  Codecs:
>4xm.c Michael Niedermayer
>8bps.cRoberto Togni
> -  8svx.cJaikrishnan Menon
>aacenc*, aaccoder.c   Rostislav Pehlivanov
> -  alacenc.c Jaikrishnan Menon
>alsdec.c  Thilo Borgmann
> -  ass*  Aurelien Jacobs
>asv*  Michael Niedermayer
>atrac3plus*   Maxim Poliakovski
>bgmc.c, bgmc.hThilo Borgmann
>binkaudio.c   Peter Ross

> -  cavs* Stefan Gehrer

was active past 2013:
From my inbox:
Date: Sun, 22 Jun 2014 13:13:47 +0200
From: Stefan Gehrer 
Subject: Re: Ticket #1901, cavs B-frames




>cdxl.cPaul B Mahol
>celp_filters.*Vitor Sessak
>cinepak.c Roberto Togni
>cinepakenc.c  Rl / Aetey G.T. AB
>ccaption_dec.cAnshul Maheshwari
> -  cljr  Alex Beregszaszi
>cpia.cStephan Hilb
>crystalhd.c   Philip Langdale
>cscd.cReimar Doeffinger
>cuvid.c   Timo Rothenpieler
>dirac*Rostislav Pehlivanov
> -  dnxhd*Baptiste Coudurier
> -  dpcm.cMike Melanson
>dss_sp.c  Oleksij Rempel
>dv.c  Roman Shaposhnik
>dvbsubdec.c   Anshul Maheshwari
> @@ -164,32 +152,21 @@ Codecs:
>exif.c, exif.hThilo Borgmann
>ffv1* Michael Niedermayer
>ffwavesynth.c Nicolas George
> -  flicvideo.c   Mike Melanson
>g722.cMartin Storsjo
>g726.cRoman Shaposhnik
> -  gifdec.c  Baptiste Coudurier
>h261* Michael Niedermayer
>h263* Michael Niedermayer
>h264* Loren Merritt, Michael Niedermayer
>hap*  Tom Butterworth
>huffyuv*  Michael Niedermayer, Christophe 
> Gisquet
> -  idcinvideo.c  Mike Melanson
> -  interplayvideo.c  Mike Melanson
>jni*, ffjni*  Matthieu Bouron
>jpeg2000* Nicolas Bertrand
>jvdec.c   Peter Ross
>lcl*.cRoberto Togni, Reimar Doeffinger
>libcelt_dec.c Nicolas George
> -  libdirac* David Conrad
> -  libgsm.c  Michel Bardiaux
>libkvazaar.c  Arttu Ylä-Outinen
> -  libop

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: drop people who do not appear in git history > 2013

[Michael Niedermayer]

On Fri, Jun 24, 2016 at 01:35:01PM +0200, Clément Bœsch wrote:
> On Fri, Jun 24, 2016 at 01:30:42PM +0200, Michael Niedermayer wrote:
> > On Fri, Jun 24, 2016 at 12:31:46PM +0200, Clément Bœsch wrote:
> > > From: Clément Bœsch 
> > [...]
> > > @@ -500,16 +416,10 @@ Resamplers:
> > >  Operating systems / CPU architectures
> > >  =
> > >  
> > > -Alpha   Falk Hueffner
> > >  MIPSNedeljko Babic
> > 
> > > -Mac OS X / PowerPC  Romain Dolbeau, Guillaume Poirier
> > 
> > i dont know if Guillaume still maintains this but he was active past
> > 2013:
> > Date: Sun, 24 Aug 2014 21:52:17 +0200
> > From: Guillaume POIRIER 
> > To: FFmpeg development discussions and patches 
> > Subject: Re: [FFmpeg-devel] [PATCH/RFC] avutil/pixelutils: port ppc/altivec 
> > sad functions
> > 
> 
> I don't see anything in the history;
> 
> % git log -i --author=poirier -1
> commit 337e3fd990aab76bfcdceb84cd3f62f3e31fa22f
> Author: Guillaume Poirier 
> Date:   Thu Dec 25 18:27:49 2008 +

i was looking at the mailing list

[...]

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

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: drop people who do not appear in git history > 2013

[Benoit Fouet]

Hi,

[just BCC'ing the removed people, if they have something to say]


On 24/06/2016 12:31, Clément Bœsch wrote:

From: Clément Bœsch 

---
  MAINTAINERS | 113 +---
  1 file changed, 8 insertions(+), 105 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index fd87db5..e908def 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -35,17 +35,12 @@ ffserver:
  Commandline utility code:
cmdutils.c, cmdutils.hMichael Niedermayer
  
-QuickTime faststart:

-  tools/qt-faststart.c  Baptiste Coudurier
-
  
  Miscellaneous Areas

  ===
  
-documentation   Stefano Sabatini, Mike Melanson, Timothy Gu, Lou Logan

+documentation   Stefano Sabatini, Timothy Gu, Lou Logan
  project server  Árpád Gereöffy, Michael Niedermayer, 
Reimar Doeffinger, Alexander Strasser
-presets Robert Swain
-metadata subsystem  Aurelien Jacobs
  release management  Michael Niedermayer
  
  
@@ -55,7 +50,7 @@ Communication

  website Deby Barbara Lepage
  fate.ffmpeg.org Timothy Gu
  Trac bug trackerAlexander Strasser, Michael 
Niedermayer, Carl Eugen Hoyos, Lou Logan
-mailing lists   Baptiste Coudurier, Lou Logan
+mailing lists   Lou Logan
  Google+ Paul B Mahol, Michael Niedermayer, 
Alexander Strasser
  Twitter Lou Logan, Reynaldo H. Verdejo 
Pinochet
  Launchpad   Timothy Gu
@@ -133,29 +128,22 @@ Generic Parts:
  Codecs:
4xm.c Michael Niedermayer
8bps.cRoberto Togni
-  8svx.cJaikrishnan Menon
aacenc*, aaccoder.c   Rostislav Pehlivanov
-  alacenc.c Jaikrishnan Menon
alsdec.c  Thilo Borgmann
-  ass*  Aurelien Jacobs
asv*  Michael Niedermayer
atrac3plus*   Maxim Poliakovski
bgmc.c, bgmc.hThilo Borgmann
binkaudio.c   Peter Ross
-  cavs* Stefan Gehrer
cdxl.cPaul B Mahol
celp_filters.*Vitor Sessak
cinepak.c Roberto Togni
cinepakenc.c  Rl / Aetey G.T. AB
ccaption_dec.cAnshul Maheshwari
-  cljr  Alex Beregszaszi
cpia.cStephan Hilb
crystalhd.c   Philip Langdale
cscd.cReimar Doeffinger
cuvid.c   Timo Rothenpieler
dirac*Rostislav Pehlivanov
-  dnxhd*Baptiste Coudurier
-  dpcm.cMike Melanson
dss_sp.c  Oleksij Rempel
dv.c  Roman Shaposhnik
dvbsubdec.c   Anshul Maheshwari
@@ -164,32 +152,21 @@ Codecs:
exif.c, exif.hThilo Borgmann
ffv1* Michael Niedermayer
ffwavesynth.c Nicolas George
-  flicvideo.c   Mike Melanson
g722.cMartin Storsjo
g726.cRoman Shaposhnik
-  gifdec.c  Baptiste Coudurier
h261* Michael Niedermayer
h263* Michael Niedermayer
h264* Loren Merritt, Michael Niedermayer
hap*  Tom Butterworth
huffyuv*  Michael Niedermayer, Christophe 
Gisquet
-  idcinvideo.c  Mike Melanson
-  interplayvideo.c  Mike Melanson
jni*, ffjni*  Matthieu Bouron
jpeg2000* Nicolas Bertrand
jvdec.c   Peter Ross
lcl*.cRoberto Togni, Reimar Doeffinger
libcelt_dec.c Nicolas George
-  libdirac* David Conrad
-  libgsm.c  Michel Bardiaux
libkvazaar.c  Arttu Ylä-Outinen
-  libopenjpeg.c Jaikrishnan Menon
libopenjpegenc.c  Michael Bradshaw
-  libschroedinger*  David Conrad
-  libtheoraenc.cDavid Conrad
- 

Re: [FFmpeg-devel] [PATCH] fate: add anequalizer test

[Michael Niedermayer]

On Fri, Jun 24, 2016 at 11:45:12AM +, Petru Rares Sincraian wrote:
> Hi there,
> 
> 
> Here is a patch for anequalizer. Soon I will improve the coverage for this 
> test.
> 
> 
> 
> Regards,
> 
> Petru Rares.

>  fate/filter-audio.mak   |6 +
>  filtergraphs/anequalizer|1 
>  ref/fate/filter-anequalizer |  264 
> 
>  3 files changed, 271 insertions(+)
> 6c85b9fe6f951c8715fa7eec6c801efb04ff4af3  0001-fate-add-anequalizer-test.patch
> From fe6fbe3a218b8a3eeffa0b6fd64e0f8c8aa2b78d Mon Sep 17 00:00:00 2001
> From: Petru Rares Sincraian 
> Date: Wed, 22 Jun 2016 12:58:14 +0200
> Subject: [PATCH] fate: add anequalizer test

applied

thanks

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

Re: [FFmpeg-devel] why ffmpeg doesn't support vp9 svc?

[Ronald S. Bultje]

Hi,

On Fri, Jun 24, 2016 at 4:45 AM, qw  wrote:

> Hi,
>
> I have one question about vp9. vp9 supports svc encoding/decoding. Why
> ffmpeg doesn't support vp9 svc?


FFmpeg (both through libvpx as well as through ffvp9) does support scalable
decoding (that is: decoding of frames using references of different
dimensions). It doesn't support multiple layers, because we don't have an
API for that. We don't have an API because nobody wrote it yet.

As for encoding, the answer is pretty much identical.

If you have a use for it, implement it and send a patch.

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

Re: [FFmpeg-devel] [PATCH 01/10] diracdsp: add SIMD for the 10 bit version of put_signed_rect_clamped

[Michael Niedermayer]

On Fri, Jun 24, 2016 at 12:44:21PM +0100, Rostislav Pehlivanov wrote:
> On 23 June 2016 at 20:57, James Almer  wrote:
> 
> > On 6/23/2016 2:06 PM, Rostislav Pehlivanov wrote:
> > > Signed-off-by: Rostislav Pehlivanov 
> > > ---
> > >  libavcodec/x86/diracdsp.asm| 47
> > ++
> > >  libavcodec/x86/diracdsp_init.c |  6 ++
> > >  2 files changed, 53 insertions(+)
> > >
> > > diff --git a/libavcodec/x86/diracdsp.asm b/libavcodec/x86/diracdsp.asm
> > > index a042413..9db7b67 100644
> > > --- a/libavcodec/x86/diracdsp.asm
> > > +++ b/libavcodec/x86/diracdsp.asm
> > > @@ -22,6 +22,8 @@
> > >
> > >  SECTION_RODATA
> > >  pw_7: times 8 dw 7
> > > +convert_to_unsigned_10bit: times 4 dd 0x200
> > > +clip_10bit:times 8 dw 0x3ff
> > >
> > >  cextern pw_3
> > >  cextern pw_16
> > > @@ -172,6 +174,48 @@ cglobal put_signed_rect_clamped_%1, 5,9,3, dst,
> > dst_stride, src, src_stride, w,
> > >  RET
> > >  %endm
> > >
> > > +%macro PUT_RECT_10 0
> > > +; void put_signed_rect_clamped_10(uint8_t *dst, int dst_stride, const
> > uint8_t *src, int src_stride, int width, int height)
> > > +cglobal put_signed_rect_clamped_10, 6, 9, 6, dst, dst_stride, src,
> > src_stride, w, h
> >
> > This is x86_64 only. Either add the relevant pre-processor checks here
> > and to the init file, or make the necessary changes to make it work
> > on x86_32.
> > Look at the 8bit version of put_signed_rect_clamped for an example of
> > how to deal with this using stack.
> >
> > > +
> > > +neg  wq
> > > +neg  hq
> >
> > Why? You're not using these as part of effective addresses, just as
> > counters. Keep them as is and just do sub instead of add in the loops
> > below.
> > For that matter, you'd need to sign extend these with movsxd before
> > negating them, or change the prototype and make them ptrdiff_t instead
> > of int.
> >
> > > +mov  r6, srcq
> > > +mov  r7, dstq
> > > +mov  r8, wq
> > > +pxor m2, m2
> > > +mova m3, [clip_10bit]
> > > +mova m4, [convert_to_unsigned_10bit]
> > > +
> > > +.loop_h:
> > > +mov  srcq, r6
> > > +mov  dstq, r7
> > > +mov  wq,   r8
> > > +
> > > +.loop_w:
> > > +movu m0, [srcq+0*mmsize]
> > > +movu m1, [srcq+1*mmsize]
> > > +
> > > +padddm0, m4
> > > +padddm1, m4
> > > +packusdw m0, m0, m1
> > > +CLIPWm0, m2, m3 ; packusdw saturates so it's fine
> >
> > Would be nice if you could make this work with SSE2 as well.
> > There are some examples of packusdw SSE2 emulation in the codebase.
> >
> > > +
> > > +movu [dstq], m0
> > > +
> > > +add  srcq, 2*mmsize
> > > +add  dstq, 1*mmsize
> > > +add  wq, 8
> > > +jl   .loop_w
> > > +
> > > +add  r6, src_strideq
> > > +add  r7, dst_strideq
> > > +add  hq, 1
> >
> > Make sure to do "sub wd, 8" and "sub hd, 1" after removing the above
> > negs if don't change the prototype.
> >
> > > +jl   .loop_h
> > > +
> > > +RET
> > > +%endm
> > > +
> > >  %macro ADD_RECT 1
> > >  ; void add_rect_clamped(uint8_t *dst, uint16_t *src, int stride,
> > int16_t *idwt, int idwt_stride, int width, int height)
> > >  cglobal add_rect_clamped_%1, 7,9,3, dst, src, stride, idwt,
> > idwt_stride, w, h
> > > @@ -263,3 +307,6 @@ ADD_RECT sse2
> > >  HPEL_FILTER sse2
> > >  ADD_OBMC 32, sse2
> > >  ADD_OBMC 16, sse2
> > > +
> > > +INIT_XMM sse4
> > > +PUT_RECT_10
> >
> > No need to make it a macro if it's going to be a single version.
> > If you add a SSE2 one then this would makes sense.
> >
> > > diff --git a/libavcodec/x86/diracdsp_init.c
> > b/libavcodec/x86/diracdsp_init.c
> > > index 5fae798..4786eea 100644
> > > --- a/libavcodec/x86/diracdsp_init.c
> > > +++ b/libavcodec/x86/diracdsp_init.c
> > > @@ -46,6 +46,8 @@ void ff_put_rect_clamped_sse2(uint8_t *dst, int
> > dst_stride, const int16_t *src,
> > >  void ff_put_signed_rect_clamped_mmx(uint8_t *dst, int dst_stride, const
> > int16_t *src, int src_stride, int width, int height);
> > >  void ff_put_signed_rect_clamped_sse2(uint8_t *dst, int dst_stride,
> > const int16_t *src, int src_stride, int width, int height);
> > >
> > > +void ff_put_signed_rect_clamped_10_sse4(uint8_t *dst, int dst_stride,
> > const uint8_t *src, int src_stride, int width, int height);
> > > +
> > >  #if HAVE_YASM
> > >
> > >  #define HPEL_FILTER(MMSIZE, EXT)
> >  \
> > > @@ -184,4 +186,8 @@ void ff_diracdsp_init_x86(DiracDSPContext* c)
> > >  c->put_dirac_pixels_tab[2][0] = ff_put_dirac_pixels32_sse2;
> > >  c->avg_dirac_pixels_tab[2][0] = ff_avg_dirac_pixels32_sse2;
> > >  }
> > > +
> > > +if (EXTERNAL_SSE4(mm_flags)) {
> > > +c->put_signed_rect_clamped[1] =
> > ff_put_signed_rect_clamped_10_sse4;
> > > +}
> > >  }
> > >
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http:/

Re: [FFmpeg-devel] FFmpeg 3.1 name

[Gregory J Wolfe]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf Of Michael Niedermayer
> Sent: Thursday, June 23, 2016 5:01 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: [FFmpeg-devel] FFmpeg 3.1 name
> 
> Hi all
> 
> what shall FFmpeg 3.1 be called ?
> 
> I still have these ideas from past suggestions:
> Von Neumann, Einstein, lorentz, poincaré, desitter, de broglie, Gauss,
> Galois, Viterbi, Darwin
> 
> Are there other suggestions?
> Is something preferred ?
> 
> In absence of any preferrance ill pick something randomly
> 
> Thanks
> 
> --
> Michael GnuPG fingerprint:
> 9FF2128B147EF6730BADF133611EC787040B0FAB
> 

Maybe to start a new tradition/policy, and since this will be sort of a June 
release, I googled famous scientists with birthdays in June.  Based on that 
here are some suggestions, with birthdays/summaries below:  Cassini, Crick, 
Stephenson, Paul, Cousteau, Maxwell, Coulomb, Rutan, Pascal, Turing, Kelvin, 
Mayer.  My pick  would be Rutan.

- June 8, 1625 Giovanni Cassini, French astronomer who discovered the moons of 
Saturn
- June 8, 1916 Francis Crick, British molecular biologist, physicist, and 
neuroscientist who co-discovered DNA structure
- June 9, 1781 George Stephenson, English inventor of the first steam 
locomotive engine for railroads
- June 9, 1915 Les Paul, American inventor who founded Les Paul guitar, and 
invented sound-on-sound, the eight-track recorder, over-dubbing, the electronic 
reverb effect, multi-track tape recording, and the Les Paul electric guitar
- June 11, 1910 Jacques-Yves Cousteau, French oceanic explorer who invented 
diving gear
- June 13, 1831 James Clerk Maxwell, Scottish physicist who discovered the 
electro-magnetic field
- June 14, 1736 Charles-Augustin de Coulomb, French physicist who wrote 
Coulomb's Law and invented the torsion balance
- June 17, - 1943 Burt Rutan, American aerospace engineer who invented light, 
strong, unusual-looking, energy-efficient aircraft designed Voyager first plane 
to fly around the world without stopping or refueling
- June 19, 1623 Blaise Pascal, French mathematician and physicist who invented 
an early calculator
- June 23, 1912 - Alan Turing, mathematician and computer theory pioneer, who 
invented the Turing Machine
- June 26, 1824 William Thomson Kelvin, British physicist who invented the 
Kelvin Scale
- June 28, 1906 - Maria Goeppert Mayer, American atomic physicist, who proposed 
the nuclear shell model of the atomic nucleus, Nobel Prize 1963

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

Re: [FFmpeg-devel] FFmpeg 3.1 name

[Gregory J Wolfe]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf Of Wang Bin
> Sent: Thursday, June 23, 2016 10:02 PM
> Subject: Re: [FFmpeg-devel] FFmpeg 3.1 name
> 
> What about choosing a scientist who was born in FFmpeg release
> month?

Don't want it to look like I'm trying to steal someone else's idea; I sent my 
suggestion in before I saw this reply.  GOOD IDEA!  See my later reply for 
suggestions!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/10] diracdsp: add SIMD for the 10 bit version of put_signed_rect_clamped

[James Almer]

On 6/24/2016 8:44 AM, Rostislav Pehlivanov wrote:
> From 86ecebfe70509329d6f5b8a587ae79d19f9c8154 Mon Sep 17 00:00:00 2001
> From: Rostislav Pehlivanov 
> Date: Thu, 23 Jun 2016 18:06:55 +0100
> Subject: [PATCH 1/2] diracdsp: add SIMD for the 10 bit version of
>  put_signed_rect_clamped
> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/x86/diracdsp.asm| 45 
> ++
>  libavcodec/x86/diracdsp_init.c | 10 ++
>  2 files changed, 55 insertions(+)
> 
> diff --git a/libavcodec/x86/diracdsp.asm b/libavcodec/x86/diracdsp.asm
> index a042413..a0d6788 100644
> --- a/libavcodec/x86/diracdsp.asm
> +++ b/libavcodec/x86/diracdsp.asm
> @@ -22,6 +22,8 @@
>  
>  SECTION_RODATA
>  pw_7: times 8 dw 7
> +convert_to_unsigned_10bit: times 4 dd 0x200
> +clip_10bit:times 8 dw 0x3ff
>  
>  cextern pw_3
>  cextern pw_16
> @@ -263,3 +265,46 @@ ADD_RECT sse2
>  HPEL_FILTER sse2
>  ADD_OBMC 32, sse2
>  ADD_OBMC 16, sse2
> +
> +%if ARCH_X86_64 == 1
> +INIT_XMM sse4
> +
> +; void put_signed_rect_clamped_10(uint8_t *dst, int dst_stride, const 
> uint8_t *src, int src_stride, int width, int height)
> +cglobal put_signed_rect_clamped_10, 6, 9, 6, dst, dst_stride, src, 
> src_stride, w, h
> +
> +mov  r6, srcq
> +mov  r7, dstq
> +mov  r8, wq
> +pxor m2, m2
> +mova m3, [clip_10bit]
> +mova m4, [convert_to_unsigned_10bit]
> +
> +.loop_h:
> +mov  srcq, r6
> +mov  dstq, r7
> +mov  wq,   r8
> +
> +.loop_w:
> +movu m0, [srcq+0*mmsize]
> +movu m1, [srcq+1*mmsize]
> +
> +padddm0, m4
> +padddm1, m4
> +packusdw m0, m0, m1
> +CLIPWm0, m2, m3 ; packusdw saturates so it's fine
> +
> +movu [dstq], m0
> +
> +add  srcq, 2*mmsize
> +add  dstq, 1*mmsize
> +sub  wq, 8
> +jl   .loop_w

Since you're substracting w now, this should be jump if greater.

Also, use wd, not wq, since it comes from stack on Win64. With msvc
x86_64 afaik there's no guarantee that the upper half of the register
is zeroed.

> +
> +add  r6, src_strideq
> +add  r7, dst_strideq
> +sub  hq, 1
> +jl   .loop_h

Ditto.

Alternatively as i said before is to just change the prototypes to
use ptrdiff_t instead of int.

> +
> +RET
> +
> +%endif
> diff --git a/libavcodec/x86/diracdsp_init.c b/libavcodec/x86/diracdsp_init.c
> index 5fae798..7fa554e 100644
> --- a/libavcodec/x86/diracdsp_init.c
> +++ b/libavcodec/x86/diracdsp_init.c
> @@ -46,6 +46,10 @@ void ff_put_rect_clamped_sse2(uint8_t *dst, int 
> dst_stride, const int16_t *src,
>  void ff_put_signed_rect_clamped_mmx(uint8_t *dst, int dst_stride, const 
> int16_t *src, int src_stride, int width, int height);
>  void ff_put_signed_rect_clamped_sse2(uint8_t *dst, int dst_stride, const 
> int16_t *src, int src_stride, int width, int height);
>  
> +#if ARCH_X86_64
> +void ff_put_signed_rect_clamped_10_sse4(uint8_t *dst, int dst_stride, const 
> uint8_t *src, int src_stride, int width, int height);
> +#endif
> +
>  #if HAVE_YASM
>  
>  #define HPEL_FILTER(MMSIZE, EXT) 
> \
> @@ -184,4 +188,10 @@ void ff_diracdsp_init_x86(DiracDSPContext* c)
>  c->put_dirac_pixels_tab[2][0] = ff_put_dirac_pixels32_sse2;
>  c->avg_dirac_pixels_tab[2][0] = ff_avg_dirac_pixels32_sse2;
>  }
> +
> +#if ARCH_X86_64
> +if (EXTERNAL_SSE4(mm_flags)) {
> +c->put_signed_rect_clamped[1] = ff_put_signed_rect_clamped_10_sse4;
> +}
> +#endif
>  }
> -- 

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

Re: [FFmpeg-devel] [PATCH 02/10] diracdsp: add dequantization SIMD

[James Almer]

On 6/24/2016 8:43 AM, Rostislav Pehlivanov wrote:
> From 154e4312b09f568108dd97089e394c10bb3c28a9 Mon Sep 17 00:00:00 2001
> From: Rostislav Pehlivanov 
> Date: Thu, 23 Jun 2016 18:06:56 +0100
> Subject: [PATCH 2/2] diracdsp: add dequantization SIMD
> 
> Currently unused, to be used in the following commits.
> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/diracdsp.c  | 24 
>  libavcodec/diracdsp.h  |  4 
>  libavcodec/x86/diracdsp.asm| 36 
>  libavcodec/x86/diracdsp_init.c |  2 ++
>  4 files changed, 66 insertions(+)
> 
> diff --git a/libavcodec/diracdsp.c b/libavcodec/diracdsp.c
> index ab8d149..cd1209e 100644
> --- a/libavcodec/diracdsp.c
> +++ b/libavcodec/diracdsp.c
> @@ -189,6 +189,27 @@ static void add_rect_clamped_c(uint8_t *dst, const 
> uint16_t *src, int stride,
>  }
>  }
>  
> +#define DEQUANT_SUBBAND(PX)  
>   \
> +static void dequant_subband_ ## PX ## _c(uint8_t *src, uint8_t *dst, 
> ptrdiff_t stride, \
> + const int qf, const int qs, int 
> tot_v, int tot_h) \
> +{
>   \
> +int i, y;
>   \
> +for (y = 0; y < tot_v; y++) {
>   \
> +PX c, sign, *src_r = (PX *)src, *dst_r = (PX *)dst;  
>   \
> +for (i = 0; i < tot_h; i++) {
>   \
> +c = *src_r++;
>   \
> +sign = FFSIGN(c)*(!!c);  
>   \
> +c = (FFABS(c)*qf + qs) >> 2; 
>   \
> +*dst_r++ = c*sign;   
>   \
> +}
>   \
> +src += tot_h << (sizeof(PX) >> 1);   
>   \
> +dst += stride;   
>   \
> +}
>   \
> +}
> +
> +DEQUANT_SUBBAND(int16_t)
> +DEQUANT_SUBBAND(int32_t)
> +
>  #define PIXFUNC(PFX, WIDTH) \
>  c->PFX ## _dirac_pixels_tab[WIDTH>>4][0] = ff_ ## PFX ## _dirac_pixels 
> ## WIDTH ## _c; \
>  c->PFX ## _dirac_pixels_tab[WIDTH>>4][1] = ff_ ## PFX ## _dirac_pixels 
> ## WIDTH ## _l2_c; \
> @@ -214,6 +235,9 @@ av_cold void ff_diracdsp_init(DiracDSPContext *c)
>  c->biweight_dirac_pixels_tab[1] = biweight_dirac_pixels16_c;
>  c->biweight_dirac_pixels_tab[2] = biweight_dirac_pixels32_c;
>  
> +c->dequant_subband[0] = c->dequant_subband[2] = 
> dequant_subband_int16_t_c;
> +c->dequant_subband[1] = c->dequant_subband[3] = 
> dequant_subband_int32_t_c;
> +
>  PIXFUNC(put, 8);
>  PIXFUNC(put, 16);
>  PIXFUNC(put, 32);
> diff --git a/libavcodec/diracdsp.h b/libavcodec/diracdsp.h
> index 25a872d..224828d 100644
> --- a/libavcodec/diracdsp.h
> +++ b/libavcodec/diracdsp.h
> @@ -22,6 +22,7 @@
>  #define AVCODEC_DIRACDSP_H
>  
>  #include 
> +#include 
>  
>  typedef void (*dirac_weight_func)(uint8_t *block, int stride, int 
> log2_denom, int weight, int h);
>  typedef void (*dirac_biweight_func)(uint8_t *dst, const uint8_t *src, int 
> stride, int log2_denom, int weightd, int weights, int h);
> @@ -46,6 +47,9 @@ typedef struct {
>  void (*add_rect_clamped)(uint8_t *dst/*align 16*/, const uint16_t 
> *src/*align 16*/, int stride, const int16_t *idwt/*align 16*/, int 
> idwt_stride, int width, int height/*mod 2*/);
>  void (*add_dirac_obmc[3])(uint16_t *dst, const uint8_t *src, int stride, 
> const uint8_t *obmc_weight, int yblen);
>  
> +/* 0-1: int16_t and int32_t asm/c, 2-3: int16 and int32_t, C only */
> +void (*dequant_subband[4])(uint8_t *src, uint8_t *dst, ptrdiff_t stride, 
> const int qf, const int qs, int tot_v, int tot_h);
> +
>  dirac_weight_func weight_dirac_pixels_tab[3];
>  dirac_biweight_func biweight_dirac_pixels_tab[3];
>  } DiracDSPContext;
> diff --git a/libavcodec/x86/diracdsp.asm b/libavcodec/x86/diracdsp.asm
> index a0d6788..a764706 100644
> --- a/libavcodec/x86/diracdsp.asm
> +++ b/libavcodec/x86/diracdsp.asm
> @@ -307,4 +307,40 @@ cglobal put_signed_rect_clamped_10, 6, 9, 6, dst, 
> dst_stride, src, src_stride, w
>  
>  RET
>  
> +; void dequant_subband_32(uint8_t *src, uint8_t *dst, ptrdiff_t stride, 
> const int qf, const int qs, int tot_v, int tot_h)
> +cglobal dequant_subband_32, 7, 9, 4, src, dst, stride, qf, qs, tot_v, tot_h
> +
> +movd   

[FFmpeg-devel] [GSoC] mid term evaluations reminder

[Michael Niedermayer]

Hi everyone

@students, dont forget to fill out the mid term eval !
@mentors, dont forget to fill out the mid term eval !

if either isnt filled out then the student is failed by google

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] FFmpeg 3.1 name

[Kyle Swanson]

On Thu, Jun 23, 2016 at 4:00 PM, Michael Niedermayer
 wrote:
> Hi all
>
> what shall FFmpeg 3.1 be called ?
>
> I still have these ideas from past suggestions:
> Von Neumann, Einstein, lorentz, poincaré, desitter, de broglie, Gauss, 
> Galois, Viterbi, Darwin
>
> Are there other suggestions?
> Is something preferred ?
>
> In absence of any preferrance ill pick something randomly
>
> Thanks
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No great genius has ever existed without some touch of madness. -- Aristotle
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Should probably be a mathematician since 3.1 is just about pi. There's
also been no FFmpeg version named after a woman. My suggestion is
`Hypatia.`[1]

[1] https://en.wikipedia.org/wiki/Hypatia

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

Re: [FFmpeg-devel] [PATCH] lavc/mediacodec: add hwaccel support

[Michael Niedermayer]

On Fri, Jun 24, 2016 at 11:17:41AM +0200, Matthieu Bouron wrote:
> On Thu, Apr 07, 2016 at 02:51:44PM +0200, Matthieu Bouron wrote:
> > On Wed, Mar 23, 2016 at 6:16 PM, Matthieu Bouron 
> > wrote:
> > 
> > >
> > >
> > > On Tue, Mar 22, 2016 at 10:04 AM, Matthieu Bouron <
> > > matthieu.bou...@gmail.com> wrote:
> > >
> > >>
> > >>
> > >> On Fri, Mar 18, 2016 at 5:50 PM, Matthieu Bouron <
> > >> matthieu.bou...@gmail.com> wrote:
> > >>
> > >>> From: Matthieu Bouron 
> > >>>
> > >>> ---
> > >>>
> > >>> Hello,
> > >>>
> > >>> The following patch add hwaccel support to the mediacodec (h264) decoder
> > >>> by allowing
> > >>> the user to render the output frames directly on a surface.
> > >>>
> > >>> In order to do so the user needs to initialize the hwaccel through the
> > >>> use of
> > >>> av_mediacodec_alloc_context and av_mediacodec_default_init functions.
> > >>> The later
> > >>> takes a reference to an android/view/Surface as parameter.
> > >>>
> > >>> If the hwaccel successfully initialize, the decoder output frames pix
> > >>> fmt will be
> > >>> AV_PIX_FMT_MEDIACODEC. The following snippet of code demonstrate how to
> > >>> render
> > >>> the frames on the surface:
> > >>>
> > >>> AVMediaCodecBuffer *buffer = (AVMediaCodecBuffer *)frame->data[3];
> > >>> av_mediacodec_release_buffer(buffer, 1);
> > >>>
> > >>> The last argument of av_mediacodec_release_buffer enable rendering of 
> > >>> the
> > >>> buffer on the surface (or not if set to 0).
> > >>>
> > >>> Regarding the internal changes in the mediacodec decoder:
> > >>>
> > >>> MediaCodec.flush() discards both input and output buffers meaning that 
> > >>> if
> > >>> MediaCodec.flush() is called all output buffers the user has a reference
> > >>> on are
> > >>> now invalid (and cannot be used).
> > >>> This behaviour does not fit well in the avcodec API.
> > >>>
> > >>> When the decoder is configured to output software buffers, there is no
> > >>> issue as
> > >>> the buffers are copied.
> > >>>
> > >>> Now when the decoder is configured to output to a surface, the user
> > >>> might not
> > >>> want to render all the frames as fast as the decoder can go and might
> > >>> want to
> > >>> control *when* the frame are rendered, so we need to make sure that the
> > >>> MediaCodec.flush() call is delayed until all the frames the user retains
> > >>> has
> > >>> been released or rendered.
> > >>>
> > >>> Delaying the call to MediaCodec.flush() means buffering any inputs that
> > >>> come
> > >>> the decoder until the user has released/renderer the frame he retains.
> > >>>
> > >>> This is a limitation of this hwaccel implementation, if the user retains
> > >>> a
> > >>> frame (a), then issue a flush command to the decoder, the packets he
> > >>> feeds to
> > >>> the decoder at that point will be queued in the internal decoder packet
> > >>> queue
> > >>> (until he releases the frame (a)). This scenario leads to a memory usage
> > >>> increase to say the least.
> > >>>
> > >>> Currently there is no limitation on the size of the internal decoder
> > >>> packet
> > >>> queue but this is something that can be added easily. Then, if the queue
> > >>> is
> > >>> full, what would be the behaviour of the decoder ? Can it block ? Or
> > >>> should it
> > >>> returns something like AVERROR(EAGAIN) ?
> > >>>
> > >>> About the other internal decoder changes I introduced:
> > >>>
> > >>> The MediaCodecDecContext is now refcounted (using the lavu/atomic api)
> > >>> since
> > >>> the (hwaccel) frames can be retained by the user, we need to delay the
> > >>> destruction of the codec until the user has released all the frames he
> > >>> has a
> > >>> reference on.
> > >>> The reference counter of the MediaCodecDecContext is incremented each
> > >>> time an
> > >>> (hwaccel) frame is outputted by the decoder and decremented each time a
> > >>> (hwaccel) frame is released.
> > >>>
> > >>> Also, when the decoder is configured to output to a surface the pts that
> > >>> are
> > >>> given to the MediaCodec API are now rescaled based on the codec_timebase
> > >>> as
> > >>> those timestamps values are propagated to the frames rendered on the
> > >>> surface
> > >>> since Android M. Not sure if it's really useful though.
> > >>>
> > >>> On the performance side:
> > >>>
> > >>> On a nexus 5, decoding an h264 stream (main profile) 1080p@60fps:
> > >>>   - software output + rgba conversion goes at 59~60fps
> > >>>   - surface output + render on a surface goes at 100~110fps
> > >>>
> > >>>
> > >> [...]
> > >>
> > >> Patch updated with the following differences:
> > >>   * the public mediacodec api is now always built (not only when
> > >> mediacodec is available) (and the build when mediacodec is not available
> > >> has been fixed)
> > >>   * the documentation of av_mediacodec_release_buffer has been improved a
> > >> bit
> > >>
> > >
> > > Patch updated with the following differences:
> > >   MediaCodecBuffer->released type is now a volatile int (instead of a 
> > > in

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

[Jens Ziller]

Hello,

deinterlacing need frame->interlaced_frame and format struct. This
patch added this to AVFrame.

Regards Jens.From 8a8961a4fab0da2bd98ef6cbfaf55462a00d3450 Mon Sep 17 00:00:00 2001
From: Jens Ziller 
Date: Fri, 24 Jun 2016 18:18:12 +0200
Subject: [PATCH] for deinterlacing needed

---
 libavcodec/mmaldec.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 099a8c5..b38a3bd 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -88,6 +88,7 @@ typedef struct MMALDecodeContext {
 int eos_received;
 int eos_sent;
 int extradata_sent;
+int interlaced_frame;
 } MMALDecodeContext;
 
 // Assume decoder is guaranteed to produce output after at least this many
@@ -274,6 +275,7 @@ static int ffmal_update_format(AVCodecContext *avctx)
 int ret = 0;
 MMAL_COMPONENT_T *decoder = ctx->decoder;
 MMAL_ES_FORMAT_T *format_out = decoder->output[0]->format;
+MMAL_PARAMETER_VIDEO_INTERLACE_TYPE_T interlace_type;
 
 ffmmal_poolref_unref(ctx->pool_out);
 if (!(ctx->pool_out = av_mallocz(sizeof(*ctx->pool_out {
@@ -300,6 +302,15 @@ static int ffmal_update_format(AVCodecContext *avctx)
 if ((status = mmal_port_format_commit(decoder->output[0])))
 goto fail;
 
+interlace_type.hdr.id = MMAL_PARAMETER_VIDEO_INTERLACE_TYPE;
+interlace_type.hdr.size = sizeof(MMAL_PARAMETER_VIDEO_INTERLACE_TYPE_T);
+status = mmal_port_parameter_get(decoder->output[0], &interlace_type.hdr);
+if (status != MMAL_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Cannot read MMAL interlace information!\n");
+} else {
+ctx->interlaced_frame = !(interlace_type.eMode == MMAL_InterlaceProgressive);
+}
+
 if ((ret = ff_set_dimensions(avctx, format_out->es->video.crop.x + format_out->es->video.crop.width,
 format_out->es->video.crop.y + format_out->es->video.crop.height)) < 0)
 goto fail;
@@ -609,8 +620,13 @@ static int ffmal_copy_frame(AVCodecContext *avctx,  AVFrame *frame,
 MMALDecodeContext *ctx = avctx->priv_data;
 int ret = 0;
 
+frame->interlaced_frame = ctx->interlaced_frame;
+
 if (avctx->pix_fmt == AV_PIX_FMT_MMAL) {
 if (!ctx->pool_out)
+// in data[2] give the format struct for configure deinterlacer and renderer
+frame->data[2] = ctx->decoder->output[0]->format;
+
 return AVERROR_UNKNOWN; // format change code failed with OOM previously
 
 if ((ret = ff_decode_frame_props(avctx, frame)) < 0)
-- 
2.7.3

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

[FFmpeg-devel] [PATCH] lavd/avfoundation: Fix skewed video output

[Rick Kern]

Fixes #5654.
The linesize can be greater than the minimum required. This copies the
frame taking linesize into account.

Signed-off-by: Rick Kern 
---
 libavdevice/avfoundation.m | 56 --
 1 file changed, 49 insertions(+), 7 deletions(-)

diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index e2ddf47..8b92308 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -35,6 +35,7 @@
 #include "libavutil/internal.h"
 #include "libavutil/parseutils.h"
 #include "libavutil/time.h"
+#include "libavutil/imgutils.h"
 #include "avdevice.h"
 
 static const int avf_time_base = 100;
@@ -892,6 +893,49 @@ fail:
 return AVERROR(EIO);
 }
 
+static int copy_cvpixelbuffer(AVFormatContext *s,
+   CVPixelBufferRef image_buffer,
+   AVPacket *pkt)
+{
+AVFContext *ctx = s->priv_data;
+int src_linesize[4];
+const uint8_t *src_data[4];
+int width  = CVPixelBufferGetWidth(image_buffer);
+int height = CVPixelBufferGetHeight(image_buffer);
+int status;
+
+memset(src_linesize, 0, sizeof(src_linesize));
+memset(src_data, 0, sizeof(src_data));
+
+status = CVPixelBufferLockBaseAddress(image_buffer, 0);
+if (status != kCVReturnSuccess) {
+av_log(s, AV_LOG_ERROR, "Could not lock base address: %d\n", status);
+return AVERROR_EXTERNAL;
+}
+
+if (CVPixelBufferIsPlanar(image_buffer)) {
+size_t plane_count = CVPixelBufferGetPlaneCount(image_buffer);
+int i;
+for(i = 0; i < plane_count; i++){
+src_linesize[i] = CVPixelBufferGetBytesPerRowOfPlane(image_buffer, 
i);
+src_data[i] = CVPixelBufferGetBaseAddressOfPlane(image_buffer, i);
+}
+} else {
+src_linesize[0] = CVPixelBufferGetBytesPerRow(image_buffer);
+src_data[0] = CVPixelBufferGetBaseAddress(image_buffer);
+}
+
+status = av_image_copy_to_buffer(pkt->data, pkt->size,
+ src_data, src_linesize,
+ ctx->pixel_format, width, height, 1);
+
+
+
+CVPixelBufferUnlockBaseAddress(image_buffer, 0);
+
+return status;
+}
+
 static int avf_read_packet(AVFormatContext *s, AVPacket *pkt)
 {
 AVFContext* ctx = (AVFContext*)s->priv_data;
@@ -903,7 +947,7 @@ static int avf_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 image_buffer = CMSampleBufferGetImageBuffer(ctx->current_frame);
 
 if (ctx->current_frame != nil) {
-void *data;
+int status;
 if (av_new_packet(pkt, 
(int)CVPixelBufferGetDataSize(image_buffer)) < 0) {
 return AVERROR(EIO);
 }
@@ -919,14 +963,12 @@ static int avf_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 pkt->stream_index  = ctx->video_stream_index;
 pkt->flags|= AV_PKT_FLAG_KEY;
 
-CVPixelBufferLockBaseAddress(image_buffer, 0);
-
-data = CVPixelBufferGetBaseAddress(image_buffer);
-memcpy(pkt->data, data, pkt->size);
-
-CVPixelBufferUnlockBaseAddress(image_buffer, 0);
+status = copy_cvpixelbuffer(s, image_buffer, pkt);
 CFRelease(ctx->current_frame);
 ctx->current_frame = nil;
+
+if (status < 0)
+return status;
 } else if (ctx->current_audio_frame != nil) {
 CMBlockBufferRef block_buffer = 
CMSampleBufferGetDataBuffer(ctx->current_audio_frame);
 int block_buffer_size = 
CMBlockBufferGetDataLength(block_buffer);
-- 
2.9.0

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

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

[Paul B Mahol]

Hi,

patch attached.
From 5b55c9c44ea103cdff3c34882dbcca29902728a4 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Fri, 24 Jun 2016 20:16:22 +0200
Subject: [PATCH] avfilter/vf_rotate: add >8 bit depth support

Signed-off-by: Paul B Mahol 
---
 libavfilter/vf_rotate.c  | 171 ++-
 tests/ref/fate/filter-pixfmts-rotate |  14 +++
 2 files changed, 123 insertions(+), 62 deletions(-)

diff --git a/libavfilter/vf_rotate.c b/libavfilter/vf_rotate.c
index 47dc01e..b37685a 100644
--- a/libavfilter/vf_rotate.c
+++ b/libavfilter/vf_rotate.c
@@ -60,7 +60,7 @@ enum var_name {
 VAR_VARS_NB
 };
 
-typedef struct {
+typedef struct RotContext {
 const AVClass *class;
 double angle;
 char *angle_expr_str;   ///< expression for the angle
@@ -77,6 +77,9 @@ typedef struct {
 double var_values[VAR_VARS_NB];
 FFDrawContext draw;
 FFDrawColor color;
+uint8_t *(*interpolate_bilinear)(uint8_t *dst_color,
+const uint8_t *src, int src_linesize, int src_linestep,
+int x, int y, int max_x, int max_y);
 } RotContext;
 
 typedef struct ThreadData {
@@ -142,6 +145,14 @@ static int query_formats(AVFilterContext *ctx)
 AV_PIX_FMT_YUV444P,  AV_PIX_FMT_YUVJ444P,
 AV_PIX_FMT_YUV420P,  AV_PIX_FMT_YUVJ420P,
 AV_PIX_FMT_YUVA444P, AV_PIX_FMT_YUVA420P,
+AV_PIX_FMT_YUV420P10LE, AV_PIX_FMT_YUVA420P10LE,
+AV_PIX_FMT_YUV444P10LE, AV_PIX_FMT_YUVA444P10LE,
+AV_PIX_FMT_YUV420P12LE,
+AV_PIX_FMT_YUV444P12LE,
+AV_PIX_FMT_YUV444P16LE, AV_PIX_FMT_YUVA444P16LE,
+AV_PIX_FMT_YUV420P16LE, AV_PIX_FMT_YUVA420P16LE,
+AV_PIX_FMT_YUV444P9LE, AV_PIX_FMT_YUVA444P9LE,
+AV_PIX_FMT_YUV420P9LE, AV_PIX_FMT_YUVA420P9LE,
 AV_PIX_FMT_NONE
 };
 
@@ -187,6 +198,93 @@ static const char * const func1_names[] = {
 NULL
 };
 
+#define FIXP (1<<16)
+#define FIXP2 (1<<20)
+#define INT_PI 3294199 //(M_PI * FIXP2)
+
+/**
+ * Compute the sin of a using integer values.
+ * Input is scaled by FIXP2 and output values are scaled by FIXP.
+ */
+static int64_t int_sin(int64_t a)
+{
+int64_t a2, res = 0;
+int i;
+if (a < 0) a = INT_PI-a; // 0..inf
+a %= 2 * INT_PI; // 0..2PI
+
+if (a >= INT_PI*3/2) a -= 2*INT_PI;  // -PI/2 .. 3PI/2
+if (a >= INT_PI/2  ) a = INT_PI - a; // -PI/2 ..  PI/2
+
+/* compute sin using Taylor series approximated to the fifth term */
+a2 = (a*a)/(FIXP2);
+for (i = 2; i < 11; i += 2) {
+res += a;
+a = -a*a2 / (FIXP2*i*(i+1));
+}
+return (res + 8)>>4;
+}
+
+/**
+ * Interpolate the color in src at position x and y using bilinear
+ * interpolation.
+ */
+static uint8_t *interpolate_bilinear8(uint8_t *dst_color,
+  const uint8_t *src, int src_linesize, int src_linestep,
+  int x, int y, int max_x, int max_y)
+{
+int int_x = av_clip(x>>16, 0, max_x);
+int int_y = av_clip(y>>16, 0, max_y);
+int frac_x = x&0x;
+int frac_y = y&0x;
+int i;
+int int_x1 = FFMIN(int_x+1, max_x);
+int int_y1 = FFMIN(int_y+1, max_y);
+
+for (i = 0; i < src_linestep; i++) {
+int s00 = src[src_linestep * int_x  + i + src_linesize * int_y ];
+int s01 = src[src_linestep * int_x1 + i + src_linesize * int_y ];
+int s10 = src[src_linestep * int_x  + i + src_linesize * int_y1];
+int s11 = src[src_linestep * int_x1 + i + src_linesize * int_y1];
+int s0 = (((1<<16) - frac_x)*s00 + frac_x*s01);
+int s1 = (((1<<16) - frac_x)*s10 + frac_x*s11);
+
+dst_color[i] = ((int64_t)((1<<16) - frac_y)*s0 + (int64_t)frac_y*s1) >> 32;
+}
+
+return dst_color;
+}
+
+/**
+ * Interpolate the color in src at position x and y using bilinear
+ * interpolation.
+ */
+static uint8_t *interpolate_bilinear16(uint8_t *dst_color,
+   const uint8_t *src, int src_linesize, int src_linestep,
+   int x, int y, int max_x, int max_y)
+{
+int int_x = av_clip(x>>16, 0, max_x);
+int int_y = av_clip(y>>16, 0, max_y);
+int frac_x = x&0x;
+int frac_y = y&0x;
+int i;
+int int_x1 = FFMIN(int_x+1, max_x);
+int int_y1 = FFMIN(int_y+1, max_y);
+
+for (i = 0; i < src_linestep; i+=2) {
+int s00 = AV_RL16(&src[src_linestep * int_x  + i + src_linesize * int_y ]);
+int s01 = AV_RL16(&src[src_linestep * int_x1 + i + src_linesize * int_y ]);
+int s10 = AV_RL16(&src[src_linestep * int_x  + i + src_linesize * int_y1]);
+int s11 = AV_RL16(&src[src_linestep * int_x1 + i + src_linesize * int_y1]);
+int s0 = (((1<<16) - frac_x)*s00 + frac_x*s01);
+int s1 = (((1<<16) - frac_x)*s10 + frac_x*s11);
+
+AV_WL16(&dst_color[i], ((int64_t)((1<<16) - frac_y)*s0 + (int64_t)frac_y*s1) >> 32);
+}
+
+return dst_color;
+}
+
 s

Re: [FFmpeg-devel] [PATCH] libopusenc: Add channel mapping family argument

[Michael Graczyk]

I fixed a comment typo and slightly modified an error message in the second
patch. I attached updated versions. Please let me know if you have any
thoughts on these patches.

On Mon, Jun 20, 2016 at 3:48 PM, Michael Graczyk 
wrote:

> Hello,
>
> I have fixed the problems Mark pointed out and attached new patches.
> I'll address Mark's comments inline.
>
>
> > This implies that -mapping_family -1 (the default) is the same as some
> > other -mapping_family 0..255, determined by the input, but it is not.
>
> I updated the doc to explain these differences.
>
>
> > This removes the restrictions on input channel layouts, allowing any
> > channel layout to be accepted.
>
> I added explicit checks in the new function
> libopus_check_vorbis_layout for this.
>
>
> > When channels <= 2, the mapping family will still be 0 even if
> -mapping_family 255 was explicitly specified.
>
> Thanks, fixed.
>
>
>
> > If there are more than 8 channels it appears that it will read beyond
> the end of the array.  If the input does not have a family 1 layout
> and mapping family 255 was specified, it will still remap the channels
> as if they had a family 1 layout.
>
> That's right, this was incorrect but now fixed. I only reorder the
> channels when necessary and I explicitly check that the input channel
> layout is the expected one.
>



-- 

Thanks,
Michael Graczyk
From ae55f62df04dd9585681cbd9f770d556cf4047ec Mon Sep 17 00:00:00 2001
From: Michael Graczyk 
Date: Tue, 14 Jun 2016 18:30:36 -0700
Subject: [PATCH 1/2] libopusenc: Refactor to simplify forthcoming
 mapping_family parameter

---
 libavcodec/libopusenc.c | 79 +++--
 1 file changed, 43 insertions(+), 36 deletions(-)

diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
index 3f3e80d..c9b96ce 100644
--- a/libavcodec/libopusenc.c
+++ b/libavcodec/libopusenc.c
@@ -79,6 +79,7 @@ static const uint8_t libavcodec_libopus_channel_map[8][8] = {
 
 static void libopus_write_header(AVCodecContext *avctx, int stream_count,
  int coupled_stream_count,
+ int mapping_family,
  const uint8_t *channel_mapping)
 {
 uint8_t *p   = avctx->extradata;
@@ -93,7 +94,7 @@ static void libopus_write_header(AVCodecContext *avctx, int stream_count,
 
 /* Channel mapping */
 if (channels > 2) {
-bytestream_put_byte(&p, channels <= 8 ? 1 : 255);
+bytestream_put_byte(&p, mapping_family);
 bytestream_put_byte(&p, stream_count);
 bytestream_put_byte(&p, coupled_stream_count);
 bytestream_put_buffer(&p, channel_mapping, channels);
@@ -159,37 +160,11 @@ static int libopus_configure_encoder(AVCodecContext *avctx, OpusMSEncoder *enc,
 static av_cold int libopus_encode_init(AVCodecContext *avctx)
 {
 LibopusEncContext *opus = avctx->priv_data;
-const uint8_t *channel_mapping;
 OpusMSEncoder *enc;
+uint8_t libopus_channel_mapping[255];
 int ret = OPUS_OK;
 int coupled_stream_count, header_size, frame_size;
 
-coupled_stream_count = opus_coupled_streams[avctx->channels - 1];
-opus->stream_count   = avctx->channels - coupled_stream_count;
-channel_mapping  = libavcodec_libopus_channel_map[avctx->channels - 1];
-
-/* FIXME: Opus can handle up to 255 channels. However, the mapping for
- * anything greater than 8 is undefined. */
-if (avctx->channels > 8) {
-av_log(avctx, AV_LOG_ERROR,
-   "Channel layout undefined for %d channels.\n", avctx->channels);
-return AVERROR_PATCHWELCOME;
-}
-if (!avctx->bit_rate) {
-/* Sane default copied from opusenc */
-avctx->bit_rate = 64000 * opus->stream_count +
-  32000 * coupled_stream_count;
-av_log(avctx, AV_LOG_WARNING,
-   "No bit rate set. Defaulting to %"PRId64" bps.\n", (int64_t)avctx->bit_rate);
-}
-
-if (avctx->bit_rate < 500 || avctx->bit_rate > 256000 * avctx->channels) {
-av_log(avctx, AV_LOG_ERROR, "The bit rate %"PRId64" bps is unsupported. "
-   "Please choose a value between 500 and %d.\n", (int64_t)avctx->bit_rate,
-   256000 * avctx->channels);
-return AVERROR(EINVAL);
-}
-
 frame_size = opus->opts.frame_duration * 48000 / 1000;
 switch (frame_size) {
 case 120:
@@ -251,17 +226,49 @@ static av_cold int libopus_encode_init(AVCodecContext *avctx)
 }
 }
 
-enc = opus_multistream_encoder_create(avctx->sample_rate, avctx->channels,
-  opus->stream_count,
-  coupled_stream_count,
-  channel_mapping,
-  opus->opts.application, &ret);
+/* FIXME: Opus can handle up to 255 channels. However, the mapping for
+ * anything greater than 8 is undefined. */
+if (avctx->channels > 8) {
+ 

[FFmpeg-devel] [PATCH 1/2] avfilter/dualinput: Add support to skip initial unpaired frames

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavfilter/dualinput.c |3 +++
 libavfilter/dualinput.h |1 +
 2 files changed, 4 insertions(+)

diff --git a/libavfilter/dualinput.c b/libavfilter/dualinput.c
index 1a078a2..4475097 100644
--- a/libavfilter/dualinput.c
+++ b/libavfilter/dualinput.c
@@ -66,6 +66,9 @@ int ff_dualinput_init(AVFilterContext *ctx, 
FFDualInputContext *s)
 in[1].after = EXT_NULL;
 in[1].sync  = 0;
 }
+if (s->skip_initial_unpaired) {
+in[1].before = EXT_STOP;
+}
 
 return ff_framesync_configure(&s->fs);
 }
diff --git a/libavfilter/dualinput.h b/libavfilter/dualinput.h
index 5ff23e6..42b2663 100644
--- a/libavfilter/dualinput.h
+++ b/libavfilter/dualinput.h
@@ -35,6 +35,7 @@ typedef struct {
 AVFrame *(*process)(AVFilterContext *ctx, AVFrame *main, const AVFrame 
*second);
 int shortest;   ///< terminate stream when the second input 
terminates
 int repeatlast; ///< repeat last second frame
+int skip_initial_unpaired;  ///< Skip initial frames that dont have a 2nd 
input
 } FFDualInputContext;
 
 int ff_dualinput_init(AVFilterContext *ctx, FFDualInputContext *s);
-- 
1.7.9.5

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

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

[Muhammad Faiz]

On Sat, Jun 25, 2016 at 1:23 AM, Paul B Mahol  wrote:
> Hi,
>
> patch attached.
>

>From 5b55c9c44ea103cdff3c34882dbcca29902728a4 Mon Sep 17 00:00:00 2001
>From: Paul B Mahol 
>Date: Fri, 24 Jun 2016 20:16:22 +0200
>Subject: [PATCH] avfilter/vf_rotate: add >8 bit depth support
>
>Signed-off-by: Paul B Mahol 
>---
> libavfilter/vf_rotate.c  | 171 ++-
> tests/ref/fate/filter-pixfmts-rotate |  14 +++
> 2 files changed, 123 insertions(+), 62 deletions(-)
>


>+AV_PIX_FMT_YUV420P10LE, AV_PIX_FMT_YUVA420P10LE,
>+AV_PIX_FMT_YUV444P10LE, AV_PIX_FMT_YUVA444P10LE,
>+AV_PIX_FMT_YUV420P12LE,
>+AV_PIX_FMT_YUV444P12LE,
>+AV_PIX_FMT_YUV444P16LE, AV_PIX_FMT_YUVA444P16LE,
>+AV_PIX_FMT_YUV420P16LE, AV_PIX_FMT_YUVA420P16LE,
>+AV_PIX_FMT_YUV444P9LE, AV_PIX_FMT_YUVA444P9LE,
>+AV_PIX_FMT_YUV420P9LE, AV_PIX_FMT_YUVA420P9LE,

Why not use native endian format?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avfilter/vf_paletteuse: enable skip_initial_unpaired

[Michael Niedermayer]

Fixes crash due to unprocessed input being passed through

This fixes the last segfault caused by mixing 3.0 and 3.1 libs and
applications

Signed-off-by: Michael Niedermayer 
---
 libavfilter/vf_paletteuse.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
index 1225a66..dece05a 100644
--- a/libavfilter/vf_paletteuse.c
+++ b/libavfilter/vf_paletteuse.c
@@ -1003,6 +1003,7 @@ static av_cold int init(AVFilterContext *ctx)
 {
 PaletteUseContext *s = ctx->priv;
 s->dinput.repeatlast = 1; // only 1 frame in the palette
+s->dinput.skip_initial_unpaired = 1;
 s->dinput.process= load_apply_palette;
 
 s->set_frame = set_frame_lut[s->color_search_method][s->dither];
-- 
1.7.9.5

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

Re: [FFmpeg-devel] FFmpeg 3.1 name

[Michael Niedermayer]

On Thu, Jun 23, 2016 at 11:00:48PM +0200, Michael Niedermayer wrote:
> Hi all
> 
> what shall FFmpeg 3.1 be called ?
> 
> I still have these ideas from past suggestions:
> Von Neumann, Einstein, lorentz, poincaré, desitter, de broglie, Gauss, 
> Galois, Viterbi, Darwin
> 
> Are there other suggestions?
> Is something preferred ?
> 
> In absence of any preferrance ill pick something randomly

Laplace (Rostislav, Bodecs)
Carl (Paul)
Lorentz (Bodecs)
fibonacci (Compn)
[list of people from june] (Gregory)
Hypatia (Kyle)

Laplace got suggested twice, everything else once
Thus the winner is Laplace

i intend to make the release tomorrow (saturday) from what is in git
master unless people want me to wait ?

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

Re: [FFmpeg-devel] [ppc] fix broken build when compiling libavcodec with LLVM on PPC backend

[Michael Niedermayer]

On Thu, Jun 23, 2016 at 04:36:46PM -0700, Jing Yu wrote:
> Hi,
> 
> This patch fixes a broken build when compiling libavcodec with LLVM
> compiler. These assembly files use non-standard format that is only
> supported by GCC compiler. It would be nice to use a common standard
> format. With this patch, both GCC and LLVM can build and generate the
> same objects.
> 
> Thanks for your review.
> 
> Jing

>  asm.S |2 +-
>  fft_altivec.S |   22 +++---
>  2 files changed, 12 insertions(+), 12 deletions(-)
> 9a8bd31cca05b51197387e7a1e244f3467e482ca  ffmpeg_ppc.patch
> diff --git a/libavcodec/ppc/asm.S b/libavcodec/ppc/asm.S

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

Re: [FFmpeg-devel] FFmpeg 3.1 name

[Amancio Hasty]

> On Jun 24, 2016, at 6:31 PM, Michael Niedermayer  
> wrote:
> 
> On Thu, Jun 23, 2016 at 11:00:48PM +0200, Michael Niedermayer wrote:
>> Hi all
>> 
>> what shall FFmpeg 3.1 be called ?
>> 
>> I still have these ideas from past suggestions:
>> Von Neumann, Einstein, lorentz, poincaré, desitter, de broglie, Gauss, 
>> Galois, Viterbi, Darwin
>> 
>> Are there other suggestions?
>> Is something preferred ?
>> 
>> In absence of any preferrance ill pick something randomly
> 
> Laplace (Rostislav, Bodecs)
> Carl (Paul)
> Lorentz (Bodecs)
> fibonacci (Compn)
> [list of people from june] (Gregory)
> Hypatia (Kyle)
> 
> Laplace got suggested twice, everything else once
> Thus the winner is Laplace
> 
> i intend to make the release tomorrow (saturday) from what is in git
> master unless people want me to wait ?
> 
> [...]
> 
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Those who would give up essential Liberty, to purchase a little
> temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Can we till Aman finishes his omx/h264 encoding?

Again lots of people in the RPI commute are waiting for this and
it looks like the finishing touch does not required much work…


Amancio

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

[FFmpeg-devel] [PATCH v2] lavd/decklink_common: Fix error caused by -Werror=missing-prototypes

[Rick Kern]

decklink_common.cpp includes a .cpp file from the DeckLink API which fails
to build because there are non-static functions in the included .cpp file.
This disables the missing-prototypes error so the file can be included.

Signed-off-by: Rick Kern 
---
 configure | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 3787894..9068d6c 100755
--- a/configure
+++ b/configure
@@ -5615,7 +5615,8 @@ enabled cuvid && { check_lib cuviddec.h 
cuvidCreateDecoder -lnvcuvid
 enabled chromaprint   && require chromaprint chromaprint.h 
chromaprint_get_version -lchromaprint
 enabled coreimage_filter  && { check_header_objcc QuartzCore/CoreImage.h || 
disable coreimage_filter; }
 enabled coreimagesrc_filter && { check_header_objcc QuartzCore/CoreImage.h || 
disable coreimagesrc_filter; }
-enabled decklink  && { check_header DeckLinkAPI.h || die "ERROR: 
DeckLinkAPI.h header not found"; }
+enabled decklink  && { { check_header DeckLinkAPI.h || die "ERROR: 
DeckLinkAPI.h header not found"; } &&
+ add_cxxflags -Wno-error=missing-prototypes; }
 enabled frei0r&& { check_header frei0r.h || die "ERROR: frei0r.h 
header not found"; }
 enabled gmp   && require2 gmp gmp.h mpz_export -lgmp
 enabled gnutls&& require_pkg_config gnutls gnutls/gnutls.h 
gnutls_global_init
-- 
2.9.0

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

Re: [FFmpeg-devel] FFmpeg 3.1 name

[James Almer]

On 6/24/2016 10:31 PM, Michael Niedermayer wrote:
> On Thu, Jun 23, 2016 at 11:00:48PM +0200, Michael Niedermayer wrote:
>> Hi all
>>
>> what shall FFmpeg 3.1 be called ?
>>
>> I still have these ideas from past suggestions:
>> Von Neumann, Einstein, lorentz, poincaré, desitter, de broglie, Gauss, 
>> Galois, Viterbi, Darwin
>>
>> Are there other suggestions?
>> Is something preferred ?
>>
>> In absence of any preferrance ill pick something randomly
> 
> Laplace (Rostislav, Bodecs)
> Carl (Paul)
> Lorentz (Bodecs)
> fibonacci (Compn)
> [list of people from june] (Gregory)
> Hypatia (Kyle)
> 
> Laplace got suggested twice, everything else once
> Thus the winner is Laplace
> 
> i intend to make the release tomorrow (saturday) from what is in git
> master unless people want me to wait ?

Rodger Combs still hasn't pushed his auto-bsf patchset.
IMO at least a part of it should be applied for 3.1 to get rid of the
memleak.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.1 name

[Michael Niedermayer]

On Fri, Jun 24, 2016 at 06:52:01PM -0700, Amancio Hasty wrote:
> 
> > On Jun 24, 2016, at 6:31 PM, Michael Niedermayer  
> > wrote:
> > 
> > On Thu, Jun 23, 2016 at 11:00:48PM +0200, Michael Niedermayer wrote:
> >> Hi all
> >> 
> >> what shall FFmpeg 3.1 be called ?
> >> 
> >> I still have these ideas from past suggestions:
> >> Von Neumann, Einstein, lorentz, poincaré, desitter, de broglie, Gauss, 
> >> Galois, Viterbi, Darwin
> >> 
> >> Are there other suggestions?
> >> Is something preferred ?
> >> 
> >> In absence of any preferrance ill pick something randomly
> > 
> > Laplace (Rostislav, Bodecs)
> > Carl (Paul)
> > Lorentz (Bodecs)
> > fibonacci (Compn)
> > [list of people from june] (Gregory)
> > Hypatia (Kyle)
> > 
> > Laplace got suggested twice, everything else once
> > Thus the winner is Laplace
> > 
> > i intend to make the release tomorrow (saturday) from what is in git
> > master unless people want me to wait ?
> > 
> > [...]
> > 
> > -- 
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> > 
> > Those who would give up essential Liberty, to purchase a little
> > temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> Can we till Aman finishes his omx/h264 encoding?
> 
> Again lots of people in the RPI commute are waiting for this and
> it looks like the finishing touch does not required much work…

we are 1 month behind shedule
we make releases once about every 3 months

There is always a feature that will be finished next week or next
3 days. If you always wait you never release.

Also you didnt mention any timeframe for when this will be in git
master

do you think its really better if we delay the release and maybe in
2 weeks have 5 new regressions that rewuire us to wait another
month to get them fixed and then theres anoter big feature that comes
the week after it and so on.
IMHO better release now, and release soon again.

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

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


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

Re: [FFmpeg-devel] FFmpeg 3.1 name

[Michael Niedermayer]

On Fri, Jun 24, 2016 at 11:12:05PM -0300, James Almer wrote:
> On 6/24/2016 10:31 PM, Michael Niedermayer wrote:
> > On Thu, Jun 23, 2016 at 11:00:48PM +0200, Michael Niedermayer wrote:
> >> Hi all
> >>
> >> what shall FFmpeg 3.1 be called ?
> >>
> >> I still have these ideas from past suggestions:
> >> Von Neumann, Einstein, lorentz, poincaré, desitter, de broglie, Gauss, 
> >> Galois, Viterbi, Darwin
> >>
> >> Are there other suggestions?
> >> Is something preferred ?
> >>
> >> In absence of any preferrance ill pick something randomly
> > 
> > Laplace (Rostislav, Bodecs)
> > Carl (Paul)
> > Lorentz (Bodecs)
> > fibonacci (Compn)
> > [list of people from june] (Gregory)
> > Hypatia (Kyle)
> > 
> > Laplace got suggested twice, everything else once
> > Thus the winner is Laplace
> > 
> > i intend to make the release tomorrow (saturday) from what is in git
> > master unless people want me to wait ?
> 

> Rodger Combs still hasn't pushed his auto-bsf patchset.
> IMO at least a part of it should be applied for 3.1 to get rid of the
> memleak.

I agree, that shouldnt really cause any delay anyway ...
can someone please apply what should be applied from it.

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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

Re: [FFmpeg-devel] FFmpeg 3.1 name

[Amancio Hasty]

> On Jun 24, 2016, at 7:39 PM, Michael Niedermayer  
> wrote:
> 
> On Fri, Jun 24, 2016 at 06:52:01PM -0700, Amancio Hasty wrote:
>> 
>>> On Jun 24, 2016, at 6:31 PM, Michael Niedermayer  
>>> wrote:
>>> 
>>> On Thu, Jun 23, 2016 at 11:00:48PM +0200, Michael Niedermayer wrote:
 Hi all
 
 what shall FFmpeg 3.1 be called ?
 
 I still have these ideas from past suggestions:
 Von Neumann, Einstein, lorentz, poincaré, desitter, de broglie, Gauss, 
 Galois, Viterbi, Darwin
 
 Are there other suggestions?
 Is something preferred ?
 
 In absence of any preferrance ill pick something randomly
>>> 
>>> Laplace (Rostislav, Bodecs)
>>> Carl (Paul)
>>> Lorentz (Bodecs)
>>> fibonacci (Compn)
>>> [list of people from june] (Gregory)
>>> Hypatia (Kyle)
>>> 
>>> Laplace got suggested twice, everything else once
>>> Thus the winner is Laplace
>>> 
>>> i intend to make the release tomorrow (saturday) from what is in git
>>> master unless people want me to wait ?
>>> 
>>> [...]
>>> 
>>> -- 
>>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>> 
>>> Those who would give up essential Liberty, to purchase a little
>>> temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> Can we till Aman finishes his omx/h264 encoding?
>> 
>> Again lots of people in the RPI commute are waiting for this and
>> it looks like the finishing touch does not required much work…
> 
> we are 1 month behind shedule
> we make releases once about every 3 months
> 
> There is always a feature that will be finished next week or next
> 3 days. If you always wait you never release.
> 
> Also you didnt mention any timeframe for when this will be in git
> master
> 
> do you think its really better if we delay the release and maybe in
> 2 weeks have 5 new regressions that rewuire us to wait another
> month to get them fixed and then theres anoter big feature that comes
> the week after it and so on.
> IMHO better release now, and release soon again.
> 
> [...]
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Dictatorship: All citizens are under surveillance, all their steps and
> actions recorded, for the politicians to enforce control.
> Democracy: All politicians are under surveillance, all their steps and
> actions recorded, for the citizens to enforce control.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org 
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel 
> 
It really depends on your intent and what do you wish to provide with
your release. We will have to wait till Aman tells us what is his next step.

With respect to RPI it has been over 2 years people have been waiting
for hardware assist h264 encoding…

Cheers
Amancio


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