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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

> -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 >

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

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

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

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,

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

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

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

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

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

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

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

- 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

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

> 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

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

> 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

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

> 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).

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

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

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

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

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

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 > >>

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

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 >>

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

> 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 ___

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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.

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

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

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

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

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

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

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

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.

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

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

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

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.

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

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

--- 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 ---

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

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

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

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

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

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 >

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

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

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

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

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

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 +

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

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

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

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

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

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

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

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 >>>

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

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,

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

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

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

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. > > #

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

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

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

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

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

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] [DECISION] Revoke the decision of dropping ffserver

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

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

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,

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

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 ---

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

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 +++

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 +++

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

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

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

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

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

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

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

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 +++

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

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 @@

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

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 +++

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

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 > >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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,

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

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

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

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