> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Ruiling Song
> Sent: Wednesday, November 28, 2018 2:09 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Song, Ruiling
> Subject: [FFmpeg-devel] [PATCH] lavfi/tonemap_opencl: reuse matrix
> calculation
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Monday, December 3, 2018 8:10 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V2] lavf: add transpose_opencl filter
>
> On 28/11/2018 02:27, Ruili
On Tue, 4 Dec 2018 03:21:30 +0100
Michael Niedermayer wrote:
> On Mon, Dec 03, 2018 at 09:24:47AM +0200, Lauri Kasanen wrote:
> > Also ping on "swscale/output: VSX-optimize
> > nbps yuv2plane1".
>
> This IIUC has not been tested on BE yet
>
> my ppc emulation setup is a bit broken and my ppc hw
On 12/3/18 4:48 PM, Andrey Semashev wrote:
> This commit ensures that all (potentially, long) filesystem activity is
> performed when the user calls av_write_trailer on the DASH libavformat
> context, not when freeing the context. Also, this defers media segment
> deletion until after the media tr
On Mon, Dec 03, 2018 at 09:24:47AM +0200, Lauri Kasanen wrote:
> On Fri, 30 Nov 2018 14:05:26 +0200
[...]
> Also ping on "swscale/output: VSX-optimize
> nbps yuv2plane1".
This IIUC has not been tested on BE yet
my ppc emulation setup is a bit broken and my ppc hw ive not tried using
since years a
On Mon, Dec 03, 2018 at 09:24:47AM +0200, Lauri Kasanen wrote:
> On Fri, 30 Nov 2018 14:05:26 +0200
> Lauri Kasanen wrote:
>
> > On Fri, 30 Nov 2018 12:30:58 +0300
> > Michael Kostylev wrote:
> > >
> > > >> Passes fate on LE (with "lavc/jrevdct: Avoid an aliasing violation"
> > > >> applied).
On Mon, Dec 03, 2018 at 01:17:42AM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Both aix and sunos define NUMBER_OF_FRAMES in a system header (as
> _NUMBER_OF_FRAMES), attached patch fixes a warning when running fate.
>
> Please comment, Carl Eugen
> api-flac-test.c | 10 +-
> 1 file chan
Hi Mark,
Is there any issue that I need to fix for this patch please?
Regards,
SUN, Jing
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Sun,
Jing A
Sent: Friday, November 23, 2018 5:37 PM
To: FFmpeg development discussions and patches
Subj
On Mon, Dec 03, 2018 at 10:19:55AM -0900, Lou Logan wrote:
> No current downstream appears to be using 3.0:
> https://trac.ffmpeg.org/wiki/Downstreams
>
> Signed-off-by: Lou Logan
> ---
> src/download| 39 ---
> src/olddownload | 37 +++
Hi
On Sun, Dec 02, 2018 at 09:44:38PM +0100, Martin Vignali wrote:
> internal.h | 12
> utils.c| 19 +++
> 2 files changed, 31 insertions(+)
> 46843c218e2c53b93a283656dc3e89f93775a286
> 0001-avcodec-utils-add-ff_int_from_list_or_default-func.patch
> From 094
Hi!
Attached patch is supposed to fix a memleak from clusterfuzz, untested...
Please review, Carl Eugen
From f94d6415885293351201e74a3760aae7f206515a Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 4 Dec 2018 00:32:25 +0100
Subject: [PATCH] lavc/ivi: Free an allocation on error.
Fixe
On 12/3/18, Michael Niedermayer wrote:
> On Mon, Dec 03, 2018 at 04:33:45PM +, Paul B Mahol wrote:
>> ffmpeg | branch: master | Paul B Mahol | Sun Dec 2
>> 17:49:03 2018 +0100| [3d8d8c7199717a0a31fbe01f8931d96fe8408bd6] |
>> committer: Paul B Mahol
>>
>> avcodec/r210: use correct pixel forma
On Mon, 3 Dec 2018, at 23:14, Marton Balint wrote:
> On Mon, 3 Dec 2018, Jean-Baptiste Kempf wrote:
> > On Mon, 3 Dec 2018, at 19:48, Paul B Mahol wrote:
> > Libraries to access hardware, notably those that are talking directly with
> > something that was shipped with the drivers, are usually cons
Hi,
This patch was part of GSoC Color Constancy filter. It introduces an
improved color constancy filter(weighted_greyedge) based on the already
pushed greyedge. I'm sending it again after updating it against latest
version of master.
V3 changes:
- fixed inconsistency in filters.texi
Reg
On Tue, Dec 4, 2018, 1:14 AM Marton Balint
>
> On Mon, 3 Dec 2018, Jean-Baptiste Kempf wrote:
>
> > On Mon, 3 Dec 2018, at 19:48, Paul B Mahol wrote:
> >> > On the general idea of this - agreed.
> >> >
> >> > Separately I think we should at least bring up a possible rethink of
> >> > our policy ab
On Mon, 3 Dec 2018, Jean-Baptiste Kempf wrote:
On Mon, 3 Dec 2018, at 19:48, Paul B Mahol wrote:
> On the general idea of this - agreed.
>
> Separately I think we should at least bring up a possible rethink of
> our policy about non-open source nonfree components.
>
> If it's:
> - Not part of
> Again: What message would this send to future license violators?
A bad one.
I would remove this.
--
Jean-Baptiste Kempf - President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-deve
On Mon, 3 Dec 2018, at 19:48, Paul B Mahol wrote:
> > On the general idea of this - agreed.
> >
> > Separately I think we should at least bring up a possible rethink of
> > our policy about non-open source nonfree components.
> >
> > If it's:
> > - Not part of the OS
> > or
> > - Not open source
>
On Mon, Dec 03, 2018 at 04:33:45PM +, Paul B Mahol wrote:
> ffmpeg | branch: master | Paul B Mahol | Sun Dec 2
> 17:49:03 2018 +0100| [3d8d8c7199717a0a31fbe01f8931d96fe8408bd6] | committer:
> Paul B Mahol
>
> avcodec/r210: use correct pixel format
>
> > http://git.videolan.org/gitweb.cgi/
On Mon, 3 Dec 2018, at 17:05, Carl Eugen Hoyos wrote:
> It appears to me that NewTek abused our willingness to add an optional
> external nonfree library, I don't see many better options. See Ticket
> #7589 and a blog post by a NewTek engineer confirming the issue.
+1, please apply.
Newtek is a b
On 11/28/18 11:24 PM, Moritz Barsnick wrote:
On Mon, Oct 01, 2018 at 18:09:46 +0200, Mina wrote:
Nit:
Thanks for your feedback and sorry for late response.
+be chosen in the range [1,20] and default value is 1.
[...]
Not sure what is here.
+chosen in the range [0.2,1024.0] and de
On Mon, 3 Dec 2018, Carl Eugen Hoyos wrote:
Hi!
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.
You should think about our users who
On Tue, Dec 4, 2018, 12:07 AM Carl Eugen Hoyos 2018-12-03 22:00 GMT+01:00, Ali KIZIL :
>
> > Newtek representative says, they will remove the binary from SDK right
> away
>
> Could you please read the sentence you sent?
> Particularly the words "says" and "will".
>
> They did not remove the binari
On Mon, Dec 3, 2018 at 10:29 PM Martin Vignali wrote:
>
> This patch looks wrong to me.
>
> It's seems like removing features for personal opinion.
>
> Ticket 7589, mention an incorrect build redistribution.
>
> So, right way to fix this ticket, will be (for people interesting in this
> kind of th
2018-12-03 22:00 GMT+01:00, Ali KIZIL :
> Newtek representative says, they will remove the binary from SDK right away
Could you please read the sentence you sent?
Particularly the words "says" and "will".
They did not remove the binariy when informed about the
license violations!
(At least, ther
On 12/3/18, Carl Eugen Hoyos wrote:
> 2018-12-03 21:28 GMT+01:00, Martin Vignali :
>> Ticket 7589, mention an incorrect build redistribution.
>>
>> So, right way to fix this ticket, will be (for people interesting in this
>> kind of thing)
>> to indicate, what need to be done, in order to have a l
Ali KIZIL (2018-12-04):
> Personally, I do not believe they break the license on purpose. If so, they
They are a commercial entity, they have a legal department. "Not on
purpose" is not an excuse for them.
> wouldn't announce it. They would fo as some others do, by trying hide. So
> personally, I
On Mon, Dec 3, 2018, 11:41 PM Carl Eugen Hoyos 2018-12-03 21:28 GMT+01:00, Martin Vignali :
> >> > >>
> >> > >> It appears to me that NewTek abused our willingness to add an
> >> > >> optional
> >> > >> external nonfree library, I don't see many better options. See
> Ticket
> >> > >> #7589 and a b
Jan Ekström (2018-12-03):
> Separately I think we should at least bring up a possible rethink of
> our policy about non-open source nonfree components.
>
> If it's:
> - Not part of the OS
> or
> - Not open source
>
> ...maybe we should not include such a component upstream?
I agree.
Maybe we ca
2018-12-03 21:28 GMT+01:00, Martin Vignali :
>> > >>
>> > >> It appears to me that NewTek abused our willingness to add an
>> > >> optional
>> > >> external nonfree library, I don't see many better options. See Ticket
>> > >> #7589 and a blog post by a NewTek engineer confirming the issue.
>> > >>
> > >>
> > >> It appears to me that NewTek abused our willingness to add an optional
> > >> external nonfree library, I don't see many better options. See Ticket
> > >> #7589 and a blog post by a NewTek engineer confirming the issue.
> > >>
> > >> Patch untested.
> > >>
> > >> Please comment, Carl
No current downstream appears to be using 3.0:
https://trac.ffmpeg.org/wiki/Downstreams
Signed-off-by: Lou Logan
---
src/download| 39 ---
src/olddownload | 37 +
2 files changed, 37 insertions(+), 39 deletions(-)
diff
On Mon, Dec 3, 2018 at 8:48 PM Paul B Mahol wrote:
>
> On 12/3/18, Jan Ekström wrote:
> > On Mon, Dec 3, 2018 at 6:06 PM Carl Eugen Hoyos wrote:
> >>
> >> Hi!
> >>
> >> It appears to me that NewTek abused our willingness to add an optional
> >> external nonfree library, I don't see many better o
On Mon, Dec 3, 2018, 9:48 PM Paul B Mahol On 12/3/18, Jan Ekström wrote:
> > On Mon, Dec 3, 2018 at 6:06 PM Carl Eugen Hoyos
> wrote:
> >>
> >> Hi!
> >>
> >> It appears to me that NewTek abused our willingness to add an optional
> >> external nonfree library, I don't see many better options. See
On 12/3/18, Jan Ekström wrote:
> On Mon, Dec 3, 2018 at 6:06 PM Carl Eugen Hoyos wrote:
>>
>> Hi!
>>
>> It appears to me that NewTek abused our willingness to add an optional
>> external nonfree library, I don't see many better options. See Ticket
>> #7589 and a blog post by a NewTek engineer con
On Mon, Dec 3, 2018 at 6:06 PM Carl Eugen Hoyos wrote:
>
> Hi!
>
> It appears to me that NewTek abused our willingness to add an optional
> external nonfree library, I don't see many better options. See Ticket
> #7589 and a blog post by a NewTek engineer confirming the issue.
>
> Patch untested.
>
Hello All,
I have created separate ffserver code which can be used for rtsp server only
with no other dependency,
Have a look into it:
Https://github.com/harshil1991/ffserver.git
Now on I will try to fix bugs and other reliability issues.
Thanks,
Harshil
_
2018-12-03 19:12 GMT+01:00, Timo Rothenpieler :
> I contacted NewTek about this, here's the pretty much immediate response
> I got:
>
> On 03.12.2018 18:55, Andrew Cross wrote:
>> Yikes, I am pretty surprised by this to be honest I think that our intent
>> might have been entirely misconstrued.
(
I contacted NewTek about this, here's the pretty much immediate response
I got:
On 03.12.2018 18:55, Andrew Cross wrote:
Yikes, I am pretty surprised by this to be honest I think that our intent might
have been entirely misconstrued.
We are in no way trying to abuse anything anyone did and i
This will enable us to change e.g. the parameter sets of H.2645 in ways
that would change the parsing process of future units. An example of
this is the h264_redundant_pps bsf.
The actual implementation of the underlying codec-dependent
make_writable functions is not contained in this commit.
Sign
Dennis Mungai (2018-12-03):
> In this case , Carl's decision to strip their code from FFmpeg is valid.
> This is a clear violation of the license terms.
Indeed.
And please stop top-posting. If you do not know what it means, look it
up.
Regards,
--
Nicolas George
signature.asc
Description:
In this case , Carl's decision to strip their code from FFmpeg is valid.
This is a clear violation of the license terms.
On Mon, Dec 3, 2018, 19:38 Nicolas George Kyle Schwarz (2018-12-03):
> > https://www.newtek.com/blog/introducing-ndi-3-5/
> >
> > > ... and we even include FFMPEG for Windows w
Kyle Schwarz (2018-12-03):
> https://www.newtek.com/blog/introducing-ndi-3-5/
>
> > ... and we even include FFMPEG for Windows with NDI support for your
> > convenience, eliminating the hassle of working out how to compile it
> > yourself.
That is not how it is supposed to work. If they want to
Carl,
If it is indeed an abuse of the license terms, as you've purported, it
would be wise to get their input on this, as Gyan Doshi has elaborated
above. They are contributors to this project, and it falls to reason that
the burden of addressing this falls on them.
Moving forward with such drast
On Mon, Dec 3, 2018 at 11:16 AM Gyan Doshi wrote:
> On 03-12-2018 09:35 PM, Carl Eugen Hoyos wrote:
> > It appears to me that NewTek abused our willingness to add an optional
> > external nonfree library, I don't see many better options. See Ticket
> > #7589 and a blog post by a NewTek engineer co
2018-12-03 17:13 GMT+01:00, Dennis Mungai :
> Has Newtek NDI been given a chance to rectify this from their end?
Why do you believe that this would be a useful way to go?
> This is clearly a license violation, but taking drastic steps such
> as stripping support for their protocols is a knee jer
On 03-12-2018 09:49 PM, Carl Eugen Hoyos wrote:
2018-12-03 17:16 GMT+01:00, Gyan Doshi :
What's the link to the blog post?
Also, is anyone from Newtek on the ML - if not, is there someone we
can invite for input?
What kind of input would seem useful to you in this case?
Insight on wha
Hello there,
Has Newtek NDI been given a chance to rectify this from their end? This is
clearly a license violation, but taking drastic steps such as stripping
support for their protocols is a knee jerk reaction.
Let them respond before merging this PR.
Regards,
Dennis.
On Mon, Dec 3, 2018, 19
2018-12-03 17:16 GMT+01:00, Gyan Doshi :
> On 03-12-2018 09:35 PM, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> It appears to me that NewTek abused our willingness to add an optional
>> external nonfree library, I don't see many better options. See Ticket
>> #7589 and a blog post by a NewTek engineer confi
On 03-12-2018 09:35 PM, Carl Eugen Hoyos wrote:
Hi!
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.
What's the link to the blog post?
A
Hi!
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.
Patch untested.
Please comment, Carl Eugen
From 48ecad006fcd9db4558d1d23482e37006805bf
On 12/3/18 3:46 PM, Nicolas George wrote:
Andrey Semashev (2018-12-03):
This commit adds support for IO synchronization API to the file backend.
---
libavformat/file.c | 10 ++
libavformat/os_support.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/libavformat/file.c
On 12/3/18 3:43 PM, Nicolas George wrote:
Andrey Semashev (2018-12-03):
This commit adds a new set of functions to avio and url subsystems, which
allow users to invoke IO buffer synchronization with the underlying media.
The most obvious target for this extension if the filesystem streams. Invok
Andrey Semashev (2018-12-03):
> This commit adds support for IO synchronization API to the file backend.
> ---
> libavformat/file.c | 10 ++
> libavformat/os_support.h | 2 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/libavformat/file.c b/libavformat/file.c
> index 1d321
Andrey Semashev (2018-12-03):
> This commit adds a new set of functions to avio and url subsystems, which
> allow users to invoke IO buffer synchronization with the underlying media.
> The most obvious target for this extension if the filesystem streams. Invoking
> IO synchronization allows user ap
This commit adds a new set of functions to avio and url subsystems, which
allow users to invoke IO buffer synchronization with the underlying media.
The most obvious target for this extension if the filesystem streams. Invoking
IO synchronization allows user applications to ensure that all written
This commit adds support for IO synchronization API to the file backend.
---
libavformat/file.c | 10 ++
libavformat/os_support.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/libavformat/file.c b/libavformat/file.c
index 1d321c4205..9765fd76c7 100644
--- a/libavformat/fil
This commit ensures that all (potentially, long) filesystem activity is
performed when the user calls av_write_trailer on the DASH libavformat
context, not when freeing the context. Also, this defers media segment
deletion until after the media trailers are written.
---
libavformat/dashenc.c | 85
On 12/3/18 8:45 AM, Jeyapal, Karthick wrote:
On 11/30/18 11:42 AM, Jeyapal, Karthick wrote:
On 11/29/18 11:58 PM, Andrey Semashev wrote:
This commit ensures that all (potentially, long) filesystem activity is
performed when the user calls av_write_trailer on the DASH libavformat
context, not
ping? any more comments ?
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Zachary Zhou
> Sent: Thursday, November 29, 2018 2:14 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Zachary Zhou ; Zhou, Zachary
>
> Subject: [FFmpeg-devel] [PATCH v4] liba
On 12/2/18, James Almer wrote:
> On 12/2/2018 4:07 PM, Paul B Mahol wrote:
>> On 12/2/18, James Almer wrote:
>>> On 12/2/2018 3:53 PM, Paul B Mahol wrote:
On 12/2/18, James Almer wrote:
> On 12/2/2018 2:51 PM, Paul B Mahol wrote:
>> Fixes #4517.
>>
>> Signed-off-by: Paul B M
On 12/3/18, Michael Niedermayer wrote:
> On Sun, Dec 02, 2018 at 06:06:56PM +0100, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol
>> ---
>> libavcodec/r210dec.c | 38 ++-
>> libavcodec/r210enc.c | 26 +++-
>> tests/ref/vsy
pict_type may be uninitialized, and assert on a value coming from an external
library is not proper.
Return invalid data error in function ff_qsv_encode to avoid using uninitialized
value.
Signed-off-by: Linjie Fu
---
libavcodec/qsvenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Almer
> Sent: Friday, November 30, 2018 23:53
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: assert
> uninitialized pict_type
>
> On 11/30/2018
64 matches
Mail list logo
