sön 2019-02-17 klockan 16:28 +0100 skrev Marton Balint:
>
> On Sun, 17 Feb 2019, Marton Balint wrote:
>
> >
> >
> > On Sun, 17 Feb 2019, Carl Eugen Hoyos wrote:
> >
> > > > > > 2019-02-17 1:40 GMT+01:00, Marton Balint :
> > > >
> > > > On Sat, 16 Feb 2019, Carl Eugen Hoyos wrote:
> > > > >
>
> -Original Message-
> From: Li, Zhong
> Sent: Monday, February 18, 2019 13:48
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: RE: [FFmpeg-devel] [PATCH, RFC] lavf/deinterlace_qsv: set TFF or
> BFF together with progressive
>
> > From: ffmpe
Hello,
I know it's off-topic, but I hope someone could help me.
I use the xupnpd2-mediaserver (https://github.com/clark15b/xupnpd2) on
my router to display some hls-streams on the TV. I try to receive this
stream: https://www.mall.tv/planespotting.
I solved the missing https-support in xupnpd2
On Sun, Feb 17, 2019 at 08:55:38PM +0100, Marton Balint wrote:
> This reworks the code to be more strict about accepting stream specifiers.
> From
> now on we strictly enforce the syntax in the documentation up until the
> decisive part of the stream specifier. Therefore matching stream specifiers
On Sat, Feb 16, 2019 at 09:40:06PM +0100, Thomas Jammet wrote:
> Hi everybody,
>
> You will find in attachment a patch proposal to add an optional RTMFP
> support in ffmpeg using librtmfp.
>
> For more information : https://github.com/MonaSolutions/librtmfp
>
> *--*
>
> *Thomas JAMMET*
> conf
On Sun, 17 Feb 2019 06:24:05 +
Soft Works wrote:
> Hi,
>
> in the above context I'm wondering about whether it is mandatory to
> treat the "cuda_sdk" option as a non-free option?
>
> In case of libnpp it's obviously required to statically link to
> proprietary Nvidia code code for which the
On Sun, 17 Feb 2019, Carl Eugen Hoyos wrote:
2019-02-17 20:55 GMT+01:00, Marton Balint :
This reworks the code to be more strict about accepting
stream specifiers. From now on we strictly enforce the
syntax in the documentation up until the decisive part of
the stream specifier. Therefore mat
> > in the above context I'm wondering about whether it is mandatory to
> > treat the "cuda_sdk" option as a non-free option?
> >
> > In case of libnpp it's obviously required to statically link to
> > proprietary Nvidia code code for which there's not public source code
> > available.
> >
> > But
On Tue, Nov 13, 2018 at 11:43:31PM +, Mark Thompson wrote:
> Fixes #7519.
> ---
> doc/ffmpeg.texi | 13
> fftools/ffmpeg.c | 10 ++
> fftools/ffmpeg.h | 4
> fftools/ffmpeg_opt.c | 47
> 4 files changed, 74 in
This reworks the code to be more strict about accepting stream specifiers. From
now on we strictly enforce the syntax in the documentation up until the
decisive part of the stream specifier. Therefore matching stream specifiers
always need to be correct, non matching specifiers only need to be corr
On Mon, Feb 18, 2019 at 01:56:22AM +, Morris Stock wrote:
> On 2/17/19 2:06 AM, Michael Niedermayer wrote:
> > On Fri, Feb 15, 2019 at 01:48:04AM +, Morris Stock wrote:
> >> mpeg.c | 56
> >> 1 file changed, 28 insertions(+), 28 de
On Sun, Feb 17, 2019, at 4:56 PM, Morris Stock wrote:
>
> Ah, yes, but seems no one else use short name, see new attachment, thanks.
You can use whatever name or alias you want. We only want consistency, so
future patches from the same address should ideally have the same author name.
___
> -Original Message-
> From: Song, Ruiling
> Sent: Wednesday, February 13, 2019 9:29 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Song, Ruiling
> Subject: [PATCH] MAINTAINERS: add myself for tonemap_opencl
>
> Signed-off-by: Ruiling Song
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertio
On Sun, Feb 17, 2019, at 10:58 AM, Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> doc/formats.texi | 24 ++--
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Fixes: runtime error: signed integer overflow: 2147483598 + 128 cannot be
represented in type 'int'
Fixes:
12926/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5705100733972480
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
On Mon, 18 Feb 2019 21:44:33 +
Soft Works wrote:
>
> Hi Phil,
>
> thanks for replying. I was just about to start migrating the filters
> to dynamic loading (nv-codec-headers)..
>
> From your explanations, the situation doesn't seem to be as bad as it
> could be. When the CPU code of the fi
VP9 decoding speed improved about 109.3%(from 32fps to 67fps, tested on
loongson 3A3000).
---
libavcodec/mips/Makefile | 1 +
libavcodec/mips/vp9_mc_mmi.c | 680 +
libavcodec/mips/vp9dsp_init_mips.c | 42 +++
libavcodec/mips/vp9dsp_mips.h
> > At least from my understanding it would be perfectly legal to exclude
> > the CUDA kernel code from ffmpeg and add an option to the filters
> > for specifying a file containing the compiled CUDA kernel to be loaded
> > at runtime (via cuModuleLoadData).
> >
> > What do you think?
>
> It's certa
Added comments regarding usage of certain movflags in streaming mode.
---
libavformat/dashenc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index a0b44a0ec3..f8782756b4 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
The master playlist can be published at a specified interval with this option
---
doc/muxers.texi | 3 +++
libavformat/dashenc.c | 9 -
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 36010cf2d1..372fab2f92 100644
--- a/doc/muxer
On 1/31/19 7:08 AM, myp...@gmail.com wrote:
> On Thu, Jan 24, 2019 at 2:01 PM Karthick J wrote:
>>
>> In streaming mode mp4 trailer is not required for playout.
>> ---
>> libavformat/dashenc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/dashenc.c b/lib
21 matches
Mail list logo
