On 12-09-2019 07:11 PM, Gyan wrote:
On 12-09-2019 02:04 PM, Moritz Barsnick wrote:
On Mon, Sep 09, 2019 at 23:44:14 +0530, Gyan wrote:
Subject: [PATCH] cmdutils: promote report level if loglevel is higher
Would it also be useful to be able to reduce the report's log level, or
would that le
This happens with any use of the hwmap filter in the derive_device
configuration with input being HEVC decoded via dxva2 with dimensions that
aren't 128-pixel-aligned and output being QSV; eg:
ffmpeg.exe -codec:0 hevc -hwaccel:0 dxva2 -hwaccel_output_format:0 dxva2_vld
test.mkv -filter_complex
On 03/09/2019 02:02, Aman Gupta wrote:
> From: Jonas Karlman
>
> This allows the cli to create a dummy drm hwcontext
> that can be shared between the v4l2 decoder/scaler/encoder.
>
> This is especially useful on older RPI3 where /dev/dri devices
> are not available in the default configuration.
On 03/09/2019 02:02, Aman Gupta wrote:
> From: Aman Gupta
>
> Based on patchset submitted to ffmpeg-devel by Lukas Rusak
>
> Signed-off-by: Aman Gupta
> ---
> libavcodec/v4l2_m2m_dec.c | 85 ---
> 1 file changed, 80 insertions(+), 5 deletions(-)
>
> diff -
On 10/09/2019 17:07, Linjie Fu wrote:
> There is no VA_RT_FORMAT_AYUV in defined in libva, and currently in
> media-driver, VA_FOURCC_AYUV is used to represent VA_RT_FORMAT_AYUV.
That doesn't make sense - VA_RT_FORMAT_* is a bit mask, so using VA_FOURCC_AYUV
looks like a random combination of oth
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_minterpolate.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_minterpolate.c b/libavfilter/vf_minterpolate.c
index b0bb238..fc8054b 100644
--- a/libavfilter/vf_minterpolate.c
+++ b/libavfilte
On Thu, Sep 12, 2019 at 07:55:30PM +0200, Marton Balint wrote:
>
>
> On Thu, 12 Sep 2019, lance.lmw...@gmail.com wrote:
>
> >From: Limin Wang
> >
> >Have been tested by fate-suite/svq3/Vertical400kbit.sorenson3.mov and the
> >testing results are consistent.
> >
> >If it is acceptable, I want to
Am Do., 12. Sept. 2019 um 00:22 Uhr schrieb Michael Niedermayer
:
> I think you will find that there is no timeout that works well
> You just do not want 50 byte files or files with the resolution
> of an icon to take days to decode
+1!
Carl Eugen
___
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: Thursday, September 12, 2019 11:29 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] FW: [PATCH] Add option to log timing
>
> On Wed, Sep 11, 2019 at 0
On Wed, Sep 11, 2019 at 08:43:36PM +, Soft Works wrote:
> Michael - you probably missed my question...
>
> -Original Message-
> From: Soft Works
> Sent: Friday, September 6, 2019 11:44 PM
> To: FFmpeg development discussions and patches
> Subject: RE: [FFmpeg-devel] [PATCH] Add optio
tor 2019-09-12 klockan 00:21 +0200 skrev Michael Niedermayer:
> On Wed, Sep 11, 2019 at 11:18:47PM +0200, Tomas Härdin wrote:
> > tis 2019-09-10 klockan 16:16 +0200 skrev Michael Niedermayer:
> > > On Mon, Sep 09, 2019 at 11:04:32PM +0200, Tomas Härdin wrote:
> > > > mån 2019-09-09 klockan 22:16 +0
Fixes: out of array write
Fixes:
17088/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEGLS_fuzzer-5654877765632000
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/mjpegdec.c | 4
1 f
Fixes: NULL pointer dereference
Fixes: assertion failure
Fixes:
17003/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MJPEG_fuzzer-5696929253556224
Fixes:
17039/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MJPEG_fuzzer-5651008134316032
Found-by: continuous fuzzing process
https://github.
On Thu, 12 Sep 2019, lance.lmw...@gmail.com wrote:
From: Limin Wang
Have been tested by fate-suite/svq3/Vertical400kbit.sorenson3.mov and the
testing results are consistent.
If it is acceptable, I want to move get_scene_score() to the public function and
make the scene change detection calc
> From: ffmpeg-devel On Behalf Of Linjie Fu
> Sent: Friday, May 31, 2019 8:35 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> vaMapBuffer returns multiple buffers
>
> It seems that VA_CODED_BUF_STATUS_SINGLE_NALU allows
ping the v210 decode thread.
On Fri, Sep 06, 2019 at 11:28:29PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> The multithread is avoid one core cpu is full with other filter like scale
> etc.
> About the performance, the gain is very small, below is my testing for
> performance.
On Thu, Sep 12, 2019 at 12:55:09PM +0200, Carl Eugen Hoyos wrote:
> Am Do., 12. Sept. 2019 um 11:24 Uhr schrieb :
> >
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/lcldec.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/l
ping for the patchset.
On Sun, Sep 01, 2019 at 09:20:19PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/v210enc.c | 83
> +++-
> 1 file changed, 36 insertions(+), 47 deletions(-)
>
> d
On 12/09/2019 15:17, Steve Lhomme wrote:
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a51c2c9..c3a9209 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-PREFIX = /usr/local
+PREFIX ?= /usr/local
Overriding the prefix worked ju
On 12-09-2019 02:04 PM, Moritz Barsnick wrote:
On Mon, Sep 09, 2019 at 23:44:14 +0530, Gyan wrote:
Subject: [PATCH] cmdutils: promote report level if loglevel is higher
Would it also be useful to be able to reduce the report's log level, or
would that lead to incomplete bug reports?
Yes, usel
> From: ffmpeg-devel On Behalf Of Linjie Fu
> Sent: Wednesday, September 11, 2019 12:09 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [FFmpeg-devel] [PATCH] qsv: get FrameInfo.Shift by
> desc->comp[0].shift
>
> Since Y410 is a pixel format with depth > 8 but shift = 0, get Shift
This is for this repo:
https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git
On 2019-09-12 15:19, Steve Lhomme wrote:
It can be useful to determine if the decoder context is the same as the display
context.
It's used in some samples at https://github.com/NVIDIA/video-sdk-samples
---
includ
This is for this repo:
https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git
On 2019-09-12 15:17, Steve Lhomme wrote:
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a51c2c9..c3a9209 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,
It can be useful to determine if the decoder context is the same as the display
context.
It's used in some samples at https://github.com/NVIDIA/video-sdk-samples
---
include/ffnvcodec/dynlink_cuda.h | 1 +
include/ffnvcodec/dynlink_loader.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a51c2c9..c3a9209 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-PREFIX = /usr/local
+PREFIX ?= /usr/local
LIBDIR = lib
INSTALL = install
SED = sed
--
2.17.1
__
> From: ffmpeg-devel On Behalf Of Rodger
> Combs
> Sent: Thursday, September 12, 2019 11:59 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH] lavu/hwcontext_qsv: update crop width/height
> when mapping frames
>
> This fixes an issue where the context could be configured with one
On Thu, Sep 12, 2019 at 13:44:57 +0200, Peter B. wrote:
> If I understand this correctly, does it mean that the order of streams
> output by the streamhash muxer will be "in order of type" (video, audio,
> etc), independent of the order in the source?
Since it's a muxer, and not a hashing demuxer
On 12-09-2019 05:14 PM, Peter B. wrote:
Hi :)
On 11/09/2019 17:57, Gyan wrote:
On 11-09-2019 08:19 PM, Moritz Barsnick wrote:
The original user suggesting this muxer also requested a stream type
indicator. Is that info really useful and not redundant, assuming the
user will need to understan
Hi :)
On 11/09/2019 17:57, Gyan wrote:
>
> On 11-09-2019 08:19 PM, Moritz Barsnick wrote:
>> The original user suggesting this muxer also requested a stream type
>> indicator. Is that info really useful and not redundant, assuming the
>> user will need to understand the implications of remuxing an
Am Do., 12. Sept. 2019 um 11:24 Uhr schrieb :
>
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/lcldec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/lcldec.c b/libavcodec/lcldec.c
> index 046cdc4f8e..1154221f8f 100644
> --- a/libavcodec
hi
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Aman Gupta
> Sent: Tuesday, September 03, 2019 9:02 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: loru...@gmail.com; Aman Gupta ;
> jorge.ramirez.or...@gmail.com; Aman Gupta
> Subject: [FFmpeg-de
example command line to verify it:
./ffmpeg -i input.stream -vf addroi=0:0:iw/3:ih/3:-0.8 -c:v libvpx -b:v 2M
tmp.webm
Signed-off-by: Guo, Yejun
---
libavcodec/libvpxenc.c | 193 +
libavcodec/version.h | 2 +-
2 files changed, 194 insertions(+
From: Limin Wang
Have been tested by fate-suite/svq3/Vertical400kbit.sorenson3.mov and the
testing results are consistent.
If it is acceptable, I want to move get_scene_score() to the public function and
make the scene change detection calculation method of the relevant module
consistent.
Sign
> -Original Message-
> From: James Zern [mailto:jz...@google.com]
> Sent: Thursday, September 12, 2019 2:18 PM
> To: FFmpeg development discussions and patches
> Cc: Guo, Yejun
> Subject: Re: [FFmpeg-devel] [PATCH V8] avcodec/libvpxenc: add ROI-based
> encoding support for VP8/VP9
>
>
On Thu, Sep 12, 2019 at 09:49:15AM +0200, Carl Eugen Hoyos wrote:
>
>
> > Am 12.09.2019 um 00:41 schrieb lance.lmw...@gmail.com:
> >
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/tscc.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/tiff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 9f24796a88..4843a11f3d 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -393,7 +393,7 @@ static int tiff_unco
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/lcldec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/lcldec.c b/libavcodec/lcldec.c
index 046cdc4f8e..1154221f8f 100644
--- a/libavcodec/lcldec.c
+++ b/libavcodec/lcldec.c
@@ -136,7 +136,7 @@ static int
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/zmbv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/zmbv.c b/libavcodec/zmbv.c
index 99e735cfd9..ace13e2ada 100644
--- a/libavcodec/zmbv.c
+++ b/libavcodec/zmbv.c
@@ -542,7 +542,7 @@ static int decode_fr
Adds a streamhash muxer, much like the hash muxer, but analyzing each stream
independently. I chose not to add a "streammd5" muxer, as the other *md5
muxers are just legacy versions of the *hash muxers with a different default
algorithm.
The first two patches re-arrange the code in preparation for
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/pngdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 2d6c1b218e..aec60ea493 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -406,7 +406,7 @@ static
Implemented as a variant of the hash muxer, reusing most functions,
and making use of the previously introduced array of hashes.
Signed-off-by: Moritz Barsnick
---
Changelog| 1 +
doc/muxers.texi | 47 ++
libavformat/Makefile | 1 +
libavformat/a
Only the frame* muxers support the format_version option.
Use macros to ease the proliferation of identical options to
coming muxers as well.
Signed-off-by: Moritz Barsnick
---
libavformat/hashenc.c | 35 +++
1 file changed, 27 insertions(+), 8 deletions(-)
diff
Only the first element of the array is used currently, the other
elements are in preparation for a new muxer calculating multiple
hashes.
Also move alloc/init code from the write_header() functions to
dedicated init() functions, and the cleanup code from the
write_trailer() functions to dedicated
On Mon, Sep 09, 2019 at 23:44:14 +0530, Gyan wrote:
> Subject: [PATCH] cmdutils: promote report level if loglevel is higher
Would it also be useful to be able to reduce the report's log level, or
would that lead to incomplete bug reports?
My use case: cron sometimes doesn't catch all output for p
> Am 12.09.2019 um 00:41 schrieb lance.lmw...@gmail.com:
>
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/tscc.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/tscc.c b/libavcodec/tscc.c
> index 6d03081..9eb17e3 100644
> --- a/lib
Ping, any update?
On Thu, 5 Sep 2019 at 06:33, Ross Nicholson wrote:
> Hey All,
>
> Anything needed from me to progress this?
>
> Thanks in advance,
>
> Ross
>
> On 29 Aug 2019, at 17:04, Ross Nicholson wrote:
>
> Hey Jun,
>
> So I got kodi running with FFmpeg n4.2 and the issue persists. Here'
46 matches
Mail list logo
