On Tue, 26 Mar 2019 22:00:54 +0100
Michael Niedermayer wrote:
> On Tue, Mar 26, 2019 at 08:58:34AM +0200, Lauri Kasanen wrote:
> > In this function, the exact same clamping happens both in the if and
> > unconditionally.
> >
> > Signed-off-by: Lauri Kasanen
> > ---
> > libswscale/output.c | 10
Signed-off-by: Steven Liu
---
libavformat/hls.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 4e38d25678..f4e449880b 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -658,7 +658,7 @@ static int open_url(AVFormatContext
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Wednesday, March 27, 2019 12:05 AM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH 3/3] doc/examples: add QSV decode
> GPU copy sample
>
> On Tue, Mar 2
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Timo Rothenpieler
> Sent: Monday, March 25, 2019 6:21 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] configure: include pkgconfig path as
> vaapi header search
>
> On 20/03/2019 08:57, Zhong Li wro
Signed-off-by: Zhong Li
---
libavcodec/qsvenc.c | 48 +---
libavcodec/qsvenc.h | 3 +++
libavcodec/qsvenc_hevc.c | 10 +
3 files changed, 49 insertions(+), 12 deletions(-)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 7903235d
Signed-off-by: Zhong Li
---
libavcodec/qsvenc.c | 17 -
libavcodec/qsvenc.h | 2 ++
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index afeb0f7b10..7903235db9 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@
cbs trace qsv vps header failed due to some reasons:
1. vps_temporal_id_nesting_flag is not set but spec required it must to
be 1 when vps_max_sub_layers_minus1 is equal to 0.
2. vps_num_hrd_parameters is not set and written.
3. other issues in ff_hevc_encode_nal_vps() (have fixed in pervious co
1. write vps_num_hrd_parameters element
2. flush left bits
Signed-off-by: Zhong Li
---
libavcodec/hevc_ps_enc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevc_ps_enc.c b/libavcodec/hevc_ps_enc.c
index 4c71cf41ca..78a73a5c0a 100644
--- a/libavcodec/hev
Signed-off-by: Zhengxu Huang
Signed-off-by: Hassene Tmar
Signed-off-by: Jun Zhao
Signed-off-by: Jing Sun
---
configure| 4 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/libsvt_hevc.c | 502 +++
4 f
On 3/26/2019 9:17 PM, Michael Niedermayer wrote:
> Fixes: NULL pointer dereference and out of array access
> Fixes:
> 13871/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5746167087890432
> Fixes:
> 13845/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-565037072803430
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Wednesday, March 27, 2019 7:39 AM
> To: FFmpeg development discussions and patches
> Subject: [FFmpeg-devel] [PATCH] configure: Do not enable both OpenCL-VAAPI
> intero
This will be needed by the eventual native AV1 decoder.
Signed-off-by: James Almer
---
Now propagating the Temporal Unit unchanged if splitting can't be performed.
configure| 1 +
libavcodec/Makefile | 1 +
libavcodec/av1_frame_split_bsf.c | 252
On 20/03/2019 09:14, Decai Lin wrote:
> 1. add MaxMBPS checking for level idc setting to align with AVC spec
>AnnexA table A-1/A-6 level limits.
> 2. update h264 level fate test.
>
> Signed-off-by: Decai Lin
> ---
> libavcodec/h264_levels.c | 4 +++
> libavcodec/h264_levels.h |
On Sun, Mar 24, 2019 at 11:17:37AM -0300, James Almer wrote:
> On 3/24/2019 7:55 AM, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/hevcdec.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> > i
Fixes: NULL pointer dereference and out of array access
Fixes:
13871/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5746167087890432
Fixes:
13845/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5650370728034304
This also fixes the return code for explode mode
Found-
Fixes: signed integer overflow: 255 + 2147483634 cannot be represented in type
'int'
Fixes:
13472/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5712444142387200
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-
2019-03-26 23:44 GMT+01:00, Mark Thompson :
> * Run exhaustively in tsan/valgrind/other race detectors and fix every
> problem it finds, then provide evidence from that to help with review.
In addition to issues you mention, I wonder if this wouldn't trigger
many unresolved issues in existing (li
Beignet offers a far more flexiable and complete interface, so choose it
by default if available.
---
On 23/03/2019 12:27, Mark Thompson wrote:
> On 22/03/2019 01:40, Ruiling Song wrote:
>> ffmpeg | branch: master | Ruiling Song | Fri Nov 23
>> 13:39:12 2018 +0800| [61cb505d18b8a335bd118d88c05b9d
On 26/03/2019 22:07, Shaofei Wang wrote:
> It enabled MULTIPLE SIMPLE filter graph concurrency, which bring above about
> 4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration
>
> ...
> ---
> The patch will only effect on multiple SIMPLE filter graphs pipeline,
> Passed fate and refi
2019-03-26 23:33 GMT+01:00, Ulf Zibis :
>
> Am 26.03.19 um 16:32 schrieb Carl Eugen Hoyos:
Please elaborate.
>>> It seems I'm doing something wrong:
>>>
>>> ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b -y -stream_loop 1024
>>> -i /dev/zero -vf fillborders=25:25:25:25:mirror -f null -
>> $ ffmp
Am 26.03.19 um 16:32 schrieb Carl Eugen Hoyos:
>>> Please elaborate.
>> It seems I'm doing something wrong:
>>
>> ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b -y -stream_loop 1024
>> -i /dev/zero -vf fillborders=25:25:25:25:mirror -f null -
> $ ffmpeg -f rawvideo -s hd1080 -i /dev/zero -vf ... -t
Support is #ifdef'd out at this stage, using ZMBV_ENABLE_24BPP (like in
the zmbv.c decoder)
---
libavcodec/zmbvenc.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/zmbvenc.c b/libavcodec/zmbvenc.c
index 98029de5f6..48871758e0 100644
--- a/libavcodec/zmbvenc.c
+++ b/libavco
This brings the channel order in line with that used in 32-bit mode (BGR0).
24-bit decoding is disabled by default (#ifdef ZMBV_ENABLE_24BPP), and no
prior encoders or sample videos are known to exist for this bit depth, so
I consider this change in implementation is unlikely to affect anyone.
Th
When the silencedetect filter is run against very large files, the
output timestamps gradually lose precision as the scan proceeds
further into the file. This is because the output is formatted (in
libavutil/timestamp.h) as "%.6g", which limits the total field length.
Eventually, for offsets greate
On Tue, Mar 26, 2019 at 06:07:21PM -0400, Shaofei Wang wrote:
> It enabled MULTIPLE SIMPLE filter graph concurrency, which bring above about
> 4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration
>
> Below are some test cases and comparison as reference.
> (Hardware platform: Intel(
On Tue, Mar 26, 2019 at 08:58:34AM +0200, Lauri Kasanen wrote:
> In this function, the exact same clamping happens both in the if and
> unconditionally.
>
> Signed-off-by: Lauri Kasanen
> ---
> libswscale/output.c | 10 --
> 1 file changed, 10 deletions(-)
>
> v2: Remove the unconditio
When using multiple output streams the playlists are written for each video
output.
For example when we have 3 video qualities, the playlists are written 3 times
per segement duration.
I would expect each playlist to be written exactly once per segment duration.
I created a little patch that wait
---
libavformat/dashenc.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 1b74bce060..e4f7843e03 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -144,6 +144,8 @@ typedef struct DASHContext {
Hello,
I’ve accounted for all feedback on this so far, I’m wondering if it is ready to
be pushed upstream?
Here are my results from ‘checkasm’ (lower is better):
v210_unpack_c: 1636
v210_unpack_ssse3: 611
v210_unpack_avx: 601
v210_unpack_avx2: 423
I ran it 5 times and averaged the middle 3 resu
2019-03-26 20:51 GMT+01:00, Michael Niedermayer :
> On Tue, Mar 26, 2019 at 01:38:14PM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch intends to fix a buffer overwrite reported today.
>>
>> Please comment, Carl Eugen
>
>> bmp.c |5 -
>> 1 file changed, 4 insertions(+), 1 deleti
On Tue, Mar 26, 2019 at 01:38:14PM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch intends to fix a buffer overwrite reported today.
>
> Please comment, Carl Eugen
> bmp.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
> ab9b89481fc3c93d4a631fb1d6b25dddbdd4bb50
> 0001-
On Tue, Mar 26, 2019, 21:20 Yufei He wrote:
> On 03/26/2019 11:31 AM, Dennis Mungai wrote:
> > On Tue, 26 Mar 2019 at 18:21, Yufei He wrote:
> >
> >> On 03/26/2019 08:53 AM, Timo Rothenpieler wrote:
> >> On 26/03/2019 13:47, Yufei He wrote:
> >> Hi
> >>
> >> Is there option for scaling on transc
On 03/26/2019 11:31 AM, Dennis Mungai wrote:
> On Tue, 26 Mar 2019 at 18:21, Yufei He wrote:
>
>> On 03/26/2019 08:53 AM, Timo Rothenpieler wrote:
>> On 26/03/2019 13:47, Yufei He wrote:
>> Hi
>>
>> Is there option for scaling on transcoding ?
>>
>> e.g. transcoding from a quadhd file to 640 * 480
On 3/26/19, Ulf Zibis wrote:
>
> Am 26.03.19 um 17:39 schrieb Carl Eugen Hoyos:
>>
>>> 1.) There may be a shortcut in CPU architecture for copying nulls in
>>> series (fillborders.c essentially does that) and more important ...
>> I am curious:
>> Which architecture are you thinking about that int
Am 26.03.19 um 17:39 schrieb Carl Eugen Hoyos:
>
>> 1.) There may be a shortcut in CPU architecture for copying nulls in
>> series (fillborders.c essentially does that) and more important ...
> I am curious:
> Which architecture are you thinking about that interprets
> FFmpeg's inner structure?
I
2019-03-26 17:36 GMT+01:00, Ulf Zibis :
>
> Am 26.03.19 um 17:20 schrieb Carl Eugen Hoyos:
>> 2019-03-26 17:17 GMT+01:00, Ulf Zibis :
>>> Am 26.03.19 um 16:32 schrieb Carl Eugen Hoyos:
2019-03-26 16:28 GMT+01:00, Ulf Zibis :
> Am 26.03.19 um 16:10 schrieb Carl Eugen Hoyos:
>> 2019-03-2
Am 26.03.19 um 17:20 schrieb Carl Eugen Hoyos:
> 2019-03-26 17:17 GMT+01:00, Ulf Zibis :
>> Am 26.03.19 um 16:32 schrieb Carl Eugen Hoyos:
>>> 2019-03-26 16:28 GMT+01:00, Ulf Zibis :
Am 26.03.19 um 16:10 schrieb Carl Eugen Hoyos:
> 2019-03-26 15:56 GMT+01:00, Ulf Zibis :
>
>> I'm
2019-03-26 17:17 GMT+01:00, Ulf Zibis :
>
> Am 26.03.19 um 16:32 schrieb Carl Eugen Hoyos:
>> 2019-03-26 16:28 GMT+01:00, Ulf Zibis :
>>> Am 26.03.19 um 16:10 schrieb Carl Eugen Hoyos:
2019-03-26 15:56 GMT+01:00, Ulf Zibis :
> I'm trying to benchmark -vf fillborders (added the timer
>
Am 26.03.19 um 16:32 schrieb Carl Eugen Hoyos:
> 2019-03-26 16:28 GMT+01:00, Ulf Zibis :
>> Am 26.03.19 um 16:10 schrieb Carl Eugen Hoyos:
>>> 2019-03-26 15:56 GMT+01:00, Ulf Zibis :
>>>
I'm trying to benchmark -vf fillborders (added the timer
code in vf_fillborders.c), so Carl Eugen's s
2019-03-26 17:09 GMT+01:00, Ulf Zibis :
>
> Am 26.03.19 um 16:34 schrieb Carl Eugen Hoyos:
>> 2019-03-26 16:23 GMT+01:00, Ulf Zibis :
>>> Am 26.03.19 um 16:00 schrieb Nicolas George:
Using the "color" filter source may be a little more
efficient, and is much more convenient.
>>> With
>>>
Am 26.03.19 um 16:34 schrieb Carl Eugen Hoyos:
> 2019-03-26 16:23 GMT+01:00, Ulf Zibis :
>> Am 26.03.19 um 16:00 schrieb Nicolas George:
>>> Using the "color" filter source may be a little more
>>> efficient, and is much more convenient.
>> With
>> ffplay -f lavfi color=green
>> I only see a monot
On Tue, Mar 26, 2019 at 01:39:49PM +0800, Linjie Fu wrote:
> Usage is:
> ./qsvdec_gpucopy on/off input_stream output_stream
>
> For example:
> - enable/disable gpu copy:
> ./qsvdec_gpucopy on input.h264 output.yuv
> ./qsvdec_gpucopy off input.h264 output.yuv
>
> Generate fps per second.
>
Am 26.03.19 um 16:26 schrieb Nicolas George:
>
> Try testsrc2.
Bad news:
ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b testsrc2 -loop 1024 -vf
fillborders=25:25:25:25:mirror -f null -
ffmpeg version N-93458-g18429ce896 Copyright (c) 2000-2019 the FFmpeg
developers
built with gcc 7 (Ubuntu 7.3.0-
2019-03-26 16:23 GMT+01:00, Ulf Zibis :
>
> Am 26.03.19 um 16:00 schrieb Nicolas George:
>> Using the "color" filter source may be a little more
>> efficient, and is much more convenient.
> With
> ffplay -f lavfi color=green
> I only see a monotone picture. This is not apropriate
> to test the fill
2019-03-26 16:28 GMT+01:00, Ulf Zibis :
>
> Am 26.03.19 um 16:10 schrieb Carl Eugen Hoyos:
>> 2019-03-26 15:56 GMT+01:00, Ulf Zibis :
>>
>>> I'm trying to benchmark -vf fillborders (added the timer
>>> code in vf_fillborders.c), so Carl Eugen's suggestion
>>> to use /dev/zero as input would not mak
On Tue, 26 Mar 2019 at 18:21, Yufei He wrote:
> On 03/26/2019 08:53 AM, Timo Rothenpieler wrote:
> On 26/03/2019 13:47, Yufei He wrote:
> Hi
>
> Is there option for scaling on transcoding ?
>
> e.g. transcoding from a quadhd file to 640 * 480.
>
> Thanks.
>
> Yufei.
>
>
> Yes there is, but this i
Ulf Zibis (12019-03-26):
> It seems I'm doing something wrong:
>
> ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b -y -stream_loop 1024 -i
> /dev/zero -vf fillborders=25:25:25:25:mirror -f null -
Obviously. Please stop putting options randomly together and wasting
everybody's time when they do not w
Am 26.03.19 um 16:10 schrieb Carl Eugen Hoyos:
> 2019-03-26 15:56 GMT+01:00, Ulf Zibis :
>
>> I'm trying to benchmark -vf fillborders (added the timer
>> code in vf_fillborders.c), so Carl Eugen's suggestion
>> to use /dev/zero as input would not make sense.
> Please elaborate.
It seems I'm doing
Ulf Zibis (12019-03-26):
> With
> ffplay -f lavfi color=green
> I only see a monotone picture. This is not apropriate to test the
> fillborders filter with mode=mirror.
Ok. Then it is not suitable. And neither would be /dev/zero.
> Also yuvtestsrc is not really helpfull on that.
Try testsrc2.
A
Am 26.03.19 um 16:00 schrieb Nicolas George:
> Using the "color" filter source may be a little more efficient, and is
> much more convenient.
With
ffplay -f lavfi color=green
I only see a monotone picture. This is not apropriate to test the
fillborders filter with mode=mirror.
Also yuvtestsrc is
On 03/26/2019 08:53 AM, Timo Rothenpieler wrote:
On 26/03/2019 13:47, Yufei He wrote:
Hi
Is there option for scaling on transcoding ?
e.g. transcoding from a quadhd file to 640 * 480.
Thanks.
Yufei.
Yes there is, but this is ffmpeg-devel, so not the place to ask user questions.
Yes, I see th
2019-03-26 15:56 GMT+01:00, Ulf Zibis :
> I'm trying to benchmark -vf fillborders (added the timer
> code in vf_fillborders.c), so Carl Eugen's suggestion
> to use /dev/zero as input would not make sense.
Please elaborate.
Carl Eugen
___
ffmpeg-devel m
Ulf Zibis (12019-03-26):
> Again only 1 runs (also with "-stream_loop 1024").
You are obviously doing something wrong.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https:
Ulf Zibis (12019-03-26):
> I'm trying to benchmark -vf fillborders (added the timer code in
> vf_fillborders.c), so Carl Eugen's suggestion to use /dev/zero as input
> would not make sense. I'll try with "-f null -".
Using the "color" filter source may be a little more efficient, and is
much more
Am 26.03.19 um 15:56 schrieb Ulf Zibis:
> I'm trying to benchmark -vf fillborders (added the timer code in
> vf_fillborders.c), so Carl Eugen's suggestion to use /dev/zero as input
> would not make sense. I'll try with "-f null -".
Again only 1 runs (also with "-stream_loop 1024").
-Ulf
___
Am 26.03.19 um 15:48 schrieb Nicolas George:
> Ulf Zibis (12019-03-26):
>> Do you mean the following option? Unfortunately I still see only 1 run.
>>
>> I know, that it works with "-vf -loop=loop=1024:size=1:start=0", but I
>> ask, because I want to understand the purpose of the shorter option
>>
Am 26.03.19 um 15:42 schrieb Ulf Zibis:
> Hi again,
>
> Am 19.03.19 um 17:31 schrieb Carl Eugen Hoyos:
>>> 122670 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,
>>> 1 runs, 0 skips
>> One run is not good.
>> Either use the loop option to filter the same frame again and
>> again or fee
Ulf Zibis (12019-03-26):
> Do you mean the following option? Unfortunately I still see only 1 run.
>
> I know, that it works with "-vf -loop=loop=1024:size=1:start=0", but I
> ask, because I want to understand the purpose of the shorter option
> "-loop number".
>
> ./ffmpeg-p7b -y -i debug/8.jpg
2019-03-26 15:42 GMT+01:00, Ulf Zibis :
> Do you mean the following option? Unfortunately I still see only 1 run.
>
> I know, that it works with "-vf -loop=loop=1024:size=1:start=0", but I
> ask, because I want to understand the purpose of the shorter option
> "-loop number".
> ./ffmpeg-p7b -y -i
Hi again,
Am 19.03.19 um 17:31 schrieb Carl Eugen Hoyos:
>> 122670 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,
>> 1 runs, 0 skips
> One run is not good.
> Either use the loop option to filter the same frame again and
> again or feed a video to ffmpeg.
Do you mean the following opt
On 26/03/2019 13:47, Yufei He wrote:
Hi
Is there option for scaling on transcoding ?
e.g. transcoding from a quadhd file to 640 * 480.
Thanks.
Yufei.
Yes there is, but this is ffmpeg-devel, so not the place to ask user
questions.
smime.p7s
Description: S/MIME Cryptographic Signature
On Mon, Mar 25, 2019 at 04:19:37PM +0530, Shivam Goyal wrote:
>
> On 3/25/19 3:59 PM, Michael Niedermayer wrote:
> >On Sun, Mar 24, 2019 at 04:35:40PM +0530, Shivam Goyal wrote:
> >>The attached patch is for ticket #3720
> >>
> >> https://trac.ffmpeg.org/ticket/3720
> >>
> >>I have tested this
Hi
Is there option for scaling on transcoding ?
e.g. transcoding from a quadhd file to 640 * 480.
Thanks.
Yufei.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above
Hi!
Attached patch intends to fix a buffer overwrite reported today.
Please comment, Carl Eugen
From bd0dfa740f879eca6b13bb841e3b8d37718460ea Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 26 Mar 2019 13:32:11 +0100
Subject: [PATCH] lavc/bmp: Avoid a heap buffer overwrite for 1bpp in
On Mon, Mar 25, 2019 at 04:43:27PM +0800, Jun Zhao wrote:
> From: Jun Zhao
>
> AVFMT_NOTIMESTAMPS may be using AVInputFormat.flags for demuxing
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/avformat.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
LGTM
thx
[...]
--
Michael
2019-03-26 12:28 GMT+01:00, Moritz Barsnick :
> On Tue, Mar 26, 2019 at 11:22:58 +0100, Carl Eugen Hoyos wrote:
>> > While trying to see if the proposed XV demuxer[1] can be simplified, I
>> > tripped over the fact that this KUX patch introduces a new demuxer for
>> > what looks like "only" a minor
On Tue, Mar 26, 2019 at 11:22:58 +0100, Carl Eugen Hoyos wrote:
> > While trying to see if the proposed XV demuxer[1] can be simplified, I
> > tripped over the fact that this KUX patch introduces a new demuxer for
> > what looks like "only" a minor variant of FLV. Could the patch not just
> > as we
On more remark:
On Tue, Mar 19, 2019 at 22:41:32 +0530, swarajhota...@gmail.com wrote:
> +static int kux_probe(AVProbeData *p)
I get a warning if this isn't declared "const AVProbeData *p".
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
h
> 在 2019年3月26日，19:04，Jun Zhao 写道：
>
> From: Jun Zhao
>
> Support AMF date type when parse the FLV metadata.
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/flvdec.c | 24 ++--
> 1 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/flvdec.c b/l
On 3/26/19, Carl Eugen Hoyos wrote:
> 2019-03-26 11:34 GMT+01:00, Paul B Mahol :
>> On 3/26/19, Carl Eugen Hoyos wrote:
>>> 2019-03-26 11:13 GMT+01:00, Paul B Mahol :
Signed-off-by: Paul B Mahol
---
libavcodec/get_bits.h | 82 +
liba
From: Jun Zhao
Support AMF date type when parse the FLV metadata.
Signed-off-by: Jun Zhao
---
libavformat/flvdec.c | 24 ++--
1 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index c4d5278..b1e13da 100644
--- a/li
From: Jun Zhao
Commit e34ba5ec53b missed the indent
Signed-off-by: Jun Zhao
---
libavformat/flvdec.c | 244 +-
1 files changed, 122 insertions(+), 122 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index b1e13da..445d58d
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Sunday, March 24, 2019 12:19 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v3 1/2] vf_crop: Add support for cropping
> hardware frames
>
> Set the c
2019-03-25 2:13 GMT+01:00, Stephen Hutchinson :
> On 3/24/2019 7:07 PM, Carl Eugen Hoyos wrote:
>> 2019-03-24 21:25 GMT+01:00, Stephen Hutchinson :
>>> These pix_fmts have been added to FFmpeg in the 31 months since
>>> commit 92916e8542e425ca20daddb490261a5818643206 added support for
>>> the large
2019-03-25 6:42 GMT+01:00, Sun, Jing A :
> Friday, March 22, 2019 5:54 PM, Carl Eugen Hoyos:
>
>>What I meant is:
>>I don't understand the comment (and your mail), it says above the
>> functionality has to be disabled but you write it works fine.
>>The comment is (still) unclear imo.
>
>>Carl Eugen
2019-03-26 0:49 GMT+01:00, Allan Cady via ffmpeg-devel
:
> Noob here. I would like to suggest a simple change to
> libavutil\timestamp.h
Please provide a patch (as attachment) that you created
with "git format-patch HEAD^"
Carl Eugen
___
ffmpeg-devel m
2019-03-26 11:26 GMT+01:00, Carl Eugen Hoyos :
> 2019-03-26 11:13 GMT+01:00, Paul B Mahol :
>> Signed-off-by: Paul B Mahol
>> ---
>> libavcodec/get_bits.h | 82 +
>> libavcodec/utvideodec.c | 4 +-
>> 2 files changed, 60 insertions(+), 26 deletions(-)
>
2019-03-26 11:34 GMT+01:00, Paul B Mahol :
> On 3/26/19, Carl Eugen Hoyos wrote:
>> 2019-03-26 11:13 GMT+01:00, Paul B Mahol :
>>> Signed-off-by: Paul B Mahol
>>> ---
>>> libavcodec/get_bits.h | 82 +
>>> libavcodec/utvideodec.c | 4 +-
>>> 2 files chan
On Tue, Mar 26, 2019 at 11:32 AM Carl Eugen Hoyos wrote:
>
> 2019-03-26 11:13 GMT+01:00, Paul B Mahol :
> > Signed-off-by: Paul B Mahol
> > ---
> > libavcodec/get_bits.h | 82 +
> > libavcodec/utvideodec.c | 4 +-
> > 2 files changed, 60 insertions(+),
2019-03-26 23:07 GMT+01:00, Shaofei Wang :
> It enabled MULTIPLE SIMPLE filter graph concurrency, which
> bring above about 4%~20% improvement in some 1:N
> scenarios by CPU or GPU acceleration
Which version of the patch did you test to get this numbers?
The following is not an actual review, fee
On 3/26/19, Carl Eugen Hoyos wrote:
> 2019-03-26 11:13 GMT+01:00, Paul B Mahol :
>> Signed-off-by: Paul B Mahol
>> ---
>> libavcodec/get_bits.h | 82 +
>> libavcodec/utvideodec.c | 4 +-
>> 2 files changed, 60 insertions(+), 26 deletions(-)
>
> How can
2019-03-26 11:13 GMT+01:00, Paul B Mahol :
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/get_bits.h | 82 +
> libavcodec/utvideodec.c | 4 +-
> 2 files changed, 60 insertions(+), 26 deletions(-)
How can the issue be reproduced?
Would my patch - that
2019-03-26 11:18 GMT+01:00, Moritz Barsnick :
> On Tue, Mar 26, 2019 at 00:24:40 +0100, Carl Eugen Hoyos wrote:
>> > Fixes ticket #4519.
>> I will push this if there are no objections.
>
> While trying to see if the proposed XV demuxer[1] can be simplified, I
> tripped over the fact that this KUX p
On Tue, Mar 26, 2019 at 00:24:40 +0100, Carl Eugen Hoyos wrote:
> > Fixes ticket #4519.
> I will push this if there are no objections.
While trying to see if the proposed XV demuxer[1] can be simplified, I
tripped over the fact that this KUX patch introduces a new demuxer for
what looks like "only
Signed-off-by: Paul B Mahol
---
libavcodec/get_bits.h | 82 +
libavcodec/utvideodec.c | 4 +-
2 files changed, 60 insertions(+), 26 deletions(-)
diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index c2f267186e..c4ab607744 100644
--- a/libavco
On Tue, 26 Mar 2019, at 10:03, Tomas Härdin wrote:
> You can include LGPL code in a proprietary library if you provide the
> object files for the proprietary parts, such that you can modify the
> LGPL part and still link together a functioning library. I don't think
> I've ever seen that done howev
On Tue, 26 Mar 2019, at 09:45, Tobias Rapp wrote:
> > I know that means that you can do more or less the same feature, but that
> > means the architecture must be different.
>
> I thought that section 7 would allow to combine a 3rd party library with
> a LGPL library to create a new library but
It enabled MULTIPLE SIMPLE filter graph concurrency, which bring above about
4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration
Below are some test cases and comparison as reference.
(Hardware platform: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz)
(Software: Intel iHD driver - 16.9.00
tis 2019-03-26 klockan 09:45 +0100 skrev Tobias Rapp:
> On 25.03.2019 18:02, Jean-Baptiste Kempf wrote:
> > On Mon, 25 Mar 2019, at 08:32, Tobias Rapp wrote:
> > > > Most of those hardware libraries are glorified ioctls around
> > > > the driver and shipped with the drivers.
> > > > And I see this
On 25.03.2019 18:02, Jean-Baptiste Kempf wrote:
On Mon, 25 Mar 2019, at 08:32, Tobias Rapp wrote:
Most of those hardware libraries are glorified ioctls around the driver and
shipped with the drivers.
And I see this with nVidia, Intel MFX and Decklink (lots of "acquire C++ interface,
set param"
90 matches
Mail list logo
