Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[James Almer]

On 11/28/2016 7:34 AM, Nicolas George wrote:
> Le septidi 7 frimaire, an CCXXV, James Almer a écrit :
>> We don't care about testing it with FATE.
> 
> Yes, we do.
> 
>>  It appears to me that you still 
>> don't
>> get that ffserver is being *dropped*. It is, as discussed and announced, no
>> longer part of the project.
> 
> Untrue. It is still there. There are threats of developers about to
> remove it, but they are in the future.

Threats? The only thing i see are reminders of what should have happened
earlier and will happen soon, as discussed an announced.

> 
> The gist of it is that YOU want ffserver dropped, and you do so for
> emotional reasons, not rational ones. Your emotional reasons are

No, i want a project decision to finally go through. I don't give a shit
about the program. If you see me "emotional" is because i can't believe my
eyes when i see all this shit happening only after the decision was made
and not when actual development work was requested, or when the *final*
discussion was taking place.

You all should have shown then. You didn't.

> inspired by rational ones, but only inspired, because you did not update
> your conclusions when the status of the rational reasons changed.
> 
> The rational behaviour is:

Follow through with a made and publicly announced project decision. Period.
Everything else are stalling attempts.

> 
> IF ffserver prevents other aspects of the development, for examples
> merges from the fork, THEN something must be done about it SOON, FOR
> EXAMPLE dropping it, but possibly something else, provided it happens
> soon.

Years, YEARS passed with ffserver in this very specific state of things.
"Something must be done", "Someone should fix it", "Someone should rewrite
it from scratch".

Nobody gave a shit. That period ended a couple months ago.

> 
> IF ffserver is unmaintained but does not block aspects of the
> development, then there is no rational reason to drop it in the short
> term. Maybe later. On the other hand, there are reasons NOT to drop it:
> some users use it.
> 
> IF ffserver is maintained, there is no reason to drop it whatsoever.
> 
> The way I read the discussions, the decision top drop was made when we
> were in the first case. But you can notice that "but possibly something
> else" just happened, and it happened soon enough.
> 
> Since Michael's patches ensure that ffserver no longer blocks merges,
> there is no longer a reason to drop ffserver urgently. Therefore, the
> decision to drop it tomorrow is void.

Every patch and change that's being done now are direct consequence and
effect of the decision to drop ffserver. It has remained broken,
unmaintained and bitrotting for years but now that we have reached the
fateful day, ffserver is suddenly more important than the h264 decoder.

Michael's and Reynaldo's patches were agreed to be efforts towards making
ffserver standalone for the only reason to not have a period of time where
whoever cares about this thing would not be able to use it with git head.
It was not our responsibility to do that, but Reynaldo wanted to do it as
a personal project of sorts. Thus ffserver was allowed to remain for a bit
to make his work easier.

Until then it was all fine. Now you people pretend using that agreement
and the development that came out of it as an argument to prove how
ffserver is in fact maintained after all.
This patch *should* have been committed weeks ago but with the excuse of
"think of the users" it was allowed to be delayed a bit. Now you come and
weaponize that. You do not do that shit. It's extremely disrespectful.

> 
> Regards,
> 

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[compn]

maybe when there is a conflict of opinion on a patch, we should agree
to disagree on said patch and ignore it?

instead of arguing endlessly about it?

not specifically targeting you, james, but a lot of people in this
thread.

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[James Almer]

On 11/28/2016 11:04 AM, compn wrote:
> maybe when there is a conflict of opinion on a patch, we should agree
> to disagree on said patch and ignore it?
> 
> instead of arguing endlessly about it?

No. The one patch where that was an option was the news entry patch, the
last time this whole deal was effectively up to debate. Nobody participated
on it.
This patch is simply making effective the project's decision. It's not up
for discussion.

Maybe next time people will participate on things at the proper time and
on the proper threads.

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Paul B Mahol]

On 11/28/16, compn  wrote:
> On Mon, 28 Nov 2016 02:22:48 +0100
> Michael Niedermayer  wrote:
>
>> I dont know if people want me and reynaldo to spend less time on
>> FFmpeg, but time is a finite resource. If ffserver is maintained
>> externally it would mean a noticable hit in maintaince man hours of
>> FFmpeg. Now it might be that ffserver being pushed out would kill it.
>> But really as dumb as i am, i dont belive theres a majority who wants
>> to kill FFserver when there are people who actively work on it and
>> care about it.
>
> it seems like there are at least a few developers who would feel better
> if ffserver was removed from master / moved somewhere else to die etc.
>
> these developers feel very strongly about removing ffserver.
>
> it might be wise to follow the opinions of these developers in order to
> have a higher morale and continue the working environment here in the
> project.
>
> otherwise some developers may feel betrayed, harmed, ignored, etc and
> foster hatred because their opinions were not chosen.
>
> so michael, my advice to you is to just OK the patch and deal with
> ffserver later... if enough users come back to complain about its
> demise. i feel that this discussion is going no where if both sides are
> unable to come to a compromise.
>
> sometimes you have to cut off the toe to save the patient. :)

Exactly what happened with so called separate libpostprocess library.
Is it still being maintained? - NOPE.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Ronald S. Bultje]

Hi,

On Mon, Nov 28, 2016 at 10:17 AM, Nicolas George  wrote:

> L'octidi 8 frimaire, an CCXXV, compn a écrit :
> > these developers feel very strongly about removing ffserver.
>
> I feel very strongly about keeping ffserver. Who is right?


The majority. OK, so this is going nowhere. Vote, everyone? We need to
settle this, it's getting ridiculous.

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Nicolas George]

L'octidi 8 frimaire, an CCXXV, compn a écrit :
> these developers feel very strongly about removing ffserver.

I feel very strongly about keeping ffserver. Who is right?


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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Nicolas George]

L'octidi 8 frimaire, an CCXXV, Ronald S. Bultje a écrit :
> The majority.

Rational arguments first.


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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Nicolas George]

L'octidi 8 frimaire, an CCXXV, James Almer a écrit :
> Threats? The only thing i see are reminders of what should have happened
> earlier and will happen soon, as discussed an announced.

Reminding of unpleasant things over which you have total control, that
is called threats.

"You will burn yourself." -> this is a warning.
"I will burn you." -> that is a threat.

Since ffserver will not remove itself, it is indeed a threat.

> No, i want a project decision to finally go through. I don't give a shit
> about the program. If you see me "emotional" is because i can't believe my
> eyes when i see all this shit happening only after the decision was made
> and not when actual development work was requested, or when the *final*
> discussion was taking place.
> 
> You all should have shown then. You didn't.

You act quite emotional over something you "don't give a shit" about.

> Every patch and change that's being done now are direct consequence and
> effect of the decision to drop ffserver. It has remained broken,
> unmaintained and bitrotting for years but now that we have reached the
> fateful day, ffserver is suddenly more important than the h264 decoder.

This is a "post hoc ergo propter hoc" fallacy.

The recent patches and the proposal to remove ffserver are not a
consequence of each other but both consequence of this single fact: the
internal APIs that ffserver is (ab)using are being changed and it is
blocking the merges.

The patches unblock the merges, therefore the removal is no longer
needed.

> This patch *should* have been committed weeks ago

I will remind you that most contributors work on the project on their
free time. If you care so much about ffserver's code (apparently you do,
or you would not be arguing so much about it), you could have sponsored
them to work on it earlier.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Nicolas George]

L'octidi 8 frimaire, an CCXXV, Ronald S. Bultje a écrit :
> To what end? Aren't we dug in, don't we need a decision and follow through
> with the elected outcome?

Democracy does not work that way. Before elections, you need
campaigning, arguments, debating. That way people can make an informed
decision about their vote rather than relying on which candidate has the
nicest face.

Without that, we get... basically all the major elections in 2016 in the
world. Please do not import that circus on ffmpeg-devel.

The arguments for keeping ffserver, IIRC, are:

- With the recent patches, it no longer does any harm.

- It has users, removing it would greatly annoy them, and just moving
  would just cause useless work for both the developers and users.

Let us see what are the arguments for removing. When we have them, if we
do not agree about which one is more important, then it becomes a
political decision and requires a vote.

Last note: "we decided it" is not a valid argument, because we can
always decide to change our mind; only idiots never do so.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[compn]

On Mon, 28 Nov 2016 02:22:48 +0100
Michael Niedermayer  wrote:

> I dont know if people want me and reynaldo to spend less time on
> FFmpeg, but time is a finite resource. If ffserver is maintained
> externally it would mean a noticable hit in maintaince man hours of
> FFmpeg. Now it might be that ffserver being pushed out would kill it.
> But really as dumb as i am, i dont belive theres a majority who wants
> to kill FFserver when there are people who actively work on it and
> care about it.

it seems like there are at least a few developers who would feel better
if ffserver was removed from master / moved somewhere else to die etc.

these developers feel very strongly about removing ffserver.

it might be wise to follow the opinions of these developers in order to
have a higher morale and continue the working environment here in the
project.

otherwise some developers may feel betrayed, harmed, ignored, etc and
foster hatred because their opinions were not chosen.

so michael, my advice to you is to just OK the patch and deal with
ffserver later... if enough users come back to complain about its
demise. i feel that this discussion is going no where if both sides are
unable to come to a compromise.

sometimes you have to cut off the toe to save the patient. :)

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Ronald S. Bultje]

Hi,

On Mon, Nov 28, 2016 at 10:25 AM, Nicolas George  wrote:

> L'octidi 8 frimaire, an CCXXV, Ronald S. Bultje a écrit :
> > The majority.
>
> Rational arguments first.


To what end? Aren't we dug in, don't we need a decision and follow through
with the elected outcome?

This has been going on for months. We need to move on, in some direction,
otherwise we'll keep talking about this for months to come.

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[James Almer]

On 11/28/2016 12:25 PM, Nicolas George wrote:
> L'octidi 8 frimaire, an CCXXV, Ronald S. Bultje a écrit :
>> The majority.
> 
> Rational arguments first.

How about the news entry on the website stating ffserver was meant to
go with 3.2? And the discussions that lead to it? That's a good rational
argument.
You want rationality yet you fight to override an old project decision.

If you meant technical arguments, the time for those was months ago.

If there's a vote, it will be to choose between ffserver being removed
tomorrow, or right before 3.3 is branched.
There's no "ffserver stays" option. That possibility was lost months
ago when neither you or anyone else showed up to back it up.

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

Re: [FFmpeg-devel] [PATCH] Avoid creating unecessary dependencies on thread libraries.

[Gregory J Wolfe]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf Of Carl Eugen Hoyos
> Sent: Monday, November 21, 2016 8:12 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] Avoid creating unecessary
> dependencies on thread libraries.
> 
> 2016-11-21 19:52 GMT+01:00 Gregory J. Wolfe
> :
> 
> > (2) When ALL threading support is disabled, the build should not
> create a
> > dependency on ANY thread library.
> 
> If this done through "#if HAVE_THREADS", it would be preferable to
> split the patches imo.
> 
> Carl Eugen

Back from Thanksgiving holiday.  Will split patch into two and resubmit.

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

[FFmpeg-devel] [PATCH] doc/filters: drawtext: add example of printing texts on same baseline

[Andrey Utkin]

Dimensions of canvas drawtext produces vary depending on symbols in
text, so add example for printing multiple texts aligned horizontally.

Signed-off-by: Andrey Utkin 
---
 doc/filters.texi | 16 
 1 file changed, 16 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index b3899b2693..c740b2671e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -7134,6 +7134,22 @@ FOD=5 # fade out duration
 ffplay -f lavfi 
"color,drawtext=text=TEST:fontsize=50:fontfile=FreeSerif.ttf:fontcolor_expr=ff%@{eif:
 clip(255*(1*between(t\\, $DS + $FID\\, $DE - $FOD) + ((t - 
$DS)/$FID)*between(t\\, $DS\\, $DS + $FID) + (-(t - $DE)/$FOD)*between(t\\, $DE 
- $FOD\\, $DE) )\\, 0\\, 255) : x: 2 @}"
 @end example

+@item
+Print multiple different texts on same baseline:
+@example
+#!/bin/sh
+FONTFILE=font.ttf
+FONTSIZE=32
+Y=10 # vertical offset of texts
+X1=10 # horizontal offset of first text
+X2=30 # horizontal offset of second text
+TEXT1="A"
+TEXT2="."
+ffplay -f lavfi -i "color=color=white,
+drawtext=fontfile=$FONTFILE:text=$TEXT1:fontsize=$FONTSIZE:x=$X1:y=$Y+$FONTSIZE-max_glyph_a,
+drawtext=fontfile=$FONTFILE:text=$TEXT2:fontsize=$FONTSIZE:x=$X2:y=$Y+$FONTSIZE-max_glyph_a"
+@end example
+
 @end itemize

 For more information about libfreetype, check:
--
2.11.0.rc2




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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Paul B Mahol]

On 11/28/16, James Almer  wrote:
>> What difference does it make?
>
> That the decision was made, and there's no going back. And much less after
> the malicious attempts i already described and pointed you to, that you
> seemingly intend to ignore.

It can be readded later, after its fixed?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Nicolas George]

L'octidi 8 frimaire, an CCXXV, James Almer a écrit :
> How about the news entry on the website stating ffserver was meant to
> go with 3.2? And the discussions that lead to it? That's a good rational
> argument.

# November 29th, 2016, ffserver not removed
#
# Thanks to the efforts of dedicated developers, ffserver has been
# updated and no longer needs to be removed immediately.

That's taken care of. And I assure you, ffserver users will prefer a
change of mind like that than a follow-through.

> If you meant technical arguments, the time for those was months ago.

The time for technical arguments is always.

> If there's a vote, it will be to choose between ffserver being removed
> tomorrow, or right before 3.3 is branched.
> There's no "ffserver stays" option. That possibility was lost months
> ago when neither you or anyone else showed up to back it up.

Hail James, our Great Dictator who decides what we are allowed to vote
about.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[James Almer]

On 11/28/2016 1:03 PM, Nicolas George wrote:
> L'octidi 8 frimaire, an CCXXV, James Almer a écrit :
>> How about the news entry on the website stating ffserver was meant to
>> go with 3.2? And the discussions that lead to it? That's a good rational
>> argument.
> 
> # November 29th, 2016, ffserver not removed
> #
> # Thanks to the efforts of dedicated developers, ffserver has been
> # updated and no longer needs to be removed immediately.
> 
> That's taken care of. And I assure you, ffserver users will prefer a
> change of mind like that than a follow-through.

You could also add

# November 29th, 2016, From now on, announcements from this project are
# worth as much as a copy of ET for the Atari.
#
# Thanks to the efforts of people that couldn't get over the fact they
# showed up late and that abused the goodwill of some developers, nothing
# you read announced here from now on is to be trusted.


> 
>> If you meant technical arguments, the time for those was months ago.
> 
> The time for technical arguments is always.

For things up to debate, sure. This is not the case.

> 
>> If there's a vote, it will be to choose between ffserver being removed
>> tomorrow, or right before 3.3 is branched.
>> There's no "ffserver stays" option. That possibility was lost months
>> ago when neither you or anyone else showed up to back it up.
> 
> Hail James, our Great Dictator who decides what we are allowed to vote
> about.

No, those are the only options within the boundaries already established.

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[James Almer]

On 11/28/2016 12:59 PM, Nicolas George wrote:
> L'octidi 8 frimaire, an CCXXV, James Almer a écrit :
>> No Nicolas. It's a reminder that this patch, as discussed and announced, will
>> be pushed.
> 
> And the Corleone give you reminders that they will break your legs.
> 
>> I don't care about ffserver.
> 
> Then do not discuss ffserver.

I discuss project management. This is a late attempt at overriding a decision
from parties that didn't participate in the real decision making discussions.

This crap wouldn't fly anywhere else, but somehow, and according to you, it's
rational on ffmpeg.

> 
>> I do care about the consequences of a bunch of
>> people that showed up very late to the party getting away with trying to
>> override an old project decision right when it was going to be made 
>> effective.
> 
> What are those consequences, pray?

That nobody will take the project seriously anymore. That nobody will believe
in any announcement anymore. That anyone will be 100% sure that with a little
lobbying and trolling they will be able to get away with absolutely anything,
including overriding old decisions.

> 
>> This is a lie
> 
> No.

How it isn't?

> 
>> Look it up, stop trying to rewrite history and stop being part of the
>> aforementioned malicious behavior.
> 
> I see nothing malicious in trying to keep a useful program up to date.
> You have strange priorities.

Malicious was the attempt at turning efforts of making the program capable
of living on its own into an argument against the reason why it must go.

You're aware that we could have told Reynaldo that no, we don't want to give
him time to make it work standalone, and this patch would have been pushed
a week or two ago, long before you even realized this all was even happening?

> 
>> Too bad the decision was made and announced.
> 
> Decisions can be revised. If this one exists, then it should.
> 
>>  Had this happened months or
>> years ago, when help was requested and promptly ignored, it wouldn't have
>> ended up like this.
> 
> What difference does it make?

That the decision was made, and there's no going back. And much less after
the malicious attempts i already described and pointed you to, that you
seemingly intend to ignore.

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

[FFmpeg-devel] [PATCH] Added Turing codec interface for ffmpeg

[Matteo Naccari]

- This patch contains the changes to interface the Turing codec
  (http://turingcodec.org/) to ffmpeg. The patch was modified to address
  the comments in the review as follows:
  - Added a pkg-config file to list all dependencies required by
  libturing. This should address the issue pointed out by Hendrik
  Leppkes on Fri 18/11/2016
  - The buffer to store the turing-params options has now a size which
  depends on how many of these parameters have been passed by the user.
  This should address the issue pointed out by wm4 and Moritz Barsnick
  on the ffmpeg-devel reflector
---
 LICENSE.md |   1 +
 configure  |   5 +
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/libturing.c | 268 +
 5 files changed, 276 insertions(+)
 create mode 100644 libavcodec/libturing.c

diff --git a/LICENSE.md b/LICENSE.md
index 640633c..86e5371 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -85,6 +85,7 @@ The following libraries are under GPL:
 - frei0r
 - libcdio
 - librubberband
+- libturing
 - libvidstab
 - libx264
 - libx265
diff --git a/configure b/configure
index 6345fc2..022ffa9 100755
--- a/configure
+++ b/configure
@@ -255,6 +255,7 @@ External library support:
   --enable-libssh  enable SFTP protocol via libssh [no]
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
   --enable-libtheora   enable Theora encoding via libtheora [no]
+  --enable-libturing   enable H.265/HEVC encoding via libturing [no]
   --enable-libtwolame  enable MP2 encoding via libtwolame [no]
   --enable-libv4l2 enable libv4l2/v4l-utils [no]
   --enable-libvidstab  enable video stabilization using vid.stab [no]
@@ -1534,6 +1535,7 @@ EXTERNAL_LIBRARY_LIST="
 libssh
 libtesseract
 libtheora
+libturing
 libtwolame
 libv4l2
 libvidstab
@@ -2831,6 +2833,7 @@ libspeex_decoder_deps="libspeex"
 libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
 libtheora_encoder_deps="libtheora"
+libturing_encoder_deps="libturing"
 libtwolame_encoder_deps="libtwolame"
 libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
 libvorbis_decoder_deps="libvorbis"
@@ -5096,6 +5099,7 @@ die_license_disabled gpl frei0r
 die_license_disabled gpl libcdio
 die_license_disabled gpl librubberband
 die_license_disabled gpl libsmbclient
+die_license_disabled gpl libturing
 die_license_disabled gpl libvidstab
 die_license_disabled gpl libx264
 die_license_disabled gpl libx265
@@ -5754,6 +5758,7 @@ enabled libssh&& require_pkg_config libssh 
libssh/sftp.h sftp_init
 enabled libspeex  && require_pkg_config speex speex/speex.h 
speex_decoder_init -lspeex
 enabled libtesseract  && require_pkg_config tesseract tesseract/capi.h 
TessBaseAPICreate
 enabled libtheora && require libtheora theora/theoraenc.h th_info_init 
-ltheoraenc -ltheoradec -logg
+enabled libturing && require_pkg_config libturing turing.h 
turing_version
 enabled libtwolame&& require libtwolame twolame.h twolame_init 
-ltwolame &&
  { check_lib twolame.h 
twolame_encode_buffer_float32_interleaved -ltwolame ||
die "ERROR: libtwolame must be installed and 
version must be >= 0.3.10"; }
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 82f7fa2..cadefdc 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -880,6 +880,7 @@ OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
 OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
 OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
 OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
+OBJS-$(CONFIG_LIBTURING_ENCODER)  += libturing.o
 OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
 OBJS-$(CONFIG_LIBVORBIS_DECODER)  += libvorbisdec.o
 OBJS-$(CONFIG_LIBVORBIS_ENCODER)  += libvorbisenc.o \
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index ada9481..0e61a4a 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -610,6 +610,7 @@ void avcodec_register_all(void)
 REGISTER_ENCDEC (LIBSPEEX,  libspeex);
 REGISTER_ENCODER(LIBTHEORA, libtheora);
 REGISTER_ENCODER(LIBTWOLAME,libtwolame);
+REGISTER_ENCODER(LIBTURING, libturing);
 REGISTER_ENCODER(LIBVO_AMRWBENC,libvo_amrwbenc);
 REGISTER_ENCDEC (LIBVORBIS, libvorbis);
 REGISTER_ENCDEC (LIBVPX_VP8,libvpx_vp8);
diff --git a/libavcodec/libturing.c b/libavcodec/libturing.c
new file mode 100644
index 000..eedaae0
--- /dev/null
+++ b/libavcodec/libturing.c
@@ -0,0 +1,268 @@
+/*
+ * libturing encoder
+ *
+ * Copyright (c) 2016 Turing Codec contributors
+ *
+ * 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 

Re: [FFmpeg-devel] [PATCH] Added the interface for the Turing codec

[Matteo Naccari]

> These dependencies are kind of a mess. Maybe you can make libturning
> include a pkg_config file so we don't have to maintain your library list here?

The new patch we just submitted addresses this point: the Turing codec will 
install a pkg-config file to list the dependencies as suggested

Matteo Naccari

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: 18 November 2016 18:51
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] Added the interface for the Turing
> codec
> 
> On Fri, Nov 18, 2016 at 4:25 PM, Matteo Naccari 
> wrote:
> > - The Turing codec is an open source HEVC encoder licensed under GPLv2
> > - More information at http://turingcodec.org/
> > ---
> >  LICENSE.md |   1 +
> >  configure  |   5 ++
> >  libavcodec/Makefile|   1 +
> >  libavcodec/allcodecs.c |   1 +
> >  libavcodec/libturing.c | 229
> > +
> >  5 files changed, 237 insertions(+)
> >  create mode 100644 libavcodec/libturing.c
> >
> > diff --git a/LICENSE.md b/LICENSE.md
> > index a384fa0..6f9fab8 100644
> > --- a/LICENSE.md
> > +++ b/LICENSE.md
> > @@ -86,6 +86,7 @@ The following libraries are under GPL:
> >  - frei0r
> >  - libcdio
> >  - librubberband
> > +- libturing
> >  - libvidstab
> >  - libx264
> >  - libx265
> > diff --git a/configure b/configure
> > index b5bfad6..47d6b93 100755
> > --- a/configure
> > +++ b/configure
> > @@ -255,6 +255,7 @@ External library support:
> >--enable-libssh  enable SFTP protocol via libssh [no]
> >--enable-libtesseractenable Tesseract, needed for ocr filter [no]
> >--enable-libtheora   enable Theora encoding via libtheora [no]
> > +  --enable-libturing   enable HEVC encoding via libturing [no]
> >--enable-libtwolame  enable MP2 encoding via libtwolame [no]
> >--enable-libv4l2 enable libv4l2/v4l-utils [no]
> >--enable-libvidstab  enable video stabilization using vid.stab [no]
> > @@ -1521,6 +1522,7 @@ EXTERNAL_LIBRARY_LIST="
> >  libssh
> >  libtesseract
> >  libtheora
> > +libturing
> >  libtwolame
> >  libv4l2
> >  libvidstab
> > @@ -2814,6 +2816,7 @@ libspeex_decoder_deps="libspeex"
> >  libspeex_encoder_deps="libspeex"
> >  libspeex_encoder_select="audio_frame_queue"
> >  libtheora_encoder_deps="libtheora"
> > +libturing_encoder_deps="libturing"
> >  libtwolame_encoder_deps="libtwolame"
> >  libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
> >  libvorbis_decoder_deps="libvorbis"
> > @@ -5072,6 +5075,7 @@ die_license_disabled gpl frei0r
> > die_license_disabled gpl libcdio  die_license_disabled gpl
> > librubberband  die_license_disabled gpl libsmbclient
> > +die_license_disabled gpl libturing
> >  die_license_disabled gpl libvidstab
> >  die_license_disabled gpl libx264
> >  die_license_disabled gpl libx265
> > @@ -5735,6 +5739,7 @@ enabled libssh&& require_pkg_config libssh
> libssh/sftp.h sftp_init
> >  enabled libspeex  && require_pkg_config speex speex/speex.h
> speex_decoder_init -lspeex
> >  enabled libtesseract  && require_pkg_config tesseract tesseract/capi.h
> TessBaseAPICreate
> >  enabled libtheora && require libtheora theora/theoraenc.h
> th_info_init -ltheoraenc -ltheoradec -logg
> > +enabled libturing && require libturing turing.h turing_version 
> > -lturing -
> lstdc++ -lboost_chrono -lboost_program_options -lboost_timer -
> lboost_system -lboost_filesystem -lhavoc
> 
> These dependencies are kind of a mess. Maybe you can make libturning
> include a pkg_config file so we don't have to maintain your library list here?
> 
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


-
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and 
may contain personal views which are not the views of the BBC unless 
specifically stated.
If you have received it in 
error, please delete it from your system.
Do not use, copy or disclose the 
information in any way nor act in reliance on it and notify the sender 
immediately.
Please note that the BBC monitors e-mails 
sent or received.
Further communication will signify your consent to 
this.
-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Added the interface for the Turing codec

[Matteo Naccari]

> This lib has a really weird API... Anyway, access to p++ seems unbounded and
> could go past the argv array. The string overflow checks also look
> questionable. snprintf() returns the size the string would have had and isn't
> limited by the buffer passed to it, so the s pointer can go out of bounds
> (which is undefined behavior). Also, "end - s"
> will underflow, making the attempt to avoid a buffer overflow pointless.

The patch we just submitted should address this point: now the buffer size for 
the command line option depends on the actual number of options passed by the 
user for the Turing codec.

Matteo Naccari


-
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless 
specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Added the interface for the Turing codec

[Matteo Naccari]

> Back to the review: From first glance, the libturing codec/library (or the
> executable only???) seems to have speed presets. Why are these not
> exposed to the libavcodec user?

All options, including the speed presets, can be specified using -turing-params 
(e.g. -turing-params speed=value). The reason why we decided to go for this 
option is because we want to be as less invasive as possible so that if we 
decide to change the name for a given option the changes will be transparent to 
FFmpeg.

Matteo Naccari

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Moritz Barsnick
> Sent: 19 November 2016 13:29
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] Added the interface for the Turing
> codec
> 
> On Fri, Nov 18, 2016 at 20:15:30 +0100, wm4 wrote:
> > This lib has a really weird API...
> 
> I can't judge the algorithms or the development direction and stuff - I'm sure
> it's all state of the art. But the API sure gives me goosebumps, and I don't
> mean the sexy feelgood type.
> 
> Sure, it has all the flexibility, but also almost all the disadvantages of 
> calling an
> external program. This makes it look so much like a proof of concept.
> 
> But I'm sure that's not the point. If it turns out to be here to stay, to 
> compete
> with x265 in one or the other way, it's probably worth integrating.
> 
> Back to the review: From first glance, the libturing codec/library (or the
> executable only???) seems to have speed presets. Why are these not
> exposed to the libavcodec user?
> 
> Furthermore: Documentation is missing.
> 
> £0.02,
> Moritz
> ___
> 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] Remove the ffserver program and the ffm muxer/demuxer

[Nicolas George]

L'octidi 8 frimaire, an CCXXV, James Almer a écrit :
> I discuss project management. This is a late attempt at overriding a decision
> from parties that didn't participate in the real decision making discussions.

Maybe they did not participate because they were busy working on the
actual code.

> This crap wouldn't fly anywhere else

Untrue.

> That nobody will take the project seriously anymore. That nobody will believe
> in any announcement anymore. That anyone will be 100% sure that with a little
> lobbying and trolling they will be able to get away with absolutely anything,
> including overriding old decisions.

I see. Then what about people who will be disgusted that FFmpeg is a
project where positive development (fixing bugs) is overridden by
negative development (removing things) just because the negative people
are more vocal?

My wet finger, which I consider more accurate than yours, tells me there
are many more.

> Malicious was the attempt at turning efforts of making the program capable
> of living on its own into an argument against the reason why it must go.

How is it malicious?

> You're aware that we could have told Reynaldo that no, we don't want to give
> him time to make it work standalone, and this patch would have been pushed
> a week or two ago, long before you even realized this all was even happening?

And that would have been incredibly rude. I would not have supported
that decision.

> That the decision was made, and there's no going back.

There is a French saying that I already quoted in this discussion: only
imbeciles never change their mind. For all it being a saying, it is
still very true.

Making one's mind involves taking into account the state of affairs at
the time and making a conclusion. If the state of affairs changes, then
the valid conclusion may change too. Someone who keeps the old
conclusion in this case is indeed an imbecile.

Well, for ffserver, the state of affairs just changed. Maybe it was a
consequence of the old decision, so what? The old decision was valid at
the time, given the state of affairs then. But the net result is still:
ffserver is now maintained, it no longer blocks the development of the
rest of the project, therefore the correct decision is no longer to
remove it.

> You could also add
> 
> # November 29th, 2016, From now on, announcements from this project are
> # worth as much as a copy of ET for the Atari.
> #
> # Thanks to the efforts of people that couldn't get over the fact they
> # showed up late and that abused the goodwill of some developers, nothing
> # you read announced here from now on is to be trusted.

You seem to have in your values system the axiom "keeping promises for
the sake of keeping promises", as if there was a superior being
rewarding that kind of consistency. A more correct axiom would be
"keeping promises for the sake of the person to whom the promise was
made".

You can try a poll on the users: "Considering the reasons to remove
ffserver are now void, would you have us keep our promise and remove it
now, or change our mind at the last minute and keep it?"

I have no doubt a huge majority of the users will answer: keep it.

> For things up to debate, sure. This is not the case.

What is this, if not a debate?

> No, those are the only options within the boundaries already established.

Changing the boundaries is always an option.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Nicolas George]

L'octidi 8 frimaire, an CCXXV, James Almer a écrit :
> The suggestion can be made if that happens in the future,

I can assure you, the suggestion will be made about five minutes about
the push, if it happens.

>   i guess, but i
> doubt it will be well received.

Well, the push without a valid reason will be very badly received too.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[wm4]

On Mon, 28 Nov 2016 16:05:29 +0100
Paul B Mahol  wrote:

> On 11/28/16, compn  wrote:
> > On Mon, 28 Nov 2016 02:22:48 +0100
> > Michael Niedermayer  wrote:
> >  
> >> I dont know if people want me and reynaldo to spend less time on
> >> FFmpeg, but time is a finite resource. If ffserver is maintained
> >> externally it would mean a noticable hit in maintaince man hours of
> >> FFmpeg. Now it might be that ffserver being pushed out would kill it.
> >> But really as dumb as i am, i dont belive theres a majority who wants
> >> to kill FFserver when there are people who actively work on it and
> >> care about it.  
> >
> > it seems like there are at least a few developers who would feel better
> > if ffserver was removed from master / moved somewhere else to die etc.
> >
> > these developers feel very strongly about removing ffserver.
> >
> > it might be wise to follow the opinions of these developers in order to
> > have a higher morale and continue the working environment here in the
> > project.
> >
> > otherwise some developers may feel betrayed, harmed, ignored, etc and
> > foster hatred because their opinions were not chosen.
> >
> > so michael, my advice to you is to just OK the patch and deal with
> > ffserver later... if enough users come back to complain about its
> > demise. i feel that this discussion is going no where if both sides are
> > unable to come to a compromise.
> >
> > sometimes you have to cut off the toe to save the patient. :)  
> 
> Exactly what happened with so called separate libpostprocess library.
> Is it still being maintained? - NOPE.

Because the only one who cared about it (michaelni) continued to
maintain the FFmpeg git copy of it, instead of the separate repository.

In other words, it was never given a chance.

But somehow it ends up as argument against splitting the repo better,
what a fucking joke is this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[James Almer]

On 11/28/2016 1:31 PM, Paul B Mahol wrote:
> On 11/28/16, James Almer  wrote:
>>> What difference does it make?
>>
>> That the decision was made, and there's no going back. And much less after
>> the malicious attempts i already described and pointed you to, that you
>> seemingly intend to ignore.
> 
> It can be readded later, after its fixed?

The suggestion can be made if that happens in the future, i guess, but i
doubt it will be well received. Fears of it bitrotting again would be
justified if it were to be accepted in the tree again.

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

Re: [FFmpeg-devel] [PATCH] Added the interface for the Turing codec

[Matteo Naccari]

>   I hope it copes well with multiple definitions of the same option, like the 
> last
> overwriting the previous ones.

The latest stable version of the Turing codec deals correctly with multiple 
definitions of the same option.

Matteo Naccari

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

Re: [FFmpeg-devel] [PATCH] Added Turing codec interface for ffmpeg

[wm4]

On Mon, 28 Nov 2016 16:29:32 +
Matteo Naccari  wrote:

> - This patch contains the changes to interface the Turing codec
>   (http://turingcodec.org/) to ffmpeg. The patch was modified to address
>   the comments in the review as follows:
>   - Added a pkg-config file to list all dependencies required by
>   libturing. This should address the issue pointed out by Hendrik
>   Leppkes on Fri 18/11/2016
>   - The buffer to store the turing-params options has now a size which
>   depends on how many of these parameters have been passed by the user.
>   This should address the issue pointed out by wm4 and Moritz Barsnick
>   on the ffmpeg-devel reflector
> ---
>  LICENSE.md |   1 +
>  configure  |   5 +
>  libavcodec/Makefile|   1 +
>  libavcodec/allcodecs.c |   1 +
>  libavcodec/libturing.c | 268 
> +
>  5 files changed, 276 insertions(+)
>  create mode 100644 libavcodec/libturing.c
> 
> diff --git a/LICENSE.md b/LICENSE.md
> index 640633c..86e5371 100644
> --- a/LICENSE.md
> +++ b/LICENSE.md
> @@ -85,6 +85,7 @@ The following libraries are under GPL:
>  - frei0r
>  - libcdio
>  - librubberband
> +- libturing
>  - libvidstab
>  - libx264
>  - libx265
> diff --git a/configure b/configure
> index 6345fc2..022ffa9 100755
> --- a/configure
> +++ b/configure
> @@ -255,6 +255,7 @@ External library support:
>--enable-libssh  enable SFTP protocol via libssh [no]
>--enable-libtesseractenable Tesseract, needed for ocr filter [no]
>--enable-libtheora   enable Theora encoding via libtheora [no]
> +  --enable-libturing   enable H.265/HEVC encoding via libturing [no]
>--enable-libtwolame  enable MP2 encoding via libtwolame [no]
>--enable-libv4l2 enable libv4l2/v4l-utils [no]
>--enable-libvidstab  enable video stabilization using vid.stab [no]
> @@ -1534,6 +1535,7 @@ EXTERNAL_LIBRARY_LIST="
>  libssh
>  libtesseract
>  libtheora
> +libturing
>  libtwolame
>  libv4l2
>  libvidstab
> @@ -2831,6 +2833,7 @@ libspeex_decoder_deps="libspeex"
>  libspeex_encoder_deps="libspeex"
>  libspeex_encoder_select="audio_frame_queue"
>  libtheora_encoder_deps="libtheora"
> +libturing_encoder_deps="libturing"
>  libtwolame_encoder_deps="libtwolame"
>  libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
>  libvorbis_decoder_deps="libvorbis"
> @@ -5096,6 +5099,7 @@ die_license_disabled gpl frei0r
>  die_license_disabled gpl libcdio
>  die_license_disabled gpl librubberband
>  die_license_disabled gpl libsmbclient
> +die_license_disabled gpl libturing
>  die_license_disabled gpl libvidstab
>  die_license_disabled gpl libx264
>  die_license_disabled gpl libx265
> @@ -5754,6 +5758,7 @@ enabled libssh&& require_pkg_config libssh 
> libssh/sftp.h sftp_init
>  enabled libspeex  && require_pkg_config speex speex/speex.h 
> speex_decoder_init -lspeex
>  enabled libtesseract  && require_pkg_config tesseract tesseract/capi.h 
> TessBaseAPICreate
>  enabled libtheora && require libtheora theora/theoraenc.h 
> th_info_init -ltheoraenc -ltheoradec -logg
> +enabled libturing && require_pkg_config libturing turing.h 
> turing_version
>  enabled libtwolame&& require libtwolame twolame.h twolame_init 
> -ltwolame &&
>   { check_lib twolame.h 
> twolame_encode_buffer_float32_interleaved -ltwolame ||
> die "ERROR: libtwolame must be installed and 
> version must be >= 0.3.10"; }
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 82f7fa2..cadefdc 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -880,6 +880,7 @@ OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
>  OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
>  OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
>  OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
> +OBJS-$(CONFIG_LIBTURING_ENCODER)  += libturing.o
>  OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
>  OBJS-$(CONFIG_LIBVORBIS_DECODER)  += libvorbisdec.o
>  OBJS-$(CONFIG_LIBVORBIS_ENCODER)  += libvorbisenc.o \
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index ada9481..0e61a4a 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -610,6 +610,7 @@ void avcodec_register_all(void)
>  REGISTER_ENCDEC (LIBSPEEX,  libspeex);
>  REGISTER_ENCODER(LIBTHEORA, libtheora);
>  REGISTER_ENCODER(LIBTWOLAME,libtwolame);
> +REGISTER_ENCODER(LIBTURING, libturing);
>  REGISTER_ENCODER(LIBVO_AMRWBENC,libvo_amrwbenc);
>  REGISTER_ENCDEC (LIBVORBIS, libvorbis);
>  REGISTER_ENCDEC (LIBVPX_VP8,libvpx_vp8);
> diff --git a/libavcodec/libturing.c b/libavcodec/libturing.c
> new file mode 100644
> index 000..eedaae0
> --- /dev/null
> +++ 

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Michael Niedermayer]

On Mon, Nov 28, 2016 at 01:07:31PM -0300, James Almer wrote:
> On 11/28/2016 12:59 PM, Nicolas George wrote:
> > L'octidi 8 frimaire, an CCXXV, James Almer a écrit :
> >> No Nicolas. It's a reminder that this patch, as discussed and announced, 
> >> will
> >> be pushed.
> > 
> > And the Corleone give you reminders that they will break your legs.
> > 
> >> I don't care about ffserver.
> > 
> > Then do not discuss ffserver.
> 
> I discuss project management. This is a late attempt at overriding a decision
> from parties that didn't participate in the real decision making discussions.
> 

> This crap wouldn't fly anywhere else, but somehow, and according to you, it's
> rational on ffmpeg.

Why is it a problem that after announcing the removial of a feature
we announce that the removial could be avoided as someone came forth
and updated the code making the removial unneeded ?
It should not be a unexpected course of events in a project driven by
volunteers that a volunteer does some work that previously was
believed noone would do

(but before any more announcing really we should check and double check
 that all issues that need fixing were fixed and i really want everyone
 agreeing and being happy and ATM everyone seems in bloodrage berseker
 mode, while that gives us a interresting suggestion for the next
 release name, it doesnt make me happy at all to see everyone fight
 and be angry)

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

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


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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[James Almer]

On 11/28/2016 12:24 PM, Nicolas George wrote:
> L'octidi 8 frimaire, an CCXXV, James Almer a écrit :
>> Threats? The only thing i see are reminders of what should have happened
>> earlier and will happen soon, as discussed an announced.
> 
> Reminding of unpleasant things over which you have total control, that
> is called threats.
> 
> "You will burn yourself." -> this is a warning.
> "I will burn you." -> that is a threat.
> 
> Since ffserver will not remove itself, it is indeed a threat.

No Nicolas. It's a reminder that this patch, as discussed and announced, will
be pushed.

> 
>> No, i want a project decision to finally go through. I don't give a shit
>> about the program. If you see me "emotional" is because i can't believe my
>> eyes when i see all this shit happening only after the decision was made
>> and not when actual development work was requested, or when the *final*
>> discussion was taking place.
>>
>> You all should have shown then. You didn't.
> 
> You act quite emotional over something you "don't give a shit" about.

I don't care about ffserver. I do care about the consequences of a bunch of
people that showed up very late to the party getting away with trying to
override an old project decision right when it was going to be made effective.

I'm here to make sure that doesn't happen.

> 
>> Every patch and change that's being done now are direct consequence and
>> effect of the decision to drop ffserver. It has remained broken,
>> unmaintained and bitrotting for years but now that we have reached the
>> fateful day, ffserver is suddenly more important than the h264 decoder.
> 
> This is a "post hoc ergo propter hoc" fallacy.
> 
> The recent patches and the proposal to remove ffserver are not a
> consequence of each other but both consequence of this single fact: the
> internal APIs that ffserver is (ab)using are being changed and it is
> blocking the merges.

This is a lie and you know it, regardless of how fancy you try to make it
sound like.
ffserver started getting all these little changes right after the removal
was going to be set in motion for the 3.2 release. Reynaldo even sent an
email stating as much. That these are meant to be efforts to make it not
depend on public api so it can live out of tree for whoever cares about it.
A little while after that, Andreas and such started to use said efforts as
an argument to "prove" ffserver was still being maintained.

Look it up, stop trying to rewrite history and stop being part of the
aforementioned malicious behavior.

> 
> The patches unblock the merges, therefore the removal is no longer
> needed.

Too bad the decision was made and announced. Had this happened months or
years ago, when help was requested and promptly ignored, it wouldn't have
ended up like this.

> 
>> This patch *should* have been committed weeks ago
> 
> I will remind you that most contributors work on the project on their
> free time. If you care so much about ffserver's code (apparently you do,
> or you would not be arguing so much about it), you could have sponsored
> them to work on it earlier.
> 
> Regards,

If you want to lose time trying to change a decision made by a group of
people, go to England and save them from Brexit. You'll probably have as
much success trying to change that as you'll have it here.

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Nicolas George]

L'octidi 8 frimaire, an CCXXV, James Almer a écrit :
> No Nicolas. It's a reminder that this patch, as discussed and announced, will
> be pushed.

And the Corleone give you reminders that they will break your legs.

> I don't care about ffserver.

Then do not discuss ffserver.

>  I do care about the consequences of a bunch of
> people that showed up very late to the party getting away with trying to
> override an old project decision right when it was going to be made effective.

What are those consequences, pray?

> This is a lie

No.

> Look it up, stop trying to rewrite history and stop being part of the
> aforementioned malicious behavior.

I see nothing malicious in trying to keep a useful program up to date.
You have strange priorities.

> Too bad the decision was made and announced.

Decisions can be revised. If this one exists, then it should.

>   Had this happened months or
> years ago, when help was requested and promptly ignored, it wouldn't have
> ended up like this.

What difference does it make?

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Reto Kromer]

I'm also very strongly for keeping ffserver.

Best regards, Reto

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[James Almer]

On 11/28/2016 1:39 PM, Nicolas George wrote:
> L'octidi 8 frimaire, an CCXXV, James Almer a écrit :
>> I discuss project management. This is a late attempt at overriding a decision
>> from parties that didn't participate in the real decision making discussions.
> 
> Maybe they did not participate because they were busy working on the
> actual code.

Keep thinking that if it helps you sleep or whatever.

> 
>> This crap wouldn't fly anywhere else
> 
> Untrue.

I'm eagerly waiting for your results about overriding Brexit, or making other
projects override their decisions of dropping their SPARC and SH5 ports.

> 
>> That nobody will take the project seriously anymore. That nobody will believe
>> in any announcement anymore. That anyone will be 100% sure that with a little
>> lobbying and trolling they will be able to get away with absolutely anything,
>> including overriding old decisions.
> 
> I see. Then what about people who will be disgusted that FFmpeg is a
> project where positive development (fixing bugs) is overridden by
> negative development (removing things) just because the negative people
> are more vocal?

Tell me of all the negative things that happened after we removed all those
library wrappers, when we replaced SDL with SDL2, and many other examples of
old, obsolete, broken or otherwise unmaintained removed modules.

> 
> My wet finger, which I consider more accurate than yours, tells me there
> are many more.

And this is why nobody tolerates talking with you. You only enter a discussion
to remind everyone they are wrong and you're right.

> 
>> Malicious was the attempt at turning efforts of making the program capable
>> of living on its own into an argument against the reason why it must go.
> 
> How is it malicious?

Do i have to say it for a third or fourth time? I think you're better re-reading
my previous emails. It's pretty clear there.

You haven't yet answered my question about how it isn't a lie, for that matter.
You're fast to make new questions while avoiding those aimed at you.

> 
>> You're aware that we could have told Reynaldo that no, we don't want to give
>> him time to make it work standalone, and this patch would have been pushed
>> a week or two ago, long before you even realized this all was even happening?
> 
> And that would have been incredibly rude. I would not have supported
> that decision.

Exactly, it would have been rude to reject a request of that kind, which is
why it was not.

What's rude is what happened after that was granted, and how.

> 
>> That the decision was made, and there's no going back.
> 
> There is a French saying that I already quoted in this discussion: only
> imbeciles never change their mind. For all it being a saying, it is
> still very true.

Call me an imbecile if you want, but i'll see this project decision being
made effective.

Push that ffprobe demuxer if you want and you find no more oposition. Unlike 
this
it's not bound or limited by a project decision, at least until someone calls
a vote about it, so both going in or not are still options, and i lost interest
on it.

You're also welcome to post a patch reintroducing ffserver after it doesn't
depend on private API and the ffm* modules.

> 
> Making one's mind involves taking into account the state of affairs at
> the time and making a conclusion. If the state of affairs changes, then
> the valid conclusion may change too. Someone who keeps the old
> conclusion in this case is indeed an imbecile.
> 
> Well, for ffserver, the state of affairs just changed. Maybe it was a
> consequence of the old decision, so what? The old decision was valid at

Finally! Looks like i'm talking with a rational being that doesn't ignore
facts after all.

> the time, given the state of affairs then. But the net result is still:
> ffserver is now maintained, it no longer blocks the development of the
> rest of the project, therefore the correct decision is no longer to
> remove it.
> 
>> You could also add
>>
>> # November 29th, 2016, From now on, announcements from this project are
>> # worth as much as a copy of ET for the Atari.
>> #
>> # Thanks to the efforts of people that couldn't get over the fact they
>> # showed up late and that abused the goodwill of some developers, nothing
>> # you read announced here from now on is to be trusted.
> 
> You seem to have in your values system the axiom "keeping promises for
> the sake of keeping promises", as if there was a superior being
> rewarding that kind of consistency. A more correct axiom would be
> "keeping promises for the sake of the person to whom the promise was
> made".

I'm pissed of at how this shit was handled. Of all the attempts at twisting
development efforts towards an specific goal in an unacceptable way.

I do not take the abuse of trust and goodwill kindly.

> 
> You can try a poll on the users: "Considering the reasons to remove
> ffserver are now void, would you have us keep our promise and remove it
> now, or change our mind at the 

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[James Almer]

On 11/28/2016 2:16 PM, Reto Kromer wrote:
> I'm also very strongly for keeping ffserver.
> 
> Best regards, Reto

Thanks, but this was up to discussion months ago, not now.

You're however welcome to help the efforts of making it work on
its own separate repository if you're interested in it.

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[wm4]

On Mon, 28 Nov 2016 16:59:54 +0100
Nicolas George  wrote:

> > Look it up, stop trying to rewrite history and stop being part of the
> > aforementioned malicious behavior.  
> 
> I see nothing malicious in trying to keep a useful program up to date.
> You have strange priorities.

I'm sorry to inform you that the way you do it (and your behavior
towards James Almer) is very malicious. If you can't see this, I'm
sorry for this project.

It's not my intention to participate in this discussion, though.
ffserver removal was decided long ago, and suddenly there is extensive
resistance against it. If you care so much, go fix it. And fix it
months ago, where we all agreed to delay ffserver removal a bit to
give you time to fix it.

These oddly timed recent patches don't fix anything about ffserver's
fundamental technical issues. They just appear to stall or sabotage the
removal for a little bit, again. This will happen over and over again.
Because you (e.g. michaelni) don't respect the decision, and just come
up with something to remove the current apparent reason for removal.
Not that it will actually help.

This just turns the FFmpeg project organization into a total joke.
Especially now that we seem to have shitstorm flamewars, where
the more persistent party gets to decide whether the decision really
goes through. This is certainly not rational behavior.

Anyway, not wasting my time on this any further. I'm sure you have a
sharp response, how about sending it to /dev/null. Spend your time
fixing ffserver out-of-tree instead, and we'll accept your patches to
readd ffserver once it's done.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Michael Niedermayer]

On Mon, Nov 28, 2016 at 09:14:15AM -0500, compn wrote:
[...]
> so michael, my advice to you is to just OK the patch and deal with
> ffserver later... if enough users come back to complain about its
> demise. i feel that this discussion is going no where if both sides are
> unable to come to a compromise.

I do not block the patch, i did not object to it. And iam not going to
kill anyone if its applied, it wont make me happy if its applied no
i would prefer a different path but thats my oppinion.

I did work on ffserver yes and i probably will continue as long as its
easy to work on it. I find the tool interresting

About approving or rejecting the patch, ffserver has a maintainer.
He is the one to make this hard decission, if a clear decission is
needed. Reynaldo is a reasonable person one can talk with

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

Never trust a computer, one day, it may think you are the virus. -- Compn


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

Re: [FFmpeg-devel] [PATCH] libvpxenc: Report encoded VP9 level

[Alex Converse]

On Mon, Nov 28, 2016 at 11:57 AM, James Zern  wrote:
> On Mon, Nov 28, 2016 at 10:34 AM, Alex Converse  
> wrote:
>> Report the actual level of the encoded output if a level is
>> targeted or the level is passively tracked with a target of 0.
>> ---
>>  libavcodec/libvpxenc.c | 32 
>>  1 file changed, 32 insertions(+)
>>
>
> lgtm

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

[FFmpeg-devel] [PATCH] No thread library dependencies when threading support is disabled.

[Gregory J. Wolfe]

When ALL threading support is disabled, the build should not create
a dependency on ANY thread library.

Signed-off-by: Gregory J. Wolfe 
---
 libavutil/cpu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index 73317c4..1803f6f 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -260,6 +260,7 @@ int av_cpu_count(void)
 static volatile int printed;
 
 int nb_cpus = 1;
+#if HAVE_THREADS
 #if HAVE_WINRT
 SYSTEM_INFO sysinfo;
 #endif
@@ -288,6 +289,7 @@ int av_cpu_count(void)
 GetNativeSystemInfo();
 nb_cpus = sysinfo.dwNumberOfProcessors;
 #endif
+#endif
 
 if (!printed) {
 av_log(NULL, AV_LOG_DEBUG, "detected %d logical cores\n", nb_cpus);
-- 
2.5.1.windows.1

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Reynaldo H. Verdejo Pinochet]

On 11/26/2016 01:00 PM, Rostislav Pehlivanov wrote:

[..]
Since a month has passed, reynaldo still hasn't responded, I think it's


This is not correct. I have been working on weeding
out it's private API usage problems. Last commit to
this effect is from 3 weeks ago.

Bests,

--
Reynaldo H. Verdejo Pinochet
Open Source Group - Samsung Research America
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[James Almer]

On 11/28/2016 5:40 PM, Andreas Cadhalpun wrote:
> On 28.11.2016 13:18, James Almer wrote:
>> [...] shit [...] shit [...] shit [...] shit. It's extremely disrespectful.
> 
> Everyone reading your mail gets a clear picture of who is disrespectful.
> 

Making my annoyance at the subject known using the above words is not the
same thing as being disrespectful to others.

> Please re-read our code of conduct and follow it in the future.
> 
> I don't know why you are so enraged about this topic, but I assume that's
> because you are frustrated about how ffserver has been allowed to continue
> using private APIs for a very long time.

You should probably read my emails before asking me to re-read them myself.
You'll find out why I'm enraged about this topic. I made it very clear.

> 
> Believe it or not, but I share some of that frustration and thus am happy
> that it has been decided to no longer let ffserver block the library cleanup.
> So if it's still using those private APIs at the next major bump, it will
> sadly have to go.
> 
> However, there is no valid technical reason to remove ffserver earlier or
> if it gets fixed, which is why this should not be done, in particular if
> other developers are still working on it.
> 
> That's the long and short of it.

The long and short of it is: You didn't show up when this was up to discussion.
You're showing up now, late, at the very moment the months old final decision
was going to be made effective, and pretending to alter and override the agreed
course of action, using malicious arguments to favor of your position in the
matter.

Where were you and Nicolas last July? Where were you during the past years when
requests for developers were made?

> 
> I'm dismayed to see that this discussion has devolved into useless flaming.
> I have no desire nor intent to take part in it and urge everyone else to
> refrain from participating in that kind of behavior as well.

And I'm dismayed at how you and Nicolas think it's "rational" to abuse the
goodwill of people and use it against them as arguments to favor your own
stance and agenda in this subject.

Neither you or Nicolas are working on ffserver, or will be working on it if you
get your way. All you're doing is proving that anything can be done in this
project if you're persistent enough, and outlast the other side in arguments.

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

Re: [FFmpeg-devel] [PATCH 1/3] ffserver: drop FeedData, its unused

[Reynaldo H. Verdejo Pinochet]

Looks good. Thank you!

Bests,


--
Reynaldo H. Verdejo Pinochet
Open Source Group - Samsung Research America
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Avoid MinGW/Windows dependency on gcc thread library.

[Gregory J. Wolfe]

Multi-threading support requires knowing the number of CPUs available.
When building with MinGW on a Windows system, both Windows and gcc run
time functions are available to get this information.  If available,
the Windows function should be used, not the gcc function.  This avoids
creating an unnecessary dependency on the gcc thread library.

Signed-off-by: Gregory J. Wolfe 
---
 libavutil/cpu.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index 1803f6f..6ebc7ce 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -264,17 +264,21 @@ int av_cpu_count(void)
 #if HAVE_WINRT
 SYSTEM_INFO sysinfo;
 #endif
-#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT)
+// if HAVE_GETPROCESSAFFINITYMASK, we will use Windows
+// GetProcessAffinityMask() over gcc library function
+// sched_getaffinity().  This avoids creating a dependency
+// on the gcc thread library that we don't need/want.
+#if HAVE_GETPROCESSAFFINITYMASK
+DWORD_PTR proc_aff, sys_aff;
+if (GetProcessAffinityMask(GetCurrentProcess(), _aff, _aff))
+nb_cpus = av_popcount64(proc_aff);
+#elif HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT)
 cpu_set_t cpuset;
 
 CPU_ZERO();
 
 if (!sched_getaffinity(0, sizeof(cpuset), ))
 nb_cpus = CPU_COUNT();
-#elif HAVE_GETPROCESSAFFINITYMASK
-DWORD_PTR proc_aff, sys_aff;
-if (GetProcessAffinityMask(GetCurrentProcess(), _aff, _aff))
-nb_cpus = av_popcount64(proc_aff);
 #elif HAVE_SYSCTL && defined(HW_NCPU)
 int mib[2] = { CTL_HW, HW_NCPU };
 size_t len = sizeof(nb_cpus);
-- 
2.5.1.windows.1

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

[FFmpeg-devel] [PATCH] lavc/vaapi-vp9: add support for profile 2 (bpp > 8)

[Mathieu Velten]

---
 libavcodec/vaapi_vp9.c |  1 +
 libavcodec/vp9.c   | 32 +---
 libavcodec/vp9.h   |  1 +
 3 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/libavcodec/vaapi_vp9.c b/libavcodec/vaapi_vp9.c
index b360dcb..9b3e81a 100644
--- a/libavcodec/vaapi_vp9.c
+++ b/libavcodec/vaapi_vp9.c
@@ -38,6 +38,7 @@ static void fill_picture_parameters(AVCodecContext
 *avctx,
 pp->first_partition_size = h->h.compressed_header_size;
 
 pp->profile = h->h.profile;
+pp->bit_depth = h->h.bpp;
 
 pp->filter_level = h->h.filter.level;
 pp->sharpness_level = h->h.filter.sharpness;
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 0ec895a..ff526da 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -68,7 +68,7 @@ typedef struct VP9Context {
 ptrdiff_t y_stride, uv_stride;
 
 uint8_t ss_h, ss_v;
-uint8_t last_bpp, bpp, bpp_index, bytesperpixel;
+uint8_t last_bpp, bpp_index, bytesperpixel;
 uint8_t last_keyframe;
 // sb_cols/rows, rows/cols and last_fmt are used for allocating all 
internal
 // arrays, and are thus per-thread. w/h and gf_fmt are synced between 
threads
@@ -258,7 +258,9 @@ static int update_size(AVCodecContext *ctx, int w, int h)
 if ((res = ff_set_dimensions(ctx, w, h)) < 0)
 return res;
 
-if (s->pix_fmt == AV_PIX_FMT_YUV420P) {
+if (s->pix_fmt == AV_PIX_FMT_YUV420P ||
+s->pix_fmt == AV_PIX_FMT_YUV420P10 ||
+s->pix_fmt == AV_PIX_FMT_YUV420P12) {
 #if CONFIG_VP9_DXVA2_HWACCEL
 *fmtp++ = AV_PIX_FMT_DXVA2_VLD;
 #endif
@@ -326,10 +328,10 @@ static int update_size(AVCodecContext *ctx, int w, int h)
 av_freep(>b_base);
 av_freep(>block_base);
 
-if (s->bpp != s->last_bpp) {
-ff_vp9dsp_init(>dsp, s->bpp, ctx->flags & AV_CODEC_FLAG_BITEXACT);
-ff_videodsp_init(>vdsp, s->bpp);
-s->last_bpp = s->bpp;
+if (s->s.h.bpp != s->last_bpp) {
+ff_vp9dsp_init(>dsp, s->s.h.bpp, ctx->flags & 
AV_CODEC_FLAG_BITEXACT);
+ff_videodsp_init(>vdsp, s->s.h.bpp);
+s->last_bpp = s->s.h.bpp;
 }
 
 return 0;
@@ -458,8 +460,8 @@ static int read_colorspace_details(AVCodecContext *ctx)
 int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(>gb); // 0:8, 1:10, 
2:12
 
 s->bpp_index = bits;
-s->bpp = 8 + bits * 2;
-s->bytesperpixel = (7 + s->bpp) >> 3;
+s->s.h.bpp = 8 + bits * 2;
+s->bytesperpixel = (7 + s->s.h.bpp) >> 3;
 ctx->colorspace = colorspaces[get_bits(>gb, 3)];
 if (ctx->colorspace == AVCOL_SPC_RGB) { // RGB = profile 1
 static const enum AVPixelFormat pix_fmt_rgb[3] = {
@@ -571,7 +573,7 @@ static int decode_frame_header(AVCodecContext *ctx,
 return res;
 } else {
 s->ss_h = s->ss_v = 1;
-s->bpp = 8;
+s->s.h.bpp = 8;
 s->bpp_index = 0;
 s->bytesperpixel = 1;
 s->pix_fmt = AV_PIX_FMT_YUV420P;
@@ -2278,7 +2280,7 @@ static int decode_coeffs_b_16bpp(VP9Context *s, int16_t 
*coef, int n_coeffs,
  const int16_t (*nb)[2], const int16_t 
*band_counts,
  const int16_t *qmul)
 {
-return decode_coeffs_b_generic(>c, coef, n_coeffs, 0, 0, s->bpp, cnt, 
eob, p,
+return decode_coeffs_b_generic(>c, coef, n_coeffs, 0, 0, s->s.h.bpp, 
cnt, eob, p,
nnz, scan, nb, band_counts, qmul);
 }
 
@@ -2288,7 +2290,7 @@ static int decode_coeffs_b32_16bpp(VP9Context *s, int16_t 
*coef, int n_coeffs,
const int16_t (*nb)[2], const int16_t 
*band_counts,
const int16_t *qmul)
 {
-return decode_coeffs_b_generic(>c, coef, n_coeffs, 1, 0, s->bpp, cnt, 
eob, p,
+return decode_coeffs_b_generic(>c, coef, n_coeffs, 1, 0, s->s.h.bpp, 
cnt, eob, p,
nnz, scan, nb, band_counts, qmul);
 }
 
@@ -2479,7 +2481,7 @@ static av_always_inline int check_intra_mode(VP9Context 
*s, int mode, uint8_t **
 int have_top = row > 0 || y > 0;
 int have_left = col > s->tile_col_start || x > 0;
 int have_right = x < w - 1;
-int bpp = s->bpp;
+int bpp = s->s.h.bpp;
 static const uint8_t mode_conv[10][2 /* have_left */][2 /* have_top */] = {
 [VERT_PRED]= { { DC_127_PRED,  VERT_PRED },
{ DC_127_PRED,  VERT_PRED } },
@@ -3310,13 +3312,13 @@ static void decode_b(AVCodecContext *ctx, int row, int 
col,
 s->uv_stride = f->linesize[1];
 }
 if (b->intra) {
-if (s->bpp > 8) {
+if (s->s.h.bpp > 8) {
 intra_recon_16bpp(ctx, yoff, uvoff);
 } else {
 intra_recon_8bpp(ctx, yoff, uvoff);
 }
 } else {
-if (s->bpp > 8) {
+if (s->s.h.bpp > 8) {
 inter_recon_16bpp(ctx);
 } else {
 

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[James Almer]

On 11/28/2016 5:40 PM, Michael Niedermayer wrote:
> On Mon, Nov 28, 2016 at 09:53:39AM -0900, Lou Logan wrote:
>> On Mon, Nov 28, 2016, at 09:15 AM, Nicolas George wrote:
>>>
>>> ffserver has users
>>
>> I don't know of any. Do you have an estimation of how many users there
>> may be? How much feedback has there been from these alleged users
>> regarding the removal plans?
> 
> iam not nicolas but just out of curiousity i checked our bug tracker
> there are 60 tickets marked as component = ffserver
> https://trac.ffmpeg.org/query?component=ffserver=id=summary=status=owner=type=priority=component=priority
> 
> to put this in perspective i tried component=ffmpeg
> which shows 313 tickets
> https://trac.ffmpeg.org/query?component=ffmpeg=id=summary=status=owner=type=priority=component=priority

How many are not tagged "ffmpeg" but are tagged as one of the libraries
and the bug in question was found by the user running ffmpeg? Now compare
that with users finding the bugs in their everyday usage of ffplay, ffprobe,
or ffserver.

Seeing we're close to six thousand bugs, it's safe to assume that number
for ffmpeg will be in the thousands, with ffprobe, ffplay and ffserver
very faw away with maybe two digit numbers.

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

[FFmpeg-devel] [PATCH] Define ETIMEDOUT in fifo_muxer.c for MinGW/Windows fate build.

[Gregory J. Wolfe]

Fate failed to build in the MinGW/Windows environment because
macro ETIMEDOUT was undefined.  When this condition is detected,
the code now includes <_ptw32.h>, which defines the symbol.

Signed-off-by: Gregory J. Wolfe 
---
 libavformat/tests/fifo_muxer.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/tests/fifo_muxer.c b/libavformat/tests/fifo_muxer.c
index 9659198..b579e48 100644
--- a/libavformat/tests/fifo_muxer.c
+++ b/libavformat/tests/fifo_muxer.c
@@ -25,6 +25,9 @@
 #include "libavutil/avassert.h"
 #include "libavformat/avformat.h"
 #include "libavformat/url.h"
+#ifndef ETIMEDOUT
+#include <_ptw32.h>
+#endif
 
 #define MAX_TST_PACKETS 128
 #define SLEEPTIME_50_MS 5
-- 
2.5.1.windows.1

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

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Michael Niedermayer]

On Mon, Nov 28, 2016 at 09:53:39AM -0900, Lou Logan wrote:
> On Mon, Nov 28, 2016, at 09:15 AM, Nicolas George wrote:
> >
> > ffserver has users
> 
> I don't know of any. Do you have an estimation of how many users there
> may be? How much feedback has there been from these alleged users
> regarding the removal plans?

iam not nicolas but just out of curiousity i checked our bug tracker
there are 60 tickets marked as component = ffserver
https://trac.ffmpeg.org/query?component=ffserver=id=summary=status=owner=type=priority=component=priority

to put this in perspective i tried component=ffmpeg
which shows 313 tickets
https://trac.ffmpeg.org/query?component=ffmpeg=id=summary=status=owner=type=priority=component=priority

[...]

-- 
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] Remove the ffserver program and the ffm muxer/demuxer

[Andreas Cadhalpun]

On 28.11.2016 13:18, James Almer wrote:
> [...] shit [...] shit [...] shit [...] shit. It's extremely disrespectful.

Everyone reading your mail gets a clear picture of who is disrespectful.

Please re-read our code of conduct and follow it in the future.

I don't know why you are so enraged about this topic, but I assume that's
because you are frustrated about how ffserver has been allowed to continue
using private APIs for a very long time.

Believe it or not, but I share some of that frustration and thus am happy
that it has been decided to no longer let ffserver block the library cleanup.
So if it's still using those private APIs at the next major bump, it will
sadly have to go.

However, there is no valid technical reason to remove ffserver earlier or
if it gets fixed, which is why this should not be done, in particular if
other developers are still working on it.

That's the long and short of it.

I'm dismayed to see that this discussion has devolved into useless flaming.
I have no desire nor intent to take part in it and urge everyone else to
refrain from participating in that kind of behavior as well.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH 2/2] lavfi: make filter_frame non-recursive.

[Andreas Cadhalpun]

On 28.11.2016 11:48, Nicolas George wrote:
> L'octidi 8 frimaire, an CCXXV, Andreas Cadhalpun a écrit :
>> I'm not sure I understand. Just do the rebase once, commit the deprecation
>> to git master and happily work on the other changes.
> 
> Except that kind of patch requires at least three rounds of review.
> Wasted time.

I see.

>> Not if the deprecation gets added, and thus this ifdeffery in avfilter.h
>> is reduced to a temporary problem.
> 
> With the provisions I added in the current patch, the only drawbacks
> that remains are matter of elegance and minor convenience. That means it
> is no matter if it stays that way a long time. Therefore, no need to
> revert (urgh, you really like wasting your time!

Rather the contrary, which is why I would prefer if the deprecation could
be applied first. However, I've no intention of wasting your time, either. ;)
So if it works better for you the other way around, I'm OK with that as well.

> reverting that big a patch!) even if the deprecation only reaches the
> repository after the release.

I'd rather not have a release that adds this ifdeffery to the public ABI
without deprecating direct use of the struct, though.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Add a compat stdatomic.h implementation based on GCC atomics

[Wan-Teh Chang]

From: Anton Khirnov 

Adapted from the code by Rémi Denis-Courmont from VLC

This merges libav commit 4e928ef340ac20325f529d92fcbc51e768085358.

Signed-off-by: Wan-Teh Chang 
---
 compat/atomics/gcc/stdatomic.h | 173 +
 configure  |   6 ++
 2 files changed, 179 insertions(+)
 create mode 100644 compat/atomics/gcc/stdatomic.h

diff --git a/compat/atomics/gcc/stdatomic.h b/compat/atomics/gcc/stdatomic.h
new file mode 100644
index 000..41cadde
--- /dev/null
+++ b/compat/atomics/gcc/stdatomic.h
@@ -0,0 +1,173 @@
+/*
+ * 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
+ */
+
+/*
+ * based on vlc_atomic.h from VLC
+ * Copyright (C) 2010 Rémi Denis-Courmont
+ */
+
+#ifndef COMPAT_ATOMICS_GCC_STDATOMIC_H
+#define COMPAT_ATOMICS_GCC_STDATOMIC_H
+
+#include 
+#include 
+
+#define ATOMIC_FLAG_INIT 0
+
+#define ATOMIC_VAR_INIT(value) (value)
+
+#define atomic_init(obj, value) \
+do {\
+*(obj) = (value);   \
+} while(0)
+
+#define kill_dependency(y) ((void)0)
+
+#define atomic_thread_fence(order) \
+__sync_synchronize()
+
+#define atomic_signal_fence(order) \
+((void)0)
+
+#define atomic_is_lock_free(obj) 0
+
+typedef _Bool  atomic_flag;
+typedef _Bool  atomic_bool;
+typedef  char  atomic_char;
+typedef   signed char  atomic_schar;
+typedef unsigned char  atomic_uchar;
+typedef  short atomic_short;
+typedef unsigned short atomic_ushort;
+typedef  int   atomic_int;
+typedef unsigned int   atomic_uint;
+typedef  long  atomic_long;
+typedef unsigned long  atomic_ulong;
+typedef  long long atomic_llong;
+typedef unsigned long long atomic_ullong;
+typedef  wchar_t   atomic_wchar_t;
+typedef   int_least8_t atomic_int_least8_t;
+typedef  uint_least8_t atomic_uint_least8_t;
+typedef  int_least16_t atomic_int_least16_t;
+typedef uint_least16_t atomic_uint_least16_t;
+typedef  int_least32_t atomic_int_least32_t;
+typedef uint_least32_t atomic_uint_least32_t;
+typedef  int_least64_t atomic_int_least64_t;
+typedef uint_least64_t atomic_uint_least64_t;
+typedef   int_fast8_t atomic_int_fast8_t;
+typedef  uint_fast8_t atomic_uint_fast8_t;
+typedef  int_fast16_t atomic_int_fast16_t;
+typedef uint_fast16_t atomic_uint_fast16_t;
+typedef  int_fast32_t atomic_int_fast32_t;
+typedef uint_fast32_t atomic_uint_fast32_t;
+typedef  int_fast64_t atomic_int_fast64_t;
+typedef uint_fast64_t atomic_uint_fast64_t;
+typedef  intptr_t atomic_intptr_t;
+typedef uintptr_t atomic_uintptr_t;
+typedefsize_t atomic_size_t;
+typedef ptrdiff_t atomic_ptrdiff_t;
+typedef  intmax_t atomic_intmax_t;
+typedef uintmax_t atomic_uintmax_t;
+
+#define atomic_store(object, desired)   \
+do {\
+*(object) = (desired);  \
+__sync_synchronize();   \
+} while (0)
+
+#define atomic_store_explicit(object, desired, order) \
+atomic_store(object, desired)
+
+#define atomic_load(object) \
+(__sync_synchronize(), *(object))
+
+#define atomic_load_explicit(object, order) \
+atomic_load(object)
+
+#define atomic_exchange(object, desired)\
+({  \
+typeof(object) _obj = (object); \
+typeof(*object) _old;   \
+do  \
+_old = atomic_load(_obj);   \
+while (!__sync_bool_compare_and_swap(_obj, _old, (desired)));   \
+_old;   \
+})
+
+#define atomic_exchange_explicit(object, desired, order) \
+atomic_exchange(object, desired)
+
+#define atomic_compare_exchange_strong(object, expected, desired)   \
+({  \
+typeof(object) _exp = (expected);   \
+typeof(*object) _old = *_exp;  

[FFmpeg-devel] [PATCH] Allow client to enable/disable openh264 load balancing.

[Gregory J. Wolfe]

The libopenh264 library allows the client to enable or disable
load balancing when running multi-threaded.  When enabled, the
slice sizes are dynamically adjusted in order to use the
multiple threads more efficiently.  However, this can also lead
to valid but slightly different results from run to run.
Disabling load balancing prevents dynamic slice adjustment and
yields repeatable results when running multi-threaded, which can
be important when running test cases.

Signed-off-by: Gregory J. Wolfe 
---
 libavcodec/libopenh264enc.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 648f59b..5aa1596 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -47,6 +47,9 @@ typedef struct SVCContext {
 int skip_frames;
 int skipped;
 int cabac;
+#if OPENH264_VER_AT_LEAST(1, 6)
+int load_balancing;
+#endif
 } SVCContext;
 
 #define OFFSET(x) offsetof(SVCContext, x)
@@ -71,6 +74,9 @@ static const AVOption options[] = {
 { "max_nal_size", "set maximum NAL size in bytes", OFFSET(max_nal_size), 
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
 { "allow_skip_frames", "allow skipping frames to hit the target bitrate", 
OFFSET(skip_frames), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
 { "cabac", "Enable cabac", OFFSET(cabac), AV_OPT_TYPE_INT, { .i64 = 0 }, 
0, 1, VE },
+#if OPENH264_VER_AT_LEAST(1, 6)
+{ "load_balancing", "enable/disable load balancing", 
OFFSET(load_balancing), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, VE },
+#endif
 { NULL }
 };
 
@@ -150,6 +156,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
 param.iLoopFilterDisableIdc  = !s->loopfilter;
 param.iEntropyCodingModeFlag = 0;
 param.iMultipleThreadIdc = avctx->thread_count;
+#if OPENH264_VER_AT_LEAST(1, 6)
+param.bUseLoadBalancing  = s->load_balancing;
+#endif
 if (s->profile && !strcmp(s->profile, "main"))
 param.iEntropyCodingModeFlag = 1;
 else if (!s->profile && s->cabac)
-- 
2.5.1.windows.1

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

Re: [FFmpeg-devel] [PATCH] ffserver: Remove last use of AVStream size

[Reynaldo H. Verdejo Pinochet]

Hi Michael

Looks good too. Please feel free to push
alongside the ones on the "Remove use of
AVStream.." thread.

Bests,

--
Reynaldo H. Verdejo Pinochet
Open Source Group - Samsung Research America
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Paul B Mahol]

Hi,

patch attached.
From a5f6dad7abb279ba1d57c1b7ee68c61b7381199c Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Mon, 28 Nov 2016 17:28:59 +0100
Subject: [PATCH] avfilter: add premultiply filter

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |   5 +
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_premultiply.c | 403 +++
 4 files changed, 410 insertions(+)
 create mode 100644 libavfilter/vf_premultiply.c

diff --git a/doc/filters.texi b/doc/filters.texi
index b3899b2..4a826a1 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10982,6 +10982,11 @@ Set medium thresholding (good results, default).
 @end table
 @end table
 
+@section premultiply
+Apply premultiply effect to input video stream using first plane of second stream.
+
+Both streams must have same dimensions and same pixel format.
+
 @section prewitt
 Apply prewitt operator to input video stream.
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index cdddb1b..cb614c9 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -240,6 +240,7 @@ OBJS-$(CONFIG_PHASE_FILTER)  += vf_phase.o
 OBJS-$(CONFIG_PIXDESCTEST_FILTER)+= vf_pixdesctest.o
 OBJS-$(CONFIG_PP_FILTER) += vf_pp.o
 OBJS-$(CONFIG_PP7_FILTER)+= vf_pp7.o
+OBJS-$(CONFIG_PREMULTIPLY_FILTER)+= vf_premultiply.o framesync.o
 OBJS-$(CONFIG_PREWITT_FILTER)+= vf_convolution.o
 OBJS-$(CONFIG_PSNR_FILTER)   += vf_psnr.o dualinput.o framesync.o
 OBJS-$(CONFIG_PULLUP_FILTER) += vf_pullup.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 82a65ee..2c37818 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -256,6 +256,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(PIXDESCTEST,pixdesctest,vf);
 REGISTER_FILTER(PP, pp, vf);
 REGISTER_FILTER(PP7,pp7,vf);
+REGISTER_FILTER(PREMULTIPLY,premultiply,vf);
 REGISTER_FILTER(PREWITT,prewitt,vf);
 REGISTER_FILTER(PSNR,   psnr,   vf);
 REGISTER_FILTER(PULLUP, pullup, vf);
diff --git a/libavfilter/vf_premultiply.c b/libavfilter/vf_premultiply.c
new file mode 100644
index 000..7b74f7d
--- /dev/null
+++ b/libavfilter/vf_premultiply.c
@@ -0,0 +1,403 @@
+/*
+ * 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
+ */
+
+#include "libavutil/imgutils.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "framesync.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct PreMultiplyContext {
+const AVClass *class;
+int width[4], height[4];
+int nb_planes;
+int planes;
+int half, depth, offset;
+FFFrameSync fs;
+
+void (*premultiply[4])(const uint8_t *msrc, const uint8_t *asrc,
+   uint8_t *dst,
+   ptrdiff_t mlinesize, ptrdiff_t alinesize,
+   ptrdiff_t dlinesize,
+   int w, int h,
+   int half, int shift, int offset);
+} PreMultiplyContext;
+
+#define OFFSET(x) offsetof(PreMultiplyContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption premultiply_options[] = {
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(premultiply);
+
+static int query_formats(AVFilterContext *ctx)
+{
+static const enum AVPixelFormat pix_fmts[] = {
+AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUVJ444P,
+AV_PIX_FMT_YUV444P9, AV_PIX_FMT_YUV444P10,
+AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV444P14,
+AV_PIX_FMT_YUV444P16,
+AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP9, AV_PIX_FMT_GBRP10,
+AV_PIX_FMT_GBRP12, AV_PIX_FMT_GBRP14, AV_PIX_FMT_GBRP16,
+AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY16,
+AV_PIX_FMT_NONE
+};
+
+return ff_set_common_formats(ctx, ff_make_format_list(pix_fmts));
+}
+
+static int process_frame(FFFrameSync *fs)
+{
+AVFilterContext *ctx = fs->parent;
+PreMultiplyContext *s = 

Re: [FFmpeg-devel] [PATCH 2/2] libvpxenc: Report encoded VP9 level

[Alex Converse]

On Tue, Nov 22, 2016 at 3:10 PM, James Zern  wrote:
> On Tue, Nov 22, 2016 at 12:08 PM, James Zern  wrote:
>> On Tue, Nov 22, 2016 at 12:04 PM, James Zern  wrote:
>>> On Fri, Nov 18, 2016 at 2:01 PM, Alex Converse  
>>> wrote:
 Report the actual level of the encoded output if a level is
 targeted or the level is passively tracked with a target of 0.
 ---
  libavcodec/libvpxenc.c | 31 +++
  1 file changed, 31 insertions(+)

>>>
>>> lgtm.
>>> I don't know if there's a better way to report this at the stream
>>> level (AV_PKT_DATA_STRINGS_METADATA?), there doesn't seem to be
>>> anything specific right now. This info can be translated quickly if
>>> someone wants to make this more structured or has any opinion now.
>>>
>>
>> I forgot that there was some discussion around adding this to the
>> codec extradata in webm. That could be a followup if there's
>> documentation on the format for that.
>
> http://wiki.webmproject.org/vp9-codecprivate

Are there any tools that read or write this data. libavformat and
libvpx/webmenc.cc don't seem to implement it. I'd rather not be the
guinea pig for this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[James Almer]

On 11/28/2016 1:52 PM, Michael Niedermayer wrote:
> On Mon, Nov 28, 2016 at 01:07:31PM -0300, James Almer wrote:
>> On 11/28/2016 12:59 PM, Nicolas George wrote:
>>> L'octidi 8 frimaire, an CCXXV, James Almer a écrit :
 No Nicolas. It's a reminder that this patch, as discussed and announced, 
 will
 be pushed.
>>>
>>> And the Corleone give you reminders that they will break your legs.
>>>
 I don't care about ffserver.
>>>
>>> Then do not discuss ffserver.
>>
>> I discuss project management. This is a late attempt at overriding a decision
>> from parties that didn't participate in the real decision making discussions.
>>
> 
>> This crap wouldn't fly anywhere else, but somehow, and according to you, it's
>> rational on ffmpeg.
> 
> Why is it a problem that after announcing the removial of a feature
> we announce that the removial could be avoided as someone came forth
> and updated the code making the removial unneeded ?
> It should not be a unexpected course of events in a project driven by
> volunteers that a volunteer does some work that previously was
> believed noone would do

Any work making ffserver not depend on private API and ffm* will take a long
while. It's unrealistic to think it will be ready even in time for 3.3 or the
major bump.

As i said, once that work is done from within a separate repo after ffserver
has been removed from the main repository as announced, I'm ok if a patch
reintroducing it is sent to this list. We can then discuss if it's something
we want to have in the tree again, knowing well history as shown interest on
it has been minimal and development sparse.

> 
> (but before any more announcing really we should check and double check
>  that all issues that need fixing were fixed and i really want everyone
>  agreeing and being happy and ATM everyone seems in bloodrage berseker
>  mode, while that gives us a interresting suggestion for the next
>  release name, it doesnt make me happy at all to see everyone fight
>  and be angry)

Neither to me. But how this was handled, how the agreed efforts towards
a graceful removal of ffserver for the benefit of anyone that still wants
to use it with up to date git master were used, rubbed me the wrong way.

I don't care about ffserver, but i do care about the image of the project,
and when people abuse trust.

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

[FFmpeg-devel] [PATCH] libvpxenc: Report encoded VP9 level

[Alex Converse]

Report the actual level of the encoded output if a level is
targeted or the level is passively tracked with a target of 0.
---
 libavcodec/libvpxenc.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 51f423a..1325199 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -137,6 +137,7 @@ static const char *const ctlidstr[] = {
 #endif
 #if VPX_ENCODER_ABI_VERSION >= 12
 [VP9E_SET_TARGET_LEVEL]= "VP9E_SET_TARGET_LEVEL",
+[VP9E_GET_LEVEL]   = "VP9E_GET_LEVEL",
 #endif
 #endif
 };
@@ -264,10 +265,41 @@ static av_cold int codecctl_int(AVCodecContext *avctx,
 return res == VPX_CODEC_OK ? 0 : AVERROR(EINVAL);
 }
 
+#if VPX_ENCODER_ABI_VERSION >= 12
+static av_cold int codecctl_intp(AVCodecContext *avctx,
+ enum vp8e_enc_control_id id, int *val)
+{
+VPxContext *ctx = avctx->priv_data;
+char buf[80];
+int width = -30;
+int res;
+
+snprintf(buf, sizeof(buf), "%s:", ctlidstr[id]);
+av_log(avctx, AV_LOG_DEBUG, "  %*s%d\n", width, buf, *val);
+
+res = vpx_codec_control(>encoder, id, val);
+if (res != VPX_CODEC_OK) {
+snprintf(buf, sizeof(buf), "Failed to set %s codec control",
+ ctlidstr[id]);
+log_encoder_error(avctx, buf);
+}
+
+return res == VPX_CODEC_OK ? 0 : AVERROR(EINVAL);
+}
+#endif
+
 static av_cold int vpx_free(AVCodecContext *avctx)
 {
 VPxContext *ctx = avctx->priv_data;
 
+#if VPX_ENCODER_ABI_VERSION >= 12
+if (ctx->level >= 0 && !(avctx->flags & AV_CODEC_FLAG_PASS1)) {
+int level_out = 0;
+if (!codecctl_intp(avctx, VP9E_GET_LEVEL, _out))
+av_log(avctx, AV_LOG_INFO, "Encoded level %.1f\n", level_out * 
0.1);
+}
+#endif
+
 vpx_codec_destroy(>encoder);
 if (ctx->is_alpha)
 vpx_codec_destroy(>encoder_alpha);
-- 
2.8.0.rc3.226.g39d4020

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Michael Niedermayer]

On Mon, Nov 28, 2016 at 05:03:53PM +0100, Nicolas George wrote:
> L'octidi 8 frimaire, an CCXXV, James Almer a écrit :
> > How about the news entry on the website stating ffserver was meant to
> > go with 3.2? And the discussions that lead to it? That's a good rational
> > argument.
> 
> # November 29th, 2016, ffserver not removed
> #
> # Thanks to the efforts of dedicated developers, ffserver has been
> # updated and no longer needs to be removed immediately.
> 
> That's taken care of. And I assure you, ffserver users will prefer a
> change of mind like that than a follow-through.
> 
> > If you meant technical arguments, the time for those was months ago.
> 
> The time for technical arguments is always.
> 

> > If there's a vote, it will be to choose between ffserver being removed
> > tomorrow, or right before 3.3 is branched.
> > There's no "ffserver stays" option. That possibility was lost months
> > ago when neither you or anyone else showed up to back it up.
> 
> Hail James, our Great Dictator who decides what we are allowed to vote
> about.

can everyone please try to not escalate this and be polite to each
other

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

Re: [FFmpeg-devel] [PATCH 2/2] libvpxenc: Report encoded VP9 level

[James Zern]

On Mon, Nov 28, 2016 at 10:32 AM, Alex Converse  wrote:
> On Tue, Nov 22, 2016 at 3:10 PM, James Zern  wrote:
>> On Tue, Nov 22, 2016 at 12:08 PM, James Zern  wrote:
>>> On Tue, Nov 22, 2016 at 12:04 PM, James Zern  wrote:
 On Fri, Nov 18, 2016 at 2:01 PM, Alex Converse  
 wrote:
> Report the actual level of the encoded output if a level is
> targeted or the level is passively tracked with a target of 0.
> ---
>  libavcodec/libvpxenc.c | 31 +++
>  1 file changed, 31 insertions(+)
>

 lgtm.
 I don't know if there's a better way to report this at the stream
 level (AV_PKT_DATA_STRINGS_METADATA?), there doesn't seem to be
 anything specific right now. This info can be translated quickly if
 someone wants to make this more structured or has any opinion now.

>>>
>>> I forgot that there was some discussion around adding this to the
>>> codec extradata in webm. That could be a followup if there's
>>> documentation on the format for that.
>>
>> http://wiki.webmproject.org/vp9-codecprivate
>
> Are there any tools that read or write this data. libavformat and
> libvpx/webmenc.cc don't seem to implement it. I'd rather not be the
> guinea pig for this.

libwebm has support in the muxer sample and webm_info for reporting:
https://chromium.googlesource.com/webm/libwebm/+/master/mkvmuxer_sample.cc#471
https://chromium.googlesource.com/webm/libwebm/+/master/webm_info.cc#381
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi/af_ebur128: update filter to use new ebur128 API

[Kyle Swanson]

On Thu, Nov 17, 2016 at 11:04 AM, Kyle Swanson  wrote:
> Hi,
>
> Here's a couple of patches which update the ebur128 filter to use the
> recently added ebur128 API. This updated filter allows fine-tuned
> control over which EBU R128 parameters are measured, and provides
> modest speed increases over the previous ebur128 filter. Also
> noteworthy: this removes the video output option of the ebur128
> filter. This is extraneous for an ebur128 measurement filter IMHO, but
> if we wanted to keep similar functionality in FFmpeg, we'd be better
> served by a new video source filter where custom meters could be
> created via exported frame metadata.
>
> The first patch adds true peak functionality to the ebur128 API using
> swresample (this was already discussed a little bit:
> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202583.html)
> The second patch is an update to the ebur128 filter.
>
> Kyle

Does anyone have any problems with the first patch?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Lou Logan]

On Mon, Nov 28, 2016, at 09:15 AM, Nicolas George wrote:
>
> ffserver has users

I don't know of any. Do you have an estimation of how many users there
may be? How much feedback has there been from these alleged users
regarding the removal plans?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Nicolas George]

Deadline: 2016-12-06 00:00 UTC.

I propose, and put to the discussion, that the decision to drop ffserver
is revoked, conditioned to the fixing of the technical issues that lead
to it.

In other words, if the technical problems that require dropping ffserver
are resolved at the time it is about to be dropped, then it must not be
and the patch is not applied.

I support the decision. Pros:

ffserver has users, if there are no reason to drop it, doing so is a
gratuitous annoyance to them.

Apparently James Almer opposes the decision. Cons, if I understand
correctly:

A decision was made, a project should stick to it stubbornly.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] libvpxenc: Report encoded VP9 level

[James Zern]

On Mon, Nov 28, 2016 at 10:34 AM, Alex Converse  wrote:
> Report the actual level of the encoded output if a level is
> targeted or the level is passively tracked with a target of 0.
> ---
>  libavcodec/libvpxenc.c | 32 
>  1 file changed, 32 insertions(+)
>

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

[FFmpeg-devel] [PATCH 2/2] tests/ffserver.regression.ref: update ffserver checksums

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 tests/ffserver.regression.ref | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/tests/ffserver.regression.ref b/tests/ffserver.regression.ref
index 9fc7497..2d7bb48 100644
--- a/tests/ffserver.regression.ref
+++ b/tests/ffserver.regression.ref
@@ -1,10 +1,10 @@
-18c4ba0e8e7adb781216e38de61c2e39  ff-test_h.avi
-f84767c7af61f360f4b443c2c73f322f  ff-test_l.avi
-d976848a9e4d5d8fc2659e4841cdece5  ff-test.swf
-28fd87d5075b9b011aad57292f271a04  ff-test_h.asf
-a31ccd3aba2551e60b9fb1c156fca2f8  ff-test_l.asf
-3279d3ed0ef2d1347b5eda84db2cf3e6  ff-test_h.rm
-440231fe3cf0849887390b4d67d6894a  ff-test_l.rm
-e0dc91430660c619e97b5c82e0f398fc  ff-test.jpg
-0d6c98fc8a4f00560fe34e94e26880a9  ff-test_small.jpg
-e2a315d7ac0576279f8b4d917999615a  ff-test.mjpg
+233020d119085ba47535d5f2faf73cc0 *ff-test_h.avi
+431b75d1f12cb039acebad61a3d39225 *ff-test_l.avi
+d41d8cd98f00b204e9800998ecf8427e *ff-test.swf
+dc16f607e13328a832e73801cd21ec98 *ff-test_h.asf
+69337d6c8cd7ac7e626338decdbf41d3 *ff-test_l.asf
+d41d8cd98f00b204e9800998ecf8427e *ff-test_h.rm
+d41d8cd98f00b204e9800998ecf8427e *ff-test_l.rm
+4c887dfc1dd0f6ea1a3a2be6dd32e495 *ff-test.jpg
+1d04b73b04aad27793cc762d5afabac1 *ff-test_small.jpg
+bc36c40ee34ebee6ffe50f3094aab733 *ff-test.mjpg
-- 
2.10.2

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

[FFmpeg-devel] [PATCH 1/2] tests/ffserver-regression.sh: give wget a timeout and prevent retries

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 tests/ffserver-regression.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/ffserver-regression.sh b/tests/ffserver-regression.sh
index 5c8ddb1..7ce5952 100755
--- a/tests/ffserver-regression.sh
+++ b/tests/ffserver-regression.sh
@@ -19,7 +19,7 @@ sleep 2
 (
 cd tests/data || exit $?
 rm -f ff-* ffserver.regression
-WGET_OPTIONS="--user-agent=NSPlayer -q --proxy=off -e verbose=off -e 
server_response=off"
+WGET_OPTIONS="--user-agent=NSPlayer -q --proxy=off -e verbose=off -e 
server_response=off -T3 --tries=1"
 for file in $FILES; do
 if [ $(expr $file : "a-*") != 0 ]; then
 wget $WGET_OPTIONS -O - http://localhost:/$file > ff-$file
-- 
2.10.2

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

Re: [FFmpeg-devel] [PATCH 1/3] ffserver: drop FeedData, its unused

[Michael Niedermayer]

On Mon, Nov 28, 2016 at 01:35:15PM -0800, Reynaldo H. Verdejo Pinochet wrote:
> Looks good. Thank you!

applied

thx

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

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


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

Re: [FFmpeg-devel] [PATCH] ffserver: Remove last use of AVStream size

[Michael Niedermayer]

On Mon, Nov 28, 2016 at 01:36:58PM -0800, Reynaldo H. Verdejo Pinochet wrote:
> Hi Michael
> 
> Looks good too. Please feel free to push
> alongside the ones on the "Remove use of
> AVStream.." thread.

applied

thx

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[James Almer]

On 11/28/2016 6:07 PM, James Almer wrote:
> On 11/28/2016 5:40 PM, Andreas Cadhalpun wrote:
>> On 28.11.2016 13:18, James Almer wrote:
>>> [...] shit [...] shit [...] shit [...] shit. It's extremely disrespectful.
>> Everyone reading your mail gets a clear picture of who is disrespectful.
>>
> Making my annoyance at the subject known using the above words is not the
> same thing as being disrespectful to others.
> 
>> Please re-read our code of conduct and follow it in the future.

I should also point that you seem to be ignoring Nicolas called me a dictator,
and indirectly an imbecile as well.

You may want to reply to his emails and tell him to read our code of conduct.

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

[FFmpeg-devel] [PATCH] Save FFmpeg colorspace info in openh264 video files.

[Gregory J. Wolfe]

As of version 1.6, libopenh264 saves (in the output video file)
information about the color primaries, transfer characteristics,
and color matrix used when the video pixel data was created.
This patch sets the required libopenh264 data structures using
the FFmpeg colorspace information so that video players will
know how to properly decode video files created using FFmpeg
and libopenh264.

Signed-off-by: Gregory J. Wolfe 
---
 libavcodec/libopenh264enc.c | 52 +
 1 file changed, 52 insertions(+)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 5aa1596..6de7790 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -206,6 +206,58 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 }
 
+#if OPENH264_VER_AT_LEAST(1, 6)
+// set video signal type information
+param.sSpatialLayers[0].bVideoSignalTypePresent = true;
+param.sSpatialLayers[0].uiVideoFormat = VF_UNDEF;
+param.sSpatialLayers[0].bFullRange = (avctx->color_range == 
AVCOL_RANGE_JPEG);
+param.sSpatialLayers[0].bColorDescriptionPresent = true;
+switch  ( avctx->color_primaries )
+{
+case  AVCOL_PRI_BT709:param.sSpatialLayers[0].uiColorPrimaries = 
CP_BT709;  break;
+case  AVCOL_PRI_UNSPECIFIED:  param.sSpatialLayers[0].uiColorPrimaries = 
CP_UNDEF;  break;
+case  AVCOL_PRI_BT470M:   param.sSpatialLayers[0].uiColorPrimaries = 
CP_BT470M;  break;
+case  AVCOL_PRI_BT470BG:  param.sSpatialLayers[0].uiColorPrimaries = 
CP_BT470BG;  break;
+case  AVCOL_PRI_SMPTE170M:param.sSpatialLayers[0].uiColorPrimaries = 
CP_SMPTE170M;  break;
+case  AVCOL_PRI_SMPTE240M:param.sSpatialLayers[0].uiColorPrimaries = 
CP_SMPTE240M;  break;
+case  AVCOL_PRI_FILM: param.sSpatialLayers[0].uiColorPrimaries = 
CP_FILM;  break;
+case  AVCOL_PRI_BT2020:   param.sSpatialLayers[0].uiColorPrimaries = 
CP_BT2020;  break;
+default:  param.sSpatialLayers[0].uiColorPrimaries = 
CP_UNDEF;  break;
+}
+switch  ( avctx->color_trc )
+{
+case  AVCOL_TRC_BT709: 
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT709;  break;
+case  AVCOL_TRC_UNSPECIFIED:   
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_UNDEF;  break;
+case  AVCOL_TRC_GAMMA22:   
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT470M;  break;
+case  AVCOL_TRC_GAMMA28:   
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT470BG;  break;
+case  AVCOL_TRC_SMPTE170M: 
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_SMPTE170M;  break;
+case  AVCOL_TRC_SMPTE240M: 
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_SMPTE240M;  break;
+case  AVCOL_TRC_LINEAR:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LINEAR;  break;
+case  AVCOL_TRC_LOG:   
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LOG100;  break;
+case  AVCOL_TRC_LOG_SQRT:  
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LOG316;  break;
+case  AVCOL_TRC_IEC61966_2_4:  
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_IEC61966_2_4;  break;
+case  AVCOL_TRC_BT1361_ECG:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT1361E;  break;
+case  AVCOL_TRC_IEC61966_2_1:  
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_IEC61966_2_1;  break;
+case  AVCOL_TRC_BT2020_10: 
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT2020_10;  break;
+case  AVCOL_TRC_BT2020_12: 
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT2020_12;  break;
+default:   
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_UNDEF;  break;
+}
+switch  ( avctx->colorspace )
+{
+case  AVCOL_SPC_RGB:  param.sSpatialLayers[0].uiColorMatrix = 
CM_GBR;  break;
+case  AVCOL_SPC_BT709:param.sSpatialLayers[0].uiColorMatrix = 
CM_BT709;  break;
+case  AVCOL_SPC_UNSPECIFIED:  param.sSpatialLayers[0].uiColorMatrix = 
CM_UNDEF;  break;
+case  AVCOL_SPC_FCC:  param.sSpatialLayers[0].uiColorMatrix = 
CM_FCC;  break;
+case  AVCOL_SPC_BT470BG:  param.sSpatialLayers[0].uiColorMatrix = 
CM_BT470BG;  break;
+case  AVCOL_SPC_SMPTE170M:param.sSpatialLayers[0].uiColorMatrix = 
CM_SMPTE170M;  break;
+case  AVCOL_SPC_SMPTE240M:param.sSpatialLayers[0].uiColorMatrix = 
CM_SMPTE240M;  break;
+case  AVCOL_SPC_YCOCG:param.sSpatialLayers[0].uiColorMatrix = 
CM_YCGCO;  break;
+case  AVCOL_SPC_BT2020_NCL:   param.sSpatialLayers[0].uiColorMatrix = 
CM_BT2020NC;  break;
+case  AVCOL_SPC_BT2020_CL:param.sSpatialLayers[0].uiColorMatrix = 
CM_BT2020C;  break;
+default:  param.sSpatialLayers[0].uiColorMatrix = 
CM_UNDEF;  break;
+}
+#endif
+
 if ((*s->encoder)->InitializeExt(s->encoder, ) != cmResultSuccess) {
 

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Steven Liu]

James Almer 于2016年11月29日 周二上午5:46写道：

> On 11/28/2016 6:07 PM, James Almer wrote:
> > On 11/28/2016 5:40 PM, Andreas Cadhalpun wrote:
> >> On 28.11.2016 13:18, James Almer wrote:
> >>> [...] shit [...] shit [...] shit [...] shit. It's extremely
> disrespectful.
> >> Everyone reading your mail gets a clear picture of who is disrespectful.
> >>
> > Making my annoyance at the subject known using the above words is not the
> > same thing as being disrespectful to others.
> >
> >> Please re-read our code of conduct and follow it in the future.
>
> I should also point that you seem to be ignoring Nicolas called me a
> dictator,
> and indirectly an imbecile as well.
>
> You may want to reply to his emails and tell him to read our code of
> conduct.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
I don't care about this, because I just use ffprobe ffplay ffmpeg, of
course, ffserver maybe important to some people for reference to
implementing a server use ffmpeg API

but I this the more and more important thing is the whole of ffmpeg
developing
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] mov: Evaluate the movie display matrix

[Vittorio Giovara]

On Fri, Nov 18, 2016 at 2:37 PM, Vittorio Giovara
 wrote:
> This matrix needs to be applied after all others have (currently only
> display matrix from trak), but cannot be handled in movie box, since
> streams are not allocated yet. So store it in main context, and apply
> it when appropriate, that is after parsing the tkhd one.
>
> Signed-off-by: Vittorio Giovara 
> ---

Hi, if no further objections I'll push the set tomorrow.
   o fate: Add test for mov displaymatrix
   o ffprobe: Fix displaying side data list only
   o mov: Evaluate the movie display matrix
Please CC me.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] hevc: Support extradata changes

[Vittorio Giovara]

On Thu, Nov 17, 2016 at 10:38 AM, Vittorio Giovara
 wrote:
> On Tue, Nov 8, 2016 at 5:03 PM, Vittorio Giovara
>  wrote:
>> Signed-off-by: Vittorio Giovara 
>> ---

Hi, if no further objections I'll push the set tomorrow.
   o hevc: Support extradata changes
   o hevc: Allow parsing external extradata buffers
Please CC.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 4/4] Add a compat dummy stdatomic.h used when threading is disabled

[Wan-Teh Chang]

From: Anton Khirnov 

Adapted from the code by Rémi Denis-Courmont from VLC

This merges libav commit eb34d40354e2474517c9b9bd787e0dadc89c2a81.

Signed-off-by: Wan-Teh Chang 
---
 compat/atomics/dummy/stdatomic.h | 176 +++
 configure|   3 +
 2 files changed, 179 insertions(+)
 create mode 100644 compat/atomics/dummy/stdatomic.h

diff --git a/compat/atomics/dummy/stdatomic.h b/compat/atomics/dummy/stdatomic.h
new file mode 100644
index 000..c26f629
--- /dev/null
+++ b/compat/atomics/dummy/stdatomic.h
@@ -0,0 +1,176 @@
+/*
+ * 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
+ */
+
+/*
+ * based on vlc_atomic.h from VLC
+ * Copyright (C) 2010 Rémi Denis-Courmont
+ */
+
+#ifndef COMPAT_ATOMICS_DUMMY_STDATOMIC_H
+#define COMPAT_ATOMICS_DUMMY_STDATOMIC_H
+
+#include 
+
+#define ATOMIC_FLAG_INIT 0
+
+#define ATOMIC_VAR_INIT(value) (value)
+
+#define atomic_init(obj, value) \
+do {\
+*(obj) = (value);   \
+} while(0)
+
+#define kill_dependency(y) ((void)0)
+
+#define atomic_thread_fence(order) \
+((void)0)
+
+#define atomic_signal_fence(order) \
+((void)0)
+
+#define atomic_is_lock_free(obj) 0
+
+typedef intptr_t atomic_flag;
+typedef intptr_t atomic_bool;
+typedef intptr_t atomic_char;
+typedef intptr_t atomic_schar;
+typedef intptr_t atomic_uchar;
+typedef intptr_t atomic_short;
+typedef intptr_t atomic_ushort;
+typedef intptr_t atomic_int;
+typedef intptr_t atomic_uint;
+typedef intptr_t atomic_long;
+typedef intptr_t atomic_ulong;
+typedef intptr_t atomic_llong;
+typedef intptr_t atomic_ullong;
+typedef intptr_t atomic_wchar_t;
+typedef intptr_t atomic_int_least8_t;
+typedef intptr_t atomic_uint_least8_t;
+typedef intptr_t atomic_int_least16_t;
+typedef intptr_t atomic_uint_least16_t;
+typedef intptr_t atomic_int_least32_t;
+typedef intptr_t atomic_uint_least32_t;
+typedef intptr_t atomic_int_least64_t;
+typedef intptr_t atomic_uint_least64_t;
+typedef intptr_t atomic_int_fast8_t;
+typedef intptr_t atomic_uint_fast8_t;
+typedef intptr_t atomic_int_fast16_t;
+typedef intptr_t atomic_uint_fast16_t;
+typedef intptr_t atomic_int_fast32_t;
+typedef intptr_t atomic_uint_fast32_t;
+typedef intptr_t atomic_int_fast64_t;
+typedef intptr_t atomic_uint_fast64_t;
+typedef intptr_t atomic_intptr_t;
+typedef intptr_t atomic_uintptr_t;
+typedef intptr_t atomic_size_t;
+typedef intptr_t atomic_ptrdiff_t;
+typedef intptr_t atomic_intmax_t;
+typedef intptr_t atomic_uintmax_t;
+
+#define atomic_store(object, desired)   \
+do {\
+*(object) = (desired);  \
+} while (0)
+
+#define atomic_store_explicit(object, desired, order) \
+atomic_store(object, desired)
+
+#define atomic_load(object) \
+(*(object))
+
+#define atomic_load_explicit(object, order) \
+atomic_load(object)
+
+static inline intptr_t atomic_exchange(intptr_t *object, intptr_t desired)
+{
+intptr_t ret = *object;
+*object = desired;
+return ret;
+}
+
+#define atomic_exchange_explicit(object, desired, order) \
+atomic_exchange(object, desired)
+
+static inline int atomic_compare_exchange_strong(intptr_t *object, intptr_t 
*expected,
+ intptr_t desired)
+{
+int ret;
+if (*object == *expected) {
+*object = desired;
+ret = 1;
+} else {
+*expected = *object;
+ret = 0;
+}
+return ret;
+}
+
+#define atomic_compare_exchange_strong_explicit(object, expected, desired, 
success, failure) \
+atomic_compare_exchange_strong(object, expected, desired)
+
+#define atomic_compare_exchange_weak(object, expected, desired) \
+atomic_compare_exchange_strong(object, expected, desired)
+
+#define atomic_compare_exchange_weak_explicit(object, expected, desired, 
success, failure) \
+atomic_compare_exchange_weak(object, expected, desired)
+
+#define FETCH_MODIFY(opname, op)\
+static inline intptr_t atomic_fetch_ ## opname(intptr_t *object, intptr_t 
operand) \
+{\
+intptr_t ret;\
+ret = 

[FFmpeg-devel] [PATCH 3/4] Add a compat stdatomic.h implementation based on pthreads

[Wan-Teh Chang]

From: Anton Khirnov 

Adapted from the code by Rémi Denis-Courmont from VLC

This merges libav commit f9a6a80e065cdb95b233978f1d96ec9bc863daa1.

Signed-off-by: Wan-Teh Chang 
---
 compat/atomics/pthread/stdatomic.c |  39 
 compat/atomics/pthread/stdatomic.h | 197 +
 configure  |   3 +
 3 files changed, 239 insertions(+)
 create mode 100644 compat/atomics/pthread/stdatomic.c
 create mode 100644 compat/atomics/pthread/stdatomic.h

diff --git a/compat/atomics/pthread/stdatomic.c 
b/compat/atomics/pthread/stdatomic.c
new file mode 100644
index 000..9fca989
--- /dev/null
+++ b/compat/atomics/pthread/stdatomic.c
@@ -0,0 +1,39 @@
+/*
+ * 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
+ */
+
+/*
+ * based on vlc_atomic.h from VLC
+ * Copyright (C) 2010 Rémi Denis-Courmont
+ */
+
+#include 
+#include 
+
+#include "stdatomic.h"
+
+static pthread_mutex_t atomic_lock = PTHREAD_MUTEX_INITIALIZER;
+
+void avpriv_atomic_lock(void)
+{
+pthread_mutex_lock(_lock);
+}
+
+void avpriv_atomic_unlock(void)
+{
+pthread_mutex_unlock(_lock);
+}
diff --git a/compat/atomics/pthread/stdatomic.h 
b/compat/atomics/pthread/stdatomic.h
new file mode 100644
index 000..1b7278e
--- /dev/null
+++ b/compat/atomics/pthread/stdatomic.h
@@ -0,0 +1,197 @@
+/*
+ * 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
+ */
+
+/*
+ * based on vlc_atomic.h from VLC
+ * Copyright (C) 2010 Rémi Denis-Courmont
+ */
+
+#ifndef COMPAT_ATOMICS_PTHREAD_STDATOMIC_H
+#define COMPAT_ATOMICS_PTHREAD_STDATOMIC_H
+
+#include 
+
+#define ATOMIC_FLAG_INIT 0
+
+#define ATOMIC_VAR_INIT(value) (value)
+
+#define atomic_init(obj, value) \
+do {\
+*(obj) = (value);   \
+} while(0)
+
+#define kill_dependency(y) ((void)0)
+
+#define atomic_signal_fence(order) \
+((void)0)
+
+#define atomic_is_lock_free(obj) 0
+
+typedef intptr_t atomic_flag;
+typedef intptr_t atomic_bool;
+typedef intptr_t atomic_char;
+typedef intptr_t atomic_schar;
+typedef intptr_t atomic_uchar;
+typedef intptr_t atomic_short;
+typedef intptr_t atomic_ushort;
+typedef intptr_t atomic_int;
+typedef intptr_t atomic_uint;
+typedef intptr_t atomic_long;
+typedef intptr_t atomic_ulong;
+typedef intptr_t atomic_llong;
+typedef intptr_t atomic_ullong;
+typedef intptr_t atomic_wchar_t;
+typedef intptr_t atomic_int_least8_t;
+typedef intptr_t atomic_uint_least8_t;
+typedef intptr_t atomic_int_least16_t;
+typedef intptr_t atomic_uint_least16_t;
+typedef intptr_t atomic_int_least32_t;
+typedef intptr_t atomic_uint_least32_t;
+typedef intptr_t atomic_int_least64_t;
+typedef intptr_t atomic_uint_least64_t;
+typedef intptr_t atomic_int_fast8_t;
+typedef intptr_t atomic_uint_fast8_t;
+typedef intptr_t atomic_int_fast16_t;
+typedef intptr_t atomic_uint_fast16_t;
+typedef intptr_t atomic_int_fast32_t;
+typedef intptr_t atomic_uint_fast32_t;
+typedef intptr_t atomic_int_fast64_t;
+typedef intptr_t atomic_uint_fast64_t;
+typedef intptr_t atomic_intptr_t;
+typedef intptr_t atomic_uintptr_t;
+typedef intptr_t atomic_size_t;
+typedef intptr_t atomic_ptrdiff_t;
+typedef intptr_t atomic_intmax_t;
+typedef intptr_t atomic_uintmax_t;
+
+void avpriv_atomic_lock(void);
+void avpriv_atomic_unlock(void);
+
+static inline void atomic_thread_fence(int order)
+{
+avpriv_atomic_lock();
+avpriv_atomic_unlock();
+}
+
+static inline void atomic_store(intptr_t *object, intptr_t desired)
+{
+avpriv_atomic_lock();
+*object = desired;
+

Re: [FFmpeg-devel] [PATCH] Save FFmpeg colorspace info in openh264 video files.

[Carl Eugen Hoyos]

2016-11-28 23:25 GMT+01:00 Gregory J. Wolfe :

> This patch sets the required libopenh264 data structures using
> the FFmpeg colorspace information so that video players will
> know how to properly decode video files created using FFmpeg
> and libopenh264.

Please copy FFmpeg's switch() style from another file and please
consider to align "param.", "=" and "break".

> +param.sSpatialLayers[0].uiVideoFormat = VF_UNDEF;

(What are the possible "formats"?)

> +param.sSpatialLayers[0].bFullRange = (avctx->color_range == 
> AVCOL_RANGE_JPEG);

The parentheses look unneeded.

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

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Michael Niedermayer]

On Mon, Nov 28, 2016 at 09:52:02PM +0100, Clément Bœsch wrote:
> On Mon, Nov 28, 2016 at 07:15:28PM +0100, Nicolas George wrote:
> > Deadline: 2016-12-06 00:00 UTC.
> > 
> > I propose, and put to the discussion, that the decision to drop ffserver
> > is revoked, conditioned to the fixing of the technical issues that lead
> > to it.
> > 
> 
> > In other words, if the technical problems that require dropping ffserver
> > are resolved at the time it is about to be dropped, then it must not be
> > and the patch is not applied.
> 
> Do we agree that the requirements are the following:
> 
> - ZERO internal API usage


> - at least partial FATE coverage

with the 2 patches i just posted
make  ffservertest
passes on x86_32, x86_64, qemu-arm and qemu-mips linux
mingw doesnt support ffserver

arm & mips used native ffmpeg as the qemu i used seems to lack execvp()
interception. That would also imlpy that mixing ffserver and
ffmpeg between big and little endian works

it does not work 100% yet though, i saw one failure that was not
reproduceable and the real media output doesnt work, ive a rough
idea why rm doesnt work but had no time to look into it

But at least ffservertest should at this point be usefull to detect
if something changes without intend


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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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

[FFmpeg-devel] [PATCH 1/4] Add a compat stdatomic.h implementation based on windows atomics

[Wan-Teh Chang]

From: Anton Khirnov 

Adapted from the code by Rémi Denis-Courmont from VLC

This merges libav commit c2755864afadfbaa349e8d583665c86fe99fa90b.

Signed-off-by: Wan-Teh Chang 
---
 compat/atomics/win32/stdatomic.h | 179 +++
 configure|   2 +
 2 files changed, 181 insertions(+)
 create mode 100644 compat/atomics/win32/stdatomic.h

diff --git a/compat/atomics/win32/stdatomic.h b/compat/atomics/win32/stdatomic.h
new file mode 100644
index 000..4cbba9c
--- /dev/null
+++ b/compat/atomics/win32/stdatomic.h
@@ -0,0 +1,179 @@
+/*
+ * 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 COMPAT_ATOMICS_WIN32_STDATOMIC_H
+#define COMPAT_ATOMICS_WIN32_STDATOMIC_H
+
+#include 
+#include 
+#include 
+
+#define ATOMIC_FLAG_INIT 0
+
+#define ATOMIC_VAR_INIT(value) (value)
+
+#define atomic_init(obj, value) \
+do {\
+*(obj) = (value);   \
+} while(0)
+
+#define kill_dependency(y) ((void)0)
+
+#define atomic_thread_fence(order) \
+MemoryBarrier();
+
+#define atomic_signal_fence(order) \
+((void)0)
+
+#define atomic_is_lock_free(obj) 0
+
+typedef intptr_t atomic_flag;
+typedef intptr_t atomic_bool;
+typedef intptr_t atomic_char;
+typedef intptr_t atomic_schar;
+typedef intptr_t atomic_uchar;
+typedef intptr_t atomic_short;
+typedef intptr_t atomic_ushort;
+typedef intptr_t atomic_int;
+typedef intptr_t atomic_uint;
+typedef intptr_t atomic_long;
+typedef intptr_t atomic_ulong;
+typedef intptr_t atomic_llong;
+typedef intptr_t atomic_ullong;
+typedef intptr_t atomic_wchar_t;
+typedef intptr_t atomic_int_least8_t;
+typedef intptr_t atomic_uint_least8_t;
+typedef intptr_t atomic_int_least16_t;
+typedef intptr_t atomic_uint_least16_t;
+typedef intptr_t atomic_int_least32_t;
+typedef intptr_t atomic_uint_least32_t;
+typedef intptr_t atomic_int_least64_t;
+typedef intptr_t atomic_uint_least64_t;
+typedef intptr_t atomic_int_fast8_t;
+typedef intptr_t atomic_uint_fast8_t;
+typedef intptr_t atomic_int_fast16_t;
+typedef intptr_t atomic_uint_fast16_t;
+typedef intptr_t atomic_int_fast32_t;
+typedef intptr_t atomic_uint_fast32_t;
+typedef intptr_t atomic_int_fast64_t;
+typedef intptr_t atomic_uint_fast64_t;
+typedef intptr_t atomic_intptr_t;
+typedef intptr_t atomic_uintptr_t;
+typedef intptr_t atomic_size_t;
+typedef intptr_t atomic_ptrdiff_t;
+typedef intptr_t atomic_intmax_t;
+typedef intptr_t atomic_uintmax_t;
+
+#define atomic_store(object, desired)   \
+do {\
+*(object) = (desired);  \
+MemoryBarrier();\
+} while (0)
+
+#define atomic_store_explicit(object, desired, order) \
+atomic_store(object, desired)
+
+#define atomic_load(object) \
+(MemoryBarrier(), *(object))
+
+#define atomic_load_explicit(object, order) \
+atomic_load(object)
+
+#define atomic_exchange(object, desired) \
+InterlockedExchangePointer(object, desired);
+
+#define atomic_exchange_explicit(object, desired, order) \
+atomic_exchange(object, desired)
+
+static inline int atomic_compare_exchange_strong(intptr_t *object, intptr_t 
*expected,
+ intptr_t desired)
+{
+intptr_t old = *expected;
+*expected = InterlockedCompareExchangePointer(object, desired, old);
+return *expected == old;
+}
+
+#define atomic_compare_exchange_strong_explicit(object, expected, desired, 
success, failure) \
+atomic_compare_exchange_strong(object, expected, desired)
+
+#define atomic_compare_exchange_weak(object, expected, desired) \
+atomic_compare_exchange_strong(object, expected, desired)
+
+#define atomic_compare_exchange_weak_explicit(object, expected, desired, 
success, failure) \
+atomic_compare_exchange_weak(object, expected, desired)
+
+#ifdef _WIN64
+#define atomic_fetch_add(object, operand) \
+InterlockedExchangeAdd64(object, operand)
+
+#define atomic_fetch_sub(object, operand) \
+InterlockedExchangeAdd64(object, -(operand))
+
+#define atomic_fetch_or(object, operand) \
+InterlockedOr64(object, operand)
+
+#define atomic_fetch_xor(object, operand) \
+InterlockedXor64(object, operand)
+
+#define atomic_fetch_and(object, operand) \
+ 

[FFmpeg-devel] [PATCH] avidec: fix leaking extradata

[Andreas Cadhalpun]

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/avidec.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index e5a292e..97dbeae 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -770,6 +770,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 st->codecpar->extradata_size = esize - 10 * 4;
 } else
 st->codecpar->extradata_size =  size - 10 * 4;
+av_freep(>codecpar->extradata);
 if (ff_get_extradata(s, st->codecpar, pb, 
st->codecpar->extradata_size) < 0)
 return AVERROR(ENOMEM);
 }
@@ -925,6 +926,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 st = s->streams[stream_index];
 
 if (size<(1<<30)) {
+av_freep(>codecpar->extradata);
 if (ff_get_extradata(s, st->codecpar, pb, size) < 0)
 return AVERROR(ENOMEM);
 }
-- 
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/4] Add a compat stdatomic.h implementation based on suncc atomics

[Wan-Teh Chang]

From: Anton Khirnov 

Adapted from the code by Rémi Denis-Courmont from VLC

This merges libav commit bb81ed476569b912a37ed553e756e123b6b13b14.

Signed-off-by: Wan-Teh Chang 
---
 compat/atomics/suncc/stdatomic.h | 186 +++
 configure|   2 +
 2 files changed, 188 insertions(+)
 create mode 100644 compat/atomics/suncc/stdatomic.h

diff --git a/compat/atomics/suncc/stdatomic.h b/compat/atomics/suncc/stdatomic.h
new file mode 100644
index 000..119c2ba
--- /dev/null
+++ b/compat/atomics/suncc/stdatomic.h
@@ -0,0 +1,186 @@
+/*
+ * 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 COMPAT_ATOMICS_SUNCC_STDATOMIC_H
+#define COMPAT_ATOMICS_SUNCC_STDATOMIC_H
+
+#include 
+#include 
+#include 
+#include 
+
+#define ATOMIC_FLAG_INIT 0
+
+#define ATOMIC_VAR_INIT(value) (value)
+
+#define atomic_init(obj, value) \
+do {\
+*(obj) = (value);   \
+} while(0)
+
+#define kill_dependency(y) ((void)0)
+
+#define atomic_thread_fence(order) \
+__machine_rw_barrier();
+
+#define atomic_signal_fence(order) \
+((void)0)
+
+#define atomic_is_lock_free(obj) 0
+
+typedef intptr_t atomic_flag;
+typedef intptr_t atomic_bool;
+typedef intptr_t atomic_char;
+typedef intptr_t atomic_schar;
+typedef intptr_t atomic_uchar;
+typedef intptr_t atomic_short;
+typedef intptr_t atomic_ushort;
+typedef intptr_t atomic_int;
+typedef intptr_t atomic_uint;
+typedef intptr_t atomic_long;
+typedef intptr_t atomic_ulong;
+typedef intptr_t atomic_llong;
+typedef intptr_t atomic_ullong;
+typedef intptr_t atomic_wchar_t;
+typedef intptr_t atomic_int_least8_t;
+typedef intptr_t atomic_uint_least8_t;
+typedef intptr_t atomic_int_least16_t;
+typedef intptr_t atomic_uint_least16_t;
+typedef intptr_t atomic_int_least32_t;
+typedef intptr_t atomic_uint_least32_t;
+typedef intptr_t atomic_int_least64_t;
+typedef intptr_t atomic_uint_least64_t;
+typedef intptr_t atomic_int_fast8_t;
+typedef intptr_t atomic_uint_fast8_t;
+typedef intptr_t atomic_int_fast16_t;
+typedef intptr_t atomic_uint_fast16_t;
+typedef intptr_t atomic_int_fast32_t;
+typedef intptr_t atomic_uint_fast32_t;
+typedef intptr_t atomic_int_fast64_t;
+typedef intptr_t atomic_uint_fast64_t;
+typedef intptr_t atomic_intptr_t;
+typedef intptr_t atomic_uintptr_t;
+typedef intptr_t atomic_size_t;
+typedef intptr_t atomic_ptrdiff_t;
+typedef intptr_t atomic_intmax_t;
+typedef intptr_t atomic_uintmax_t;
+
+static inline void atomic_store(intptr_t *object, intptr_t desired)
+{
+*object = desired;
+__machine_rw_barrier();
+}
+
+#define atomic_store_explicit(object, desired, order) \
+atomic_store(object, desired)
+
+static inline intptr_t atomic_load(intptr_t *object)
+{
+__machine_rw_barrier();
+return *object;
+}
+
+#define atomic_load_explicit(object, order) \
+atomic_load(object)
+
+#define atomic_exchange(object, desired) \
+atomic_swap_ptr(object, desired)
+
+#define atomic_exchange_explicit(object, desired, order) \
+atomic_exchange(object, desired)
+
+static inline int atomic_compare_exchange_strong(intptr_t *object, intptr_t 
*expected,
+ intptr_t desired)
+{
+intptr_t  old = *expected;
+*expected = atomic_cas_ptr(object, old, desired);
+return *expected == old;
+}
+
+#define atomic_compare_exchange_strong_explicit(object, expected, desired, 
success, failure) \
+atomic_compare_exchange_strong(object, expected, desired)
+
+#define atomic_compare_exchange_weak(object, expected, desired) \
+atomic_compare_exchange_strong(object, expected, desired)
+
+#define atomic_compare_exchange_weak_explicit(object, expected, desired, 
success, failure) \
+atomic_compare_exchange_weak(object, expected, desired)
+
+static inline intptr_t atomic_fetch_add(intptr_t *object, intptr_t operand)
+{
+return atomic_add_ptr_nv(object, operand) - operand;
+}
+
+#define atomic_fetch_sub(object, operand) \
+atomic_fetch_add(object, -(operand))
+
+static inline intptr_t atomic_fetch_or(intptr_t *object, intptr_t operand)
+{
+intptr_t old;
+do {
+old = atomic_load(object);
+} while (!atomic_compare_exchange_strong(object, old, old | 

Re: [FFmpeg-devel] [PATCH] lavfi/af_ebur128: update filter to use new ebur128 API

[Michael Niedermayer]

On Mon, Nov 28, 2016 at 01:13:41PM -0600, Kyle Swanson wrote:
> On Thu, Nov 17, 2016 at 11:04 AM, Kyle Swanson  wrote:
> > Hi,
> >
> > Here's a couple of patches which update the ebur128 filter to use the
> > recently added ebur128 API. This updated filter allows fine-tuned
> > control over which EBU R128 parameters are measured, and provides
> > modest speed increases over the previous ebur128 filter. Also
> > noteworthy: this removes the video output option of the ebur128
> > filter. This is extraneous for an ebur128 measurement filter IMHO, but
> > if we wanted to keep similar functionality in FFmpeg, we'd be better
> > served by a new video source filter where custom meters could be
> > created via exported frame metadata.
> >
> > The first patch adds true peak functionality to the ebur128 API using
> > swresample (this was already discussed a little bit:
> > http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202583.html)
> > The second patch is an update to the ebur128 filter.
> >
> > Kyle
> 
> Does anyone have any problems with the first patch?

i see some compiler warnings:

CC  libavfilter/ebur128.o
libavfilter/ebur128.c: In function ‘ebur128_init_resampler’:
libavfilter/ebur128.c:233:9: warning: variable ‘errcode’ set but not used 
[-Wunused-but-set-variable]
libavfilter/ebur128.c: In function ‘ff_ebur128_init’:
libavfilter/ebur128.c:358:5: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]

(there are 2 more that were present before)

CC  libavfilter/ebur128.o
libavfilter/ebur128.c: In function ‘ebur128_gated_loudness.part.7’:
libavfilter/ebur128.c:382:20: warning: ‘relative_threshold’ may be used 
uninitialized in this function [-Wuninitialized]
libavfilter/ebur128.c:548:12: note: ‘relative_threshold’ was declared here
libavfilter/ebur128.c:565:8: warning: ‘above_thresh_counter’ may be used 
uninitialized in this function [-Wuninitialized]



[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


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

Re: [FFmpeg-devel] [PATCH 1/3] hevc: Allow parsing external extradata buffers

[Michael Niedermayer]

On Tue, Nov 08, 2016 at 05:03:26PM -0500, Vittorio Giovara wrote:
> ---
> As mentioned in the discussion.
> Please CC.
> Vittorio
> 
>  libavcodec/hevc.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
> index 29e0d49..02fd606 100644
> --- a/libavcodec/hevc.c
> +++ b/libavcodec/hevc.c
> @@ -2973,17 +2973,15 @@ static int verify_md5(HEVCContext *s, AVFrame *frame)
>  return 0;
>  }
>  
> -static int hevc_decode_extradata(HEVCContext *s)
> +static int hevc_decode_extradata(HEVCContext *s, uint8_t *buf, int length)
>  {
>  AVCodecContext *avctx = s->avctx;
>  GetByteContext gb;
>  int ret, i;
>  
> -bytestream2_init(, avctx->extradata, avctx->extradata_size);
> +bytestream2_init(, buf, length);
>  
> -if (avctx->extradata_size > 3 &&
> -(avctx->extradata[0] || avctx->extradata[1] ||
> - avctx->extradata[2] > 1)) {
> +if (avctx->extradata_size > 3 && (buf[0] || buf[1] || buf[2] > 1)) {
   ^

is that intended to stay extradata_size ?

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

[FFmpeg-devel] [PATCH] idroqdec: fix leaking pkt on failure

[Andreas Cadhalpun]

The code calls av_new_packet a few lines above and the allocated memory
has to be freed in case of an error.

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/idroqdec.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/idroqdec.c b/libavformat/idroqdec.c
index b664279..c42b3d3 100644
--- a/libavformat/idroqdec.c
+++ b/libavformat/idroqdec.c
@@ -219,8 +219,10 @@ static int roq_read_packet(AVFormatContext *s,
 pkt->pos= avio_tell(pb);
 ret = avio_read(pb, pkt->data + RoQ_CHUNK_PREAMBLE_SIZE,
 chunk_size);
-if (ret != chunk_size)
+if (ret != chunk_size) {
+av_packet_unref(pkt);
 ret = AVERROR(EIO);
+}
 
 packet_read = 1;
 break;
-- 
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Define ETIMEDOUT in fifo_muxer.c for MinGW/Windows fate build.

[Daniel Verkamp]

On Mon, Nov 28, 2016 at 1:22 PM, Gregory J. Wolfe
 wrote:
> Fate failed to build in the MinGW/Windows environment because
> macro ETIMEDOUT was undefined.  When this condition is detected,
> the code now includes <_ptw32.h>, which defines the symbol.
>
> Signed-off-by: Gregory J. Wolfe 
> ---
>  libavformat/tests/fifo_muxer.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavformat/tests/fifo_muxer.c b/libavformat/tests/fifo_muxer.c
> index 9659198..b579e48 100644
> --- a/libavformat/tests/fifo_muxer.c
> +++ b/libavformat/tests/fifo_muxer.c
> @@ -25,6 +25,9 @@
>  #include "libavutil/avassert.h"
>  #include "libavformat/avformat.h"
>  #include "libavformat/url.h"
> +#ifndef ETIMEDOUT
> +#include <_ptw32.h>
> +#endif

Should this maybe be including libavformat/network.h, which already
has a workaround using the winsock definitions?

My local MinGW-w64 installation doesn't have a _ptw32.h file.

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

Re: [FFmpeg-devel] [PATCH] idroqdec: fix leaking pkt on failure

[Michael Niedermayer]

On Tue, Nov 29, 2016 at 12:46:11AM +0100, Andreas Cadhalpun wrote:
> The code calls av_new_packet a few lines above and the allocated memory
> has to be freed in case of an error.

should be ok

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

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi-vp9: add support for profile 2 (bpp > 8)

[Mark Thompson]

On 28/11/16 21:22, Mathieu Velten wrote:
> ---
>  libavcodec/vaapi_vp9.c |  1 +
>  libavcodec/vp9.c   | 32 +---
>  libavcodec/vp9.h   |  1 +
>  3 files changed, 19 insertions(+), 15 deletions(-)

Nice :)

Tested on Kaby Lake, works for me (woo 180fps 4K 10-bit decode).

This should probably be split into two patches, though - one for the generic 
vp9 hwaccel support, a second then enabling it for VAAPI.

> diff --git a/libavcodec/vaapi_vp9.c b/libavcodec/vaapi_vp9.c
> index b360dcb..9b3e81a 100644
> --- a/libavcodec/vaapi_vp9.c
> +++ b/libavcodec/vaapi_vp9.c
> @@ -38,6 +38,7 @@ static void fill_picture_parameters(AVCodecContext  
>*avctx,
>  pp->first_partition_size = h->h.compressed_header_size;
>  
>  pp->profile = h->h.profile;
> +pp->bit_depth = h->h.bpp;
>  
>  pp->filter_level = h->h.filter.level;
>  pp->sharpness_level = h->h.filter.sharpness;
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index 0ec895a..ff526da 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -68,7 +68,7 @@ typedef struct VP9Context {
>  ptrdiff_t y_stride, uv_stride;
>  
>  uint8_t ss_h, ss_v;
> -uint8_t last_bpp, bpp, bpp_index, bytesperpixel;
> +uint8_t last_bpp, bpp_index, bytesperpixel;
>  uint8_t last_keyframe;
>  // sb_cols/rows, rows/cols and last_fmt are used for allocating all 
> internal
>  // arrays, and are thus per-thread. w/h and gf_fmt are synced between 
> threads
> @@ -258,7 +258,9 @@ static int update_size(AVCodecContext *ctx, int w, int h)
>  if ((res = ff_set_dimensions(ctx, w, h)) < 0)
>  return res;
>  
> -if (s->pix_fmt == AV_PIX_FMT_YUV420P) {
> +if (s->pix_fmt == AV_PIX_FMT_YUV420P ||
> +s->pix_fmt == AV_PIX_FMT_YUV420P10 ||
> +s->pix_fmt == AV_PIX_FMT_YUV420P12) {
>  #if CONFIG_VP9_DXVA2_HWACCEL
>  *fmtp++ = AV_PIX_FMT_DXVA2_VLD;
>  #endif

This is enabling it for DXVA2 and D3D11VA as well?  I'm guessing you probably 
didn't want to do that - I think it would be better with something more like 
.

> @@ -326,10 +328,10 @@ static int update_size(AVCodecContext *ctx, int w, int 
> h)
>  av_freep(>b_base);
>  av_freep(>block_base);
>  
> -if (s->bpp != s->last_bpp) {
> -ff_vp9dsp_init(>dsp, s->bpp, ctx->flags & AV_CODEC_FLAG_BITEXACT);
> -ff_videodsp_init(>vdsp, s->bpp);
> -s->last_bpp = s->bpp;
> +if (s->s.h.bpp != s->last_bpp) {
> +ff_vp9dsp_init(>dsp, s->s.h.bpp, ctx->flags & 
> AV_CODEC_FLAG_BITEXACT);
> +ff_videodsp_init(>vdsp, s->s.h.bpp);
> +s->last_bpp = s->s.h.bpp;
>  }
>  
>  return 0;
> @@ -458,8 +460,8 @@ static int read_colorspace_details(AVCodecContext *ctx)
>  int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(>gb); // 0:8, 1:10, 
> 2:12
>  
>  s->bpp_index = bits;
> -s->bpp = 8 + bits * 2;
> -s->bytesperpixel = (7 + s->bpp) >> 3;
> +s->s.h.bpp = 8 + bits * 2;
> +s->bytesperpixel = (7 + s->s.h.bpp) >> 3;
>  ctx->colorspace = colorspaces[get_bits(>gb, 3)];
>  if (ctx->colorspace == AVCOL_SPC_RGB) { // RGB = profile 1
>  static const enum AVPixelFormat pix_fmt_rgb[3] = {
> @@ -571,7 +573,7 @@ static int decode_frame_header(AVCodecContext *ctx,
>  return res;
>  } else {
>  s->ss_h = s->ss_v = 1;
> -s->bpp = 8;
> +s->s.h.bpp = 8;
>  s->bpp_index = 0;
>  s->bytesperpixel = 1;
>  s->pix_fmt = AV_PIX_FMT_YUV420P;
> @@ -2278,7 +2280,7 @@ static int decode_coeffs_b_16bpp(VP9Context *s, int16_t 
> *coef, int n_coeffs,
>   const int16_t (*nb)[2], const int16_t 
> *band_counts,
>   const int16_t *qmul)
>  {
> -return decode_coeffs_b_generic(>c, coef, n_coeffs, 0, 0, s->bpp, cnt, 
> eob, p,
> +return decode_coeffs_b_generic(>c, coef, n_coeffs, 0, 0, s->s.h.bpp, 
> cnt, eob, p,
> nnz, scan, nb, band_counts, qmul);
>  }
>  
> @@ -2288,7 +2290,7 @@ static int decode_coeffs_b32_16bpp(VP9Context *s, 
> int16_t *coef, int n_coeffs,
> const int16_t (*nb)[2], const int16_t 
> *band_counts,
> const int16_t *qmul)
>  {
> -return decode_coeffs_b_generic(>c, coef, n_coeffs, 1, 0, s->bpp, cnt, 
> eob, p,
> +return decode_coeffs_b_generic(>c, coef, n_coeffs, 1, 0, s->s.h.bpp, 
> cnt, eob, p,
> nnz, scan, nb, band_counts, qmul);
>  }
>  
> @@ -2479,7 +2481,7 @@ static av_always_inline int check_intra_mode(VP9Context 
> *s, int mode, uint8_t **
>  int have_top = row > 0 || y > 0;
>  int have_left = col > s->tile_col_start || x > 0;
>  int have_right = x < w - 1;
> -int bpp = s->bpp;
> +  

Re: [FFmpeg-devel] [PATCH] avidec: fix leaking extradata

[Michael Niedermayer]

On Tue, Nov 29, 2016 at 12:33:17AM +0100, Andreas Cadhalpun wrote:
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/avidec.c | 2 ++
>  1 file changed, 2 insertions(+)

If previous extradata is freed it should probably print a warning or
error out

[...]
-- 
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 1/3] hevc: Allow parsing external extradata buffers

[Michael Niedermayer]

On Tue, Nov 29, 2016 at 03:01:28AM +0100, Michael Niedermayer wrote:
> On Tue, Nov 08, 2016 at 05:03:26PM -0500, Vittorio Giovara wrote:
> > ---
> > As mentioned in the discussion.
> > Please CC.
> > Vittorio
> > 
> >  libavcodec/hevc.c | 12 +---
> >  1 file changed, 5 insertions(+), 7 deletions(-)
> > 
> > diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
> > index 29e0d49..02fd606 100644
> > --- a/libavcodec/hevc.c
> > +++ b/libavcodec/hevc.c
> > @@ -2973,17 +2973,15 @@ static int verify_md5(HEVCContext *s, AVFrame 
> > *frame)
> >  return 0;
> >  }
> >  
> > -static int hevc_decode_extradata(HEVCContext *s)
> > +static int hevc_decode_extradata(HEVCContext *s, uint8_t *buf, int length)
> >  {
> >  AVCodecContext *avctx = s->avctx;
> >  GetByteContext gb;
> >  int ret, i;
> >  
> > -bytestream2_init(, avctx->extradata, avctx->extradata_size);
> > +bytestream2_init(, buf, length);
> >  
> > -if (avctx->extradata_size > 3 &&
> > -(avctx->extradata[0] || avctx->extradata[1] ||
> > - avctx->extradata[2] > 1)) {
> > +if (avctx->extradata_size > 3 && (buf[0] || buf[1] || buf[2] > 1)) {
>^
> 
> is that intended to stay extradata_size ?

and like always i forget the CC :(

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] [PATCH 2/3] hevc: Support extradata changes

[Michael Niedermayer]

On Tue, Nov 08, 2016 at 05:03:27PM -0500, Vittorio Giovara wrote:
> Signed-off-by: Vittorio Giovara 
> ---
> Applied review.
> Please CC.
> Vittorio
> 
>  libavcodec/hevc.c | 10 ++
>  libavformat/mov.c |  4 

please split this in 2 patches, the libavcodec one probably should
also have its version bumped as apps might want to depend on
a libavcodec with that feature

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

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


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

Re: [FFmpeg-devel] [PATCH 2/3] hevc: Support extradata changes

[Vittorio Giovara]

On Mon, Nov 28, 2016 at 9:06 PM, Michael Niedermayer
 wrote:
> On Tue, Nov 08, 2016 at 05:03:27PM -0500, Vittorio Giovara wrote:
>> Signed-off-by: Vittorio Giovara 
>> ---
>> Applied review.
>> Please CC.
>> Vittorio
>>
>>  libavcodec/hevc.c | 10 ++
>>  libavformat/mov.c |  4 
>
> please split this in 2 patches, the libavcodec one probably should
> also have its version bumped as apps might want to depend on
> a libavcodec with that feature

ok for the version bumb, why splitting it 2 patches though?
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/vaapi-vp9: add support for profile 2 (bpp > 8)

[Ronald S. Bultje]

Hi,

On Mon, Nov 28, 2016 at 7:26 PM, Mark Thompson  wrote:

> On 28/11/16 21:22, Mathieu Velten wrote:
> > ---
> >  libavcodec/vaapi_vp9.c |  1 +
> >  libavcodec/vp9.c   | 32 +---
> >  libavcodec/vp9.h   |  1 +
> >  3 files changed, 19 insertions(+), 15 deletions(-)
>
> Nice :)
>
> Tested on Kaby Lake, works for me (woo 180fps 4K 10-bit decode).
>
> This should probably be split into two patches, though - one for the
> generic vp9 hwaccel support, a second then enabling it for VAAPI.
>
> > diff --git a/libavcodec/vaapi_vp9.c b/libavcodec/vaapi_vp9.c
> > index b360dcb..9b3e81a 100644
> > --- a/libavcodec/vaapi_vp9.c
> > +++ b/libavcodec/vaapi_vp9.c
> > @@ -38,6 +38,7 @@ static void fill_picture_parameters(AVCodecContext
>  *avctx,
> >  pp->first_partition_size = h->h.compressed_header_size;
> >
> >  pp->profile = h->h.profile;
> > +pp->bit_depth = h->h.bpp;
> >
> >  pp->filter_level = h->h.filter.level;
> >  pp->sharpness_level = h->h.filter.sharpness;
> > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > index 0ec895a..ff526da 100644
> > --- a/libavcodec/vp9.c
> > +++ b/libavcodec/vp9.c
> > @@ -68,7 +68,7 @@ typedef struct VP9Context {
> >  ptrdiff_t y_stride, uv_stride;
> >
> >  uint8_t ss_h, ss_v;
> > -uint8_t last_bpp, bpp, bpp_index, bytesperpixel;
> > +uint8_t last_bpp, bpp_index, bytesperpixel;
> >  uint8_t last_keyframe;
> >  // sb_cols/rows, rows/cols and last_fmt are used for allocating all
> internal
> >  // arrays, and are thus per-thread. w/h and gf_fmt are synced
> between threads
> > @@ -258,7 +258,9 @@ static int update_size(AVCodecContext *ctx, int w,
> int h)
> >  if ((res = ff_set_dimensions(ctx, w, h)) < 0)
> >  return res;
> >
> > -if (s->pix_fmt == AV_PIX_FMT_YUV420P) {
> > +if (s->pix_fmt == AV_PIX_FMT_YUV420P ||
> > +s->pix_fmt == AV_PIX_FMT_YUV420P10 ||
> > +s->pix_fmt == AV_PIX_FMT_YUV420P12) {
> >  #if CONFIG_VP9_DXVA2_HWACCEL
> >  *fmtp++ = AV_PIX_FMT_DXVA2_VLD;
> >  #endif
>
> This is enabling it for DXVA2 and D3D11VA as well?  I'm guessing you
> probably didn't want to do that - I think it would be better with something
> more like  libavcodec/hevc.c;hb=HEAD#l350>.


I'll let you guys figure out the details for this, but generic vp9.[ch]
changes are OK with me.

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

Re: [FFmpeg-devel] [PATCH 1/3] hevc: Allow parsing external extradata buffers

[Vittorio Giovara]

On Mon, Nov 28, 2016 at 9:07 PM, Michael Niedermayer
 wrote:
> On Tue, Nov 29, 2016 at 03:01:28AM +0100, Michael Niedermayer wrote:
>> On Tue, Nov 08, 2016 at 05:03:26PM -0500, Vittorio Giovara wrote:
>> > ---
>> > As mentioned in the discussion.
>> > Please CC.
>> > Vittorio
>> >
>> >  libavcodec/hevc.c | 12 +---
>> >  1 file changed, 5 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
>> > index 29e0d49..02fd606 100644
>> > --- a/libavcodec/hevc.c
>> > +++ b/libavcodec/hevc.c
>> > @@ -2973,17 +2973,15 @@ static int verify_md5(HEVCContext *s, AVFrame 
>> > *frame)
>> >  return 0;
>> >  }
>> >
>> > -static int hevc_decode_extradata(HEVCContext *s)
>> > +static int hevc_decode_extradata(HEVCContext *s, uint8_t *buf, int length)
>> >  {
>> >  AVCodecContext *avctx = s->avctx;
>> >  GetByteContext gb;
>> >  int ret, i;
>> >
>> > -bytestream2_init(, avctx->extradata, avctx->extradata_size);
>> > +bytestream2_init(, buf, length);
>> >
>> > -if (avctx->extradata_size > 3 &&
>> > -(avctx->extradata[0] || avctx->extradata[1] ||
>> > - avctx->extradata[2] > 1)) {
>> > +if (avctx->extradata_size > 3 && (buf[0] || buf[1] || buf[2] > 1)) {
>>^
>>
>> is that intended to stay extradata_size ?

ops, no, good catch

applied
>> > +if (length > 3 && (buf[0] || buf[1] || buf[2] > 1)) {
locally, thanks
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Clément Bœsch]

On Mon, Nov 28, 2016 at 07:15:28PM +0100, Nicolas George wrote:
> Deadline: 2016-12-06 00:00 UTC.
> 
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.
> 

> In other words, if the technical problems that require dropping ffserver
> are resolved at the time it is about to be dropped, then it must not be
> and the patch is not applied.

Do we agree that the requirements are the following:

- ZERO internal API usage
- at least partial FATE coverage

?

What's the due date already? Next release?

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi/af_ebur128: update filter to use new ebur128 API

[Marton Balint]

On Mon, 28 Nov 2016, Kyle Swanson wrote:


On Thu, Nov 17, 2016 at 11:04 AM, Kyle Swanson  wrote:

Hi,

Here's a couple of patches which update the ebur128 filter to use the
recently added ebur128 API. This updated filter allows fine-tuned
control over which EBU R128 parameters are measured, and provides
modest speed increases over the previous ebur128 filter. Also
noteworthy: this removes the video output option of the ebur128
filter. This is extraneous for an ebur128 measurement filter IMHO, but
if we wanted to keep similar functionality in FFmpeg, we'd be better
served by a new video source filter where custom meters could be
created via exported frame metadata.

The first patch adds true peak functionality to the ebur128 API using
swresample (this was already discussed a little bit:
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202583.html)
The second patch is an update to the ebur128 filter.

Kyle


Does anyone have any problems with the first patch?



From 6912ed3a03cd19f46e96f1f4b9eb3aa69b7ce4df Mon Sep 17 00:00:00 2001
From: Kyle Swanson 
Date: Thu, 17 Nov 2016 10:32:45 -0600
Subject: [PATCH 1/2] lavfi/ebur128: add ebur128_check_true_peak()

Signed-off-by: Kyle Swanson 
---
 libavfilter/ebur128.c | 162 +-
 libavfilter/ebur128.h |  17 ++
 2 files changed, 177 insertions(+), 2 deletions(-)

diff --git a/libavfilter/ebur128.c b/libavfilter/ebur128.c
index a46692e..dc16647 100644
--- a/libavfilter/ebur128.c
+++ b/libavfilter/ebur128.c
@@ -50,6 +50,9 @@
 #include "libavutil/common.h"
 #include "libavutil/mem.h"
 #include "libavutil/thread.h"
+#include "libavutil/channel_layout.h"
+#include "libswresample/swresample.h"


Isn't this include needs an ifdef as well?


+#include "libavutil/opt.h"

 #define CHECK_ERROR(condition, errorcode, goto_point)  
\
 if ((condition)) { 
\
@@ -91,6 +94,16 @@ struct FFEBUR128StateInternal {
 size_t short_term_frame_counter;
 /** Maximum sample peak, one per channel */
 double *sample_peak;
+/** Maximum true peak, one per channel */
+double* true_peak;
+#if CONFIG_SWRESAMPLE
+SwrContext *resampler;
+size_t oversample_factor;
+float* resampler_buffer_input;
+size_t resampler_buffer_input_frames;
+float* resampler_buffer_output;
+size_t resampler_buffer_output_frames;
+#endif
 /** The maximum window duration in ms. */
 unsigned long window;
 /** Data pointer array for interleaved data */
@@ -214,12 +227,78 @@ static inline void init_histogram(void)
 }
 }

+#if CONFIG_SWRESAMPLE
+static int ebur128_init_resampler(FFEBUR128State* st) {
+int64_t channel_layout;
+int errcode;
+
+if (st->samplerate < 96000) {
+st->d->oversample_factor = 4;
+} else if (st->samplerate < 192000) {
+st->d->oversample_factor = 2;
+} else {
+st->d->oversample_factor = 1;
+st->d->resampler_buffer_input = NULL;
+st->d->resampler_buffer_output = NULL;
+st->d->resampler = NULL;
+}
+
+st->d->resampler_buffer_input_frames = st->d->samples_in_100ms * 4;
+st->d->resampler_buffer_input = 
av_malloc(st->d->resampler_buffer_input_frames *
+  st->channels *
+  sizeof(float));


av_malloc_array


+CHECK_ERROR(!st->d->resampler_buffer_input, 0, exit)
+
+st->d->resampler_buffer_output_frames =
+st->d->resampler_buffer_input_frames *
+st->d->oversample_factor;
+st->d->resampler_buffer_output = 
av_malloc(st->d->resampler_buffer_output_frames *
+   st->channels *
+   sizeof(float));


av_malloc_array


+CHECK_ERROR(!st->d->resampler_buffer_output, 0, free_input)
+
+st->d->resampler = swr_alloc();
+CHECK_ERROR(!st->d->resampler, 0, free_output)
+
+channel_layout = av_get_default_channel_layout(st->channels);
+
+av_opt_set_int(st->d->resampler, "in_channel_layout", channel_layout, 0);
+av_opt_set_int(st->d->resampler, "in_sample_rate", st->samplerate, 0);
+av_opt_set_sample_fmt(st->d->resampler, "in_sample_fmt", 
AV_SAMPLE_FMT_FLT, 0);
+av_opt_set_int(st->d->resampler, "out_channel_layout", channel_layout, 0);
+av_opt_set_int(st->d->resampler, "out_sample_rate", st->samplerate * 
st->d->oversample_factor, 0);
+av_opt_set_sample_fmt(st->d->resampler, "out_sample_fmt", 
AV_SAMPLE_FMT_FLT, 0);
+
+swr_init(st->d->resampler);
+return 0;
+
+free_output:
+av_free(st->d->resampler_buffer_output);
+st->d->resampler_buffer_output = NULL;


av_freep


+free_input:
+av_free(st->d->resampler_buffer_input);
+st->d->resampler_buffer_input = NULL;


av_freep


+exit:
+return AVERROR(ENOMEM);
+}
+
+static void ebur128_destroy_resampler(FFEBUR128State* st) 

[FFmpeg-devel] [PATCH] msrle: implement vertical offset in 4-bit RLE

[Daniel Verkamp]

The delta escape (2) is supposed to work the same in 4-bit RLE as in
8-bit RLE.  This is documented in the MSDN Bitmap Compression page:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd183383(v=vs.85).aspx

The unchecked modification of line is safe, since the loop condition
(line >= 0) will check it before any pixel data is written.

Fixes ticket #5153 (output now matches ImageMagick for the provided
sample).

Signed-off-by: Daniel Verkamp 
---
 libavcodec/msrledec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/msrledec.c b/libavcodec/msrledec.c
index 805802ae18..f0cbde67ff 100644
--- a/libavcodec/msrledec.c
+++ b/libavcodec/msrledec.c
@@ -63,7 +63,7 @@ static int msrle_decode_pal4(AVCodecContext *avctx, AVFrame 
*pic,
 stream_byte = bytestream2_get_byte(gb);
 pixel_ptr += stream_byte;
 stream_byte = bytestream2_get_byte(gb);
-avpriv_request_sample(avctx, "Unused stream byte %X", 
stream_byte);
+line -= stream_byte;
 } else {
 // copy pixels from encoded stream
 odd_pixel =  stream_byte & 1;
-- 
2.11.0.rc2

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Nicolas George]

Le septidi 7 frimaire, an CCXXV, James Almer a écrit :
> We don't care about testing it with FATE.

Yes, we do.

>   It appears to me that you still 
> don't
> get that ffserver is being *dropped*. It is, as discussed and announced, no
> longer part of the project.

Untrue. It is still there. There are threats of developers about to
remove it, but they are in the future.

The gist of it is that YOU want ffserver dropped, and you do so for
emotional reasons, not rational ones. Your emotional reasons are
inspired by rational ones, but only inspired, because you did not update
your conclusions when the status of the rational reasons changed.

The rational behaviour is:

IF ffserver prevents other aspects of the development, for examples
merges from the fork, THEN something must be done about it SOON, FOR
EXAMPLE dropping it, but possibly something else, provided it happens
soon.

IF ffserver is unmaintained but does not block aspects of the
development, then there is no rational reason to drop it in the short
term. Maybe later. On the other hand, there are reasons NOT to drop it:
some users use it.

IF ffserver is maintained, there is no reason to drop it whatsoever.

The way I read the discussions, the decision top drop was made when we
were in the first case. But you can notice that "but possibly something
else" just happened, and it happened soon enough.

Since Michael's patches ensure that ffserver no longer blocks merges,
there is no longer a reason to drop ffserver urgently. Therefore, the
decision to drop it tomorrow is void.

Regards,

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Matthieu Bouron]

On Mon, Nov 28, 2016 at 02:22:48AM +0100, Michael Niedermayer wrote:
> On Sun, Nov 27, 2016 at 05:31:39PM -0500, Ronald S. Bultje wrote:
> > Hi,
> > 
> > On Sun, Nov 27, 2016 at 1:46 PM, Michael Niedermayer  > > wrote:
> > 
> > > On Sun, Nov 27, 2016 at 07:30:24PM +0100, Clément Bœsch wrote:
> > > > On Sun, Nov 27, 2016 at 06:49:35PM +0100, Michael Niedermayer wrote:
> > > > > On Sun, Nov 27, 2016 at 04:57:36PM +0100, Clément Bœsch wrote:
> > > > > > On Sun, Nov 27, 2016 at 04:25:18PM +0100, Michael Niedermayer wrote:
> > > > > > [...]
> > > > > > > ffserver had 14 commits to it in about the last month
> > > > > >
> > > > > > That's also pretty close to the number of commits in the last years.
> > > > > >
> > > > > > Good will in the last weeks is not enough of a technical
> > > > > > merit/justification to prevent the removal of junk code scheduled 
> > > > > > for
> > > > > > deletion for a long time now.
> > > > >
> > > > > why do you call it junk ?
> > > >
> > > > because it's highly dependent on internal stuff, very limited, 
> > > > completely
> > > > untested, unmaintained for several years but still contains a ton of
> > > code.
> > > >
> > > > > and the sheduling for deletion was conditional on it not being fixed
> > > > > IIRC.
> > > > > Why the hurry to remove it while people work on fixing it ?
> > > > > its not blocking anything ATM AFAIK
> > > >
> > > > There is no hurry, but piling up a bunch patches to fix small things 
> > > > just
> > > > to use it as an argument to say "hey look now it's maintained" in order
> > > to
> > > > save it from being killed is really annoying. The people interested in 
> > > > it
> > > > had years to act.
> > > >
> > >
> > > > You can fix a ton of little things in it, but unless the fundamental
> > > > problems are addressed (ZERO internal API usage + at least partial FATE
> > > > coverage) it's pointless
> > >
> > > of course the goal is ZERO internal API usage + at least partial FATE
> > > coverage.
> > > Well in fact the lack of fate tests have been the primary reason
> > > why i didnt fix some of the API issues years ago. I felt uneasy
> > > changing it without regression tests
> > >
> > >
> > > > and will be seen as yet another case of "KEEP
> > > > EVERYTHING FOREVER" toxic mentality.
> > >
> > > The opposit is toxic too
> > 
> > 
> > I'm perfectly fine with keeping the code, just not in the ffmpeg tree.
> > Please move it to its own tree.
> > 
> 
> > Everybody wants it out. Please follow majority.
> 
> Some people want it out yes, how many and what the majority want i do
> not know.
> Some people also wanted all tools treated equally and moved out (again
> i dont know how many support that)
> 
> Spliting just ffserver out means more work for whoever maintains it
> setting up seperate infrastructure, seperate coverity, coverage, fate,
> ...
> theres a lot of work in all this, its long term continuous effort
> and this is time that wont be spent on FFmpeg.
> 
> I dont know if people want me and reynaldo to spend less time on
> FFmpeg, but time is a finite resource. If ffserver is maintained
> externally it would mean a noticable hit in maintaince man hours of
> FFmpeg. Now it might be that ffserver being pushed out would kill it.
> But really as dumb as i am, i dont belive theres a majority who wants
> to kill FFserver when there are people who actively work on it and
> care about it.

Just a thought, maybe ffserver could live in a separate branch for some time ?

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

Re: [FFmpeg-devel] [PATCH 2/2] lavfi: make filter_frame non-recursive.

[Nicolas George]

L'octidi 8 frimaire, an CCXXV, Andreas Cadhalpun a écrit :
> I'm not sure I understand. Just do the rebase once, commit the deprecation
> to git master and happily work on the other changes.

Except that kind of patch requires at least three rounds of review.
Wasted time.

> Not if the deprecation gets added, and thus this ifdeffery in avfilter.h
> is reduced to a temporary problem.

With the provisions I added in the current patch, the only drawbacks
that remains are matter of elegance and minor convenience. That means it
is no matter if it stays that way a long time. Therefore, no need to
revert (urgh, you really like wasting your time! reverting that big a
patch!) even if the deprecation only reaches the repository after the
release.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] msrle: implement vertical offset in 4-bit RLE

[Paul B Mahol]

On 11/28/16, Daniel Verkamp  wrote:
> The delta escape (2) is supposed to work the same in 4-bit RLE as in
> 8-bit RLE.  This is documented in the MSDN Bitmap Compression page:
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd183383(v=vs.85).aspx
>
> The unchecked modification of line is safe, since the loop condition
> (line >= 0) will check it before any pixel data is written.
>
> Fixes ticket #5153 (output now matches ImageMagick for the provided
> sample).
>
> Signed-off-by: Daniel Verkamp 
> ---
>  libavcodec/msrledec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/msrledec.c b/libavcodec/msrledec.c
> index 805802ae18..f0cbde67ff 100644
> --- a/libavcodec/msrledec.c
> +++ b/libavcodec/msrledec.c
> @@ -63,7 +63,7 @@ static int msrle_decode_pal4(AVCodecContext *avctx,
> AVFrame *pic,
>  stream_byte = bytestream2_get_byte(gb);
>  pixel_ptr += stream_byte;
>  stream_byte = bytestream2_get_byte(gb);
> -avpriv_request_sample(avctx, "Unused stream byte %X",
> stream_byte);
> +line -= stream_byte;
>  } else {
>  // copy pixels from encoded stream
>  odd_pixel =  stream_byte & 1;
> --
> 2.11.0.rc2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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