On Tue, Feb 18, 2020 at 02:40:49 +, Soft Works wrote:
> It's often not obvious how option constants relate to numerical values.
> Defaults are sometimes printed as numbers and from/to are always printed as
> numbers.
> Printing the numeric values of options constants avoids this confusion.
> I
Signed-off-by: Ting Fu
---
libswscale/x86/yuv_2_rgb.asm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libswscale/x86/yuv_2_rgb.asm b/libswscale/x86/yuv_2_rgb.asm
index e05bbb89f5..575a84d921 100644
--- a/libswscale/x86/yuv_2_rgb.asm
+++ b/libswscale/x86/yuv_2_rgb.asm
@@
> -Original Message-
> From: Pedro Arthur [mailto:bygran...@gmail.com]
> Sent: Monday, February 24, 2020 11:30 PM
> To: FFmpeg development discussions and patches
> Cc: Guo, Yejun
> Subject: Re: [FFmpeg-devel] [PATCH 1/4] avfilter/vf_sr.c: refine code to use
> AVPixFmtDescriptor.log2_ch
On Mon, Feb 24, 2020 at 5:18 PM Mark Thompson wrote:
> On 24/02/2020 21:28, Vittorio Giovara wrote:
> > On Sun, Feb 23, 2020 at 6:41 PM Mark Thompson wrote:
> >
> >> ---
> >> libavcodec/Makefile | 2 +-
> >> libavcodec/cbs_h265.c | 99 +++
> >> libavco
On Mon, Feb 24, 2020 at 5:07 PM Thilo Borgmann
wrote:
> Am 24.02.20 um 22:41 schrieb Lou Logan:
> > On Mon, Feb 24, 2020, at 3:37 AM, Anton Khirnov wrote:
> >> It fundamentally depends on an API that has been deprecated for five
> >> years, has seen no commits since that time and is of highly dub
Return an error directly if pixfmt is not supported for encoding, otherwise
it may be hidden until query/check in MSDK.
Signed-off-by: Linjie Fu
---
libavcodec/qsvenc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 571
Enables HEVC Range Extension encoding support for 4:2:2 8/10 bit
on ICL+ (gen11 +) platform with VMEPAK.
Signed-off-by: Linjie Fu
---
libavcodec/qsv.c | 2 ++
libavcodec/qsvenc.c | 4 +++-
libavcodec/qsvenc_hevc.c | 1 +
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/
Enables HEVC Range Extension decoding support for 4:2:2 8/10 bit
on ICL+ (gen11 +) platform.
Signed-off-by: Linjie Fu
---
libavcodec/qsv.c | 12
libavutil/hwcontext_qsv.c | 22 ++
2 files changed, 34 insertions(+)
diff --git a/libavcodec/qsv.c b/libavco
On Mon, Feb 24, 2020 at 11:08 PM Thilo Borgmann wrote:
> And how comes, if Michael's investigation, that all of this is based on use
> of _a function_ that is deprecated instead of direct access of AVFrame's
> fields is the cause of all of this?
>
The entire functionality is deprecated, that th
On 24/02/2020 22:42, Andreas Rheinhardt wrote:
> Mark Thompson:
>> On 24/02/2020 22:10, Andreas Rheinhardt wrote:
>>> Mark Thompson:
On 24/02/2020 17:19, Andreas Rheinhardt wrote:
> Mark Thompson:
>> Unit types are split into three categories, depending on how their
>> content is m
Mark Thompson:
> On 24/02/2020 22:10, Andreas Rheinhardt wrote:
>> Mark Thompson:
>>> On 24/02/2020 17:19, Andreas Rheinhardt wrote:
Mark Thompson:
> Unit types are split into three categories, depending on how their
> content is managed:
> * POD structure - these require no specia
On 24/02/2020 22:10, Andreas Rheinhardt wrote:
> Mark Thompson:
>> On 24/02/2020 17:19, Andreas Rheinhardt wrote:
>>> Mark Thompson:
Unit types are split into three categories, depending on how their
content is managed:
* POD structure - these require no special treatment.
* Str
On 24/02/2020 21:28, Vittorio Giovara wrote:
> On Sun, Feb 23, 2020 at 6:41 PM Mark Thompson wrote:
>
>> ---
>> libavcodec/Makefile | 2 +-
>> libavcodec/cbs_h265.c | 99 +++
>> libavcodec/cbs_h265.h | 18
>> 3 files changed, 118 insertions(+),
Mark Thompson:
> On 24/02/2020 17:19, Andreas Rheinhardt wrote:
>> Mark Thompson:
>>> Unit types are split into three categories, depending on how their
>>> content is managed:
>>> * POD structure - these require no special treatment.
>>> * Structure containing references to refcounted buffers - th
Am 24.02.20 um 22:41 schrieb Lou Logan:
> On Mon, Feb 24, 2020, at 3:37 AM, Anton Khirnov wrote:
>> It fundamentally depends on an API that has been deprecated for five
>> years, has seen no commits since that time and is of highly dubious
>> usefulness.
>> ---
>> doc/filters.texi| 32
On 24/02/2020 17:19, Andreas Rheinhardt wrote:
> Mark Thompson:
>> Unit types are split into three categories, depending on how their
>> content is managed:
>> * POD structure - these require no special treatment.
>> * Structure containing references to refcounted buffers - these can use
>> a com
On Mon, 24 Feb 2020, Nicolas George wrote:
Michael Niedermayer (12020-02-24):
No, they can't: being the same subtitle or not is part of the semantic.
Does anyone else share this oppinion ?
iam asking because we need to resolve such differences of oppinion to
move forward.
Theres no way to
On 24/02/2020 16:07, Andreas Rheinhardt wrote:
> Mark Thompson:
>> From: Andreas Rheinhardt
>>
>> Since c6a63e11092c975b89d824f08682fe31948d3686, the parameter sets
>> modified as content of PPS units were references shared with the
>> CodedBitstreamH264Context, so modifying them alters the parsin
On 24/02/2020 01:57, Andreas Rheinhardt wrote:
> Mark Thompson:
>> ---
>> libavcodec/cbs_h264.c | 47 +++
>> libavcodec/cbs_h264.h | 8
>> 2 files changed, 55 insertions(+)
>>
>> diff --git a/libavcodec/cbs_h264.c b/libavcodec/cbs_h264.c
>> index 7
On 24/02/2020 01:55, Andreas Rheinhardt wrote:
> Mark Thompson:
>> Use the unit type table to determine what we need to do to clone the
>> internals of the unit content when making copies for refcounting or
>> writeability. (This will still fail for units with complex content
>> if they do not hav
On Mon, Feb 24, 2020, at 3:37 AM, Anton Khirnov wrote:
> It fundamentally depends on an API that has been deprecated for five
> years, has seen no commits since that time and is of highly dubious
> usefulness.
> ---
> doc/filters.texi| 32 ---
> libavfilter/Makefile| 1 -
On Sun, Feb 23, 2020 at 6:41 PM Mark Thompson wrote:
> ---
> libavcodec/Makefile | 2 +-
> libavcodec/cbs_h265.c | 99 +++
> libavcodec/cbs_h265.h | 18
> 3 files changed, 118 insertions(+), 1 deletion(-)
> create mode 100644 libavcodec/cbs_h2
On Sat, Feb 22, 2020 at 2:47 AM Clément Bœsch wrote:
>
> On Fri, Feb 14, 2020 at 03:26:30AM +, Soft Works wrote:
> > Hi,
> >
>
> Hi,
>
> > I am looking for some guidance regarding future plans about processing
> > subtitle streams in filter graphs.
> >
> > Please correct me where I'm wrong -
Michael Niedermayer (12020-02-24):
> > No, they can't: being the same subtitle or not is part of the semantic.
> Does anyone else share this oppinion ?
>
> iam asking because we need to resolve such differences of oppinion to
> move forward.
> Theres no way to design an API if such relativly fund
On Mon, Feb 24, 2020 at 12:17:37AM +0100, Nicolas George wrote:
> Marton Balint (12020-02-23):
> > Two overlapping subtitles can be broken into 3 non-overlapping subtitles,
>
> No, they can't: being the same subtitle or not is part of the semantic.
Does anyone else share this oppinion ?
iam aski
On Mon, Feb 24, 2020 at 03:54:45PM +0100, Anton Khirnov wrote:
> Quoting Carl Eugen Hoyos (2020-02-24 13:50:57)
> > Am Mo., 24. Feb. 2020 um 13:40 Uhr schrieb Anton Khirnov
> > :
> > >
> > > It fundamentally depends on an API that has been deprecated for five
> > > years, has seen no commits since
On 2/24/20, Anton Khirnov wrote:
> Quoting Paul B Mahol (2020-02-24 18:07:26)
>> On 2/24/20, Anton Khirnov wrote:
>> > Quoting Paul B Mahol (2020-02-24 17:02:52)
>> >> On 2/24/20, James Almer wrote:
>> >> > On Monday, February 24, 2020, Carl Eugen Hoyos
>> >> > wrote:
>> >> >>
>> >> >>
>> >> >>
On Sat, Feb 22, 2020 at 12:44 PM Mohammad Izadi wrote:
> On Fri, Feb 21, 2020, 6:44 PM Vittorio Giovara >
> wrote:
>
> > On Fri, Feb 21, 2020 at 5:17 PM Mohammad Izadi
> > wrote:
> >
> > > Why does the struct belong to lavu? This struct is super similar to
> > structs
> > > in libavcodec/hevc_s
Quoting Paul B Mahol (2020-02-24 18:07:26)
> On 2/24/20, Anton Khirnov wrote:
> > Quoting Paul B Mahol (2020-02-24 17:02:52)
> >> On 2/24/20, James Almer wrote:
> >> > On Monday, February 24, 2020, Carl Eugen Hoyos
> >> > wrote:
> >> >>
> >> >>
> >> >>
> >> >>> Am 24.02.2020 um 15:54 schrieb Ant
Hi,
>>> please help fill the 2020 GSoC Ideas page
>>> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020
>>>
>>> (This page is key to being acccepted to GSoC)
>>
>> I guess everybody already noticed that FFmpeg had been accepted as a
>> mentoring Org in GSoC 2020! :D
>
> Hi,
>
> Just to s
Mark Thompson:
> Unit types are split into three categories, depending on how their
> content is managed:
> * POD structure - these require no special treatment.
> * Structure containing references to refcounted buffers - these can use
> a common free function when the offsets of all the internal
applied
On 2/24/20, Anamitra Ghorui wrote:
> ---
> libavcodec/Makefile | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 0de585279c..f1c032b456 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -1059,7 +1059,6 @@ OBJS-$(CO
On 2/24/20, Anton Khirnov wrote:
> Quoting Paul B Mahol (2020-02-24 17:02:52)
>> On 2/24/20, James Almer wrote:
>> > On Monday, February 24, 2020, Carl Eugen Hoyos
>> > wrote:
>> >>
>> >>
>> >>
>> >>> Am 24.02.2020 um 15:54 schrieb Anton Khirnov :
>> >>>
>> >>> Quoting Carl Eugen Hoyos (2020-02-
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Paul B Mahol
> Sent: Monday, February 24, 2020 5:39 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp
>
> On 2/24/20, Soft Works wrote:
> >> -
> De : ffmpeg-devel De la part de Hendrik
> Leppkes
> Envoyé : lundi 24 février 2020 17:26
> À : FFmpeg development discussions and patches
> Objet : Re: [FFmpeg-devel] [PATCH] avcodec/mpeg12dec: Do not alter
> avctx->rc_buffer_size
>
> On Mon, Feb 24, 2020 at 5:13 PM Nicolas Gaullier
> wrote
Quoting Paul B Mahol (2020-02-24 13:56:56)
> Filter should not be removed, it should use qp via frame side data.
For what purpose? I am yet to hear about any valid use case for this
filter.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ff
Quoting Soft Works (2020-02-24 17:13:54)
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Anton Khirnov
> > Sent: Monday, February 24, 2020 3:55 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 03/12] lavfi: dro
Quoting Paul B Mahol (2020-02-24 17:02:52)
> On 2/24/20, James Almer wrote:
> > On Monday, February 24, 2020, Carl Eugen Hoyos wrote:
> >>
> >>
> >>
> >>> Am 24.02.2020 um 15:54 schrieb Anton Khirnov :
> >>>
> >>> Quoting Carl Eugen Hoyos (2020-02-24 13:50:57)
> > Am Mo., 24. Feb. 2020 um 13:
On 2/24/20, Soft Works wrote:
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Anton Khirnov
>> Sent: Monday, February 24, 2020 3:55 PM
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp
>>
>> Quo
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Monday, February 24, 2020 3:55 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp
>
> Quoting Carl Eugen Hoyos (2020-02-24 13:50
On Mon, Feb 24, 2020 at 5:13 PM Nicolas Gaullier
wrote:
>
rc_buffer_size doesn't really have a meaning to a decoder (its for
encoders and muxers), so why should it not be able to change it to
match the value it reads from the bitstream?
- Hendrik
___
f
---
libavcodec/mpeg12dec.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 17f9495a1d..2945728edd 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -64,6 +64,7 @@ typedef struct Mpeg1Context {
Mark Thompson:
> From: Andreas Rheinhardt
>
> Since c6a63e11092c975b89d824f08682fe31948d3686, the parameter sets
> modified as content of PPS units were references shared with the
> CodedBitstreamH264Context, so modifying them alters the parsing process
> of future access units which meant that f
On 2/24/20, James Almer wrote:
> On Monday, February 24, 2020, Carl Eugen Hoyos wrote:
>>
>>
>>
>>> Am 24.02.2020 um 15:54 schrieb Anton Khirnov :
>>>
>>> Quoting Carl Eugen Hoyos (2020-02-24 13:50:57)
> Am Mo., 24. Feb. 2020 um 13:40 Uhr schrieb Anton Khirnov <
> an...@khirnov.net>:
>
>>
On Monday, February 24, 2020, Carl Eugen Hoyos wrote:
>
>
>
>> Am 24.02.2020 um 15:54 schrieb Anton Khirnov :
>>
>> Quoting Carl Eugen Hoyos (2020-02-24 13:50:57)
Am Mo., 24. Feb. 2020 um 13:40 Uhr schrieb Anton Khirnov <
an...@khirnov.net>:
It fundamentally depends on an API that h
On Mon, Feb 24, 2020 at 2:02 PM Carl Eugen Hoyos wrote:
>
> Am Mo., 24. Feb. 2020 um 13:39 Uhr schrieb Anton Khirnov :
>
> > we have discussed previously that we want to do a major bump soon.
> > This set starts with some preparations for that. After it, lavu should be
> > ready for the bump.
> >
Em seg., 24 de fev. de 2020 às 05:50, Guo, Yejun escreveu:
>
> Signed-off-by: Guo, Yejun
> ---
> libavfilter/vf_sr.c | 40 ++--
> 1 file changed, 6 insertions(+), 34 deletions(-)
>
> diff --git a/libavfilter/vf_sr.c b/libavfilter/vf_sr.c
> index 562b030..f000e
> Am 24.02.2020 um 15:54 schrieb Anton Khirnov :
>
> Quoting Carl Eugen Hoyos (2020-02-24 13:50:57)
>>> Am Mo., 24. Feb. 2020 um 13:40 Uhr schrieb Anton Khirnov
>>> :
>>>
>>> It fundamentally depends on an API that has been deprecated for five
>>> years, has seen no commits since that time an
---
libavcodec/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 0de585279c..f1c032b456 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1059,7 +1059,6 @@ OBJS-$(CONFIG_MLP_PARSER) += mlp_parse.o
mlp_parser.o mlp
Quoting Carl Eugen Hoyos (2020-02-24 13:50:57)
> Am Mo., 24. Feb. 2020 um 13:40 Uhr schrieb Anton Khirnov :
> >
> > It fundamentally depends on an API that has been deprecated for five
> > years, has seen no commits since that time and is of highly dubious
> > usefulness.
>
> Please explain how th
> 2020年2月24日 下午10:09，tianchi huang 写道：
>
> Hi,
>
> I am interested in taking up a project with FFmpeg for GSOC’20. Specifically,
> I found that the proposal called ‘ABR meets FFmpeg’ is extremely fit for me,
> since:
>
> i) I am proficient in c, c++, js, etc. Especially, I really enjoy sub
Hi,
I am interested in taking up a project with FFmpeg for GSOC’20. Specifically, I
found that the proposal called ‘ABR meets FFmpeg’ is extremely fit for me,
since:
i) I am proficient in c, c++, js, etc. Especially, I really enjoy submitting
my work to and contributing to the open-source com
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Thilo Borgmann
> Sent: Saturday, February 22, 2020 5:50 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] GSoC 2020
>
> Hi,
>
> > please help fill the 2020 GSoC Ideas page
> >
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/mux.c | 19 +--
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/libavformat/mux.c b/libavformat/mux.c
> index 2728c62de5..4089382ffd 100644
> --- a/libavformat/mux.c
> +++ b/libavforma
Anton Khirnov:
> There is no reason whatsoever for it to be public.
> ---
The flac-parser (and maybe other code) uses it directly.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsub
Am Mo., 24. Feb. 2020 um 13:39 Uhr schrieb Anton Khirnov :
> we have discussed previously that we want to do a major bump soon.
> This set starts with some preparations for that. After it, lavu should be
> ready for the bump.
>
> Please comment
I don't think the set is acceptable.
Carl Eugen
___
Filter should not be removed, it should use qp via frame side data.
On 2/24/20, Anton Khirnov wrote:
> It fundamentally depends on an API that has been deprecated for five
> years, has seen no commits since that time and is of highly dubious
> usefulness.
> ---
> doc/filters.texi| 3
Am Mo., 24. Feb. 2020 um 13:40 Uhr schrieb Anton Khirnov :
>
> It fundamentally depends on an API that has been deprecated for five
> years, has seen no commits since that time and is of highly dubious
> usefulness.
Please explain how the removed functionality was replaced.
Carl Eugen
___
---
libavutil/hash.c| 2 ++
libavutil/hash.h| 1 +
libavutil/murmur3.c | 2 ++
libavutil/murmur3.h | 1 +
libavutil/ripemd.c | 1 +
libavutil/ripemd.h | 1 +
6 files changed, 8 insertions(+)
diff --git a/libavutil/hash.c b/libavutil/hash.c
index 75edb6db78..d626c31181 100644
--- a/libav
Inline public functions should be avoided unless absolutely necessary,
and no such necessity exists in this code.
---
libavutil/fifo.c | 13 +
libavutil/fifo.h | 5 +
2 files changed, 18 insertions(+)
diff --git a/libavutil/fifo.c b/libavutil/fifo.c
index 1060aedf13..0baaadc521 1
This API has been deprecated for five years and is of highly dubious
usefulness.
---
libavcodec/h263dec.c | 2 --
libavcodec/mpeg12dec.c | 2 --
libavcodec/mpegvideo.c | 12
libavcodec/mpegvideo.h | 2 --
libavcodec/rv10.c | 2 --
libavcodec/rv34.c | 2 --
6 files cha
This API has been deprecated for five years and is of highly dubious
usefulness.
---
libavcodec/mjpegdec.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index d5e7c21610..c535fd0fff 100644
--- a/libavcodec/mjpegdec.c
It fundamentally depends on an API that has been deprecated for five
years, has seen no commits since that time and is of highly dubious
usefulness.
---
doc/filters.texi| 32 ---
libavfilter/Makefile| 1 -
libavfilter/allfilters.c| 1 -
libavfilter/vf_qp.c
This API has been deprecated for five years.
---
doc/filters.texi | 7 +--
libavfilter/vf_spp.c | 100 +++
libavfilter/vf_spp.h | 3 --
3 files changed, 26 insertions(+), 84 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 3b1470e
This API has been deprecated for five years.
---
doc/filters.texi | 6 --
libavfilter/vf_fspp.c | 129 ++
libavfilter/vf_fspp.h | 3 -
3 files changed, 30 insertions(+), 108 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 43e52f
This API has been deprecated for five years.
---
doc/filters.texi | 3 +-
libavfilter/vf_uspp.c | 94 +--
2 files changed, 19 insertions(+), 78 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 5fa1663426..4d17330df5 100644
--- a/doc
This API has been deprecated for five years.
---
libavfilter/vf_pp.c | 8 ++--
tests/fate/filter-video.mak | 3 +--
tests/ref/fate/filter-pp| 10 --
3 files changed, 3 insertions(+), 18 deletions(-)
delete mode 100644 tests/ref/fate/filter-pp
diff --git a/libavfilter/vf
This API has been deprecated for five years.
---
doc/filters.texi | 3 +--
libavfilter/vf_pp7.c | 34 ++
2 files changed, 11 insertions(+), 26 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 59571a7022..3b1470ed0f 100644
--- a/doc/filters.t
Hi,
we have discussed previously that we want to do a major bump soon. This
set starts with some preparations for that. After it, lavu should be
ready for the bump.
Please comment
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
h
There is no reason whatsoever for it to be public.
---
libavutil/fifo.c | 9 +
libavutil/fifo.h | 8 ++--
libavutil/tests/fifo.c | 2 +-
libavutil/version.h| 3 +++
4 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/libavutil/fifo.c b/libavutil/fifo.c
index
It depends on API that has been deprecated for five years and is of
highly dubious usefulness.
---
doc/filters.texi | 3 ---
libavfilter/vf_codecview.c | 26 --
2 files changed, 29 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 2a1235183f..4
lgtm
On 2/22/20, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes:
> 20763/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_fuzzer-5759562508664832
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: M
Am 23.02.20 um 21:40 schrieb Josh de Kock:
> On Sun, Feb 23, 2020, at 4:07 PM, Thilo Borgmann wrote:
>> [...]
>>
>> How is it automatically generated?
>
> I wrote a small script to parse author names/emails and group
> emails together based on names. In the future, additions should
> be added manu
Am Mo., 24. Feb. 2020 um 02:09 Uhr schrieb Mark Thompson :
>
> On 24/02/2020 00:37, Carl Eugen Hoyos wrote:
> > Am Mo., 24. Feb. 2020 um 01:25 Uhr schrieb Mark Thompson :
> >
> >> We seem to have agreement that the Y210 / wider YUYV is fine
> >
> > Why do you think so?
> > I was under the impressio
Fixes #7190
Signed-off-by: Paul B Mahol
---
doc/filters.texi| 22
libavfilter/vf_program_opencl.c | 64 ++---
2 files changed, 65 insertions(+), 21 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 70fd7a4cc7..6b10f649b9
Quoting James Almer (2020-02-20 17:26:00)
> Signed-off-by: James Almer
Commit message is now misleading since it will only enable prft if it's
not disabled.
> ---
> Now it can be overriden if you explicitly set write_prft to 0.
>
> libavformat/dashenc.c | 8 +++-
> 1 file changed, 7 inserti
Signed-off-by: Guo, Yejun
---
libavfilter/vf_dnn_processing.c | 81 +++--
1 file changed, 61 insertions(+), 20 deletions(-)
diff --git a/libavfilter/vf_dnn_processing.c b/libavfilter/vf_dnn_processing.c
index 492df93..4d0ee78 100644
--- a/libavfilter/vf_dnn_pr
The Y channel is handled by dnn, and also resized by dnn. The UV channels
are resized with swscale.
The command to use espcn.pb (see vf_sr) looks like:
./ffmpeg -i 480p.jpg -vf
format=yuv420p,dnn_processing=dnn_backend=tensorflow:model=espcn.pb:input=x:output=y
-y tmp.espcn.jpg
Signed-off-by: G
Only the Y channel is handled by dnn, the UV channels are copied
without changes.
The command to use srcnn.pb (see vf_sr) looks like:
./ffmpeg -i 480p.jpg -vf
format=yuv420p,scale=w=iw*2:h=ih*2,dnn_processing=dnn_backend=tensorflow:model=srcnn.pb:input=x:output=y
-y srcnn.jpg
Signed-off-by: Guo
Signed-off-by: Guo, Yejun
---
libavfilter/vf_sr.c | 40 ++--
1 file changed, 6 insertions(+), 34 deletions(-)
diff --git a/libavfilter/vf_sr.c b/libavfilter/vf_sr.c
index 562b030..f000eda 100644
--- a/libavfilter/vf_sr.c
+++ b/libavfilter/vf_sr.c
@@ -176,40 +1
80 matches
Mail list logo
