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
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
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
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 =
> 在 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
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
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
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
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
>
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.c
> index 2c99753b5b..561ec152e7 100644
> --- a/libavformat/webm_chunk.c
> +++
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
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
>
Στις Παρ, 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
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
>
Michael Niedermayer:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/webm_chunk.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/webm_chunk.c b/libavformat/webm_chunk.c
> index 561ec152e7..e2fbd8be1d 100644
> --- a/libavformat/webm_chunk.c
>
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
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
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
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 @@
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
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
>
>
> 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
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
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
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
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
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
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
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?
> >
>
>
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
---
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, 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 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, 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
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
36 matches
Mail list logo
