On 04-05-2019 06:17 AM, Stephen Hutchinson wrote:
On 5/3/2019 12:45 PM, Gyan wrote:
On 3/30/2019 7:39 PM, Stephen Hutchinson wrote:
I've uploaded the amended 1st patch and added a 6th to deal with
the issues I encountered when testing the 'build FFmpeg with MSVC'
route. Since git send-email
> On 2019-05-02 08:55 +, avih wrote:
> > > It seems awk is unconditionally required already. However I wanted to
> > > say that it's a very nice dep to have
> >
> > While it's possibly nicer than other deps to have, it's still better to use
> > it IMHO only when it adds some value, like simpler
> 在 2019年5月4日，上午9:32，Peter Ross 写道：
>
>> On Fri, May 03, 2019 at 10:43:36AM -0700, Baptiste Coudurier wrote:
>>
>>> On May 3, 2019, at 1:15 AM, Paul B Mahol wrote:
>>>
>>> On 4/28/19, Marton Balint wrote:
Hi All,
There has been discussion on the mailing list several times ab
On 5/2/2019 7:42 AM, Moritz Barsnick wrote:
> On Wed, May 01, 2019 at 12:03:41 -0300, James Almer wrote:
>>> +if (pkt->pts != AV_NOPTS_VALUE) {
>>> +int64_t pts = av_rescale_q(pkt->pts, bsf->time_base_in,
>>> AV_TIME_BASE_Q) / ctx->speed;
>>> +int64_t now = av_gettime_relative(
On Sat, May 04, 2019 at 01:38:38AM +0200, Michael Niedermayer wrote:
> Fixes: Timeout (11sec -> 5sec)
> Fixes:
> 14473/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JV_fuzzer-5761630857592832
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/f
On Fri, May 03, 2019 at 10:43:36AM -0700, Baptiste Coudurier wrote:
>
> > On May 3, 2019, at 1:15 AM, Paul B Mahol wrote:
> >
> > On 4/28/19, Marton Balint wrote:
> >> Hi All,
> >>
> >> There has been discussion on the mailing list several times about the
> >> inclusion of support for closed s
On 5/3/2019 12:45 PM, Gyan wrote:
On 3/30/2019 7:39 PM, Stephen Hutchinson wrote:
I've uploaded the amended 1st patch and added a 6th to deal with the
issues I encountered when testing the 'build FFmpeg with MSVC'
route. Since git send-email (or Gmail) screwed up the threading
when I sent the
Fixes: Assertion failure
Fixes:
14484/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGMYUV_fuzzer-5150016408125440
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/pnm_parser.c | 1 +
1 fil
Fixes: Timeout (11sec -> 5sec)
Fixes:
14473/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JV_fuzzer-5761630857592832
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/jvdec.c | 10 --
Hi Carl Eugen!
On 2019-05-01 22:57 +0200, Carl Eugen Hoyos wrote:
> 2019-04-28 3:18 GMT+02:00, Alexander Strasser :
>
> > What do you think about using awk instead of shell?
>
> Do we only use awk for --enable-random and the dependency
> files so far? Does configure also work without awk now and
>
Hi Avih!
On 2019-05-02 08:55 +, avih wrote:
> > It seems awk is unconditionally required already. However I wanted to
> > say that it's a very nice dep to have
>
> While it's possibly nicer than other deps to have, it's still better to use
> it IMHO only when it adds some value, like simpler c
New VdpYCbCr Formats VDP_YCBCR_FORMAT_Y_U_V_444 and,
VDP_YCBCR_FORMAT_Y_UV_444 have been added in VDPAU with libvdpau-1.2
to be used in get/putbits for YUV 4:4:4 surfaces. Earlier mapping of
AV_PIX_FMT_YUV444P to VDP_YCBCR_FORMAT_YV12 is not valid.
Hence this Change maps AV_PIX_FMT_YUV444P to VDP_
Sorry for the delayed reply.
Yes #if is needed in this patch too, to avoid build break incase system is
having
vdpau.h earlier to libvdpau-1.2
thanks for pointing it out.
Thanks,
ManojGupta.
> -Original Message-
> From: ffmpeg-devel On Behalf Of James
> Almer
> Sent: Friday, April 26
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch
Signed-off-by: Paul B Mahol
---
libavfilter/f_interleave.c | 125 +++--
1 file changed, 51 insertions(+), 74 deletions(-)
diff --git a/libavfilter/f_interleave.c b/libavfilter/f_interleave.c
index d8a73b52e5..0966c4a0d8 100644
--- a/libavfilter/f_interleave.c
+++
On Fri, May 03, 2019 at 11:08:35AM +0200, Carl Eugen Hoyos wrote:
> Am Fr., 3. Mai 2019 um 07:27 Uhr schrieb Jeyapal, Karthick
> :
>
> > In this case NDI took prompt action and removed the said binaries from
> > their website immediately.
>
> This is not true, please stop spreading this wrong cl
> On May 3, 2019, at 1:15 AM, Paul B Mahol wrote:
>
> On 4/28/19, Marton Balint wrote:
>> Hi All,
>>
>> There has been discussion on the mailing list several times about the
>> inclusion of support for closed source components (codecs, formats,
>> filters, etc) in the main ffmpeg codebase.
>>
On Fri, 3 May 2019, at 07:27, Jeyapal, Karthick wrote:
> Open source violation by NDI is a serious issue that needs to be
> addressed. But removing the libndi plugin from the ffmpeg repository
> will not address the issue of violation. A willful violator can still
You are confusing 2 things:
-
On 02-05-2019 09:58 PM, Stephen Hutchinson wrote:
On 3/30/2019 7:39 PM, Stephen Hutchinson wrote:
I've uploaded the amended 1st patch and added a 6th to deal with the
issues I encountered when testing the 'build FFmpeg with MSVC'
route. Since git send-email (or Gmail) screwed up the threadin
On 02-05-2019 10:00 PM, Stephen Hutchinson wrote:
On 3/31/2019 8:12 PM, Stephen Hutchinson wrote:
---
The text has been updated to reflect that 32-bit builds of FFmpeg
in general don't default to AviSynth+GCC compatibility.
doc/general.texi | 15 +++
1 file changed, 15 insertion
On Fri, May 03, 2019 at 06:11:00AM +, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/webm_chunk.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/webm_chunk.c b/libavformat/webm_chunk.
This allows handling more than 26.5h of mpeg* input
Fixes: Ticket 7876
Signed-off-by: Michael Niedermayer
---
fftools/ffmpeg.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 01f04103cf..b58336679d 100644
--- a/fftools/
Hello Panagiotis,
> On May 3, 2019, at 4:50 AM, Panagiotis Malakoudis wrote:
>
> As I mentioned in ticket http://trac.ffmpeg.org/ticket/7876 this is
> not my code, I just adapted it for current git. It is also very old
> code (back from 2012), probably it fitted OK back then. This code
> fixes t
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 11 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_xmedian.c | 325 +++
4 files changed, 338 insertions(+)
create mode 100644 libavfilter/vf_xmedian.c
diff --gi
On Fri, 3 May 2019 at 15:24, Kieran Kunhya wrote:
> >
> >
> > Kieran,
> >
> > Can you point to evidence on the same? An active legal threat to "a
> > developer writing an open source implementation of NDI"?
> >
> > With that in place, it wouldn't be ignored as a material fact, would it?
> >
>
> h
>
>
> Kieran,
>
> Can you point to evidence on the same? An active legal threat to "a
> developer writing an open source implementation of NDI"?
>
> With that in place, it wouldn't be ignored as a material fact, would it?
>
https://trac.ffmpeg.org/ticket/7589
Discussed in there. A few people in t
Gives noticeable speed boost.
Signed-off-by: Paul B Mahol
---
libavcodec/wavpack.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index d0242809fe..9798662045 100644
--- a/libavcodec/wavpack.c
+++ b/libavcodec/wavpack.c
@@ -21,6 +21,7 @@
#inclu
Am Fr., 3. Mai 2019 um 07:27 Uhr schrieb Jeyapal, Karthick
:
> In this case NDI took prompt action and removed the said binaries from their
> website immediately.
This is not true, please stop spreading this wrong claim.
> A similar violation was done by Amazon some time back
> (https://trac.f
On 5/3/19, Gyan wrote:
>
>
> On 29-04-2019 01:32 AM, Marton Balint wrote:
>> So here is a call to the voting committee [1] to decide on the
>> following two questions:
>>
>> 1) Should libNDI support be removed from the ffmpeg codebase?
>
> No.
>
Yes.
> Gyan
>
Στις Παρ, 3 Μαΐ 2019 στις 11:36 π.μ., ο/η Michael Niedermayer
έγραψε:
>
> this will break timestamp handling
> not sure what you are trying to do exactly but the way its done is wrong.
> There is alot of code that depends on the timestamps from the demuxer
> not being mangled like this.
>
> also i
On Thu, May 02, 2019 at 10:09:23PM +0300, Panagiotis Malakoudis wrote:
> OK, here it is again, attached.
>
>
> Στις Πέμ, 2 Μαΐ 2019 στις 9:56 μ.μ., ο/η Carl Eugen Hoyos
> έγραψε:
> >
> > Am Do., 2. Mai 2019 um 20:52 Uhr schrieb Panagiotis Malakoudis
> > :
> > >
> > > > On Thu, May 02, 2019 at 08
On 29-04-2019 01:32 AM, Marton Balint wrote:
So here is a call to the voting committee [1] to decide on the
following two questions:
1) Should libNDI support be removed from the ffmpeg codebase?
No.
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel
On Fri, May 3, 2019, 10:22 Kieran Kunhya wrote:
> On Fri, 3 May 2019, 06:27 Jeyapal, Karthick, wrote:
>
> >
> > On Sun, Apr 28, 2019 at 4:02 PM Marton Balint wrote:
> >
> > > (In this case, NDI plugin is already open source).
>
>
> This is untrue.
>
> Furthermore, I am amazed you are all ignori
On 4/28/19, Marton Balint wrote:
> Hi All,
>
> There has been discussion on the mailing list several times about the
> inclusion of support for closed source components (codecs, formats,
> filters, etc) in the main ffmpeg codebase.
>
> Also the removal of libNDI happened without general consensus,
Cuvid supports clips with a limit on maximum number of macroblocks.
This check was missing after cuvidGetDecoderCaps API call allowing
unsupported clips to proceed.
Added the missing check, same as the one in hwaccel nvdec implementation.
---
libavcodec/cuviddec.c | 6 ++
1 file changed, 6 ins
On Fri, 3 May 2019, 06:27 Jeyapal, Karthick, wrote:
>
> On Sun, Apr 28, 2019 at 4:02 PM Marton Balint wrote:
>
> > (In this case, NDI plugin is already open source).
This is untrue.
Furthermore, I am amazed you are all ignoring the fact this is an Open
Source hostile company, actively sending
36 matches
Mail list logo
