Re: [FFmpeg-devel] [PATCH v6 1/6] libavcodec: VAAPI support infrastructure

[wm4]

On Mon, 8 Feb 2016 13:56:57 +
Mark Thompson  wrote:

> ...
> >> +/** Map a surface so that it can be operated on by the CPU.
> >> + *
> >> + * This may need to copy the frame data between some sort of external 
> >> memory
> >> + * and normal CPU-addressable memory.  The copy-in will only take place if
> >> + * read access was requested.
> >> + *
> >> + * @param frame AVFrame to map.  Must have been allocated in an
> >> + * @ref AVVAAPISurfacePool
> >> + * @param flags A set of AV_VAAPI_MAP flags, ored together.
> >> + * @return Zero on success, or negative error code.
> >> + */
> >> +int av_vaapi_map_frame(AVFrame *frame, int flags);  
> >
> > I know I've stared at the implementation for this in the few previous
> > patch iterations, but just looking at this it's not clear to me at all
> > what the input and output is.
> >
> > So the input is a PIX_FMT_VAAPI AVFrame. And on output, this is
> > replaced with a "software" AVFrame or what? What happens on unmap? Is
> > it magically undone? What happens with the vaapi frame reference?
> >
> > Maybe it would be better to add a separate AVFrame argument, into which
> > the surface is mapped.  
> 
> This function is the lowest level mapping for people who know exactly what 
> they 
> are doing (especially wrt memory types).  The input is the AV_PIX_FMT_VAAPI 
> AVFrame with buf[0,1] giving the mapping to a surface.  The output is the 
> same 
> frame with data[0,1,2] and linesize[0,1,2] filled in to use, but nothing else 
> about the frame changed.  Unmap removes the mapping along with the data and 
> linesize values.  I'll clarify how it works in the comment.

Still questionable. What if a mapped AVFrame requires all 4 planes?
Then data[3] would be overwritten, even though it normally contains the
surface ID.

> If you think there should be a pair of functions mapping/unmapping to/from a 
> distinct AVFrame (which would call these two) then I would prefer to add that 
> separately.

I'd say so.

> >> +
> >> +/** Unmap a surface after operating on it with the CPU.
> >> + *
> >> + * If the frame data was copied and write access was requested, this will 
> >> copy
> >> + * back to external memory.
> >> + */
> >> +int av_vaapi_unmap_frame(AVFrame *frame);
> >> +
> >> +/** Copy data from memory to a surface.
> >> + *
> >> + * The size and format of the source must match the underlying format of 
> >> the
> >> + * surface.
> >> + */
> >> +int av_vaapi_copy_to_surface(AVFrame *dst, const AVFrame *src);
> >> +
> >> +/** Copy data from a surface to memory.
> >> + *
> >> + * The size and format of the destination must match the underlying 
> >> format of
> >> + * the surface.
> >> + */
> >> +int av_vaapi_copy_from_surface(AVFrame *dst, AVFrame *src);
> >> +
> >> +
> >> +/** Given a libva fourcc, return the corresponding pixel format. */
> >> +enum AVPixelFormat av_vaapi_pix_fmt(unsigned int fourcc);
> >> +/** Given a pixel format, return the corresponding libva fourcc. */
> >> +unsigned int av_vaapi_fourcc(enum AVPixelFormat pix_fmt);
> >> +/** Given a libva fourcc, return the associated pipeline chroma format. */
> >> +unsigned int av_vaapi_rt_format(unsigned int fourcc);
> >> +
> >> +/** Given a pixel format, return the corresponding libva image format.
> >> + *
> >> + * This uses vaQueryImageFormats(), so results need not be exactly 
> >> equivalent
> >> + * between different drivers.
> >> + */
> >> +int av_vaapi_get_image_format(AVVAAPIHardwareContext *hw_ctx,
> >> +  enum AVPixelFormat pix_fmt,
> >> +  VAImageFormat *image_format);
> >> +
> >> +/** @} */
> >> +
> >> +#endif /* AVCODEC_VAAPI_SUPPORT_H */  
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter: add BobWeaver deinterlacing filter

[Thomas Mundt]

I forgot one information:
With yadif and w3fdif the temporal interpolation of the first and last field of 
a source file tend to result in heavy artefacts at fast motions. Therefore 
BobWeaver uses spatial cubic interpolation at first and last field.
That´s the filter_intra function.
I attached the same version of the patch. But this time as git format patch.


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

Re: [FFmpeg-devel] [PATCH] Check av_dup_packet() return code

[Michael Niedermayer]

On Mon, Feb 08, 2016 at 12:46:11PM +0100, wm4 wrote:
> On Mon, 8 Feb 2016 00:33:15 +0100
> Michael Niedermayer  wrote:
> 
> > On Wed, Feb 03, 2016 at 11:27:00PM +0100, Andreas Cadhalpun wrote:
> > > On 03.02.2016 19:05, Michael Niedermayer wrote:  
> > > > Fixes: CID1338320
> > > > 
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >  libavcodec/frame_thread_encoder.c |4 +++-
> > > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/libavcodec/frame_thread_encoder.c 
> > > > b/libavcodec/frame_thread_encoder.c
> > > > index 04c9a0e..27ae356 100644
> > > > --- a/libavcodec/frame_thread_encoder.c
> > > > +++ b/libavcodec/frame_thread_encoder.c
> > > > @@ -89,7 +89,9 @@ static void * attribute_align_arg worker(void *v){
> > > >  pthread_mutex_unlock(>buffer_mutex);
> > > >  av_frame_free();
> > > >  if(got_packet) {
> > > > -av_dup_packet(pkt);
> > > > +int ret2 = av_dup_packet(pkt);
> > > > +if (ret >= 0 && ret2 < 0)
> > > > +ret = ret2;
> > > >  } else {
> > > >  pkt->data = NULL;
> > > >  pkt->size = 0;
> > > >   
> > > 
> > > Checking the return code this way is probably OK, but maybe you can also 
> > > replace the
> > > deprecated av_dup_packet with av_packet_ref while at it?  
> > 
> > what exactly do you suggest ?
> > 
> > av_packet_ref() creates a reference, av_dup_packet() turns "reusable"
> > packets into ref counted ones
> > av_dup_packet() does nothing if the packet is already a ref counted
> > one.
> > 
> > i can not see a efficient and clean way to replace av_dup_packet()
> > by av_packet_ref()
> > 
> > if its ref counted already nothing needs to be done, if its not
> > ref counted i would have to litterally reimplement av_dup_packet()
> > and i dont even have a testcase for that, all cases seem to return
> > ref counted packets
> > 
> > i can remove av_dup_packet and put an assert there assuming that
> > all packets will always be already ref counted (this might be true
> > currently, i dont know, i also dont know if we always want this to
> > be true in the future)
> > 
> > I dont really want to always run av_packet_ref() over it just to
> > unref it in the next line, which probably would work too
> > 
> > [...]
> 
> It's deprecated?

av_dup_packet() has been marked as deprecated, yes, the function or a
equivalent is needed though for efficicent support of non ref counted
packets.
Because what it does is exactly that it ensures that the packet
after the call is ref counted

iam happy with any solution the community likes

av_dup_packet() can be undeprecated or aded back under a different name

support for non reference counted packets can be removed (with the
obvious consequence that its then not supported anymore)

a redundant reference can always be added (this feels silly though as
it performs operations which take cpu time& thread sync when they are
entirely unneeded)

something else, there likely is some other option ...


[...]
-- 
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] [PATCH] avfilter: add BobWeaver deinterlacing filter

[Hendrik Leppkes]

On Mon, Feb 8, 2016 at 12:24 PM, Thomas Mundt
 wrote:
> I forgot one information:
> With yadif and w3fdif the temporal interpolation of the first and last field 
> of a source file tend to result in heavy artefacts at fast motions. Therefore 
> BobWeaver uses spatial cubic interpolation at first and last field.
> That´s the filter_intra function.
> I attached the same version of the patch. But this time as git format patch.
>

How does the speed compare to YADIF?
Or in other words, is it usable in real-time, or rather designed for
offline processing?

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

Re: [FFmpeg-devel] [PATCH] Check av_dup_packet() return code

[wm4]

On Mon, 8 Feb 2016 00:33:15 +0100
Michael Niedermayer  wrote:

> On Wed, Feb 03, 2016 at 11:27:00PM +0100, Andreas Cadhalpun wrote:
> > On 03.02.2016 19:05, Michael Niedermayer wrote:  
> > > Fixes: CID1338320
> > > 
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavcodec/frame_thread_encoder.c |4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/libavcodec/frame_thread_encoder.c 
> > > b/libavcodec/frame_thread_encoder.c
> > > index 04c9a0e..27ae356 100644
> > > --- a/libavcodec/frame_thread_encoder.c
> > > +++ b/libavcodec/frame_thread_encoder.c
> > > @@ -89,7 +89,9 @@ static void * attribute_align_arg worker(void *v){
> > >  pthread_mutex_unlock(>buffer_mutex);
> > >  av_frame_free();
> > >  if(got_packet) {
> > > -av_dup_packet(pkt);
> > > +int ret2 = av_dup_packet(pkt);
> > > +if (ret >= 0 && ret2 < 0)
> > > +ret = ret2;
> > >  } else {
> > >  pkt->data = NULL;
> > >  pkt->size = 0;
> > >   
> > 
> > Checking the return code this way is probably OK, but maybe you can also 
> > replace the
> > deprecated av_dup_packet with av_packet_ref while at it?  
> 
> what exactly do you suggest ?
> 
> av_packet_ref() creates a reference, av_dup_packet() turns "reusable"
> packets into ref counted ones
> av_dup_packet() does nothing if the packet is already a ref counted
> one.
> 
> i can not see a efficient and clean way to replace av_dup_packet()
> by av_packet_ref()
> 
> if its ref counted already nothing needs to be done, if its not
> ref counted i would have to litterally reimplement av_dup_packet()
> and i dont even have a testcase for that, all cases seem to return
> ref counted packets
> 
> i can remove av_dup_packet and put an assert there assuming that
> all packets will always be already ref counted (this might be true
> currently, i dont know, i also dont know if we always want this to
> be true in the future)
> 
> I dont really want to always run av_packet_ref() over it just to
> unref it in the next line, which probably would work too
> 
> [...]

It's deprecated?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/dnxhddec added support for raw 444 and dnxhr formats

[Christophe Gisquet]

Hi,

2016-02-08 8:15 GMT+01:00 Christophe Gisquet :
> At this point, I'd say the encoder would better use that prefix.
> That's what the attached patch does (rebased but not tested). You may
> consider building on top of it for that purpose.

Which I haven't attached... So here's one /not/ rebased, but that
should provide the same information, should that interest you.

BR,
-- 
Christophe
From 89e2da58de95af055b16c513de746a0cb64dd33c Mon Sep 17 00:00:00 2001
From: Christophe Gisquet 
Date: Fri, 2 Oct 2015 10:38:22 +0200
Subject: [PATCH 2/7] dnxhd: add and use header version

This makes it somewhat easier to extend and cleaner. The DNxHR
versions are not very well defined for lack of specs.

This also allows writing the correct header for CIDs 1256 to 1260.
---
 libavcodec/dnxhddata.c | 45 ++---
 libavcodec/dnxhddata.h | 13 +
 libavcodec/dnxhddec.c  | 16 +---
 libavcodec/dnxhdenc.c  |  3 +--
 4 files changed, 49 insertions(+), 28 deletions(-)

diff --git a/libavcodec/dnxhddata.c b/libavcodec/dnxhddata.c
index 82fbfdf..a1b452d 100644
--- a/libavcodec/dnxhddata.c
+++ b/libavcodec/dnxhddata.c
@@ -23,6 +23,13 @@
 #include "dnxhddata.h"
 #include "libavutil/common.h"
 
+const uint8_t ff_dnxhd_headers[DNXHD_HEADER_VERSIONS][5] = {
+{ 0x00, 0x00, 0x02, 0x80, 0x01 },
+{ 0x00, 0x00, 0x02, 0x80, 0x02 },
+{ 0x00, 0x00, 0x02, 0x80, 0x03 },
+{ 0x00, 0x00, 0x03, 0x8C, 0x03 },
+};
+
 /* The quantization tables below are in zigzag order! */
 
 /* Used in CID 1235, 1256, 1270 */
@@ -932,7 +939,7 @@ static const uint8_t dnxhd_1250_run[62] = {
 
 const CIDEntry ff_dnxhd_cid_table[] = {
 { 1235, 1920, 1080, 917504, 917504,
-  0, 6, 10, 4,
+  DNXHD_HEADER_INITIAL, 0, 6, 10, 4,
   dnxhd_1235_luma_weight, dnxhd_1235_chroma_weight,
   dnxhd_1235_dc_codes, dnxhd_1235_dc_bits,
   dnxhd_1235_ac_codes, dnxhd_1235_ac_bits, dnxhd_1235_ac_info,
@@ -940,7 +947,7 @@ const CIDEntry ff_dnxhd_cid_table[] = {
   { 175, 185, 365, 440 },
   { { 24000, 1001 }, { 25, 1 }, { 50, 1 }, { 6, 1001 } } },
 { 1237, 1920, 1080, 606208, 606208,
-  0, 4, 8, 3,
+  DNXHD_HEADER_INITIAL, 0, 4, 8, 3,
   dnxhd_1237_luma_weight, dnxhd_1237_chroma_weight,
   dnxhd_1237_dc_codes, dnxhd_1237_dc_bits,
   dnxhd_1237_ac_codes, dnxhd_1237_ac_bits, dnxhd_1237_ac_info,
@@ -948,7 +955,7 @@ const CIDEntry ff_dnxhd_cid_table[] = {
   { 115, 120, 145, 240, 290 },
   { { 24000, 1001 }, { 25, 1 }, { 3, 1001 }, { 50, 1 }, { 6, 1001 } } },
 { 1238, 1920, 1080, 917504, 917504,
-  0, 4, 8, 4,
+  DNXHD_HEADER_INITIAL, 0, 4, 8, 4,
   dnxhd_1238_luma_weight, dnxhd_1238_chroma_weight,
   dnxhd_1237_dc_codes, dnxhd_1237_dc_bits,
   dnxhd_1238_ac_codes, dnxhd_1238_ac_bits, dnxhd_1238_ac_info,
@@ -956,7 +963,7 @@ const CIDEntry ff_dnxhd_cid_table[] = {
   { 175, 185, 220, 365, 440 },
   { { 24000, 1001 }, { 25, 1 }, { 3, 1001 }, { 50, 1 }, { 6, 1001 } } },
 { 1241, 1920, 1080, 917504, 458752,
-  DNXHD_INTERLACED, 6, 10, 4,
+  DNXHD_HEADER_INITIAL, DNXHD_INTERLACED, 6, 10, 4,
   dnxhd_1241_luma_weight, dnxhd_1241_chroma_weight,
   dnxhd_1235_dc_codes, dnxhd_1235_dc_bits,
   dnxhd_1235_ac_codes, dnxhd_1235_ac_bits, dnxhd_1235_ac_info,
@@ -964,7 +971,7 @@ const CIDEntry ff_dnxhd_cid_table[] = {
   { 185, 220 },
   { { 25, 1 }, { 3, 1001 } } },
 { 1242, 1920, 1080, 606208, 303104,
-  DNXHD_INTERLACED, 4, 8, 3,
+  DNXHD_HEADER_INITIAL, DNXHD_INTERLACED, 4, 8, 3,
   dnxhd_1242_luma_weight, dnxhd_1242_chroma_weight,
   dnxhd_1237_dc_codes, dnxhd_1237_dc_bits,
   dnxhd_1237_ac_codes, dnxhd_1237_ac_bits, dnxhd_1237_ac_info,
@@ -972,7 +979,7 @@ const CIDEntry ff_dnxhd_cid_table[] = {
   { 120, 145 },
   { { 25, 1 }, { 3, 1001 } } },
 { 1243, 1920, 1080, 917504, 458752,
-  DNXHD_INTERLACED, 4, 8, 4,
+  DNXHD_HEADER_INITIAL, DNXHD_INTERLACED, 4, 8, 4,
   dnxhd_1243_luma_weight, dnxhd_1243_chroma_weight,
   dnxhd_1237_dc_codes, dnxhd_1237_dc_bits,
   dnxhd_1238_ac_codes, dnxhd_1238_ac_bits, dnxhd_1238_ac_info,
@@ -980,7 +987,7 @@ const CIDEntry ff_dnxhd_cid_table[] = {
   { 185, 220 },
   { { 25, 1 }, { 3, 1001 } } },
 { 1250, 1280,  720, 458752, 458752,
-  0, 6, 10, 4,
+  DNXHD_HEADER_INITIAL, 0, 6, 10, 4,
   dnxhd_1250_luma_weight, dnxhd_1250_chroma_weight,
   dnxhd_1235_dc_codes, dnxhd_1235_dc_bits,
   dnxhd_1250_ac_codes, dnxhd_1250_ac_bits, dnxhd_1250_ac_info,
@@ -988,7 +995,7 @@ const CIDEntry ff_dnxhd_cid_table[] = {
   { 90, 90, 180, 220 },
   { { 24000, 1001 }, { 25, 1 }, { 50, 1 }, { 6, 1001 } } },
 { 1251, 1280,  720, 458752, 458752,
-  0, 4, 8, 4,
+  DNXHD_HEADER_INITIAL, 0, 4, 8, 4,
   dnxhd_1251_luma_weight, dnxhd_1251_chroma_weight,
   dnxhd_1237_dc_codes, 

Re: [FFmpeg-devel] [PATCH v6 0/6] VAAPI support infrastructure

[wm4]

On Sun, 7 Feb 2016 21:51:23 +
Mark Thompson  wrote:

> Hi all,
> 
> More VAAPI following.  This is only parts one and two (infrastructure), the 
> other parts have not changed beyond what is needed to support changes to 
> these two.
> 
> 
> Changes:
> 
> * Made some more structures user-opaque, added allocation functions for them. 
>  Log classes around them also more consistent.
> 
> * Surface mapping can now explicitly request direct access, and if possible 
> will get it by default for write-only mapping.
> 
> * Documentation (doxygen) added for all public interfaces.
> 
> * Format handling is improved; the surface configuration can now make RGB 
> surfaces correctly.  (User visibility of RT_FORMAT is removed.)
> 
> 
> Outstanding:
> 
> * Interaction (or not) with other patches.

I asked when the Libav patches are going to land:

 evilril: do you intend to apply the hwctx patches any time soon?
 within a week or two ideally, depending on whether i get any new 
reviews
 i'm planning to send a new set today or tomorrow

> 
> * There is still no way to get a hardware context through the filter graph.

The Libav idea is probably good enough.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/dnxhddec added support for raw 444 and dnxhr

[Michael Niedermayer]

On Sun, Feb 07, 2016 at 05:31:40PM -0800, Mark Reid wrote:
> Hi,
> This patch enable demuxing of raw 444 and dnxhr streams.

> To generate a raw stream of dnxhr (since there is no encoder support yet)
> ffmpeg -i fate-suite/dnxhd/dnxhr444_cid1270.mov -an -vcodec copy out.dnxhd
> ffplay out.dnxhd

this looks a bit like adding a fate test would be easy.
If so, please add a fate test for this

[...]
-- 
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] [PATCH v6 1/6] libavcodec: VAAPI support infrastructure

[wm4]

On Sun, 7 Feb 2016 21:53:39 +
Mark Thompson  wrote:

> ---
>  configure  |   5 +
>  libavcodec/Makefile|   1 +
>  libavcodec/vaapi_support.c | 852 
> +
>  libavcodec/vaapi_support.h | 284 +++
>  4 files changed, 1142 insertions(+)
>  create mode 100644 libavcodec/vaapi_support.c
>  create mode 100644 libavcodec/vaapi_support.h
> 
> diff --git a/configure b/configure
> index 1000cb1..0880569 100755
> --- a/configure
> +++ b/configure
> @@ -2037,6 +2037,7 @@ CONFIG_EXTRA="
>  texturedsp
>  texturedspenc
>  tpeldsp
> +vaapi_recent
>  videodsp
>  vp3dsp
>  vp56dsp
> @@ -5770,6 +5771,10 @@ enabled vaapi &&
>  check_lib va/va.h vaInitialize -lva ||
>  disable vaapi
> 
> +enabled vaapi &&
> +check_code cc va/va.h "vaCreateSurfaces(0, 0, 0, 0, 0, 0, 0, 0)" &&
> +enable vaapi_recent
> +
>  enabled vaapi && enabled xlib &&
>  check_lib2 "va/va.h va/va_x11.h" vaGetDisplay -lva -lva-x11 &&
>  enable vaapi_x11
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 941057b..64c68b7 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -719,6 +719,7 @@ OBJS-$(CONFIG_ADPCM_YAMAHA_ENCODER)   += adpcmenc.o 
> adpcm_data.o
>  OBJS-$(CONFIG_D3D11VA)+= dxva2.o
>  OBJS-$(CONFIG_DXVA2)  += dxva2.o
>  OBJS-$(CONFIG_VAAPI)  += vaapi.o
> +OBJS-$(CONFIG_VAAPI_RECENT)   += vaapi_support.o
>  OBJS-$(CONFIG_VDA)+= vda.o videotoolbox.o
>  OBJS-$(CONFIG_VIDEOTOOLBOX)   += videotoolbox.o
>  OBJS-$(CONFIG_VDPAU)  += vdpau.o
> diff --git a/libavcodec/vaapi_support.c b/libavcodec/vaapi_support.c
> new file mode 100644
> index 000..6be4669
> --- /dev/null
> +++ b/libavcodec/vaapi_support.c
> @@ -0,0 +1,852 @@
> +/*
> + * VAAPI helper functions.
> + *
> + * Copyright (C) 2016 Mark Thompson 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "vaapi_support.h"
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/imgutils.h"
> +#include "libavutil/pixfmt.h"
> +
> +#define AV_VAAPI_MAX_SURFACES 64
> +
> +
> +static const AVClass vaapi_class = {
> +.class_name = "vaapi",
> +.item_name  = av_default_item_name,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +
> +AVVAAPIHardwareContext *av_vaapi_alloc_hardware_context(void)
> +{
> +AVVAAPIHardwareContext *hw_ctx =
> +av_mallocz(sizeof(AVVAAPIHardwareContext));
> +if(!hw_ctx)
> +return NULL;
> +
> +hw_ctx->class = _class;
> +return hw_ctx;
> +}
> +
> +void av_vaapi_lock_hardware_context(AVVAAPIHardwareContext *ctx)
> +{
> +if(ctx->lock)
> +ctx->lock(ctx->lock_user_context);
> +}
> +
> +void av_vaapi_unlock_hardware_context(AVVAAPIHardwareContext *ctx)
> +{
> +if(ctx->unlock)
> +ctx->unlock(ctx->lock_user_context);
> +}
> +
> +
> +typedef struct AVVAAPISurfacePool {
> +AVVAAPIHardwareContext *hardware_context;
> +
> +int frame_count;
> +AVFrame *frames[AV_VAAPI_MAX_SURFACES];
> +} AVVAAPISurfacePool;
> +
> +AVVAAPISurfacePool *av_vaapi_alloc_surface_pool(AVVAAPIHardwareContext 
> *hw_ctx)
> +{
> +AVVAAPISurfacePool *pool = av_mallocz(sizeof(AVVAAPISurfacePool));
> +if(!pool)
> +return NULL;
> +
> +pool->hardware_context = hw_ctx;
> +return pool;
> +}
> +
> +
> +typedef struct AVVAAPIPipelineContext {
> +const AVClass *class;
> +
> +AVVAAPIHardwareContext *hardware_context;
> +
> +VAConfigID config_id;
> +VAContextID context_id;
> +} AVVAAPIPipelineContext;
> +
> +AVVAAPIPipelineContext 
> *av_vaapi_alloc_pipeline_context(AVVAAPIHardwareContext *hw_ctx)
> +{
> +AVVAAPIPipelineContext *ctx =
> +av_mallocz(sizeof(AVVAAPIPipelineContext));
> +if(!ctx)
> +return NULL;
> +
> +ctx->class = _class;
> +ctx->hardware_context = hw_ctx;
> +return ctx;
> +}
> +
> +
> +typedef struct AVVAAPISurface {
> +VASurfaceID id;
> +AVVAAPIHardwareContext *hardware_context;
> +
> +VAImage image;
> +int derive_doesnt_work;
> +int mapping_flags;
> +void 

Re: [FFmpeg-devel] [PATCH] libavformat/dnxhddec added support for raw 444 and dnxhr formats

[Mark Reid]

On Mon, Feb 8, 2016 at 1:25 AM, Christophe Gisquet
 wrote:
> Hi,
>
> 2016-02-08 8:15 GMT+01:00 Christophe Gisquet :
>> At this point, I'd say the encoder would better use that prefix.
>> That's what the attached patch does (rebased but not tested). You may
>> consider building on top of it for that purpose.
>
> Which I haven't attached... So here's one /not/ rebased, but that
> should provide the same information, should that interest you.
>
> BR,
> --
> Christophe
>

Thanks! That looks much better, I'll rebase on top of that and send a
new patch, I'll also  add a fate test. I'm guessing its okay to
include "libavcodec/dnxhddata.h" in something thats in libavformat
then? movenc.c uses those prefixes too.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/dnxhddec added support for raw 444 and dnxhr formats

[Christophe Gisquet]

Hi,

2016-02-09 6:27 GMT+01:00 Mark Reid :
[...]
> I'm guessing its okay to
> include "libavcodec/dnxhddata.h" in something thats in libavformat
> then? movenc.c uses those prefixes too.

Argh, nice catch, you can't use the the content of ff_dnxhd_headers
there, which is the point.

I didn't notice the avformat in the path of dnxhddec.

Please ignore my patch, or if you like, just have constructs to allow
iterations.

The only problem would be in the dnxhd libavcodec encoder, which could
write an incorrect header version depending on the CID.

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

Re: [FFmpeg-devel] [PATCH] libavformat/dnxhddec added support for raw 444 and dnxhr formats

[Carl Eugen Hoyos]

Mark Reid  gmail.com> writes:

> I'm guessing its okay to include "libavcodec/dnxhddata.h" 
> in something thats in libavformat then?

Yes, it is ok to include headers from libavcodec in 
libavformat. It may be more complicated with symbols 
though.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH v6 1/6] libavcodec: VAAPI support infrastructure

[Mark Thompson]

On 08/02/16 12:08, wm4 wrote:

On Sun, 7 Feb 2016 21:53:39 +
Mark Thompson  wrote:

diff --git a/libavcodec/vaapi_support.h b/libavcodec/vaapi_support.h
new file mode 100644
index 000..c159ee7
--- /dev/null
+++ b/libavcodec/vaapi_support.h
@@ -0,0 +1,284 @@
+/*
+ * VAAPI helper functions.
+ *
+ * Copyright (C) 2016 Mark Thompson 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVCODEC_VAAPI_SUPPORT_H
+#define AVCODEC_VAAPI_SUPPORT_H
+
+/**
+ * @defgroup lavc_vaapi VAAPI support
+ * @ingroup lavc_misc
+ * @{
+ */
+
+#include 
+
+#include "libavutil/pixfmt.h"
+#include "libavutil/frame.h"
+
+#include "vaapi.h"
+
+
+/**
+ * Structure defining a VAAPI hardware context.
+ *
+ * This is managed by the user, and must be passed to all components which
+ * require it.
+ *
+ * Allocated using @ref av_vaapi_alloc_hardware_context().
+ */
+typedef struct AVVAAPIHardwareContext {
+/** Logging class.
+ * @ref av_vaapi_alloc_hardware_context sets this to a default value,
+ * and the user can override it if desired.
+ */
+const AVClass *class;
+/** libva display handle.
+ * Initialised by the user.
+ */
+VADisplay display;
+/** Context lock function.
+ * This should be set by the user to allow suitable mutual exclusion if
+ * multiple components might use this context simultaneously.
+ * Note that recursive locking must be supported.
+ */
+void (*lock)(void *user_context);
+/** Context unlock function. */
+void (*unlock)(void *user_context);
+/** User data passed as argument to lock and unlock. */
+void *lock_user_context;
+} AVVAAPIHardwareContext;
+
+/** Allocate a new @ref AVVAAPIHardwareContext.
+ *
+ * Also fills in a default logging class.
+ * Use @ref av_free() to free it after use.
+ *
+ * @return Newly-allocated context.
+ */
+AVVAAPIHardwareContext *av_vaapi_alloc_hardware_context(void);
+
+/** Lock the context, using the user-supplied lock function.
+ */
+void av_vaapi_lock_hardware_context(AVVAAPIHardwareContext *ctx);
+/** Unlock the context, using the user-supplied lock function.
+ */
+void av_vaapi_unlock_hardware_context(AVVAAPIHardwareContext *ctx);
+
+
+/** Surface configuration structure.
+ *
+ * Defines the properties of surfaces to be allocated in an
+ * @ref AVVAAPISurfacePool.
+ */
+typedef struct AVVAAPISurfaceConfig {
+/** Pixel format of the surfaces. */
+enum AVPixelFormat av_format;
+
+/** libva image format of the surfaces.
+ *
+ * In most cases, this is obtainable by @ref av_vaapi_get_image_format()
+ * on the av_format.
+ */
+VAImageFormat va_format;
+
+/** Width of the surface. */
+unsigned int width;
+/** Height of the surface. */
+unsigned int height;
+
+/** Number of extra attributes to be passed to vaCreateSurfaces(). */
+unsigned int attribute_count;
+/** Pointer to extra attributes (or null if attribute_count is zero). */
+VASurfaceAttrib *attributes;
+} AVVAAPISurfaceConfig;


No alloc function for this struct? (Although I can't think of anything
that could possibly added to it in the future. Maybe not needed?)


Yeah.  I was thinking that unless libva changes very significantly, any 
different features are going to apply to the pool (which can be changed, see 
below) rather than the surfaces.



+
+/** Opaque surface pool structure.
+ *
+ * Manages a set of VAAPI surfaces contained in AVFrames.  Individual frames
+ * use reference-counting to track lifetime.
+ */
+typedef struct AVVAAPISurfacePool AVVAAPISurfacePool;
+
+/** Allocate a new @ref AVVAAPISurfacePool.
+ *
+ * @param hw_ctx VAAPI hardware context this pool will create surfaces in.
+ * @return Newly-allocated surface pool.
+ */
+AVVAAPISurfacePool *av_vaapi_alloc_surface_pool(AVVAAPIHardwareContext 
*hw_ctx);
+
+/** Initialise an @ref AVVAAPISurfacePool and allocate the surfaces in it.
+ *
+ * @param pool Pool to initialise (allocated by
+ * @ref av_vaapi_alloc_surface_pool()).
+ * @param config Surface configuration for the allocated surfaces.  It need
+ * not last beyond this call (can be on the stack).
+ * @param surface_count Number of surfaces to allocate in the pool.
+ * @return Zero on success, or 

Re: [FFmpeg-devel] [PATCH] avfilter: add BobWeaver deinterlacing filter

[Thomas Mundt]

>>> Hendrik Leppkes  schrieb am Mo, 8.2.2016:
> How does the speed compare to YADIF?
> Or in other words, is it usable in real-time, or rather designed for
> offline processing?
> 
YADIF is quicker, because of its CPU optimizations. Without CPU optimizations 
BobWeaver is quicker.
It should definitely be usable in real-time.

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

[FFmpeg-devel] Outreachy 2016

[Michael Niedermayer]

Hi all

This is a reminder that the deadline to register FFmpeg with outreachy
is tomorrow, the 9th february
see: https://www.gnome.org/outreachy/
"Free and open source software organizations and supporting companies are 
invited to express interest in offering internships or sponsoring the program 
in the upcoming round by February 9, 2016."

If you care to have FFmpeg participate, contact the outreachy admins
and CC ffmpeg-devel

Also the trac wiki page for this round is not in shape, well its not
even existing i just created an empty page:
https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-05
Please help fill it with whatever project and ideas the community
wants to have in it.
(based on previous rounds or create a differnt page or structure but
 make sure that anything different is conformant to the regulations of
 the specific sponsoring program.
 IIRC a common page for gsoc and outreachy was not possible previously)

iam CCing this to a few people who where previously doing some
admin related work, this is not meant that i expect any of them to
do any work just so they dont miss it.

Its quite unlikely that FFmpeg will participate in Outreachy if you
(yes you the reader) doesnt do anything or said differently work doesnt
do itself, someone needs to do it ...

Thanks

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

Re: [FFmpeg-devel] [PATCH v3] avcodec: implement a native VC-2 HQ profile encoder

[Kieran Kunhya]

On 7 February 2016 at 22:21, Rostislav Pehlivanov  wrote:
> Changes from last version:
> -use ptrdiff_t for strides
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/Makefile |1 +
>  libavcodec/allcodecs.c  |1 +
>  libavcodec/vc2enc.c | 1194 
> +++
>  libavcodec/vc2enc_dwt.c |  234 ++
>  libavcodec/vc2enc_dwt.h |   54 +++
>  5 files changed, 1484 insertions(+)
>  create mode 100644 libavcodec/vc2enc.c
>  create mode 100644 libavcodec/vc2enc_dwt.c
>  create mode 100644 libavcodec/vc2enc_dwt.h
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 941057b..f6a4fbb 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -543,6 +543,7 @@ OBJS-$(CONFIG_VC1_DECODER) += vc1dec.o 
> vc1_block.o vc1_loopfilter.o
>wmv2dsp.o
>  OBJS-$(CONFIG_VC1_MMAL_DECODER)+= mmaldec.o
>  OBJS-$(CONFIG_VC1_QSV_DECODER) += qsvdec_vc1.o
> +OBJS-$(CONFIG_VC2_ENCODER) += vc2enc.o vc2enc_dwt.o diractab.o
>  OBJS-$(CONFIG_VCR1_DECODER)+= vcr1.o
>  OBJS-$(CONFIG_VMDAUDIO_DECODER)+= vmdaudio.o
>  OBJS-$(CONFIG_VMDVIDEO_DECODER)+= vmdvideo.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index c7c1af5..2097db0 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -336,6 +336,7 @@ void avcodec_register_all(void)
>  REGISTER_DECODER(VC1IMAGE,  vc1image);
>  REGISTER_DECODER(VC1_MMAL,  vc1_mmal);
>  REGISTER_DECODER(VC1_QSV,   vc1_qsv);
> +REGISTER_ENCODER(VC2,   vc2);
>  REGISTER_DECODER(VCR1,  vcr1);
>  REGISTER_DECODER(VMDVIDEO,  vmdvideo);
>  REGISTER_DECODER(VMNC,  vmnc);
> diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
> new file mode 100644
> index 000..dbcde0f
> --- /dev/null
> +++ b/libavcodec/vc2enc.c
> @@ -0,0 +1,1194 @@
> +/*
> + * Copyright (C) 2016 Open Broadcast Systems Ltd.
> + * Author(C) 2016 Rostislav Pehlivanov 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "libavutil/ffversion.h"
> +#include "libavutil/pixdesc.h"
> +#include "libavutil/opt.h"
> +#include "dirac.h"
> +#include "put_bits.h"
> +#include "internal.h"
> +
> +#include "vc2enc_dwt.h"
> +#include "diractab.h"
> +
> +/* Quantizations above this usually zero coefficients and lower the quality 
> */
> +#define MAX_QUANT_INDEX 49
> +
> +#define COEF_LUT_TAB 2048
> +
> +enum VC2_QM {
> +VC2_QM_DEF = 0,
> +VC2_QM_COL,
> +VC2_QM_FLAT,
> +
> +VC2_QM_NB
> +};
> +
> +typedef struct SubBand {
> +dwtcoef *buf;
> +ptrdiff_t stride;
> +int width;
> +int height;
> +} SubBand;
> +
> +typedef struct Plane {
> +SubBand band[MAX_DWT_LEVELS][4];
> +dwtcoef *coef_buf;
> +int width;
> +int height;
> +int dwt_width;
> +int dwt_height;
> +ptrdiff_t coef_stride;
> +} Plane;
> +
> +typedef struct SliceArgs {
> +PutBitContext pb;
> +void *ctx;
> +int x;
> +int y;
> +int quant_idx;
> +int bits_ceil;
> +int bytes;
> +} SliceArgs;
> +
> +typedef struct TransformArgs {
> +void *ctx;
> +Plane *plane;
> +void *idata;
> +ptrdiff_t istride;
> +int field;
> +VC2TransformContext t;
> +} TransformArgs;
> +
> +typedef struct VC2EncContext {
> +AVClass *av_class;
> +PutBitContext pb;
> +Plane plane[3];
> +AVCodecContext *avctx;
> +DiracVersionInfo ver;
> +
> +SliceArgs *slice_args;
> +TransformArgs transform_args[3];
> +
> +/* For conversion from unsigned pixel values to signed */
> +int diff_offset;
> +int bpp;
> +
> +/* Picture number */
> +uint32_t picture_number;
> +
> +/* Base video format */
> +int base_vf;
> +int level;
> +int profile;
> +
> +/* Quantization matrix */
> +uint8_t quant[MAX_DWT_LEVELS][4];
> +
> +/* Coefficient LUT */
> +uint32_t *coef_lut_val;
> +uint8_t  *coef_lut_len;
> +
> +int num_x; /* #slices horizontally */
> +int num_y; /* #slices vertically */

pointles comment imo

> +

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

[Paul B Mahol]

Hi,

patch attached.
From 4c19898e68d816309521aa353c65c93f159471f6 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Mon, 8 Feb 2016 12:31:29 +0100
Subject: [PATCH] avfilter: add graphhint filter

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi   |  18 +++
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_graphhint.c | 381 +
 4 files changed, 401 insertions(+)
 create mode 100644 libavfilter/vf_graphhint.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 8ae402a..241ded0 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -7537,6 +7537,24 @@ gradfun=radius=8
 
 @end itemize
 
+@section graphhint
+
+Filter video frames with graphs defined from file.
+
+@table @option
+@item file
+Set file that defines filtergraphs for input frame ranges.
+
+Example file:
+
+0,10 negate,vflip
+11,11 drawbox
+22,55 drawgrid
+
+The lines which specify range need to be sorted otherwise first greater
+number wins.
+@end table
+
 @anchor{haldclut}
 @section haldclut
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a1268e2..6fc12fe 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -164,6 +164,7 @@ OBJS-$(CONFIG_FREI0R_FILTER) += vf_frei0r.o
 OBJS-$(CONFIG_FSPP_FILTER)   += vf_fspp.o
 OBJS-$(CONFIG_GEQ_FILTER)+= vf_geq.o
 OBJS-$(CONFIG_GRADFUN_FILTER)+= vf_gradfun.o
+OBJS-$(CONFIG_GRAPHHINT_FILTER)  += vf_graphhint.o
 OBJS-$(CONFIG_HALDCLUT_FILTER)   += vf_lut3d.o dualinput.o framesync.o
 OBJS-$(CONFIG_HFLIP_FILTER)  += vf_hflip.o
 OBJS-$(CONFIG_HISTEQ_FILTER) += vf_histeq.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 489da25..b6a01a9 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -185,6 +185,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(FSPP,   fspp,   vf);
 REGISTER_FILTER(GEQ,geq,vf);
 REGISTER_FILTER(GRADFUN,gradfun,vf);
+REGISTER_FILTER(GRAPHHINT,  graphhint,  vf);
 REGISTER_FILTER(HALDCLUT,   haldclut,   vf);
 REGISTER_FILTER(HFLIP,  hflip,  vf);
 REGISTER_FILTER(HISTEQ, histeq, vf);
diff --git a/libavfilter/vf_graphhint.c b/libavfilter/vf_graphhint.c
new file mode 100644
index 000..b5f0328
--- /dev/null
+++ b/libavfilter/vf_graphhint.c
@@ -0,0 +1,381 @@
+/*
+ * Copyright (c) 2016 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * graphhint video filter
+ */
+
+#include "libavutil/attributes.h"
+#include "libavutil/avstring.h"
+#include "libavutil/avassert.h"
+#include "libavutil/opt.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/internal.h"
+#include "libavutil/time.h"
+#include "libavutil/timestamp.h"
+#include "libavformat/avformat.h"
+#include "audio.h"
+#include "avfilter.h"
+#include "buffersink.h"
+#include "buffersrc.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+#define MAX_LINE_SIZE 8192
+
+typedef struct GraphHintContext {
+const AVClass *class;
+
+char *file;
+char *filter_graph_str;
+char *current_graph_str;
+char *null_graph_str;
+
+FILE *f;
+int start, end;
+int reinit;
+
+AVFilterContext *sink;
+AVFilterContext *src;
+AVFilterInOut   *inputs;
+AVFilterInOut   *outputs;
+AVFilterContext *format;
+AVFilterGraph   *graph;
+} GraphHintContext;
+
+#define OFFSET(x) offsetof(GraphHintContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM | AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption graphhint_options[]= {
+{ "file",  "specify the file from which to read graphs", OFFSET(file), AV_OPT_TYPE_STRING, {.str = NULL }, .flags = FLAGS },
+{ NULL },
+};
+
+static void read_line(AVFilterContext *ctx)
+{
+GraphHintContext *s = ctx->priv;
+char line[MAX_LINE_SIZE + 512];
+
+s->reinit = 1;
+memcpy(s->filter_graph_str, s->null_graph_str, strlen(s->null_graph_str) + 1);
+while (fgets(line, sizeof(line), s->f)) {
+if (sscanf(line, "%d,%d %8192s", >start, >end, 

Re: [FFmpeg-devel] [PATCH] lavc/hevc Parse SEI_TYPE_MASTERING_DISPLAY_INFO and propagate contents into the AVMasteringDisplayMetadata side data.

[Neil Birkbeck]

I'm sending an updated patch that persists the data within the CVS
(between IRAP access units with no_rasl_output_flag=1). If this seems
like overkill, we can fallback to Hendrik's suggestion of just sending
it once. I did consider this alternative but figured the side data
could get lost if some frames were dropped in some part of the filter
chain.


On Thu, Feb 4, 2016 at 11:04 PM, Hendrik Leppkes  wrote:
> On Fri, Feb 5, 2016 at 3:05 AM, Neil Birkbeck  wrote:
>> According to the ITU-T H.265 v3, in Table D - 1, the persistence scope
>> of the mastering display metadata is "The Coded Video Sequence (CVS)
>> containing the SEI message". So I guess we want to clear when we start
>> the next CVS, so I guess when we see the next IDR frame.
>>
>> Given that the SEI comes before the IDR, I don't see a great way to do
>> this aside from initializing the flag to 2 and decrementing (when > 0)
>> when we see an IDR.
>>
>
> The usual way I would handle such SEI metadata is just to send the
> sidedata once when it appears in the bitstream and not repeat it with
> every single frame, and let the user worry about its lifetime.
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


0001-lavc-hevc-Parse-SEI_TYPE_MASTERING_DISPLAY_INFO-and-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] List of FFmpeg API changes

[Lou Logan]

On Sun, 07 Feb 2016 19:20:40 +0300, Ponomarenko Andrey wrote:

> Hello,
> 
> I continue maintaining list of API changes in FFmpeg here:
> http://abi-laboratory.pro/tracker/timeline/ffmpeg/
> 
> Please fix the link on this page: https://trac.ffmpeg.org/ (List of
> FFmpeg API changes/compatibility test results). The domain
> upstream-tracker dot org was sold by my old employer and contains
> inappropriate content for now.

Thanks for the notification. I fixed the link, but as Paul mentioned
anybody can update the wiki.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/cfhd: Add support for 12-bit RGBA.

[Kieran Kunhya]

Plays all known samples
---
 libavcodec/cfhd.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 2436aae..0773ffa 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -152,14 +152,15 @@ static void free_buffers(AVCodecContext *avctx)
 static int alloc_buffers(AVCodecContext *avctx)
 {
 CFHDContext *s = avctx->priv_data;
-int i, j, k, ret;
+int i, j, k, ret, planes;
 
 if ((ret = ff_set_dimensions(avctx, s->coded_width, s->coded_height)) < 0)
 return ret;
 
 avcodec_get_chroma_sub_sample(avctx->pix_fmt, >chroma_x_shift, 
>chroma_y_shift);
+planes = av_pix_fmt_count_planes(avctx->pix_fmt);
 
-for (i = 0; i < 3; i++) {
+for (i = 0; i < planes; i++) {
 int width = i ? avctx->width >> s->chroma_x_shift : avctx->width;
 int height = i ? avctx->height >> s->chroma_y_shift : avctx->height;
 int stride = FFALIGN(width / 8, 8) * 8;
@@ -224,7 +225,7 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, 
int *got_frame,
 GetByteContext gb;
 ThreadFrame frame = { .f = data };
 AVFrame *pic = data;
-int ret = 0, i, j, plane, got_buffer = 0;
+int ret = 0, i, j, planes, plane, got_buffer = 0;
 int16_t *coeff_data;
 
 avctx->pix_fmt = AV_PIX_FMT_YUV422P10;
@@ -254,7 +255,7 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, 
int *got_frame,
 } else if (tag == 12) {
 av_log(avctx, AV_LOG_DEBUG, "Channel Count: %"PRIu16"\n", data);
 s->channel_cnt = data;
-if (data != 3) {
+if (data > 4) {
 av_log(avctx, AV_LOG_ERROR, "Channel Count of %"PRIu16" is 
unsupported\n", data);
 ret = AVERROR_PATCHWELCOME;
 break;
@@ -269,7 +270,7 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, 
int *got_frame,
 } else if (tag == 62) {
 s->channel_num = data;
 av_log(avctx, AV_LOG_DEBUG, "Channel number %"PRIu16"\n", data);
-if (s->channel_num > 2) {
+if (s->channel_num > 3) {
 av_log(avctx, AV_LOG_ERROR, "Invalid channel number\n");
 ret = AVERROR(EINVAL);
 break;
@@ -403,6 +404,8 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, 
int *got_frame,
 avctx->pix_fmt = AV_PIX_FMT_YUV422P10;
 else if (data == 3)
 avctx->pix_fmt = AV_PIX_FMT_GBRP12;
+else if (data == 4)
+avctx->pix_fmt = AV_PIX_FMT_GBRAP12;
 else {
 avpriv_report_missing_feature(avctx, "Sample format of 
%"PRIu16" is unsupported\n", data);
 ret = AVERROR_PATCHWELCOME;
@@ -564,12 +567,13 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, 
int *got_frame,
 goto end;
 }
 
-for (plane = 0; plane < 3 && !ret; plane++) {
+planes = av_pix_fmt_count_planes(avctx->pix_fmt);
+for (plane = 0; plane < planes && !ret; plane++) {
 /* level 1 */
 int lowpass_height  = s->plane[plane].band[0][0].height;
 int lowpass_width   = s->plane[plane].band[0][0].width;
 int highpass_stride = s->plane[plane].band[0][1].stride;
-int act_plane = plane == 1 ? 2 : plane == 2 ? 1 : 0;
+int act_plane = plane == 1 ? 2 : plane == 2 ? 1 : plane;
 int16_t *low, *high, *output, *dst;
 
 if (lowpass_height > s->plane[plane].band[0][0].a_height || 
lowpass_width > s->plane[plane].band[0][0].a_width ||
@@ -612,7 +616,7 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, 
int *got_frame,
 high   += lowpass_width;
 output += lowpass_width * 2;
 }
-if (avctx->pix_fmt == AV_PIX_FMT_GBRP12) {
+if (s->bpc == 12) {
 output = s->plane[plane].subband[0];
 for (i = 0; i < lowpass_height * 2; i++) {
 for (j = 0; j < lowpass_width * 2; j++)
-- 
1.9.1

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

[FFmpeg-devel] [PATCH] vf_blend: Add SSE2 optimization for multiply

[Timothy Gu]

5 times faster than C, 3 times overall.
---

Removes constant.c changes in accordance with James's comments

---
 libavfilter/x86/vf_blend.asm| 29 +
 libavfilter/x86/vf_blend_init.c |  2 ++
 2 files changed, 31 insertions(+)

diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm
index 730be77..9388a74 100644
--- a/libavfilter/x86/vf_blend.asm
+++ b/libavfilter/x86/vf_blend.asm
@@ -24,6 +24,7 @@
 
 SECTION_RODATA
 
+pw_1:   times 8 dw 1
 pw_128: times 8 dw 128
 pw_255: times 8 dw 255
 pb_127: times 16 db 127
@@ -101,6 +102,34 @@ BLEND_INIT difference128, 4
 jl .loop
 BLEND_END
 
+BLEND_INIT multiply, 4
+pxor   m2, m2
+mova   m3, [pw_1]
+.nextrow:
+movxq, widthq
+
+.loop:
+ ; word
+ ; |--|
+movhm0, [topq + xq]  ; 
+movhm1, [bottomq + xq]
+punpcklbw   m0, m2   ; 00xx00xx
+punpcklbw   m1, m2
+
+pmullw  m0, m1   ;   a * b
+paddw   m0, m3
+movam1, m0
+psrlw   m1, 8
+paddw   m0, m1
+psrlw   m0, 8; 00xx00xx  a * b / 255
+
+packuswbm0, m0   ; 
+movh   [dstq + xq], m0
+add xq, mmsize / 2
+
+jl .loop
+BLEND_END
+
 BLEND_INIT average, 3
 pxor   m2, m2
 .nextrow:
diff --git a/libavfilter/x86/vf_blend_init.c b/libavfilter/x86/vf_blend_init.c
index dc29547..8ac526a 100644
--- a/libavfilter/x86/vf_blend_init.c
+++ b/libavfilter/x86/vf_blend_init.c
@@ -36,6 +36,7 @@ BLEND_FUNC(average, sse2)
 BLEND_FUNC(and, sse2)
 BLEND_FUNC(darken, sse2)
 BLEND_FUNC(difference128, sse2)
+BLEND_FUNC(multiply, sse2)
 BLEND_FUNC(hardmix, sse2)
 BLEND_FUNC(lighten, sse2)
 BLEND_FUNC(or, sse2)
@@ -61,6 +62,7 @@ av_cold void ff_blend_init_x86(FilterParams *param, int 
is_16bit)
 case BLEND_DIFFERENCE128: param->blend = ff_blend_difference128_sse2; 
break;
 case BLEND_HARDMIX:  param->blend = ff_blend_hardmix_sse2;  break;
 case BLEND_LIGHTEN:  param->blend = ff_blend_lighten_sse2;  break;
+case BLEND_MULTIPLY: param->blend = ff_blend_multiply_sse2; break;
 case BLEND_OR:   param->blend = ff_blend_or_sse2;   break;
 case BLEND_PHOENIX:  param->blend = ff_blend_phoenix_sse2;  break;
 case BLEND_SUBTRACT: param->blend = ff_blend_subtract_sse2; break;
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] vf_blend: Add SSE2 optimization for multiply

[Timothy Gu]

On Mon, Feb 08, 2016 at 09:51:55PM +0100, Paul B Mahol wrote:
> On 2/8/16, Timothy Gu  wrote:
> > 5 times faster than C, 3 times overall.
> > ---
> >
> > Removes constant.c changes in accordance with James's comments
> >
> > ---
> >  libavfilter/x86/vf_blend.asm| 29 +
> >  libavfilter/x86/vf_blend_init.c |  2 ++
> >  2 files changed, 31 insertions(+)
> >
> 
> If output is always bitexact with C, should be OK for me.

Yes.

Pushed, thanks.

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

Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads

[Ronald S. Bultje]

Hi,

On Tue, Jan 26, 2016 at 5:23 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> On 25.01.2016 00:53, Hendrik Leppkes wrote:
> > On Sat, Jan 23, 2016 at 3:52 PM, Andreas Cadhalpun
> >  wrote:
> >> On 23.01.2016 15:10, Hendrik Leppkes wrote:
> >>> On Sat, Jan 23, 2016 at 2:45 PM, Ronald S. Bultje 
> wrote:
>  Both of you keep shouting from one side of the room to the other
> without
>  trying to actually converge to a point that might somehow be mutually
>  acceptable. I'm getting very grumbly here.
> 
> >>>
> >>> I'm not trying to be unreasonable here, all I'm asking for at this
> >>> point is to make sure the new vp9 hwaccel doesn't break spectacularly
> >>> when MT is turned on before its allowed back.
> >>
> >> OK, that would be fine with me.
> >>
> >> Do you agree that the attached patch is sufficient for this?
> >>
> >
> > YUV420P will not remain the only format available for hwaccel, I
> > already have some work pending to allow Profile2/10-bit as well, so
> > the check should be further out.
>
> OK. Though if Ronald manages to (hopefully soon) find a solution for
> automatically throttling the hwaccel threads to 1, this check will be
> removed again anyway.
>
> > It would also log every time the function executes, no matter if
> > hwaccel is requested or not, unfortunately I don't see a way to fix
> > that nicely since the decoder doesn't know if the user is going to
> > activate hwaccel.
>
> Indeed. But since that is anyway logged in setup_hwaccel there
> is not really much need for another warning here. I've thus reduced
> the log level to verbose. Attached is an updated patch.


See attached for what I had in mind, and along with this you can then
remove the current blocking code in libavcodec/utils.c which you're
complaining about.

So, this _sometimes_ works for dxva2/vp9, but it still fails sometimes.
Hendrik thinks it's related to dxva2 generic buffer handling, not
vp9-related anymore, and in line with that, it's indeed true that
h264/dxva2 hwaccel+threading fails also. vdpau hwaccel+mt works, but has no
vp9 so we can't confirm if vp9 is fine here. I haven't found anyone with
vaapi vp9 yet...

Hendrik is not against applying this, but the question is whether it's
helpful, because if you remove the libavcodec/utils.c block, mt+hwaccel for
dxva2 will fail again (easily reproduced with make THREADS=4 HWACCEL=dxva2
fate-h264/vp9 -k). Hendrik suggested possibly putting locks around the
dxva2 picture pool, but that's stupid. Also, this whole setup still doesn't
allow much room for adaptive fallback and delayed hw decoding (i.e. having
multiple buffers in the hw queue), since the hw is disabled without flush
as soon as we switch between hw and fallback...

Ronald


0001-vp9-only-call-ff_get_format-on-stream-format-changes.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2] Add GBRAP12 pixel format

[Kieran Kunhya]

---
 libavcodec/utils.c|  2 ++
 libavutil/pixdesc.c   | 28 
 libavutil/pixfmt.h|  4 
 libavutil/version.h   |  2 +-
 libswscale/input.c|  4 
 libswscale/swscale_unscaled.c |  3 +++
 libswscale/utils.c|  6 ++
 7 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index ee73670..f4b68ac 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -351,6 +351,8 @@ void avcodec_align_dimensions2(AVCodecContext *s, int 
*width, int *height,
 case AV_PIX_FMT_GBRP14BE:
 case AV_PIX_FMT_GBRP16LE:
 case AV_PIX_FMT_GBRP16BE:
+case AV_PIX_FMT_GBRAP12LE:
+case AV_PIX_FMT_GBRAP12BE:
 case AV_PIX_FMT_GBRAP16LE:
 case AV_PIX_FMT_GBRAP16BE:
 w_align = 16; //FIXME assume 16 pixel per macroblock
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 58833cf..f546088 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2028,6 +2028,34 @@ static const AVPixFmtDescriptor 
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
 },
 .flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_BE,
 },
+[AV_PIX_FMT_GBRAP12LE] = {
+.name = "gbrap12le",
+.nb_components = 4,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 2, 2, 0, 0, 12, 1, 11, 1 },   /* R */
+{ 0, 2, 0, 0, 12, 1, 11, 1 },   /* G */
+{ 1, 2, 0, 0, 12, 1, 11, 1 },   /* B */
+{ 3, 2, 0, 0, 12, 1, 11, 1 },   /* A */
+},
+.flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_RGB |
+ AV_PIX_FMT_FLAG_ALPHA,
+},
+[AV_PIX_FMT_GBRAP12BE] = {
+.name = "gbrap12be",
+.nb_components = 4,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 2, 2, 0, 0, 12, 1, 11, 1 },   /* R */
+{ 0, 2, 0, 0, 12, 1, 11, 1 },   /* G */
+{ 1, 2, 0, 0, 12, 1, 11, 1 },   /* B */
+{ 3, 2, 0, 0, 12, 1, 11, 1 },   /* A */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR |
+ AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_ALPHA,
+},
 };
 #if FF_API_PLUS1_MINUS1
 FF_ENABLE_DEPRECATION_WARNINGS
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index c01c057..7d2eac0 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -292,6 +292,9 @@ enum AVPixelFormat {
 AV_PIX_FMT_P010LE, ///< like NV12, with 10bpp per component, data in the 
high bits, zeros in the low bits, little-endian
 AV_PIX_FMT_P010BE, ///< like NV12, with 10bpp per component, data in the 
high bits, zeros in the low bits, big-endian
 
+AV_PIX_FMT_GBRAP12BE,  ///< planar GBR 4:4:4:4 48bpp, big-endian
+AV_PIX_FMT_GBRAP12LE,  ///< planar GBR 4:4:4:4 48bpp, little-endian
+
 AV_PIX_FMT_NB,///< number of pixel formats, DO NOT USE THIS if you 
want to link with shared libav* because the number of formats might differ 
between versions
 };
 
@@ -347,6 +350,7 @@ enum AVPixelFormat {
 #define AV_PIX_FMT_GBRP12AV_PIX_FMT_NE(GBRP12BE,GBRP12LE)
 #define AV_PIX_FMT_GBRP14AV_PIX_FMT_NE(GBRP14BE,GBRP14LE)
 #define AV_PIX_FMT_GBRP16AV_PIX_FMT_NE(GBRP16BE,GBRP16LE)
+#define AV_PIX_FMT_GBRAP12   AV_PIX_FMT_NE(GBRAP12BE,   GBRAP12LE)
 #define AV_PIX_FMT_GBRAP16   AV_PIX_FMT_NE(GBRAP16BE,   GBRAP16LE)
 
 #define AV_PIX_FMT_BAYER_BGGR16 AV_PIX_FMT_NE(BAYER_BGGR16BE,
BAYER_BGGR16LE)
diff --git a/libavutil/version.h b/libavutil/version.h
index 5352f26..9a330f9 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -64,7 +64,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  55
-#define LIBAVUTIL_VERSION_MINOR  17
+#define LIBAVUTIL_VERSION_MINOR  18
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
diff --git a/libswscale/input.c b/libswscale/input.c
index 1df84a9..078a28d 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -963,6 +963,7 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
 case AV_PIX_FMT_GBRP10LE:
 c->readChrPlanar = planar_rgb10le_to_uv;
 break;
+case AV_PIX_FMT_GBRAP12LE:
 case AV_PIX_FMT_GBRP12LE:
 c->readChrPlanar = planar_rgb12le_to_uv;
 break;
@@ -979,6 +980,7 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
 case AV_PIX_FMT_GBRP10BE:
 c->readChrPlanar = planar_rgb10be_to_uv;
 break;
+case AV_PIX_FMT_GBRAP12BE:
 case AV_PIX_FMT_GBRP12BE:
 c->readChrPlanar = planar_rgb12be_to_uv;
 break;
@@ -1241,6 +1243,7 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
 case AV_PIX_FMT_GBRP10LE:
 c->readLumPlanar = planar_rgb10le_to_y;
 break;
+case AV_PIX_FMT_GBRAP12LE:
 case AV_PIX_FMT_GBRP12LE:
 c->readLumPlanar = planar_rgb12le_to_y;
 break;
@@ -1257,6 +1260,7 @@ av_cold void 

[FFmpeg-devel] [PATCH 1/3] x86/constants: extend pw_128 to 256 bits

[Timothy Gu]

---
 libavcodec/x86/constants.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/x86/constants.c b/libavcodec/x86/constants.c
index 11002ee..c2d3bb8 100644
--- a/libavcodec/x86/constants.c
+++ b/libavcodec/x86/constants.c
@@ -42,7 +42,8 @@ DECLARE_ALIGNED(8,  const uint64_t, ff_pw_42)   =   
0x002A002A002A002AULL;
 DECLARE_ALIGNED(8,  const uint64_t, ff_pw_53)   =   0x0035003500350035ULL;
 DECLARE_ALIGNED(16, const xmm_reg,  ff_pw_64)   = { 0x0040004000400040ULL, 
0x0040004000400040ULL };
 DECLARE_ALIGNED(8,  const uint64_t, ff_pw_96)   =   0x0060006000600060ULL;
-DECLARE_ALIGNED(8,  const uint64_t, ff_pw_128)  =   0x0080008000800080ULL;
+DECLARE_ALIGNED(32, const ymm_reg,  ff_pw_128)  = { 0x0080008000800080ULL, 
0x0080008000800080ULL,
+0x0080008000800080ULL, 
0x0080008000800080ULL };
 DECLARE_ALIGNED(32, const ymm_reg,  ff_pw_255)  = { 0x00ff00ff00ff00ffULL, 
0x00ff00ff00ff00ffULL,
 0x00ff00ff00ff00ffULL, 
0x00ff00ff00ff00ffULL };
 DECLARE_ALIGNED(32, const ymm_reg,  ff_pw_256)  = { 0x0100010001000100ULL, 
0x0100010001000100ULL,
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 2/3] x86/vf_blend: use shared constants

[Timothy Gu]

---
 libavfilter/x86/vf_blend.asm | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm
index 730be77..8e4251a 100644
--- a/libavfilter/x86/vf_blend.asm
+++ b/libavfilter/x86/vf_blend.asm
@@ -24,11 +24,11 @@
 
 SECTION_RODATA
 
-pw_128: times 8 dw 128
-pw_255: times 8 dw 255
+cextern pw_128
+cextern pw_255
+cextern pw_m1
+cextern pb_80
 pb_127: times 16 db 127
-pb_128: times 16 db 128
-pb_255: times 16 db 255
 
 SECTION .text
 
@@ -139,8 +139,8 @@ BLEND_INIT addition128, 4
 BLEND_END
 
 BLEND_INIT hardmix, 5
-mova   m2, [pb_255]
-mova   m3, [pb_128]
+mova   m2, [pw_m1]
+mova   m3, [pb_80]
 mova   m4, [pb_127]
 .nextrow:
 movxq, widthq
@@ -158,7 +158,7 @@ BLEND_INIT hardmix, 5
 BLEND_END
 
 BLEND_INIT phoenix, 4
-mova   m3, [pb_255]
+mova   m3, [pw_m1]
 .nextrow:
 movxq, widthq
 
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 3/3] vf_blend: Add SSE2 optimization for multiply

[Timothy Gu]

5 times faster than C, 3 times overall.
---
 libavfilter/x86/vf_blend.asm| 29 +
 libavfilter/x86/vf_blend_init.c |  2 ++
 2 files changed, 31 insertions(+)

diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm
index 8e4251a..01bee36 100644
--- a/libavfilter/x86/vf_blend.asm
+++ b/libavfilter/x86/vf_blend.asm
@@ -24,6 +24,7 @@
 
 SECTION_RODATA
 
+cextern pw_1
 cextern pw_128
 cextern pw_255
 cextern pw_m1
@@ -101,6 +102,34 @@ BLEND_INIT difference128, 4
 jl .loop
 BLEND_END
 
+BLEND_INIT multiply, 4
+pxor   m2, m2
+mova   m3, [pw_1]
+.nextrow:
+movxq, widthq
+
+.loop:
+ ; word
+ ; |--|
+movhm0, [topq + xq]  ; 
+movhm1, [bottomq + xq]
+punpcklbw   m0, m2   ; 00xx00xx
+punpcklbw   m1, m2
+
+pmullw  m0, m1   ;   a * b
+paddw   m0, m3
+movam1, m0
+psrlw   m1, 8
+paddw   m0, m1
+psrlw   m0, 8; 00xx00xx  a * b / 255
+
+packuswbm0, m0   ; 
+movh   [dstq + xq], m0
+add xq, mmsize / 2
+
+jl .loop
+BLEND_END
+
 BLEND_INIT average, 3
 pxor   m2, m2
 .nextrow:
diff --git a/libavfilter/x86/vf_blend_init.c b/libavfilter/x86/vf_blend_init.c
index dc29547..8ac526a 100644
--- a/libavfilter/x86/vf_blend_init.c
+++ b/libavfilter/x86/vf_blend_init.c
@@ -36,6 +36,7 @@ BLEND_FUNC(average, sse2)
 BLEND_FUNC(and, sse2)
 BLEND_FUNC(darken, sse2)
 BLEND_FUNC(difference128, sse2)
+BLEND_FUNC(multiply, sse2)
 BLEND_FUNC(hardmix, sse2)
 BLEND_FUNC(lighten, sse2)
 BLEND_FUNC(or, sse2)
@@ -61,6 +62,7 @@ av_cold void ff_blend_init_x86(FilterParams *param, int 
is_16bit)
 case BLEND_DIFFERENCE128: param->blend = ff_blend_difference128_sse2; 
break;
 case BLEND_HARDMIX:  param->blend = ff_blend_hardmix_sse2;  break;
 case BLEND_LIGHTEN:  param->blend = ff_blend_lighten_sse2;  break;
+case BLEND_MULTIPLY: param->blend = ff_blend_multiply_sse2; break;
 case BLEND_OR:   param->blend = ff_blend_or_sse2;   break;
 case BLEND_PHOENIX:  param->blend = ff_blend_phoenix_sse2;  break;
 case BLEND_SUBTRACT: param->blend = ff_blend_subtract_sse2; break;
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 1/3] x86/constants: extend pw_128 to 256 bits

[Timothy Gu]

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

diff --git a/libavcodec/x86/constants.c b/libavcodec/x86/constants.c
index 11002ee..c2d3bb8 100644
--- a/libavcodec/x86/constants.c
+++ b/libavcodec/x86/constants.c
@@ -42,7 +42,8 @@ DECLARE_ALIGNED(8,  const uint64_t, ff_pw_42)   =   
0x002A002A002A002AULL;
 DECLARE_ALIGNED(8,  const uint64_t, ff_pw_53)   =   0x0035003500350035ULL;
 DECLARE_ALIGNED(16, const xmm_reg,  ff_pw_64)   = { 0x0040004000400040ULL, 
0x0040004000400040ULL };
 DECLARE_ALIGNED(8,  const uint64_t, ff_pw_96)   =   0x0060006000600060ULL;
-DECLARE_ALIGNED(8,  const uint64_t, ff_pw_128)  =   0x0080008000800080ULL;
+DECLARE_ALIGNED(32, const ymm_reg,  ff_pw_128)  = { 0x0080008000800080ULL, 
0x0080008000800080ULL,
+0x0080008000800080ULL, 
0x0080008000800080ULL };
 DECLARE_ALIGNED(32, const ymm_reg,  ff_pw_255)  = { 0x00ff00ff00ff00ffULL, 
0x00ff00ff00ff00ffULL,
 0x00ff00ff00ff00ffULL, 
0x00ff00ff00ff00ffULL };
 DECLARE_ALIGNED(32, const ymm_reg,  ff_pw_256)  = { 0x0100010001000100ULL, 
0x0100010001000100ULL,
diff --git a/libavcodec/x86/constants.h b/libavcodec/x86/constants.h
index b82aef9..90d53ba 100644
--- a/libavcodec/x86/constants.h
+++ b/libavcodec/x86/constants.h
@@ -41,7 +41,7 @@ extern const uint64_t ff_pw_42;
 extern const uint64_t ff_pw_53;
 extern const xmm_reg  ff_pw_64;
 extern const uint64_t ff_pw_96;
-extern const uint64_t ff_pw_128;
+extern const ymm_reg  ff_pw_128;
 extern const ymm_reg  ff_pw_255;
 extern const ymm_reg  ff_pw_512;
 extern const ymm_reg  ff_pw_1023;
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 2/3] x86/vf_blend: use shared constants

[Timothy Gu]

---
 libavfilter/x86/vf_blend.asm | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm
index 730be77..8e4251a 100644
--- a/libavfilter/x86/vf_blend.asm
+++ b/libavfilter/x86/vf_blend.asm
@@ -24,11 +24,11 @@
 
 SECTION_RODATA
 
-pw_128: times 8 dw 128
-pw_255: times 8 dw 255
+cextern pw_128
+cextern pw_255
+cextern pw_m1
+cextern pb_80
 pb_127: times 16 db 127
-pb_128: times 16 db 128
-pb_255: times 16 db 255
 
 SECTION .text
 
@@ -139,8 +139,8 @@ BLEND_INIT addition128, 4
 BLEND_END
 
 BLEND_INIT hardmix, 5
-mova   m2, [pb_255]
-mova   m3, [pb_128]
+mova   m2, [pw_m1]
+mova   m3, [pb_80]
 mova   m4, [pb_127]
 .nextrow:
 movxq, widthq
@@ -158,7 +158,7 @@ BLEND_INIT hardmix, 5
 BLEND_END
 
 BLEND_INIT phoenix, 4
-mova   m3, [pb_255]
+mova   m3, [pw_m1]
 .nextrow:
 movxq, widthq
 
-- 
1.9.1

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

Re: [FFmpeg-devel] Outreachy 2016

[Kieran Kunhya]

On Mon, 8 Feb 2016, 15:34 Michael Niedermayer 
wrote:
>
> Hi all
>
> This is a reminder that the deadline to register FFmpeg with outreachy
> is tomorrow, the 9th february
> see: https://www.gnome.org/outreachy/
> "Free and open source software organizations and supporting companies are
invited to express interest in offering internships or sponsoring the
program in the upcoming round by February 9, 2016."
>
> If you care to have FFmpeg participate, contact the outreachy admins
> and CC ffmpeg-devel
>
> Also the trac wiki page for this round is not in shape, well its not
> even existing i just created an empty page:
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-05
> Please help fill it with whatever project and ideas the community
> wants to have in it.
> (based on previous rounds or create a differnt page or structure but
>  make sure that anything different is conformant to the regulations of
>  the specific sponsoring program.
>  IIRC a common page for gsoc and outreachy was not possible previously)
>
> iam CCing this to a few people who where previously doing some
> admin related work, this is not meant that i expect any of them to
> do any work just so they dont miss it.
>
> Its quite unlikely that FFmpeg will participate in Outreachy if you
> (yes you the reader) doesnt do anything or said differently work doesnt
> do itself, someone needs to do it ...

I have no issue doing this.

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

Re: [FFmpeg-devel] [PATCH 2/3] x86/vf_blend: use shared constants

[James Almer]

On 2/8/2016 4:24 PM, Timothy Gu wrote:
> ---
>  libavfilter/x86/vf_blend.asm | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm
> index 730be77..8e4251a 100644
> --- a/libavfilter/x86/vf_blend.asm
> +++ b/libavfilter/x86/vf_blend.asm
> @@ -24,11 +24,11 @@
>  
>  SECTION_RODATA
>  
> -pw_128: times 8 dw 128
> -pw_255: times 8 dw 255
> +cextern pw_128
> +cextern pw_255
> +cextern pw_m1
> +cextern pb_80

None of the lavc constants are available outside lavc on shared builds.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Fwd: Fwd: libavformat/segment : add option to increment timecode

[Stefano Sabatini]

On date Friday 2016-02-05 11:41:06 +0100, Martin Vignali encoded:
> 2016-01-30 10:44 GMT+01:00 Stefano Sabatini :
> 
> > On date Friday 2016-01-29 17:38:13 +0100, Martin Vignali encoded:
> > > 2016-01-29 12:35 GMT+01:00 Stefano Sabatini :
> > [...]
> > > > +AVDictionaryEntry * tcr = av_dict_get(s->metadata, "timecode",
> > > > NULL, 0);
> > > > > +if (tcr){
> > > > > +if (s->nb_streams > 0){
> > > >
> > > > > +rate = s->streams[0]->avg_frame_rate;//Get fps from
> > > > first stream
> > > >
> > > > this looks a bit arbitrary, why the first stream?
> > > >
> > > > > +err = av_timecode_init_from_string(, rate,
> > > > tcr->value, s);
> > > > > +if (err < 0)
> > > > > +return err;
> > > >
> > > > > +tc.start += (int)(seg->time / 100.) *
> > > > av_q2d(rate);//second count * fps
> > > >
> > > > You're losing precision here. Consider using the rescaling utilities
> > > > in libavutil/mathematics.h or something like (seg->time * rate.num) /
> > > > (rate.den * 100).
> > [...]
> > > Thanks you for your comments, i will make the modifications.
> > >
> > > For the fps issue, you're right, i use the first stream because in my
> > tests
> > > it's always the video stream.
> > > Is there a better way, to get fps ? without choosing one of the stream ?
> >
> > My guess is that timecode is always related to a video stream, right?
> >
> > In this case you can loop through the streams and select the first
> > video stream (check also the select_reference_stream() function in
> > segment.c).
> >
> >
> I follow your proposal, and search the first video stream, to take fps.
> 
> In attach the new patch (and a documentation).
> 
> Best regards
> 
> Martin
> 
> 
> 
> ping

> From c266385a63b5f768e484e0aaccfa27de1f870663 Mon Sep 17 00:00:00 2001
> From: Martin Vignali 
> Date: Sat, 30 Jan 2016 20:52:54 +0100
> Subject: [PATCH 1/2] add increment timecode option using segment v2

Nit: lavf/segment: add increment timecode option

You could describe a use case in the log (optional).

> 
> ---
>  libavformat/segment.c | 29 +
>  1 file changed, 29 insertions(+)
> 
> diff --git a/libavformat/segment.c b/libavformat/segment.c
> index 9da5168..933abd1 100644
> --- a/libavformat/segment.c
> +++ b/libavformat/segment.c
> @@ -40,6 +40,7 @@
>  #include "libavutil/parseutils.h"
>  #include "libavutil/mathematics.h"
>  #include "libavutil/time.h"
> +#include "libavutil/timecode.h"
>  #include "libavutil/time_internal.h"
>  #include "libavutil/timestamp.h"
>  
> @@ -94,6 +95,7 @@ typedef struct SegmentContext {
>  char *time_str;///< segment duration specification string
>  int64_t time;  ///< segment duration
>  int use_strftime;  ///< flag to expand filename with strftime
> +int increment_tc;  ///< flag to increment timecode if found
>  
>  char *times_str;   ///< segment times specification string
>  int64_t *times;///< list of segment interval specification
> @@ -223,6 +225,32 @@ static int segment_start(AVFormatContext *s, int 
> write_header)
>  SegmentContext *seg = s->priv_data;
>  AVFormatContext *oc = seg->avf;
>  int err = 0;
> +AVTimecode tc;
> +AVRational rate;
> +int i;
> +
> +if (seg->increment_tc) {
> +AVDictionaryEntry * tcr = av_dict_get(s->metadata, "timecode", NULL, 
> 0);

nit: *tcr

> +if (tcr) {
> +/* search the first video stream */
> +for (i = 0; i < s->nb_streams; i++) {
> +if (s->streams[i]->codec->codec_type == AVMEDIA_TYPE_VIDEO) {
> +rate = s->streams[i]->avg_frame_rate;/* Get fps from the 
> video stream */
> +err = av_timecode_init_from_string(, rate, 
> tcr->value, s);
> +if (err < 0)
> +return err;

> +tc.start += (seg->time * rate.num) / (rate.den
> * 100);/* increment timecode */

This can overflow (yes I know you literally used my own
suggestion). You can use av_mul_q() to avoid that, or cast to floating
point numbers before the multiplication.

> +char buf[AV_TIMECODE_STR_SIZE];
> +av_dict_set(>metadata, "timecode",
> +av_timecode_make_string(, buf, 0), 0);/* 
> Set the new tc. */
> +break;
> +}
> +}

Please drop the comments in this section, since the code is
self-evident.

> +}
> +else{
> +av_log(s, AV_LOG_ERROR, "can't increment timecode. No timecode 
> found");


Style nit:

} else {

Also this should be an AV_LOG_WARNING since it's not an hard failure
(that is, the process will continue to run).

About the message, it could be more descriptive, something like:
"Could not increment timecode, no 

Re: [FFmpeg-devel] [SPI] Donation request to ffis.de

[Michael Niedermayer]

On Tue, Feb 02, 2016 at 07:30:27PM +0100, Stefano Sabatini wrote:
> Hi,
> 
> I propose to make a donation of 200 EUR to ffis.de to thank them for
> their services in the last two years.
> 
> Currently the ffis.de FFmpeg fund contains 9195 EUR, so I would ask
> the ffis.de officers to directly grab from that fund.

noone objected to teh 200euro donation so i think it should be ok

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

[FFmpeg-devel] [PATCH 3/3] vf_blend: Add SSE2 optimization for multiply

[Timothy Gu]

5 times faster than C, 3 times overall.
---
 libavfilter/x86/vf_blend.asm| 29 +
 libavfilter/x86/vf_blend_init.c |  2 ++
 2 files changed, 31 insertions(+)

diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm
index 8e4251a..01bee36 100644
--- a/libavfilter/x86/vf_blend.asm
+++ b/libavfilter/x86/vf_blend.asm
@@ -24,6 +24,7 @@
 
 SECTION_RODATA
 
+cextern pw_1
 cextern pw_128
 cextern pw_255
 cextern pw_m1
@@ -101,6 +102,34 @@ BLEND_INIT difference128, 4
 jl .loop
 BLEND_END
 
+BLEND_INIT multiply, 4
+pxor   m2, m2
+mova   m3, [pw_1]
+.nextrow:
+movxq, widthq
+
+.loop:
+ ; word
+ ; |--|
+movhm0, [topq + xq]  ; 
+movhm1, [bottomq + xq]
+punpcklbw   m0, m2   ; 00xx00xx
+punpcklbw   m1, m2
+
+pmullw  m0, m1   ;   a * b
+paddw   m0, m3
+movam1, m0
+psrlw   m1, 8
+paddw   m0, m1
+psrlw   m0, 8; 00xx00xx  a * b / 255
+
+packuswbm0, m0   ; 
+movh   [dstq + xq], m0
+add xq, mmsize / 2
+
+jl .loop
+BLEND_END
+
 BLEND_INIT average, 3
 pxor   m2, m2
 .nextrow:
diff --git a/libavfilter/x86/vf_blend_init.c b/libavfilter/x86/vf_blend_init.c
index dc29547..8ac526a 100644
--- a/libavfilter/x86/vf_blend_init.c
+++ b/libavfilter/x86/vf_blend_init.c
@@ -36,6 +36,7 @@ BLEND_FUNC(average, sse2)
 BLEND_FUNC(and, sse2)
 BLEND_FUNC(darken, sse2)
 BLEND_FUNC(difference128, sse2)
+BLEND_FUNC(multiply, sse2)
 BLEND_FUNC(hardmix, sse2)
 BLEND_FUNC(lighten, sse2)
 BLEND_FUNC(or, sse2)
@@ -61,6 +62,7 @@ av_cold void ff_blend_init_x86(FilterParams *param, int 
is_16bit)
 case BLEND_DIFFERENCE128: param->blend = ff_blend_difference128_sse2; 
break;
 case BLEND_HARDMIX:  param->blend = ff_blend_hardmix_sse2;  break;
 case BLEND_LIGHTEN:  param->blend = ff_blend_lighten_sse2;  break;
+case BLEND_MULTIPLY: param->blend = ff_blend_multiply_sse2; break;
 case BLEND_OR:   param->blend = ff_blend_or_sse2;   break;
 case BLEND_PHOENIX:  param->blend = ff_blend_phoenix_sse2;  break;
 case BLEND_SUBTRACT: param->blend = ff_blend_subtract_sse2; break;
-- 
1.9.1

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

Re: [FFmpeg-devel] [SPI] Donation request to ffis.de

[Stefano Sabatini]

On date Monday 2016-02-08 21:21:36 +0100, Michael Niedermayer encoded:
> On Tue, Feb 02, 2016 at 07:30:27PM +0100, Stefano Sabatini wrote:
> > Hi,
> > 
> > I propose to make a donation of 200 EUR to ffis.de to thank them for
> > their services in the last two years.
> > 
> > Currently the ffis.de FFmpeg fund contains 9195 EUR, so I would ask
> > the ffis.de officers to directly grab from that fund.
> 
> noone objected to teh 200euro donation so i think it should be ok

I consider this one approved then, and I'll request ffis to proceed
with the donation.
-- 
FFmpeg = Fanciful and Fostering Moronic Powerful Extravagant God
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] FFmpeg in Outreachy Round 12

[Kieran Kunhya]

Hello,

I have volunteered to be the co-ordinator for FFmpeg in Outreachy 2016. I
was a mentor for Outreachy in 2015 and look forward to working with
Outreachy to attract a more diverse base of contributors to FFmpeg.

Over the next few hours you should start seeing our project page start to
fill up:
https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-05

Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9

[Timothy Gu]

On Sun, Jan 31, 2016 at 3:38 PM Timothy Gu  wrote:

On Sat, Jan 30, 2016 at 07:27:22PM +, Derek Buitenhuis wrote:
> On 1/30/2016 7:15 PM, Timothy Gu wrote:
> > FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1.
>
> Perhaps this should be restricted to x86?

Fair enough.


Pushed.

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

Re: [FFmpeg-devel] [PATCH] lavf/mov: Extend extracting XMP in mov files using UUID Box

[Michael Niedermayer]

On Fri, Feb 05, 2016 at 03:39:25PM -0800, Thierry Foucu wrote:
> The UUID is based on http://www.adobe.com/devnet/xmp.html
> 
> The patch is made according to XMP SPECIFICATION PART 3 - STORAGE IN
> FILES See Table 8
> ---
>  libavformat/mov.c | 25 +
>  1 file changed, 25 insertions(+)

applied

thanks

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

Re: [FFmpeg-devel] [PATCH v2] Add GBRAP12 pixel format

[Michael Niedermayer]

On Mon, Feb 08, 2016 at 09:40:10PM +, Kieran Kunhya wrote:
> ---
>  libavcodec/utils.c|  2 ++
>  libavutil/pixdesc.c   | 28 
>  libavutil/pixfmt.h|  4 
>  libavutil/version.h   |  2 +-
>  libswscale/input.c|  4 
>  libswscale/swscale_unscaled.c |  3 +++
>  libswscale/utils.c|  6 ++
>  7 files changed, 48 insertions(+), 1 deletion(-)

i think a planar_rgb12le/be_to_a() is missing


 its also missing for 16bit i think
 (if someone has a testcase for that ...)


the patch shuld be ok otherwise

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

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/cfhd: Add support for 12-bit RGBA.

[Michael Niedermayer]

On Mon, Feb 08, 2016 at 09:42:53PM +, Kieran Kunhya wrote:
> Plays all known samples

without knowing cfhd i would say the patch should be ok then

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