Re: [FFmpeg-devel] bans

[James Almer]

On 6/16/2016 12:27 AM, compn wrote:
> On Wed, 15 Jun 2016 21:21:28 -0300
> James Almer  wrote:
> 
> ...
> 
> you are aware that we have voted in a code of conduct.[1]
> 
> you may want to review it, again.
> 
> https://ffmpeg.org/developer.html#Code-of-conduct
> 
> calling developers names will not be tolerated.

I made a list of what you can expect from any kind of exchange with
him to save both people's time and sanity, and even linked to a very
recent example of this kind of behavior to show I'm not just making
things up.

I don't think i called him names but if you think i did and violated
the CoC then you're welcome to call a vote for whatever action you
think should be taken. This entire situation is so distorted and
derailed among other things by what i denounced and warned about that
at this point i don't know what to expect of it.
Or rather, i know i shouldn't expect any concrete and logic action
whatsoever being taken at all.

> 
> -compn
> 
> [1] http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-May/194529.html
> ___
> 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] bans

[compn]

On Wed, 15 Jun 2016 21:21:28 -0300
James Almer  wrote:

...

you are aware that we have voted in a code of conduct.[1]

you may want to review it, again.

https://ffmpeg.org/developer.html#Code-of-conduct

calling developers names will not be tolerated.

-compn

[1] http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-May/194529.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] bans

[jd1008]

for what it's worth, I have been met with similar issue on this list.
Very unfortunate, and the principals are not doing anything about it.


On 06/15/2016 06:21 PM, James Almer wrote:

On 6/15/2016 8:16 PM, Ivan Kalvachev wrote:

Loads of crap

No one, and i mean no one reply to this email.

You will not get a single answer to any question you make. All you'll get is
counter questions. He will make questions he knows the answers for only to
read the reply in your own words. And once you reply to said questions, your
answer will be nitpicked expecting you to focus on said comments until the
conversation is fully derailed.
Insisting with your questions will be useless.

This is the guy that in a reply to the vote thread said he wasn't aware the
subject was mentioned in the IRC meeting [1] while in reality he knew well
about everything and even acknowledged it, as pointed out by Ronald in a
subsequent email [2].
He will lie and he will pretend to be unaware of things, be it to not answer
your questions or to get you to reply his, starting the cycle i mentioned
above.

This is is a guy that has since day 1 derailed every single conversation and
tried to put the aggressor as the victim and the victim as the aggressor,
installing the idea of secret unjustified feuds and invoking old bullshit like
libav's debacle in a perfect godwin's law fashion.

Not a single discussion in IRC where he was involved went anywhere, and neither
will anything in this thread. You'll get inside a spiral of bullshit with no
end until you decide to stop feeding the troll disguised as worried contributor.

[1] https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195306.html
[2] https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195344.html
___
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] bans

[James Almer]

On 6/15/2016 8:16 PM, Ivan Kalvachev wrote:
>Loads of crap

No one, and i mean no one reply to this email.

You will not get a single answer to any question you make. All you'll get is
counter questions. He will make questions he knows the answers for only to
read the reply in your own words. And once you reply to said questions, your
answer will be nitpicked expecting you to focus on said comments until the
conversation is fully derailed.
Insisting with your questions will be useless.

This is the guy that in a reply to the vote thread said he wasn't aware the
subject was mentioned in the IRC meeting [1] while in reality he knew well
about everything and even acknowledged it, as pointed out by Ronald in a
subsequent email [2].
He will lie and he will pretend to be unaware of things, be it to not answer
your questions or to get you to reply his, starting the cycle i mentioned
above.

This is is a guy that has since day 1 derailed every single conversation and
tried to put the aggressor as the victim and the victim as the aggressor,
installing the idea of secret unjustified feuds and invoking old bullshit like
libav's debacle in a perfect godwin's law fashion.

Not a single discussion in IRC where he was involved went anywhere, and neither
will anything in this thread. You'll get inside a spiral of bullshit with no
end until you decide to stop feeding the troll disguised as worried contributor.

[1] https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195306.html
[2] https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195344.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Michael Graczyk]

Mark,

Thanks for the comments and for pointing out the problems with the
code. I am working on fixing these and will send an updated patch
shortly.

As for the difference in behavior between mapping_family == -1 and
mapping_family == 1, I wanted to preserve existing behavior for users
who do not specify the new mapping_family command line argument. The
code would be more simple if the default behavior were the same as the
behavior when mapping_family==1 is specified explicitly. Do you think
we should change the default behavior in this case for consistency and
simplicity?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] bans

[Ivan Kalvachev]

On 6/15/16, Michael Niedermayer  wrote:
> Hi all
>
> As noone is doing anything about the situation and what is being
> done will not lead anywhere (the vote likely wont lead anywhere as
> likely few would ban a active developer 4 month and then if not
> some will feel injustice prevailed thus
>
> After writing this mail i will
>
> 1. ban carl for 24h from the ML due to
> causing  derek to leave the project. (24h was suggested in the IRC
> meeting)
> I suspect carl saw the merges done by derek as causing more bugs than
> good so he attacked until derek stoped doing the merges.
> The correct course of action would have been a vote about stoping the
> merges or a change to the procedure to reduce the amount of bugs.
> Like maybe a seperate branch where merges can be tested for ~24h before
> being pushed to master ...
> Or maybe more people working on fixing regressions
> As a sidenote, most of the regressions should be fixed by now.
>
> 2. ban derek for ~24h from the ML due to causing lukasz to leave the
> project last year, and due to personal insults on the ML and IRC
> to lukasz and carl.
> As derek is not subscribed to the list ATM, this will be implemented
> by moving him from the accept_these_nonmembers list to the
> reject_these_nonmembers list for ~24h
>
> 3. ban myself for ~24h from the ML because i wrote offensive mails too
> years ago and i doubt none was pivotal in causing someone to leave
>
> Thanks

I don't think that these bans would change anything.


The problem is that they would not address
any of the reasons for getting here.

There's been accumulation of a lot of mud,
and what we have seen so far is not even
the tip of the iceberg.

There are people who sincerely believe that
FFmpeg project would be better without Carl.
That Carl hates LibAV project and that hate is
obstruction to the consolidation between the
two projects.

The negativity turns into hostility and provocations.

When Carl complains that some merge breaks FFmpeg,
he is viewed as attacking LibAV and the merger,
even when he is actually only concerned about bugs in FFmpeg.
Then some people think they are in their right to counterattack.

Somebody described the result as:
"it's years of build up displeasure about
the general behavior of a person."

How do you resolve that?

I have no idea.

People don't remember facts, they remember emotions.
And people refuse to acknowledge making mistake,
rejecting any arguments, based on facts and logic.

This basically means that things would only get worse.
Derek's dramatic departure put quite a pain in hearths of
the people who consider him a friend.
They would not forgive Carl for that.



For these who are relatively new to the project,
the same crisis has happened before in FFmpeg,
but with different people.

It was Mans who left FFmpeg, because of Michael's
alleged violations of rules and savage behavior.
There was a vote to keep or kick Michael and the vote kept him.
Things then got silent for few months, until Mans returned by
takeover of FFmpeg project and servers, supported by
a big portion of developers and the other admins.

Takeover at the moment is not really plausible,
since the admins won't support it.

What is plausible is that hostility would remain.
There will be more incidents involving Carl,
some people would push for stricter punishments.

Likely outcomes are:
1. Carl leaves on his own.
2. Carl is banned permanently.
3. Derek friends leave FFmpeg one by one.
4. Derek friends fork FFmpeg.

The first two variants does look like they are
going to be best for FFmpeg, however things
are never this simple. Once Carl is gone,
hostility would be directed to anybody who
opposes in any way the friends circle.

What happened to lukasz, would happen
to a lot more developers and contributors.

This would inevitably lead to stagnation,
lack of manpower, lack of new features,
increase in bugs, long delays in handling security exploits.
All things that are quite common in LibAV project
and also some of main reasons for FFmpeg
replacing it in Debian.
After all, this is how LibAV came to be,
as a circle of friends who got rid of
undesirable developer(s).


So what do you really want?

Do you want to ruin FFmpeg? Because that's how you ruin a project.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v7] Add experimental support for vp9 in iso-bmff

[KongQun Yang]

-- KongQun Yang (KQ)

On Wed, Jun 15, 2016 at 3:08 PM, Ronald S. Bultje 
wrote:

> Hi,
>
> On Wed, Jun 15, 2016 at 4:53 PM, Kongqun Yang 
> wrote:
>
>> Implemented according to the draft specification
>> "VP Codec ISO Media File Format Binding":
>>
>> http://www.webmproject.org/vp9/#draft-vp-codec-iso-media-file-format-binding
>>
>> '-strict -2' is required to use this feature.
>>
>> Change-Id: Iaa7ddf5524b17e8d79cd1923b26f096d6e91
>> ---
>>  libavformat/Makefile |   2 +-
>>  libavformat/isom.c   |   3 ++
>>  libavformat/movenc.c |  26 +
>>  libavformat/vpcc.c   | 148
>> +++
>>  libavformat/vpcc.h   |  47 
>>  5 files changed, 225 insertions(+), 1 deletion(-)
>>  create mode 100644 libavformat/vpcc.c
>>  create mode 100644 libavformat/vpcc.h
>
>
> No further comments from me, LGTM but I'd wait a day before push to give
> others a day to re-review also.
>

Sure, thanks for reviewing and all the helpful comments! Btw, are you going
to help commit the change?


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

Re: [FFmpeg-devel] [PATCH] PPC64: Add IBM POWER8 SIMD Implementation

[Dan Parrot]

On Wed, 2016-06-15 at 16:51 +0200, Hendrik Leppkes wrote:
> On Wed, Jun 15, 2016 at 6:25 AM, Dan Parrot  wrote:
> > This is the first commit addressing Trac ticket #5570. Functions defined in
> > libswscale/input.c have corresponding definitions in 
> > libswscale/ppc/input_vsx.h
> > The corresponding function names in the latter contain the suffix "_vsx".
> > ---
> >  libswscale/input.c |  44 +--
> >  libswscale/ppc/input_vsx.h | 831 
> > +
> >  2 files changed, 853 insertions(+), 22 deletions(-)
> >  create mode 100644 libswscale/ppc/input_vsx.h
> >
> > diff --git a/libswscale/input.c b/libswscale/input.c
> > index 14ab5ab..de4347e 100644
> > --- a/libswscale/input.c
> > +++ b/libswscale/input.c
> > @@ -40,6 +40,13 @@
> >  #define r ((origin == AV_PIX_FMT_BGR48BE || origin == AV_PIX_FMT_BGR48LE 
> > || origin == AV_PIX_FMT_BGRA64BE || origin == AV_PIX_FMT_BGRA64LE) ? b_r : 
> > r_b)
> >  #define b ((origin == AV_PIX_FMT_BGR48BE || origin == AV_PIX_FMT_BGR48LE 
> > || origin == AV_PIX_FMT_BGRA64BE || origin == AV_PIX_FMT_BGRA64LE) ? r_b : 
> > b_r)
> >
> > +#ifdef HAVE_VSX
> > +#include "ppc/input_vsx.h"
> > +#define RENAME_SIMD(fname) fname ## _vsx
> > +#elif
> > +#define RENAME_SIMD(fname) fname
> > +#endif
> > +
> >  static av_always_inline void
> >  rgb64ToY_c_template(uint16_t *dst, const uint16_t *src, int width,
> >  enum AVPixelFormat origin, int32_t *rgb2yuv)
> > @@ -99,7 +106,7 @@ static void pattern ## 64 ## BE_LE ## ToY_c(uint8_t 
> > *_dst, const uint8_t *_src,
> >  { \
> >  const uint16_t *src = (const uint16_t *) _src; \
> >  uint16_t *dst = (uint16_t *) _dst; \
> > -rgb64ToY_c_template(dst, src, width, origin, rgb2yuv); \
> > +RENAME_SIMD(rgb64ToY_c_template)(dst, src, width, origin, rgb2yuv); \
> >  } \
> 
> This is not how we integrate SIMD optimizations. These are the C
> functions, they are not meant to perform the SIMD.
> What you should do is provide SIMD functions and then provide a
> SIMD-specific init function that overwrites the function pointers with
> your SIMD functions.
> ie. just how it is done on x86. But do not touch the C functions by
> overriding them right in the code with SIMD variants, making the C
> variants inaccessible.

1. The #ifdef HAVE_VSX at the top of the file should actually be #if
HAVE_VSX. The intent is for C variants of functions to be replaced by
SIMD versions. But only for PowerPC machines that have Vector-Scalar
hardware. All other machines will retain exactly the same function names
they currently possess. Would that change eliminate this particular
objection?

2. To achieve the same effect using the style done for x86 requires more
code. Just considering the first function in input.c, one must provide:
i. A SIMD implementation of rgb64ToY_c_template
ii. Definitions for results of the 4 macro expansions of rgb64funcs.
These are the functions that actually instantiate rgb64ToY_c_template
iii. Replication of all the code in ff_sws_init_input_funcs that assigns
the results of item ii. above to function pointers.

Why is the x86 approach preferred over the seemingly simpler
preprocessor renaming?

> 
> >   \
> >  static void pattern ## 64 ## BE_LE ## ToUV_c(uint8_t *_dstU, uint8_t 
> > *_dstV, \
> > @@ -109,7 +116,7 @@ static void pattern ## 64 ## BE_LE ## ToUV_c(uint8_t 
> > *_dstU, uint8_t *_dstV, \
> >  const uint16_t *src1 = (const uint16_t *) _src1, \
> > *src2 = (const uint16_t *) _src2; \
> >  uint16_t *dstU = (uint16_t *) _dstU, *dstV = (uint16_t *) _dstV; \
> > -rgb64ToUV_c_template(dstU, dstV, src1, src2, width, origin, rgb2yuv); \
> > +RENAME_SIMD(rgb64ToUV_c_template)(dstU, dstV, src1, src2, width, 
> > origin, rgb2yuv); \
> >  } \
> >   \
> >  static void pattern ## 64 ## BE_LE ## ToUV_half_c(uint8_t *_dstU, uint8_t 
> > *_dstV, \
> > @@ -119,7 +126,7 @@ static void pattern ## 64 ## BE_LE ## 
> > ToUV_half_c(uint8_t *_dstU, uint8_t *_dstV
> >  const uint16_t *src1 = (const uint16_t *) _src1, \
> > *src2 = (const uint16_t *) _src2; \
> >  uint16_t *dstU = (uint16_t *) _dstU, *dstV = (uint16_t *) _dstV; \
> > -rgb64ToUV_half_c_template(dstU, dstV, src1, src2, width, origin, 
> > rgb2yuv); \
> > +RENAME_SIMD(rgb64ToUV_half_c_template)(dstU, dstV, src1, src2, width, 
> > origin, rgb2yuv); \
> >  }
> >
> >  rgb64funcs(rgb, LE, AV_PIX_FMT_RGBA64LE)
> > @@ -203,7 +210,7 @@ static void pattern ## 48 ## BE_LE ## ToY_c(uint8_t 
> > *_dst,  \
> >  {   \
> >  const uint16_t *src = (const uint16_t *)_src;   \
> >  uint16_t *dst   = (uint16_t *)_dst; \
> > -rgb48ToY_c_template(dst, src, width, origin, rgb2yuv);  \
> > +RENAME_SIMD(rgb48ToY_c_template)(dst, src, width, origin, rgb2yuv);
> >   \
> >  }  

Re: [FFmpeg-devel] [PATCH v7] Add experimental support for vp9 in iso-bmff

[Ronald S. Bultje]

Hi,

On Wed, Jun 15, 2016 at 4:53 PM, Kongqun Yang  wrote:

> Implemented according to the draft specification
> "VP Codec ISO Media File Format Binding":
>
> http://www.webmproject.org/vp9/#draft-vp-codec-iso-media-file-format-binding
>
> '-strict -2' is required to use this feature.
>
> Change-Id: Iaa7ddf5524b17e8d79cd1923b26f096d6e91
> ---
>  libavformat/Makefile |   2 +-
>  libavformat/isom.c   |   3 ++
>  libavformat/movenc.c |  26 +
>  libavformat/vpcc.c   | 148
> +++
>  libavformat/vpcc.h   |  47 
>  5 files changed, 225 insertions(+), 1 deletion(-)
>  create mode 100644 libavformat/vpcc.c
>  create mode 100644 libavformat/vpcc.h


No further comments from me, LGTM but I'd wait a day before push to give
others a day to re-review also.

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

Re: [FFmpeg-devel] [PATCH v6] Add experimental support for vp9 in iso-bmff

[KongQun Yang]

-- KongQun Yang (KQ)

On Wed, Jun 15, 2016 at 5:00 AM, Carl Eugen Hoyos  wrote:

> Kongqun Yang  gmail.com> writes:
>
> > +} else if (chroma_w == 0 && chroma_h == 0) {
> > +return VPX_SUBSAMPLING_444;
>
> Could you confirm that this fixes RGB encoding?
> I believe this was broken in your previous patch.
>

Yes, RGB is now supported (chroma subsampling is VPX_SUBSAMPLING_444).

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

Re: [FFmpeg-devel] [PATCH v5] Add experimental support for vp9 in iso-bmff

[KongQun Yang]

Thanks for the review, uploaded patch v7 with two changes:
1. Use AVFormatContext as the logging context
2. Renamed the file from vpc.c/vpc.h to vpcc.c/vpcc.h

Please take another look.

-- KongQun Yang (KQ)

On Tue, Jun 14, 2016 at 11:27 PM, Hendrik Leppkes 
wrote:

> On Wed, Jun 15, 2016 at 3:25 AM, KongQun Yang
>  wrote:
> > -- KongQun Yang (KQ)
> >
> > On Tue, Jun 14, 2016 at 4:20 PM, Ronald S. Bultje 
> > wrote:
> >
> >> Hi,
> >>
> >> On Tue, Jun 14, 2016 at 6:05 PM, Kongqun Yang 
> >> wrote:
> >>
> >>> +default:
> >>> +av_log(NULL, AV_LOG_ERROR, "Unsupported color space (%d)\n",
> >>> +   color_space);
> >>> +return -1;
> >>>
> >> [..]
> >>
> >>> +default:
> >>> +av_log(NULL, AV_LOG_ERROR, "Unsupported pixel format (%d)\n",
> >>> +   pixel_format);
> >>> +return -1;
> >>>
> >> [..]
> >>
> >>> +if (desc == NULL) {
> >>> +av_log(NULL, AV_LOG_ERROR, "Unsupported pixel format (%d)\n",
> >>> +   pixel_format);
> >>> +return -1;
> >>>
> >>
> >> You're still logging without a context (first argument), can you please
> >> provide one so people know which muxer is complaining about these error
> >> messages?
> >>
> >
> > Are you ok with using "AVIOContext" as the context?
> >
>
> Thats an odd choice for logging.
> If there is no natural logging context, you should just add a "void*
> logctx" argument to the new function you introduced, its what is
> commonly done in other places. That way the mov muxer can then pass a
> reference to the AVFormatContext in there for more natural logging.
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v7] Add experimental support for vp9 in iso-bmff

[Kongqun Yang]

Implemented according to the draft specification
"VP Codec ISO Media File Format Binding":
http://www.webmproject.org/vp9/#draft-vp-codec-iso-media-file-format-binding

'-strict -2' is required to use this feature.

Change-Id: Iaa7ddf5524b17e8d79cd1923b26f096d6e91
---
 libavformat/Makefile |   2 +-
 libavformat/isom.c   |   3 ++
 libavformat/movenc.c |  26 +
 libavformat/vpcc.c   | 148 +++
 libavformat/vpcc.h   |  47 
 5 files changed, 225 insertions(+), 1 deletion(-)
 create mode 100644 libavformat/vpcc.c
 create mode 100644 libavformat/vpcc.h

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 6684ead..dc7daca 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -276,7 +276,7 @@ OBJS-$(CONFIG_MM_DEMUXER)+= mm.o
 OBJS-$(CONFIG_MMF_DEMUXER)   += mmf.o
 OBJS-$(CONFIG_MMF_MUXER) += mmf.o rawenc.o
 OBJS-$(CONFIG_MOV_DEMUXER)   += mov.o mov_chan.o replaygain.o
-OBJS-$(CONFIG_MOV_MUXER) += movenc.o avc.o hevc.o \
+OBJS-$(CONFIG_MOV_MUXER) += movenc.o avc.o hevc.o vpcc.o \
 movenchint.o mov_chan.o rtp.o \
 movenccenc.o rawutils.o
 OBJS-$(CONFIG_MP2_MUXER) += mp3enc.o rawenc.o id3v2enc.o
diff --git a/libavformat/isom.c b/libavformat/isom.c
index b1757e2..9a65268 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -59,6 +59,7 @@ const AVCodecTag ff_mp4_obj_type[] = {
 { AV_CODEC_ID_AC3 , 0xA5 },
 { AV_CODEC_ID_EAC3, 0xA6 },
 { AV_CODEC_ID_DTS , 0xA9 }, /* mp4ra.org */
+{ AV_CODEC_ID_VP9 , 0xC0 }, /* non standard, update when there is 
a standard value */
 { AV_CODEC_ID_TSCC2   , 0xD0 }, /* non standard, camtasia uses it */
 { AV_CODEC_ID_VORBIS  , 0xDD }, /* non standard, gpac uses it */
 { AV_CODEC_ID_DVD_SUBTITLE, 0xE0 }, /* non standard, see 
unsupported-embedded-subs-2.mp4 */
@@ -179,6 +180,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
 { AV_CODEC_ID_H264, MKTAG('a', 'i', 'v', 'x') }, /* XAVC 4:2:2 10bit */
 { AV_CODEC_ID_H264, MKTAG('r', 'v', '6', '4') }, /* X-Com Radvision */
 
+{ AV_CODEC_ID_VP9,  MKTAG('v', 'p', '0', '9') }, /* VP9 */
+
 { AV_CODEC_ID_MPEG1VIDEO, MKTAG('m', '1', 'v', ' ') },
 { AV_CODEC_ID_MPEG1VIDEO, MKTAG('m', '1', 'v', '1') }, /* Apple MPEG-1 
Camcorder */
 { AV_CODEC_ID_MPEG1VIDEO, MKTAG('m', 'p', 'e', 'g') }, /* MPEG */
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 2f00091..837e1e5 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -49,6 +49,7 @@
 #include "hevc.h"
 #include "rtpenc.h"
 #include "mov_chan.h"
+#include "vpcc.h"
 
 static const AVOption options[] = {
 { "movflags", "MOV muxer flags", offsetof(MOVMuxContext, flags), 
AV_OPT_TYPE_FLAGS, {.i64 = 0}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
@@ -1039,6 +1040,17 @@ static int mov_write_avcc_tag(AVIOContext *pb, MOVTrack 
*track)
 return update_size(pb, pos);
 }
 
+static int mov_write_vpcc_tag(AVFormatContext *s, AVIOContext *pb, MOVTrack 
*track)
+{
+int64_t pos = avio_tell(pb);
+
+avio_wb32(pb, 0);
+ffio_wfourcc(pb, "vpcC");
+avio_wb32(pb, 0); /* version & flags */
+ff_isom_write_vpcc(s, pb, track->par);
+return update_size(pb, pos);
+}
+
 static int mov_write_hvcc_tag(AVIOContext *pb, MOVTrack *track)
 {
 int64_t pos = avio_tell(pb);
@@ -1143,6 +1155,7 @@ static int mp4_get_codec_tag(AVFormatContext *s, MOVTrack 
*track)
 
 if  (track->par->codec_id == AV_CODEC_ID_H264)  tag = 
MKTAG('a','v','c','1');
 else if (track->par->codec_id == AV_CODEC_ID_HEVC)  tag = 
MKTAG('h','e','v','1');
+else if (track->par->codec_id == AV_CODEC_ID_VP9)   tag = 
MKTAG('v','p','0','9');
 else if (track->par->codec_id == AV_CODEC_ID_AC3)   tag = 
MKTAG('a','c','-','3');
 else if (track->par->codec_id == AV_CODEC_ID_EAC3)  tag = 
MKTAG('e','c','-','3');
 else if (track->par->codec_id == AV_CODEC_ID_DIRAC) tag = 
MKTAG('d','r','a','c');
@@ -1758,6 +1771,8 @@ static int mov_write_video_tag(AVIOContext *pb, 
MOVMuxContext *mov, MOVTrack *tr
 mov_write_avcc_tag(pb, track);
 if (track->mode == MODE_IPOD)
 mov_write_uuid_tag_ipod(pb);
+} else if (track->par->codec_id == AV_CODEC_ID_VP9) {
+mov_write_vpcc_tag(mov->fc, pb, track);
 } else if (track->par->codec_id == AV_CODEC_ID_VC1 && track->vos_len > 0)
 mov_write_dvc1_tag(pb, track);
 else if (track->par->codec_id == AV_CODEC_ID_VP6F ||
@@ -5369,6 +5384,17 @@ static int mov_write_header(AVFormatContext *s)
 pix_fmt == AV_PIX_FMT_MONOWHITE ||
 pix_fmt == AV_PIX_FMT_MONOBLACK;
 }
+if (track->mode == MODE_MP4 &&
+track->par->codec_id == 

Re: [FFmpeg-devel] [PATCH v4] Add experimental support for vp9 in iso-bmff

[KongQun Yang]

Please take a look at patchset v5. Thanks.

-- KongQun Yang (KQ)

On Tue, Jun 14, 2016 at 2:58 PM, Ronald S. Bultje 
wrote:

> Hi,
>
> On Tue, Jun 14, 2016 at 5:52 PM, Kongqun Yang 
> wrote:
>
>> +if (profile == FF_PROFILE_UNKNOWN) {
>> +  if (vpx_chroma_subsampling == VPX_SUBSAMPLING_420_VERTICAL ||
>>
>
> Indent is still 2 spaces in the second block (relative to first).
>

Oops, missed this one. Thanks.

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

[FFmpeg-devel] [PATCH] lavd/v4l2: allow devices not implementing VIDIOC_G_PARM

[Niklas Söderlund]

Not all v4l2 devices implement the VIDIOC_G_PARM ioctl. This patch allow
ffmpeg to open such device and treat it the same as devices that do
implement the ioctl but returns that it do not implement the
V4L2_CAP_TIMEPERFRAME capability.

Signed-off-by: Niklas Söderlund 
---
 libavdevice/v4l2.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index 103fb10..c8915e0 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -715,11 +715,8 @@ static int v4l2_set_parameters(AVFormatContext *ctx)
 streamparm.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
 if (v4l2_ioctl(s->fd, VIDIOC_G_PARM, ) < 0) {
 ret = AVERROR(errno);
-av_log(ctx, AV_LOG_ERROR, "ioctl(VIDIOC_G_PARM): %s\n", 
av_err2str(ret));
-return ret;
-}
-
-if (framerate_q.num && framerate_q.den) {
+av_log(ctx, AV_LOG_WARNING, "ioctl(VIDIOC_G_PARM): %s\n", 
av_err2str(ret));
+} else if (framerate_q.num && framerate_q.den) {
 if (streamparm.parm.capture.capability & V4L2_CAP_TIMEPERFRAME) {
 tpf = 
 
-- 
2.8.3

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

Re: [FFmpeg-devel] [PATCH] fate: add swr-resample_exact_async tests

[Muhammad Faiz]

On Wed, Jun 15, 2016 at 4:21 PM, Michael Niedermayer
 wrote:
> On Wed, Jun 15, 2016 at 02:02:48PM +0700, Muhammad Faiz wrote:
>> Signed-off-by: Muhammad Faiz 
>> ---
>>  tests/fate/libswresample.mak | 87 
>> 
>>  1 file changed, 87 insertions(+)
>
> LGTM
>
> thx
>
applied

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

Re: [FFmpeg-devel] [PATCH] fate: add afade tes

[Muhammad Faiz]

On Tue, Jun 14, 2016 at 11:44 PM, Petru Rares Sincraian
 wrote:
> I look the code for some time but I don't know how to express the dependency. 
> I think it's ok because it uses FATE_AFILTER_SAMPLES and then this variable 
> is added to FATE_SAMPLES_AVCONV.
>
>
> Muhammad which command did you execute to reproduce the error?
>
this has been already fixed by Michael

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

[FFmpeg-devel] [PATCH 2/2] swresample/x86: add support for exact_rational

[Muhammad Faiz]

phase_shift and phase_mask is removed
generally exact_rational=on is faster than exact_rational=off 

Signed-off-by: Muhammad Faiz 
---
 libswresample/resample.c  |  2 -
 libswresample/resample.h  |  3 --
 libswresample/x86/resample.asm| 87 +--
 libswresample/x86/resample_init.c |  4 --
 4 files changed, 46 insertions(+), 50 deletions(-)

diff --git a/libswresample/resample.c b/libswresample/resample.c
index 3b01408..0952f2b 100644
--- a/libswresample/resample.c
+++ b/libswresample/resample.c
@@ -349,8 +349,6 @@ static ResampleContext *resample_init(ResampleContext *c, 
int out_rate, int in_r
 goto error;
 }
 
-c->phase_shift   = phase_shift;
-c->phase_mask= phase_count - 1;
 c->phase_count   = phase_count;
 c->linear= linear;
 c->factor= factor;
diff --git a/libswresample/resample.h b/libswresample/resample.h
index 2c29959..ff0dec1 100644
--- a/libswresample/resample.h
+++ b/libswresample/resample.h
@@ -40,9 +40,6 @@ typedef struct ResampleContext {
 int frac;
 int src_incr;
 int compensation_distance;
-/* TODO remove phase_shift and phase_mask */
-attribute_deprecated int phase_shift;
-attribute_deprecated int phase_mask;
 int phase_count;
 int linear;
 enum SwrFilterType filter_type;
diff --git a/libswresample/x86/resample.asm b/libswresample/x86/resample.asm
index 4989aa6..4163df1 100644
--- a/libswresample/x86/resample.asm
+++ b/libswresample/x86/resample.asm
@@ -41,8 +41,7 @@ struc ResampleContext
 .frac:  resd 1
 .src_incr:  resd 1
 .compensation_distance: resd 1
-.phase_shift:   resd 1
-.phase_mask:resd 1
+.phase_count:   resd 1
 
 ; there's a few more here but we only care about the first few
 endstruc
@@ -55,11 +54,12 @@ pd_0x4000: dd 0x4000
 
 SECTION .text
 
+; FIXME remove unneeded variables (index_incr, phase_mask)
 %macro RESAMPLE_FNS 3-5 ; format [float or int16], bps, log2_bps, float op 
suffix [s or d], 1.0 constant
 ; int resample_common_$format(ResampleContext *ctx, $format *dst,
 ; const $format *src, int size, int update_ctx)
 %if ARCH_X86_64 ; unix64 and win64
-cglobal resample_common_%1, 0, 15, 2, ctx, dst, src, phase_shift, index, frac, 
\
+cglobal resample_common_%1, 0, 15, 2, ctx, dst, src, phase_count, index, frac, 
\
   dst_incr_mod, size, min_filter_count_x4, 
\
   min_filter_len_x4, dst_incr_div, 
src_incr, \
   phase_mask, dst_end, filter_bank
@@ -76,7 +76,6 @@ cglobal resample_common_%1, 0, 15, 2, ctx, dst, src, 
phase_shift, index, frac, \
 ; load as many variables in registers as possible; for the rest, store
 ; on stack so that we have 'ctx' available as one extra register
 movsized, r3d
-mov  phase_maskd, [ctxq+ResampleContext.phase_mask]
 %if UNIX64
 movupdate_context_stackd, r4d
 %endif
@@ -92,17 +91,17 @@ cglobal resample_common_%1, 0, 15, 2, ctx, dst, src, 
phase_shift, index, frac, \
 lea dst_endq, [dstq+sizeq*%2]
 
 %if UNIX64
-mov  ecx, [ctxq+ResampleContext.phase_shift]
+mov  ecx, [ctxq+ResampleContext.phase_count]
 mov  edi, [ctxq+ResampleContext.filter_alloc]
 
-DEFINE_ARGS filter_alloc, dst, src, phase_shift, index, frac, 
dst_incr_mod, \
+DEFINE_ARGS filter_alloc, dst, src, phase_count, index, frac, 
dst_incr_mod, \
 filter, min_filter_count_x4, min_filter_len_x4, dst_incr_div, \
 src_incr, phase_mask, dst_end, filter_bank
 %elif WIN64
 mov  R9d, [ctxq+ResampleContext.filter_alloc]
-mov  ecx, [ctxq+ResampleContext.phase_shift]
+mov  ecx, [ctxq+ResampleContext.phase_count]
 
-DEFINE_ARGS phase_shift, dst, src, filter_alloc, index, frac, 
dst_incr_mod, \
+DEFINE_ARGS phase_count, dst, src, filter_alloc, index, frac, 
dst_incr_mod, \
 filter, min_filter_count_x4, min_filter_len_x4, dst_incr_div, \
 src_incr, phase_mask, dst_end, filter_bank
 %endif
@@ -112,7 +111,7 @@ cglobal resample_common_%1, 0, 15, 2, ctx, dst, src, 
phase_shift, index, frac, \
 sub srcq, min_filter_len_x4q
 mov   src_stackq, srcq
 %else ; x86-32
-cglobal resample_common_%1, 1, 7, 2, ctx, phase_shift, dst, frac, \
+cglobal resample_common_%1, 1, 7, 2, ctx, phase_count, dst, frac, \
  index, min_filter_length_x4, filter_bank
 
 ; push temp variables to stack
@@ -127,7 +126,7 @@ cglobal resample_common_%1, 1, 7, 2, ctx, phase_shift, dst, 
frac, \
 PUSH   

[FFmpeg-devel] [PATCH 1/2] swresample: fix phase_count calculation

[Muhammad Faiz]

support odd phase_count
stick to low phase_count until set_compensation is called

Signed-off-by: Muhammad Faiz 
---
 libswresample/resample.c | 83 +---
 libswresample/resample.h |  1 +
 2 files changed, 73 insertions(+), 11 deletions(-)

diff --git a/libswresample/resample.c b/libswresample/resample.c
index 1b1d83e..3b01408 100644
--- a/libswresample/resample.c
+++ b/libswresample/resample.c
@@ -144,9 +144,10 @@ static double bessel(double x) {
 static int build_filter(ResampleContext *c, void *filter, double factor, int 
tap_count, int alloc, int phase_count, int scale,
 int filter_type, double kaiser_beta){
 int ph, i;
+int ph_nb = phase_count % 2 ? phase_count : phase_count / 2 + 1;
 double x, y, w, t, s;
 double *tab = av_malloc_array(tap_count+1,  sizeof(*tab));
-double *sin_lut = av_malloc_array(phase_count / 2 + 1, sizeof(*sin_lut));
+double *sin_lut = av_malloc_array(ph_nb, sizeof(*sin_lut));
 const int center= (tap_count-1)/2;
 
 if (!tab || !sin_lut)
@@ -156,13 +157,11 @@ static int build_filter(ResampleContext *c, void *filter, 
double factor, int tap
 if (factor > 1.0)
 factor = 1.0;
 
-av_assert0(phase_count == 1 || phase_count % 2 == 0);
-
 if (factor == 1.0) {
-for (ph = 0; ph <= phase_count / 2; ph++)
+for (ph = 0; ph < ph_nb; ph++)
 sin_lut[ph] = sin(M_PI * ph / phase_count);
 }
-for(ph = 0; ph <= phase_count / 2; ph++) {
+for(ph = 0; ph < ph_nb; ph++) {
 double norm = 0;
 s = sin_lut[ph];
 for(i=0;i<=tap_count;i++) {
@@ -203,6 +202,7 @@ static int build_filter(ResampleContext *c, void *filter, 
double factor, int tap
 case AV_SAMPLE_FMT_S16P:
 for(i=0;i 1 && 
phase_count_exact < INT_MAX/2)
-phase_count_exact *= 2;
-
 if (phase_count_exact <= phase_count) {
-/* FIXME this is not required when soft compensation is disabled */
-phase_count_exact *= phase_count / phase_count_exact;
+phase_count_comp = phase_count_exact * (phase_count / 
phase_count_exact);
 phase_count = phase_count_exact;
 }
 }
@@ -360,6 +359,7 @@ static ResampleContext *resample_init(ResampleContext *c, 
int out_rate, int in_r
 c->filter_bank   = av_calloc(c->filter_alloc, 
(phase_count+1)*c->felem_size);
   

Re: [FFmpeg-devel] bans

[Felt, Patrick]

On 6/15/16, 7:50 AM, "ffmpeg-devel on behalf of James Almer" 
 wrote:

>On 6/15/2016 10:14 AM, Michael Niedermayer wrote:
>> After writing this mail i will
>> 
>> 1. ban carl for 24h from the ML due to
>> causing  derek to leave the project. (24h was suggested in the IRC
>> meeting)
>
>This is useless IMO. While four months is too much, 24 hours is
>insignificant.

Might I throw in an exponential backoff algorithm?  Perhaps every incident 
incurs a 24 hour ban with a one month half-life or some such thing.  Once a 
person passes above a 24h ban they are actually banned for some time.  It’s 
worked for BGP for a lot of years.

>
>> 2. ban derek for ~24h from the ML
>> 
>> 3. ban myself for ~24h from the ML

>And this is silly. It's old history and nobody requested such action in
>any what whatsoever. It will only derail the discussion and again, bans
>without discussion or vote are a big no.
>

I also think all the current bans are silly.  Retroactively applying rules that 
were voted on today to issues that happened in the past, for any value of past, 
is not something that I think is appropriate.  What’s happened on all fronts is 
a horrible shame, but it seems that a consistent set of rules going forward and 
water under the bridge presently is a better way to go of it.  Don’t we all 
have better things to do that squabble over this?  I see a lot of amazing stuff 
coming in patches.



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

Re: [FFmpeg-devel] [PATCH] lavf/srtdec: fix probing files with negative first timestamps

[Clément Bœsch]

On Thu, Jun 09, 2016 at 11:01:54PM -0500, Rodger Combs wrote:
> ---
>  libavformat/srtdec.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/srtdec.c b/libavformat/srtdec.c
> index 585aa6a..9ab7a4e 100644
> --- a/libavformat/srtdec.c
> +++ b/libavformat/srtdec.c
> @@ -52,7 +52,10 @@ static int srt_probe(AVProbeData *p)
>  /* Check if the next line matches a SRT timestamp */
>  if (ff_subtitles_read_line(, buf, sizeof(buf)) < 0)
>  return 0;
> -if (buf[0] >= '0' && buf[0] <= '9' && strstr(buf, " --> ")
> +pbuf = buf;
> +if (buf[0] == '-')
> +  pbuf++;
> +if (pbuf[0] >= '0' && pbuf[0] <= '9' && strstr(buf, " --> ")
>  && sscanf(buf, "%*d:%*d:%*d%*1[,.]%*d --> %*d:%*d:%*d%*1[,.]%d", ) 
> == 1)
>  return AVPROBE_SCORE_MAX;

Wrong indent but looks fine functionally.

Thanks

-- 
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] PPC64: Add IBM POWER8 SIMD Implementation

[Dan Parrot]

On Wed, 2016-06-15 at 11:19 +, Carl Eugen Hoyos wrote:
> Dan Parrot  mail.com> writes:
> 
> [...]
> 
> I know this is isn't completely related but do you have time 
> to look at ticket #5508?
> https://trac.ffmpeg.org/ticket/5508
> No active developer has hardware and knowledge to look into 
> this issue;-(
> 
> Carl Eugen
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

I hope to have some time this weekend. We'll see how much progress I can
make on the ticket then.


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

Re: [FFmpeg-devel] [PATCH] tools: update normalize script example to use loudnorm

[Clément Bœsch]

On Wed, Jun 15, 2016 at 09:40:41AM -0500, Kyle Swanson wrote:
> On Mon, Jun 13, 2016 at 3:23 AM, Clément Bœsch  wrote:
> > On Sun, Jun 12, 2016 at 10:44:15PM -0500, Kyle Swanson wrote:
> >> Signed-off-by: Kyle Swanson 
> >> ---
> >>  tools/normalize.py | 33 --
> >>  tools/normalize.rb | 60 
> >> ++
> >>  2 files changed, 60 insertions(+), 33 deletions(-)
> >>  delete mode 100755 tools/normalize.py
> >>  create mode 100644 tools/normalize.rb
> >>
> >
> > Please de not delete normalize.py
> 
> We have a filter that does this now, if we're distributing a loudness
> normalization script it should be using the loudnorm filter.
> 

Add your script if you want, but keep the current one in place. You can
also rename them normalize-ebur128 and normalize-lourdnorm.

-- 
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] PPC64: Add IBM POWER8 SIMD Implementation

[Hendrik Leppkes]

On Wed, Jun 15, 2016 at 6:25 AM, Dan Parrot  wrote:
> This is the first commit addressing Trac ticket #5570. Functions defined in
> libswscale/input.c have corresponding definitions in 
> libswscale/ppc/input_vsx.h
> The corresponding function names in the latter contain the suffix "_vsx".
> ---
>  libswscale/input.c |  44 +--
>  libswscale/ppc/input_vsx.h | 831 
> +
>  2 files changed, 853 insertions(+), 22 deletions(-)
>  create mode 100644 libswscale/ppc/input_vsx.h
>
> diff --git a/libswscale/input.c b/libswscale/input.c
> index 14ab5ab..de4347e 100644
> --- a/libswscale/input.c
> +++ b/libswscale/input.c
> @@ -40,6 +40,13 @@
>  #define r ((origin == AV_PIX_FMT_BGR48BE || origin == AV_PIX_FMT_BGR48LE || 
> origin == AV_PIX_FMT_BGRA64BE || origin == AV_PIX_FMT_BGRA64LE) ? b_r : r_b)
>  #define b ((origin == AV_PIX_FMT_BGR48BE || origin == AV_PIX_FMT_BGR48LE || 
> origin == AV_PIX_FMT_BGRA64BE || origin == AV_PIX_FMT_BGRA64LE) ? r_b : b_r)
>
> +#ifdef HAVE_VSX
> +#include "ppc/input_vsx.h"
> +#define RENAME_SIMD(fname) fname ## _vsx
> +#elif
> +#define RENAME_SIMD(fname) fname
> +#endif
> +
>  static av_always_inline void
>  rgb64ToY_c_template(uint16_t *dst, const uint16_t *src, int width,
>  enum AVPixelFormat origin, int32_t *rgb2yuv)
> @@ -99,7 +106,7 @@ static void pattern ## 64 ## BE_LE ## ToY_c(uint8_t *_dst, 
> const uint8_t *_src,
>  { \
>  const uint16_t *src = (const uint16_t *) _src; \
>  uint16_t *dst = (uint16_t *) _dst; \
> -rgb64ToY_c_template(dst, src, width, origin, rgb2yuv); \
> +RENAME_SIMD(rgb64ToY_c_template)(dst, src, width, origin, rgb2yuv); \
>  } \

This is not how we integrate SIMD optimizations. These are the C
functions, they are not meant to perform the SIMD.

What you should do is provide SIMD functions and then provide a
SIMD-specific init function that overwrites the function pointers with
your SIMD functions.
ie. just how it is done on x86. But do not touch the C functions by
overriding them right in the code with SIMD variants, making the C
variants inaccessible.

>   \
>  static void pattern ## 64 ## BE_LE ## ToUV_c(uint8_t *_dstU, uint8_t *_dstV, 
> \
> @@ -109,7 +116,7 @@ static void pattern ## 64 ## BE_LE ## ToUV_c(uint8_t 
> *_dstU, uint8_t *_dstV, \
>  const uint16_t *src1 = (const uint16_t *) _src1, \
> *src2 = (const uint16_t *) _src2; \
>  uint16_t *dstU = (uint16_t *) _dstU, *dstV = (uint16_t *) _dstV; \
> -rgb64ToUV_c_template(dstU, dstV, src1, src2, width, origin, rgb2yuv); \
> +RENAME_SIMD(rgb64ToUV_c_template)(dstU, dstV, src1, src2, width, origin, 
> rgb2yuv); \
>  } \
>   \
>  static void pattern ## 64 ## BE_LE ## ToUV_half_c(uint8_t *_dstU, uint8_t 
> *_dstV, \
> @@ -119,7 +126,7 @@ static void pattern ## 64 ## BE_LE ## ToUV_half_c(uint8_t 
> *_dstU, uint8_t *_dstV
>  const uint16_t *src1 = (const uint16_t *) _src1, \
> *src2 = (const uint16_t *) _src2; \
>  uint16_t *dstU = (uint16_t *) _dstU, *dstV = (uint16_t *) _dstV; \
> -rgb64ToUV_half_c_template(dstU, dstV, src1, src2, width, origin, 
> rgb2yuv); \
> +RENAME_SIMD(rgb64ToUV_half_c_template)(dstU, dstV, src1, src2, width, 
> origin, rgb2yuv); \
>  }
>
>  rgb64funcs(rgb, LE, AV_PIX_FMT_RGBA64LE)
> @@ -203,7 +210,7 @@ static void pattern ## 48 ## BE_LE ## ToY_c(uint8_t 
> *_dst,  \
>  {   \
>  const uint16_t *src = (const uint16_t *)_src;   \
>  uint16_t *dst   = (uint16_t *)_dst; \
> -rgb48ToY_c_template(dst, src, width, origin, rgb2yuv);  \
> +RENAME_SIMD(rgb48ToY_c_template)(dst, src, width, origin, rgb2yuv);  
> \
>  }   \
>  \
>  static void pattern ## 48 ## BE_LE ## ToUV_c(uint8_t *_dstU,\
> @@ -218,7 +225,7 @@ static void pattern ## 48 ## BE_LE ## ToUV_c(uint8_t 
> *_dstU,\
> *src2 = (const uint16_t *)_src2; \
>  uint16_t *dstU = (uint16_t *)_dstU, \
>   *dstV = (uint16_t *)_dstV; \
> -rgb48ToUV_c_template(dstU, dstV, src1, src2, width, origin, rgb2yuv);
> \
> +RENAME_SIMD(rgb48ToUV_c_template)(dstU, dstV, src1, src2, width, origin, 
> rgb2yuv);\
>  }   \
>  \
>  static void pattern ## 48 ## BE_LE ## ToUV_half_c(uint8_t *_dstU,   \
> @@ -233,7 +240,7 @@ static void pattern ## 48 ## BE_LE ## ToUV_half_c(uint8_t 
> *_dstU,   \
> *src2 = (const uint16_t *)_src2; 

Re: [FFmpeg-devel] [PATCH] tools: update normalize script example to use loudnorm

[Hendrik Leppkes]

On Wed, Jun 15, 2016 at 4:40 PM, Kyle Swanson  wrote:
> On Mon, Jun 13, 2016 at 3:23 AM, Clément Bœsch  wrote:
>> On Sun, Jun 12, 2016 at 10:44:15PM -0500, Kyle Swanson wrote:
>>> Signed-off-by: Kyle Swanson 
>>> ---
>>>  tools/normalize.py | 33 --
>>>  tools/normalize.rb | 60 
>>> ++
>>>  2 files changed, 60 insertions(+), 33 deletions(-)
>>>  delete mode 100755 tools/normalize.py
>>>  create mode 100644 tools/normalize.rb
>>>
>>
>> Please de not delete normalize.py
>
> We have a filter that does this now, if we're distributing a loudness
> normalization script it should be using the loudnorm filter.
>

One key point, changing the script to use another filter is one thing,
entirely changing the language its written in .. maybe not quite as
expected of a change.
If anything the syntax of the script should remain the same and it
should do the same (and require the same interpreter), if it
internally does something else, thats fine by me. Unless ubitux
prefers the old one for testing purposes to keep existing.

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

Re: [FFmpeg-devel] [PATCH] lavc/mediacodec: refactor ff_AMediaCodecList_getCodecByType

[Matthieu Bouron]

On Mon, Jun 13, 2016 at 02:47:45PM +0200, Matthieu Bouron wrote:
> On Wed, Jun 08, 2016 at 11:19:51PM +0200, Matthieu Bouron wrote:
> > From: Matthieu Bouron 
> > 
> > Allows to select a codec (encoder or decoder) only if it supports a
> > specific profile.
> > 
> > Adds ff_AMediaCodecProfile_getProfileFromAVCodecContext to convert an
> > AVCodecContext profile to a MediaCodec profile. It only supports H264
> > for now.
> > 
> > The codepath using MediaCodecList.findDecoderForFormat() (Android >= 5.0)
> > has been dropped as this method does not allow to select a decoder
> > compatible with a specific profile.
> > ---
> 
> If there is no objection, I will push this patch in one day.

Pushed.

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

Re: [FFmpeg-devel] [PATCH] tools: update normalize script example to use loudnorm

[Kyle Swanson]

On Mon, Jun 13, 2016 at 3:23 AM, Clément Bœsch  wrote:
> On Sun, Jun 12, 2016 at 10:44:15PM -0500, Kyle Swanson wrote:
>> Signed-off-by: Kyle Swanson 
>> ---
>>  tools/normalize.py | 33 --
>>  tools/normalize.rb | 60 
>> ++
>>  2 files changed, 60 insertions(+), 33 deletions(-)
>>  delete mode 100755 tools/normalize.py
>>  create mode 100644 tools/normalize.rb
>>
>
> Please de not delete normalize.py

We have a filter that does this now, if we're distributing a loudness
normalization script it should be using the loudnorm filter.

>
> Regards,
>
> --
> Clément B.
>
> ___
> 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] PPC64: Add IBM POWER8 SIMD Implementation

[Dan Parrot]

On Wed, 2016-06-15 at 10:15 +0200, Michael Niedermayer wrote:
> On Wed, Jun 15, 2016 at 04:25:11AM +, Dan Parrot wrote:
> > This is the first commit addressing Trac ticket #5570. Functions defined in
> > libswscale/input.c have corresponding definitions in 
> > libswscale/ppc/input_vsx.h
> > The corresponding function names in the latter contain the suffix "_vsx".
> > ---
> >  libswscale/input.c |  44 +--
> >  libswscale/ppc/input_vsx.h | 831 
> > +
> >  2 files changed, 853 insertions(+), 22 deletions(-)
> >  create mode 100644 libswscale/ppc/input_vsx.h
> 
> breaks build on x86
>  ./configure && make -j12
> In file included from libswscale/input.c:44:0:
> libswscale/ppc/input_vsx.h: In function ‘rgb64ToY_c_template_vsx’:
> libswscale/ppc/input_vsx.h:34:5: error: ‘vector’ undeclared (first use in 
> this function)
> libswscale/ppc/input_vsx.h:34:5: note: each undeclared identifier is reported 
> only once for each function it appears in
> libswscale/ppc/input_vsx.h:34:12: error: expected ‘;’ before ‘int’
> libswscale/ppc/input_vsx.h:35:12: error: expected ‘;’ before ‘int’
> libswscale/ppc/input_vsx.h:36:12: error: expected ‘;’ before ‘int’
> 
> [...]
> > @@ -978,7 +984,6 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
> >  case AV_PIX_FMT_GBRP9LE:
> >  c->readChrPlanar = planar_rgb9le_to_uv;
> >  break;
> > -case AV_PIX_FMT_GBRAP10LE:
> >  case AV_PIX_FMT_GBRP10LE:
> >  c->readChrPlanar = planar_rgb10le_to_uv;
> >  break;
> > @@ -996,7 +1001,6 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
> >  case AV_PIX_FMT_GBRP9BE:
> >  c->readChrPlanar = planar_rgb9be_to_uv;
> >  break;
> > -case AV_PIX_FMT_GBRAP10BE:
> >  case AV_PIX_FMT_GBRP10BE:
> >  c->readChrPlanar = planar_rgb10be_to_uv;
> >  break;
> > @@ -1260,8 +1264,6 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
> >  case AV_PIX_FMT_GBRP9LE:
> >  c->readLumPlanar = planar_rgb9le_to_y;
> >  break;
> > -case AV_PIX_FMT_GBRAP10LE:
> > -c->readAlpPlanar = planar_rgb10le_to_a;
> >  case AV_PIX_FMT_GBRP10LE:
> >  c->readLumPlanar = planar_rgb10le_to_y;
> >  break;
> > @@ -1281,8 +1283,6 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
> >  case AV_PIX_FMT_GBRP9BE:
> >  c->readLumPlanar = planar_rgb9be_to_y;
> >  break;
> > -case AV_PIX_FMT_GBRAP10BE:
> > -c->readAlpPlanar = planar_rgb10be_to_a;
> >  case AV_PIX_FMT_GBRP10BE:
> >  c->readLumPlanar = planar_rgb10be_to_y;
> >  break;
> 
> why do you remove these ?
> thats not ppc related
> 
> [...]
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Did not intend to touch anything non-PPC. I didn't review git diff
carefully enough. I'll resend patch with modifications only for PPC.


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

Re: [FFmpeg-devel] bans

[Reto Kromer]

Michael Niedermayer wrote:

>1. ban carl for 24h

>2. ban derek for ~24h

>3. ban myself for ~24h

May I suggest to stop the Kindergarten for the next 24
years?

Kindest regards, Reto

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

Re: [FFmpeg-devel] bans

[James Almer]

On 6/15/2016 10:14 AM, Michael Niedermayer wrote:
> Hi all
> 
> As noone is doing anything about the situation and what is being
> done will not lead anywhere (the vote likely wont lead anywhere as
> likely few would ban a active developer 4 month and then if not
> some will feel injustice prevailed thus
> 
> After writing this mail i will
> 
> 1. ban carl for 24h from the ML due to
> causing  derek to leave the project. (24h was suggested in the IRC
> meeting)

This is useless IMO. While four months is too much, 24 hours is
insignificant.

Let's not implement bans without a discussion and a vote first.
The current vote will probably go nowhere, so a proper discussion thread
followed by a vote will have to be made.

> I suspect carl saw the merges done by derek as causing more bugs than
> good so he attacked until derek stoped doing the merges.

Which is the shitty behavior that's being discussed about. When you find
problems you report them, or help fix them. You don't attack the person
working on them.

> The correct course of action would have been a vote about stoping the
> merges or a change to the procedure to reduce the amount of bugs.
> Like maybe a seperate branch where merges can be tested for ~24h before
> being pushed to master ...
> Or maybe more people working on fixing regressions
> As a sidenote, most of the regressions should be fixed by now.
> 
> 2. ban derek for ~24h from the ML due to causing lukasz to leave the
> project last year, and due to personal insults on the ML and IRC
> to lukasz and carl.
> As derek is not subscribed to the list ATM, this will be implemented
> by moving him from the accept_these_nonmembers list to the
> reject_these_nonmembers list for ~24h
> 
> 3. ban myself for ~24h from the ML because i wrote offensive mails too
> years ago and i doubt none was pivotal in causing someone to leave

And this is silly. It's old history and nobody requested such action in
any what whatsoever. It will only derail the discussion and again, bans
without discussion or vote are a big no.

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

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

[FFmpeg-devel] bans

[Michael Niedermayer]

Hi all

As noone is doing anything about the situation and what is being
done will not lead anywhere (the vote likely wont lead anywhere as
likely few would ban a active developer 4 month and then if not
some will feel injustice prevailed thus

After writing this mail i will

1. ban carl for 24h from the ML due to
causing  derek to leave the project. (24h was suggested in the IRC
meeting)
I suspect carl saw the merges done by derek as causing more bugs than
good so he attacked until derek stoped doing the merges.
The correct course of action would have been a vote about stoping the
merges or a change to the procedure to reduce the amount of bugs.
Like maybe a seperate branch where merges can be tested for ~24h before
being pushed to master ...
Or maybe more people working on fixing regressions
As a sidenote, most of the regressions should be fixed by now.

2. ban derek for ~24h from the ML due to causing lukasz to leave the
project last year, and due to personal insults on the ML and IRC
to lukasz and carl.
As derek is not subscribed to the list ATM, this will be implemented
by moving him from the accept_these_nonmembers list to the
reject_these_nonmembers list for ~24h

3. ban myself for ~24h from the ML because i wrote offensive mails too
years ago and i doubt none was pivotal in causing someone to leave

Thanks

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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

Re: [FFmpeg-devel] [PATCH v5] Add experimental support for vp9 in iso-bmff

[Ronald S. Bultje]

Hi,

On Tue, Jun 14, 2016 at 9:24 PM, KongQun Yang <
kqyang-at-google@ffmpeg.org> wrote:

> -- KongQun Yang (KQ)
>
> On Tue, Jun 14, 2016 at 6:13 PM, Ronald S. Bultje 
> wrote:
>
> > Hi,
> >
> > On Tue, Jun 14, 2016 at 7:34 PM, Hendrik Leppkes 
> > wrote:
> >
> > > On Wed, Jun 15, 2016 at 12:05 AM, Kongqun Yang 
> > > wrote:
> > > > Implemented according to the draft specification
> > > > "VP Codec ISO Media File Format Binding":
> > > >
> > >
> >
> http://www.webmproject.org/vp9/#draft-vp-codec-iso-media-file-format-binding
> > > >
> > > > '-strict -2' is required to use this feature.
> > > >
> > >
> > > Not sure I really like the vpc name, when I read vpc I don't think of
> > > vp9, and the correlation to avc/hevc is also not really there, as
> > > those codecs are actually called that. AVC and HEVC, the C isn't added
> > > randomly.
> > > If anything, it should have been vp9.c then, but oh well.
> > >
> > > But anyway, if Ronald is ok with the name I won't complain.
> > >
> >
> > I think they intend to use it for vp10 also.
> >
>
> Correct. I don't want to limit it to vp9 only. I can use vpcc if Hendrik is
> more comfortable with that.


The atom is called vpcc, so I think that makes a lot of sense, thanks.

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

Re: [FFmpeg-devel] [PATCH] Use int32_t instead of int for gaintable in hdcd filter

[Michael Niedermayer]

On Wed, Jun 01, 2016 at 09:47:25PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Jun 1, 2016 at 7:47 PM, Michael Niedermayer 
> wrote:
> 
> > On Thu, Jun 02, 2016 at 12:01:50AM +0200, Benjamin St wrote:
> > >
> >
> > >  af_hdcd.c |2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > b56f3e60dbd8c688ad37cc5dceb5378f68855622
> > 0001-Use-int32_t-instead-of-int-for-gaintable-in-hdcd-fil.patch
> > > From 11bbac3343cb06ce0862ffbbf6365ba834b4284b Mon Sep 17 00:00:00 2001
> > > From: Benjamin Steffes 
> > > Date: Sun, 29 May 2016 17:45:33 +0200
> > > Subject: [PATCH] Use int32_t instead of int for gaintable in hdcd filter.
> >
> > the commit message is missing the "why"
> >
> > also note POSIX gurantees >=32bit int and we require POSIX
> 
> 
> It may be to prevent the theoretical case where the container type (int)
> would be 64 bit on some platforms, which would waste some space...

applied with that comment

thx

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


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

Re: [FFmpeg-devel] [PATCH][libavfilter] codecview: improved options

[Michael Niedermayer]

On Thu, Jun 09, 2016 at 01:24:57PM +, Davinder Singh wrote:
> On Mon, May 30, 2016 at 1:45 PM Michael Niedermayer 
> wrote:
> 
> > On Mon, May 23, 2016 at 05:09:35PM +, Davinder Singh wrote:
> > >  vf_codecview.c |   55
> > +--
> > >  1 file changed, 45 insertions(+), 10 deletions(-)
> > > 464b23c4638d1a408e8237651facf327994945bf
> > 0001-vf_codecview-added-new-options.patch
> > > From 641d6f92e792ea7def3610f5462b6bbec019c4b7 Mon Sep 17 00:00:00 2001
> > > From: dsmudhar 
> > > Date: Mon, 23 May 2016 22:29:51 +0530
> > > Subject: [PATCH] vf_codecview: added new options
> > >
> > > ---
> > >  libavfilter/vf_codecview.c | 55
> > +-
> > >  1 file changed, 45 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/libavfilter/vf_codecview.c b/libavfilter/vf_codecview.c
> > > index e70b397..1cb521d 100644
> > > --- a/libavfilter/vf_codecview.c
> > > +++ b/libavfilter/vf_codecview.c
> > > @@ -38,21 +38,39 @@
> > >  #define MV_P_FOR  (1<<0)
> > >  #define MV_B_FOR  (1<<1)
> > >  #define MV_B_BACK (1<<2)
> > > +#define MV_TYPE_FOR  (1<<0)
> > > +#define MV_TYPE_BACK (1<<1)
> > > +#define FRAME_TYPE_I (1<<0)
> > > +#define FRAME_TYPE_P (1<<1)
> > > +#define FRAME_TYPE_B (1<<2)
> > >
> > >  typedef struct {
> > >  const AVClass *class;
> > >  unsigned mv;
> > > +unsigned frame_type;
> > > +unsigned mv_type;
> > >  int hsub, vsub;
> > >  int qp;
> > >  } CodecViewContext;
> > >
> > >  #define OFFSET(x) offsetof(CodecViewContext, x)
> > >  #define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
> > > +#define CONST(name, help, val, unit) { name, help, 0,
> > AV_OPT_TYPE_CONST, {.i64=val}, 0, 0, FLAGS, unit }
> > > +
> > >  static const AVOption codecview_options[] = {
> > >  { "mv", "set motion vectors to visualize", OFFSET(mv),
> > AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS, "mv" },
> > > -{"pf", "forward predicted MVs of P-frames",  0,
> > AV_OPT_TYPE_CONST, {.i64 = MV_P_FOR },  INT_MIN, INT_MAX, FLAGS, "mv"},
> > > -{"bf", "forward predicted MVs of B-frames",  0,
> > AV_OPT_TYPE_CONST, {.i64 = MV_B_FOR },  INT_MIN, INT_MAX, FLAGS, "mv"},
> > > -{"bb", "backward predicted MVs of B-frames", 0,
> > AV_OPT_TYPE_CONST, {.i64 = MV_B_BACK }, INT_MIN, INT_MAX, FLAGS, "mv"},
> > > +CONST("pf", "forward predicted MVs of P-frames",  MV_P_FOR,
> > "mv"),
> > > +CONST("bf", "forward predicted MVs of B-frames",  MV_B_FOR,
> > "mv"),
> > > +CONST("bb", "backward predicted MVs of B-frames", MV_B_BACK,
> > "mv"),
> > > +{ "mv_type", "set motion vectors type", OFFSET(mv_type),
> > AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS, "mv_type" },
> > > +{ "mvt", "set motion vectors type", OFFSET(mv_type),
> > AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS, "mv_type" },
> > > +CONST("fp", "forward predicted MVs",  MV_TYPE_FOR,  "mv_type"),
> > > +CONST("bp", "backward predicted MVs", MV_TYPE_BACK, "mv_type"),
> > > +{ "frame_type", "set frame types to visualize motion vectors of",
> > OFFSET(frame_type), AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS,
> > "frame_type" },
> > > +{ "ft", "set frame types to visualize motion vectors of",
> > OFFSET(frame_type), AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS,
> > "frame_type" },
> > > +CONST("if", "I-frames", FRAME_TYPE_I, "frame_type"),
> > > +CONST("pf", "P-frames", FRAME_TYPE_P, "frame_type"),
> > > +CONST("bf", "B-frames", FRAME_TYPE_B, "frame_type"),
> > >  { "qp", NULL, OFFSET(qp), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, .flags
> > = FLAGS },
> >
> > the new options should be added at the end, inserting them in the middle
> > breaks for example
> > -flags2 +export_mvs -vf codecview=0:1
> >
> > [...]
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Good people do not need laws to tell them to act responsibly, while bad
> > people will find a way around the laws. -- Plato
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> 
> patch attached.

>  doc/filters.texi   |   38 ---
>  libavfilter/vf_codecview.c |   55 
> -
>  2 files changed, 80 insertions(+), 13 deletions(-)
> 88778603071af6afe4dd2d0ab37a0802449e792c  
> 0001-vf_codecview-added-new-options.patch
> From 44016bf074281bf96ee40567b5aaf6a7d4d9f063 Mon Sep 17 00:00:00 2001
> From: dsmudhar 
> Date: Thu, 9 Jun 2016 18:42:33 +0530
> Subject: [PATCH] vf_codecview: added new options

applied

thanks

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the 

Re: [FFmpeg-devel] [PATCH 4/5] fate: update sub-cc tests for closed caption positioning

[Carl Eugen Hoyos]

Aman Gupta  tmm1.net> writes:

[...]

This has to be merged into the commit that actually 
changes fate output: Every commit should pass fate.

Are any of your commits related to the open tickets 
that describe issues with Closed Caption?

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH v6] Add experimental support for vp9 in iso-bmff

[Carl Eugen Hoyos]

Kongqun Yang  gmail.com> writes:

> +} else if (chroma_w == 0 && chroma_h == 0) {
> +return VPX_SUBSAMPLING_444;

Could you confirm that this fixes RGB encoding?
I believe this was broken in your previous patch.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] fix few compiler warnings

[Michael Niedermayer]

On Fri, Jun 03, 2016 at 12:56:36AM +, Davinder Singh wrote:
> On Thu, Jun 2, 2016 at 5:18 PM Michael Niedermayer 
> wrote:
> 
> > On Sun, May 22, 2016 at 01:51:05AM +, Davinder Singh wrote:
> > [...]
> >
> > >  vf_hwdownload.c |6 --
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > 5eb7416fececde847414f37de9a78a4e1cd5e1af
> > 0004-libavfilter-vf_hwdownload-show-error-when-ff_formats.patch
> > > From d1d00989a374facba3cdf777d95c61bf385f1332 Mon Sep 17 00:00:00 2001
> > > From: dsmudhar 
> > > Date: Sun, 22 May 2016 06:26:36 +0530
> > > Subject: [PATCH 4/7] libavfilter/vf_hwdownload: show error when
> > ff_formats_ref
> > >  fails
> > >
> > > ---
> > >  libavfilter/vf_hwdownload.c | 6 --
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavfilter/vf_hwdownload.c b/libavfilter/vf_hwdownload.c
> > > index 2dcc9fa..79ea82d 100644
> > > --- a/libavfilter/vf_hwdownload.c
> > > +++ b/libavfilter/vf_hwdownload.c
> > > @@ -56,8 +56,10 @@ static int hwdownload_query_formats(AVFilterContext
> > *avctx)
> > >  }
> > >  }
> > >
> > > -ff_formats_ref(infmts,  >inputs[0]->out_formats);
> > > -ff_formats_ref(outfmts, >outputs[0]->in_formats);
> > > +if ((err = ff_formats_ref(infmts,  >inputs[0]->out_formats))
> > < 0 ||
> > > +(err = ff_formats_ref(outfmts, >outputs[0]->in_formats))
> > < 0)
> > > +return err;
> >
> > according to coverity this introduces a memleak
> > (1362184)
> > ill send you an invite so you can take a look
> >
> > [...]
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Those who are too smart to engage in politics are punished by being
> > governed by those who are dumber. -- Plato
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> 
> this patch should fix it
> 
> Thanks,
> DSM_

>  vf_hwdownload.c |   14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 7b9bf5b1d20562c575b6aa815e47e8a22a888ccb  
> 0001-vf_hwdownload-fix-memory-leak.patch
> From 2cdac9e4bc4b66294a561776f0284499d4971282 Mon Sep 17 00:00:00 2001
> From: dsmudhar 
> Date: Fri, 3 Jun 2016 06:19:25 +0530
> Subject: [PATCH] vf_hwdownload: fix memory leak
> 
> ---
>  libavfilter/vf_hwdownload.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/libavfilter/vf_hwdownload.c b/libavfilter/vf_hwdownload.c
> index 79ea82d..f012356 100644
> --- a/libavfilter/vf_hwdownload.c
> +++ b/libavfilter/vf_hwdownload.c
> @@ -49,18 +49,20 @@ static int hwdownload_query_formats(AVFilterContext 
> *avctx)
>  err = ff_add_format(,  av_pix_fmt_desc_get_id(desc));
>  else
>  err = ff_add_format(, av_pix_fmt_desc_get_id(desc));
> -if (err) {
> -ff_formats_unref();
> -ff_formats_unref();
> -return err;
> -}
> +if (err < 0)
> +goto fail;
>  }
>  
>  if ((err = ff_formats_ref(infmts,  >inputs[0]->out_formats)) < 0 
> ||
>  (err = ff_formats_ref(outfmts, >outputs[0]->in_formats)) < 0)
> -return err;
> +goto fail;
>  
>  return 0;
> +
> +fail:
> +ff_formats_unref();
> +ff_formats_unref();


this could unref infmts even after successfull ff_formats_ref(infmts, ...
which would cause problems i think

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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

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

[Michael Niedermayer]

Hi

On Tue, May 31, 2016 at 10:43:38PM +, Davinder Singh wrote:
> There’s a lot of research done on Motion Estimation. Depending upon the
> intended application of the resultant motion vectors, the method used for
> motion estimation can be very different.
> 
> Classification of Motion Estimation Methods:
> 
> Direct Methods: In direct methods we calculate optical flow
>  in the scene.
> 
> - Phase Correlation
> 
> - Block Matching
> 
> - Spatio-Temporal Gradient
> 
>  - Optical flow: Uses optical flow equation to find motion in the scene.
> 
>  - Pel-recursive: Also compute optical flow, but in such a way that allow
> recursive computability on vector fields)
> 
> Indirect Methods
> 
> - Feature based Method: Find features in the frame, and used for estimation.
> 
> Here are some papers on Frame Rate Up-Conversion (FRUC):
> 
> Phase Correlation:
> 
> This method relies on frequency-domain representation of data, calculated
> using fast Fourier transform.
>  Phase Correlation
> provides a correlation surface from the comparison of images. This enables
> the identification of motion on a pixel-by-pixel basis for correct
> processing of each motion type. Since phase correlation operates in the
> frequency rather than the spatial domain, it is able to zero in on details
> while ignoring such factors as noise and grain within the picture. In other
> words, the system is highly tolerant of the noise variations and rapid
> changes in luminance levels that are found in many types of content –
> resulting in high-quality performance on fades, objects moving in and out
> of shade, and light ashes.
> 
> Papers:
> 
> [1] "Disney Research » Phase-Based Frame Interpolation for Video." IEEE
> CVPR 2015 
> 
> [2] Yoo, DongGon et al. "Phase Correlated Bilateral Motion Estimation for
> Frame Rate Up-Conversion." The 23rd International Technical Conference on
> Circuits/Systems, Computers and Communications (ITC-CSCC Jul. 2008.
> 
> 
> 
> The video on paper [1] page demonstrate comparison between various methods.
> 
> Optical Flow:
> 
> http://www.cs.toronto.edu/~fleet/research/Papers/flowChapter05.pdf
> 
> [3] Brox et al. "High accuracy optical flow estimation based on a theory
> for warping." Computer Vision - ECCV 2004: 25-36.
> 
> <
> http://www.wisdom.weizmann.ac.il/~/vision/courses/2006_2/papers/optic_flow_multigrid/brox_eccv04_of.pdf
> >
> 
> Slowmovideo  open-source project is based
> on Optical flow equation.
> 
> Algorithm we can implement is based on block matching method.
> 
> Motion Compensated Frame Interpolation
> 
> Paper:
> 
> [4] Zhai et al. "A low complexity motion compensated frame interpolation
> method." IEEE ISCAS 2005: 4927-4930.
> 
> 
> 
> Block-based motion estimation and pixel-wise motion estimation are the two
> main categories of motion estimation methods. In general, pixel-wise motion
> estimation can attain accurate motion fields, but needs a substantial
> amount of computation. In contrast, block matching algorithms (BMA) can be
> efficiently implemented and provide good performance.
> 
> Most MCFI algorithms utilize the block-matching algorithm (BMA) for motion
> estimation (ME). BMA is simple and easy to implement. It also generates a
> compactly represented motion field. However, unlike video compression, it
> is more important to find true motion trajectories in MCFI. The objective
> of MC in MCFI is not to minimize the energy of MC residual signals, but to
> reconstruct interpolated frames with better visual quality.
> 
> The algorithm uses motion vectors which are embedded in bit-stream. If
> vectors exported by codec (using +export_mvs flag2) are used when
> available, computation of the motion vectors will be significantly reduced
> for realtime playback. Otherwise the mEstimate filter will generate MVs,
> and to make the process faster, same algorithms (used by x264 and x265) -
> Diamond, Hex, UMH, Star will be implemented in the filter. Other filter -
> mInterpolate will use the MVs in the frame side data to interpolate frames
> using various methods - OBMC (Overlapped block motion compensation), simple
> frame blending and frame duplication etc.
> 
> However, MVs generated based on SAD or BAD might bring serious artifacts if
> they are used directly. So, the algorithm first examines the motion vectors
> and classify into two groups, one group with vectors which are considered
> to represent “true” motion, other having “bad” vectors, then carries out
> overlapped block bi-directional motion estimation on corresponding blocks
> having “bad” MVs. Finally, it utilizes motion vector post-processing and
> overlapped block motion compensation to generate interpolated frames 

Re: [FFmpeg-devel] [PATCH] PPC64: Add IBM POWER8 SIMD Implementation

[Carl Eugen Hoyos]

Dan Parrot  mail.com> writes:

[...]

I know this is isn't completely related but do you have time 
to look at ticket #5508?
https://trac.ffmpeg.org/ticket/5508
No active developer has hardware and knowledge to look into 
this issue;-(

Carl Eugen

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

Re: [FFmpeg-devel] PATCH: dshow: don't add two instances of same device to graphs

[Clément Bœsch]

On Wed, Jun 15, 2016 at 02:54:09AM -0600, Roger Pack wrote:
> A handful of devices don't support this, and the rest work fine with it :)
> 
> -roger-

> From e724d7f169bcae3217455cd88f9c023d275d367a Mon Sep 17 00:00:00 2001
> From: rogerdpack 
> Date: Wed, 15 Jun 2016 02:17:11 -0600
> Subject: [PATCH] dshow: don't add two instances of same device to graphs
> 
> Signed-off-by: rogerdpack 
> ---
>  libavdevice/dshow.c | 37 ++---
>  libavdevice/dshow_capture.h |  2 ++
>  2 files changed, 32 insertions(+), 7 deletions(-)
> 
> diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
> index 5f2cad7..e1ac855 100644
> --- a/libavdevice/dshow.c
> +++ b/libavdevice/dshow.c
> @@ -108,6 +108,10 @@ dshow_read_close(AVFormatContext *s)
>  av_freep(>device_name[0]);
>  if (ctx->device_name[1])
>  av_freep(>device_name[1]);

> +if (ctx->device_unique_name[0])
> +av_freep(>device_unique_name[0]);
> +if (ctx->device_unique_name[1])
> +av_freep(>device_unique_name[1]);

I can't comment the rest of the patch, but please remove the ifs. They are,
and always were, totally useless. Just like those above.

-- 
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] hls muxer doc: clarify segment splitting option

[Michael Niedermayer]

On Mon, Jun 13, 2016 at 08:40:48PM +0200, Benoit Fouet wrote:
> Hi,
> 
> Le 08/06/2016 11:46, Benoit Fouet a écrit :
> >Hi,
> >
> >find attached a patch to $subj
> >This would have been useful at least to me :-)
> >
> 
> Anyone against this patch?
> If not, can someone please apply it?

applied, though you have a git write account IIRC

thx

[...]
-- 
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] [PATCH] fate: add swr-resample_exact_async tests

[Michael Niedermayer]

On Wed, Jun 15, 2016 at 02:02:48PM +0700, Muhammad Faiz wrote:
> Signed-off-by: Muhammad Faiz 
> ---
>  tests/fate/libswresample.mak | 87 
> 
>  1 file changed, 87 insertions(+)

LGTM

thx

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

Avoid a single point of failure, be that a person or equipment.


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

[FFmpeg-devel] PATCH: dshow: don't add two instances of same device to graphs

[Roger Pack]

A handful of devices don't support this, and the rest work fine with it :)

-roger-
From e724d7f169bcae3217455cd88f9c023d275d367a Mon Sep 17 00:00:00 2001
From: rogerdpack 
Date: Wed, 15 Jun 2016 02:17:11 -0600
Subject: [PATCH] dshow: don't add two instances of same device to graphs

Signed-off-by: rogerdpack 
---
 libavdevice/dshow.c | 37 ++---
 libavdevice/dshow_capture.h |  2 ++
 2 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 5f2cad7..e1ac855 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -108,6 +108,10 @@ dshow_read_close(AVFormatContext *s)
 av_freep(>device_name[0]);
 if (ctx->device_name[1])
 av_freep(>device_name[1]);
+if (ctx->device_unique_name[0])
+av_freep(>device_unique_name[0]);
+if (ctx->device_unique_name[1])
+av_freep(>device_unique_name[1]);
 
 if(ctx->mutex)
 CloseHandle(ctx->mutex);
@@ -205,7 +209,8 @@ fail:
  */
 static int
 dshow_cycle_devices(AVFormatContext *avctx, ICreateDevEnum *devenum,
-enum dshowDeviceType devtype, enum dshowSourceFilterType 
sourcetype, IBaseFilter **pfilter)
+enum dshowDeviceType devtype, enum dshowSourceFilterType 
sourcetype,
+IBaseFilter **pfilter, char **device_unique_name)
 {
 struct dshow_ctx *ctx = avctx->priv_data;
 IBaseFilter *device_filter = NULL;
@@ -276,10 +281,13 @@ dshow_cycle_devices(AVFormatContext *avctx, 
ICreateDevEnum *devenum,
 av_log(avctx, AV_LOG_ERROR, "Unable to BindToObject for 
%s\n", device_name);
 goto fail1;
 }
+*device_unique_name = unique_name;
+// success, loop will end now
 }
 } else {
 av_log(avctx, AV_LOG_INFO, " \"%s\"\n", friendly_name);
 av_log(avctx, AV_LOG_INFO, "Alternative name \"%s\"\n", 
unique_name);
+av_free(unique_name);
 }
 
 fail1:
@@ -288,7 +296,6 @@ fail1:
 if (bind_ctx)
 IBindCtx_Release(bind_ctx);
 av_free(friendly_name);
-av_free(unique_name);
 if (bag)
 IPropertyBag_Release(bag);
 IMoniker_Release(m);
@@ -706,14 +713,15 @@ dshow_list_device_options(AVFormatContext *avctx, 
ICreateDevEnum *devenum,
 {
 struct dshow_ctx *ctx = avctx->priv_data;
 IBaseFilter *device_filter = NULL;
+char *device_unique_name = NULL;
 int r;
 
-if ((r = dshow_cycle_devices(avctx, devenum, devtype, sourcetype, 
_filter)) < 0)
+if ((r = dshow_cycle_devices(avctx, devenum, devtype, sourcetype, 
_filter, _unique_name)) < 0)
 return r;
 ctx->device_filter[devtype] = device_filter;
 if ((r = dshow_cycle_pins(avctx, devtype, sourcetype, device_filter, 
NULL)) < 0)
 return r;
-
+av_freep(_unique_name);
 return 0;
 }
 
@@ -723,6 +731,7 @@ dshow_open_device(AVFormatContext *avctx, ICreateDevEnum 
*devenum,
 {
 struct dshow_ctx *ctx = avctx->priv_data;
 IBaseFilter *device_filter = NULL;
+char *device_filter_unique_name = NULL;
 IGraphBuilder *graph = ctx->graph;
 IPin *device_pin = NULL;
 libAVPin *capture_pin = NULL;
@@ -733,6 +742,7 @@ dshow_open_device(AVFormatContext *avctx, ICreateDevEnum 
*devenum,
 IStream *ifile_stream = NULL;
 IStream *ofile_stream = NULL;
 IPersistStream *pers_stream = NULL;
+enum dshowDeviceType otherDevType = (devtype == VideoDevice) ? AudioDevice 
: VideoDevice;
 
 const wchar_t *filter_name[2] = { L"Audio capture filter", L"Video capture 
filter" };
 
@@ -766,13 +776,26 @@ dshow_open_device(AVFormatContext *avctx, ICreateDevEnum 
*devenum,
 av_log(avctx, AV_LOG_INFO, "Capture filter loaded successfully from 
file \"%s\".\n", filename);
 } else {
 
-if ((r = dshow_cycle_devices(avctx, devenum, devtype, sourcetype, 
_filter)) < 0) {
+if ((r = dshow_cycle_devices(avctx, devenum, devtype, sourcetype, 
_filter, _filter_unique_name)) < 0) {
 ret = r;
 goto error;
 }
 }
+   if (ctx->device_filter[otherDevType]) {
+// avoid adding add two instances of the same device to the graph, one 
for video, one for audio
+// a few devices don't support this (could also do this check earlier 
to avoid double crossbars, etc. but they seem OK)
+if (strcmp(device_filter_unique_name, 
ctx->device_unique_name[otherDevType]) == 0) {
+  av_log(avctx, AV_LOG_DEBUG, "reusing previous graph capture 
filter... %s\n", device_filter_unique_name);
+  IBaseFilter_Release(device_filter);
+  device_filter = ctx->device_filter[otherDevType];
+  IBaseFilter_AddRef(ctx->device_filter[otherDevType]);
+} else {
+av_log(avctx, AV_LOG_DEBUG, "not reusing previous graph capture 
filter %s != %s\n", 

Re: [FFmpeg-devel] [PATCH] PPC64: Add IBM POWER8 SIMD Implementation

[Michael Niedermayer]

On Wed, Jun 15, 2016 at 04:25:11AM +, Dan Parrot wrote:
> This is the first commit addressing Trac ticket #5570. Functions defined in
> libswscale/input.c have corresponding definitions in 
> libswscale/ppc/input_vsx.h
> The corresponding function names in the latter contain the suffix "_vsx".
> ---
>  libswscale/input.c |  44 +--
>  libswscale/ppc/input_vsx.h | 831 
> +
>  2 files changed, 853 insertions(+), 22 deletions(-)
>  create mode 100644 libswscale/ppc/input_vsx.h

breaks build on x86
 ./configure && make -j12
In file included from libswscale/input.c:44:0:
libswscale/ppc/input_vsx.h: In function ‘rgb64ToY_c_template_vsx’:
libswscale/ppc/input_vsx.h:34:5: error: ‘vector’ undeclared (first use in this 
function)
libswscale/ppc/input_vsx.h:34:5: note: each undeclared identifier is reported 
only once for each function it appears in
libswscale/ppc/input_vsx.h:34:12: error: expected ‘;’ before ‘int’
libswscale/ppc/input_vsx.h:35:12: error: expected ‘;’ before ‘int’
libswscale/ppc/input_vsx.h:36:12: error: expected ‘;’ before ‘int’

[...]
> @@ -978,7 +984,6 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
>  case AV_PIX_FMT_GBRP9LE:
>  c->readChrPlanar = planar_rgb9le_to_uv;
>  break;
> -case AV_PIX_FMT_GBRAP10LE:
>  case AV_PIX_FMT_GBRP10LE:
>  c->readChrPlanar = planar_rgb10le_to_uv;
>  break;
> @@ -996,7 +1001,6 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
>  case AV_PIX_FMT_GBRP9BE:
>  c->readChrPlanar = planar_rgb9be_to_uv;
>  break;
> -case AV_PIX_FMT_GBRAP10BE:
>  case AV_PIX_FMT_GBRP10BE:
>  c->readChrPlanar = planar_rgb10be_to_uv;
>  break;
> @@ -1260,8 +1264,6 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
>  case AV_PIX_FMT_GBRP9LE:
>  c->readLumPlanar = planar_rgb9le_to_y;
>  break;
> -case AV_PIX_FMT_GBRAP10LE:
> -c->readAlpPlanar = planar_rgb10le_to_a;
>  case AV_PIX_FMT_GBRP10LE:
>  c->readLumPlanar = planar_rgb10le_to_y;
>  break;
> @@ -1281,8 +1283,6 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
>  case AV_PIX_FMT_GBRP9BE:
>  c->readLumPlanar = planar_rgb9be_to_y;
>  break;
> -case AV_PIX_FMT_GBRAP10BE:
> -c->readAlpPlanar = planar_rgb10be_to_a;
>  case AV_PIX_FMT_GBRP10BE:
>  c->readLumPlanar = planar_rgb10be_to_y;
>  break;

why do you remove these ?
thats not ppc related

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

[FFmpeg-devel] [PATCH] d3d11va: don't keep the context lock while waiting for a frame

[Steve Lhomme]

also fixes a deadlock found by Денис Кулаков 
---
 libavcodec/dxva2.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 2cf57ad..f68df86 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -158,9 +158,15 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx, 
AVFrame *frame,
  ff_dxva2_get_surface(frame),
  NULL);
 #endif
-if (hr == E_PENDING)
-av_usleep(2000);
-} while (hr == E_PENDING && ++runs < 50);
+if (hr != E_PENDING || ++runs > 50)
+break;
+#if CONFIG_D3D11VA
+if (avctx->pix_fmt == AV_PIX_FMT_D3D11VA_VLD)
+if (D3D11VA_CONTEXT(ctx)->context_mutex != INVALID_HANDLE_VALUE)
+ReleaseMutex(D3D11VA_CONTEXT(ctx)->context_mutex);
+#endif
+av_usleep(2000);
+} while(1);
 
 if (FAILED(hr)) {
 av_log(avctx, AV_LOG_ERROR, "Failed to begin frame: 0x%lx\n", hr);
-- 
2.8.2

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

Re: [FFmpeg-devel] dxva2 patch

[Steve Lhomme]

On Wed, Jun 8, 2016 at 8:57 AM, Денис Кулаков  wrote:
> In dxva2 code there is bug with context_mutex usage -
> if ID3D11VideoContext_DecoderBeginFrame return E_PENDING -
> WaitForSingleObjectEx(context_mutex) will be called again, but each call to
> it must have corresponding ReleaseMutex, otherwise it will not be released
> - so after E_PENDING context mutex will never be released.

You are correct, the should not be in the while, or we should release
the lock when we loop again, so that another thread has a chance to do
something with the video_context.

> ___
> 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 v5] Add experimental support for vp9 in iso-bmff

[Hendrik Leppkes]

On Wed, Jun 15, 2016 at 3:25 AM, KongQun Yang
 wrote:
> -- KongQun Yang (KQ)
>
> On Tue, Jun 14, 2016 at 4:20 PM, Ronald S. Bultje 
> wrote:
>
>> Hi,
>>
>> On Tue, Jun 14, 2016 at 6:05 PM, Kongqun Yang 
>> wrote:
>>
>>> +default:
>>> +av_log(NULL, AV_LOG_ERROR, "Unsupported color space (%d)\n",
>>> +   color_space);
>>> +return -1;
>>>
>> [..]
>>
>>> +default:
>>> +av_log(NULL, AV_LOG_ERROR, "Unsupported pixel format (%d)\n",
>>> +   pixel_format);
>>> +return -1;
>>>
>> [..]
>>
>>> +if (desc == NULL) {
>>> +av_log(NULL, AV_LOG_ERROR, "Unsupported pixel format (%d)\n",
>>> +   pixel_format);
>>> +return -1;
>>>
>>
>> You're still logging without a context (first argument), can you please
>> provide one so people know which muxer is complaining about these error
>> messages?
>>
>
> Are you ok with using "AVIOContext" as the context?
>

Thats an odd choice for logging.
If there is no natural logging context, you should just add a "void*
logctx" argument to the new function you introduced, its what is
commonly done in other places. That way the mov muxer can then pass a
reference to the AVFormatContext in there for more natural logging.

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