AV1 decoder is supported on Tiger Lake+ platforms since libmfx 1.34
Signed-off-by: Haihao Xiang
---
Changelog | 1 +
configure | 1 +
libavcodec/allcodecs.c| 1 +
libavcodec/qsv.c | 4
libavcodec/qsvdec_other.c | 31 ++
Signed-off-by: Zane van Iperen
---
libavcodec/adpcm.c | 86 +++---
1 file changed, 43 insertions(+), 43 deletions(-)
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index 14be1f4f88..4755308824 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
Signed-off-by: Zane van Iperen
---
libavformat/argo_asf.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
index b1632f3ba5..deb64f7b1c 100644
--- a/libavformat/argo_asf.c
+++ b/libavformat/argo_asf.c
@@ -26
Increases decode speed significantly.
Signed-off-by: Zane van Iperen
---
libavcodec/adpcm.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index e409a3aa6a..14be1f4f88 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/a
Signed-off-by: Zane van Iperen
---
libavformat/argo_brp.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/libavformat/argo_brp.c b/libavformat/argo_brp.c
index 122f616ecc..4716ad85eb 100644
--- a/libavformat/argo_brp.c
+++ b/libavformat/argo_brp.c
@@ -86,7 +86,
For the argo_brp demuxer.
Signed-off-by: Zane van Iperen
---
libavformat/argo_asf.c | 50 ++
libavformat/argo_asf.h | 2 ++
2 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
index deb64f7b1c..
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Haihao Xiang
> Sent: Wednesday, September 16, 2020 8:45 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Haihao Xiang
> Subject: [FFmpeg-devel] [PATCH 0/6] qsv: Fix compiler errors when using
> libmfx 2.0 (oneVPL)
>
> The oneAPI Video Proce
On Wed, 2020-09-16 at 08:12 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Haihao Xiang
> > Sent: Wednesday, September 16, 2020 8:45 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Haihao Xiang
> > Subject: [FFmpeg-devel] [PATCH 0/6] qsv: Fix compiler e
Dear FFMPEG Team,
I am developing SW with C# .NET for video processing purposes, and I would
like to know information about the existing nuget packages related with FFPMEG.
I found the FFMEG.Nightly package, but I am not able to find documentation
about it. I would like to know which classes
On Mon, Sep 14, 2020 at 07:27:31AM +0200, Andreas Rheinhardt wrote:
> The decoder's close function simply presumed that some AVFrames have
> been successfully allocated although this can of course fail.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Once could btw return immediately as soon as one
On Mon, Sep 14, 2020 at 07:27:35AM +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/c93.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
ffmpeg.zeranoe.com will close on Sep 18, 2020
Last published builds are from Aug 31 2020.
---
src/download | 6 --
1 file changed, 6 deletions(-)
diff --git a/src/download b/src/download
index 02e2fe7..34fa093 100644
--- a/src/download
+++ b/src/download
@@ -79,9 +79,6 @@
Window
---
src/download | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/download b/src/download
index 34fa093..cc427a5 100644
--- a/src/download
+++ b/src/download
@@ -79,6 +79,9 @@
Windows EXE Files
+ https://www.gyan.dev/ffmpeg/builds/";>
+
On Wed, Sep 16, 2020 at 07:39:21AM +, Zane van Iperen wrote:
> For the argo_brp demuxer.
>
> Signed-off-by: Zane van Iperen
> ---
> libavformat/argo_asf.c | 50 ++
> libavformat/argo_asf.h | 2 ++
> 2 files changed, 28 insertions(+), 24 deletions(-)
>
On Tue, Sep 15, 2020 at 11:07:30PM +0200, Michael Niedermayer wrote:
> This should help fuzzer coverage
>
> The sample file can be generated by
> dd
> if=samples/audible/2004FirstPresidentialDebateBushvs.Kerry93004_acelp85_maihde.aa
> of=bush.aa count=110
>
> Signed-off-by: Michael Niedermayer
From: Xu Jun
Before patch, memory was allocated in each thread functions,
which may cause more than one time of memory allocation and
cause crash.
After patch, memory is allocated in the main thread once,
an index was parsed into thread functions. Bug fixed.
Signed-off-by: Xu Jun
---
v3: fix b
From: Xu Jun
Move thread area allocate out of thread function into
main thread.
Signed-off-by: Xu Jun
---
.../dnn/dnn_backend_native_layer_conv2d.c | 30 +--
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/libavfilter/dnn/dnn_backend_native_layer_conv2d.c
b
On Wed, Sep 16, 2020 at 12:24 AM Michael Niedermayer
wrote:
>
> On Mon, Sep 14, 2020 at 12:33:14AM +0300, Jan Ekström wrote:
> > - For video, this means a single initialization point in do_video_out.
> > - For audio we unfortunately need to do it in two places just
> > before the buffer sink is
On Wed, 16 Sep 2020 11:26:55 +0200
"Paul B Mahol" wrote:
> > +pkt->stream_index = st->index;
> > +pkt->duration = ckhdr->num_samples * (ret /
> > st->codecpar->block_align);
> > +*blocks_read += (ret / st->codecpar->block_align);
>
> This line breaks seeking.
>
> Ulti
Gyan Doshi 于2020年9月16日周三 下午5:24写道：
>
> ffmpeg.zeranoe.com will close on Sep 18, 2020
>
> Last published builds are from Aug 31 2020.
> ---
> src/download | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/src/download b/src/download
> index 02e2fe7..34fa093 100644
> --- a/src/download
The ffmpeg project does not provide any bindings for other languages
that can't interact with a C API on their own.
You will have to find and talk to the author of that wrapper.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/ma
On 11/09/2020 22:51, Kieran Kunhya wrote:
Because when you have a WebRTC server/service, you need WebRTC ingest.
You may be surprised by the amount of mixed RTC/streaming services that
are being implemented as we speak since COVID.
Why is that the case?
Mainly because if you already have WebR
---
src/download | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/download b/src/download
index 706d402..0f090b8 100644
--- a/src/download
+++ b/src/download
@@ -79,6 +79,9 @@
Windows EXE Files
+ https://github.com/BtbN/FFmpeg-Builds/releases";>
There is a great wrapper for invoking FFmpeg in .NET available here
https://github.com/tomaszzmuda/Xabe.FFmpeg/ however it does not support
calling the C API directly. I am not aware of any tools or libraries that
have this functionality.
Thanks
Tom
On Wed, 16 Sep 2020 at 12:06, Timo Rothenpieler
Is there a known alternative for windows which provides the same features
of Zeranoe? If not I would be interested in setting something up but I'm
having trouble building all the external libs for windows. If anyone has
any tips or guidance please let me know.
Thanks
Tom
On Wed, 16 Sep 2020 at 11
On 9/16/2020 10:00 AM, Tom Needham wrote:
> Is there a known alternative for windows which provides the same features
> of Zeranoe? If not I would be interested in setting something up but I'm
> having trouble building all the external libs for windows. If anyone has
> any tips or guidance please l
On Wed, Sep 16, 2020 at 2:16 PM Timo Rothenpieler wrote:
>
> ---
> src/download | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/download b/src/download
> index 706d402..0f090b8 100644
> --- a/src/download
> +++ b/src/download
> @@ -79,6 +79,9 @@
> Windows EXE Files
>
Jan Ekström (12020-09-16):
> This value - while it looks like the actual range of the content -
> is nothing but the internal value of swscale.
>
> Thus, if we have RGB content, force the value to 1. Swscale will
> ignore it, but at least the value of the output AVFrame will now
> properly be "ful
On Tue, Sep 15, 2020 at 01:35:25PM +0200, Paul B Mahol wrote:
> This removes big CPU overhead for demuxing chained ogg streams.
>
> Signed-off-by: Paul B Mahol
> ---
> libavformat/aviobuf.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/aviobuf.c b/lib
On Mon, Sep 14, 2020 at 07:27:45AM +0200, Andreas Rheinhardt wrote:
> The FFV1 encoder has so far not cleaned up after itself in this case;
> but it can be done easily by setting the FF_CODEC_CAP_INIT_CLEANUP flag.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/ffv1enc.c | 1 +
> 1 fil
On Mon, Sep 14, 2020 at 07:27:46AM +0200, Andreas Rheinhardt wrote:
> Now that ff_ffv1_close() for both the FFV1 encoder and decoder,
> the code contained therein can be used to free the partially allocated
> slice contexts if allocating the slice contexts failed. One just has to
> set the correct
On Mon, Sep 14, 2020 at 07:27:44AM +0200, Andreas Rheinhardt wrote:
> When allocating FFV1 slice contexts fails, ff_ffv1_init_slice_contexts()
> frees everything that it has allocated, yet it does not reset the
> counter for the number of allocated slice contexts. This inconsistent
> state leads to
On Mon, Sep 14, 2020 at 09:26:53PM +0200, Nicolas George wrote:
> Filters mostly work in native endianness, but they must output
> a specified endianness, usually little: that requires a final
> conversion for big endian.
>
> I do not know what's the deal with gif-deal: inserting explicitly
Michael Niedermayer:
> On Mon, Sep 14, 2020 at 09:26:53PM +0200, Nicolas George wrote:
>> Filters mostly work in native endianness, but they must output
>> a specified endianness, usually little: that requires a final
>> conversion for big endian.
>>
>> I do not know what's the deal with gif-deal:
This removes big CPU overhead for demuxing chained ogg streams.
Signed-off-by: Paul B Mahol
---
libavformat/aviobuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index a77517d712..c27d564602 100644
--- a/libavformat/aviobuf.c
Paul B Mahol:
> This removes big CPU overhead for demuxing chained ogg streams.
>
> Signed-off-by: Paul B Mahol
> ---
> libavformat/aviobuf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index a77517d712..c27d564602 100
This removes big CPU overhead for demuxing chained ogg streams.
Signed-off-by: Paul B Mahol
---
libavformat/aviobuf.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index a77517d712..88cc0b4030 100644
--- a/libavformat/aviobuf.c
+++ b/libavform
Paul B Mahol:
> This removes big CPU overhead for demuxing chained ogg streams.
>
> Signed-off-by: Paul B Mahol
> ---
> libavformat/aviobuf.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index a77517d712..88cc0b4030 100644
> --- a/lib
This value - while it looks like the actual range of the content -
is nothing but the internal value of swscale.
Thus, if we have RGB content, force the value to 1. Swscale will
ignore it, but at least the value of the output AVFrame will now
properly be "full range" instead of "limited range", as
On Wed, Sep 16, 2020 at 12:16:43AM +0300, Jan Ekström wrote:
> This value - while it looks like the actual range of the content -
> is nothing but the internal value of swscale.
>
> Thus, if we have RGB content, force the value to 1. Swscale will
> ignore it, but at least the value of the output A
On Wed, Sep 16, 2020 at 11:38 PM Michael Niedermayer
wrote:
>
> On Wed, Sep 16, 2020 at 12:16:43AM +0300, Jan Ekström wrote:
> > This value - while it looks like the actual range of the content -
> > is nothing but the internal value of swscale.
> >
> > Thus, if we have RGB content, force the valu
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Xiang, Haihao
> Sent: Wednesday, September 16, 2020 10:30 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 0/6] qsv: Fix compiler errors when using
> libmfx 2.0 (oneVPL)
>
> On Wed, 2020-09-16 at 08:12 +,
This removes big CPU overhead for demuxing chained ogg streams.
Signed-off-by: Paul B Mahol
---
libavformat/aviobuf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index a77517d712..9dfef2377e 100644
--- a/libavformat/aviobu
Great. I'll use that in the future.
Thanks Tom
On Wed, 16 Sep 2020, 14:27 James Almer, wrote:
> On 9/16/2020 10:00 AM, Tom Needham wrote:
> > Is there a known alternative for windows which provides the same features
> > of Zeranoe? If not I would be interested in setting something up but I'm
>
On Wed Sep 16 12:23:52 EEST 2020 Gyan wrote:
> ffmpeg.zeranoe.com will close on Sep 18, 2020
>
> Last published builds are from Aug 31 2020.
> ---
> src/download | 6 --
> 1 file changed, 6 deletions(-)
Patchset pushed. Thanks.
___
ffmpeg-devel ma
On Mon, Sep 14, 2020 at 10:49 AM Thierry Foucu wrote:
> In case the pb does not contain 4 bytes, the buf[256] will not be
> initialize before we pass it to ff_codec_get_id
> ---
> libavformat/rmdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/rmdec.c b/l
On Sat, Sep 12, 2020 at 11:28:33AM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/luodatdec.c | 129 +++
> 3 files changed, 131 insertions(+)
> create mode 1
Paul B Mahol:
> On Sat, Sep 12, 2020 at 11:28:33AM +0200, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol
>> ---
>> libavformat/Makefile | 1 +
>> libavformat/allformats.c | 1 +
>> libavformat/luodatdec.c | 129 +++
>> 3 files changed, 131 insertio
On Mon, Sep 14, 2020 at 12:11:02AM +0200, Michael Niedermayer wrote:
> Fixes: Timeout (1101sec -> 0.4sec)
> Fixes:
> 24491/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-5725337036783616
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/mast
On Wed, Sep 16, 2020 at 11:44:01PM +0200, Andreas Rheinhardt wrote:
> Paul B Mahol:
> > On Sat, Sep 12, 2020 at 11:28:33AM +0200, Paul B Mahol wrote:
> >> Signed-off-by: Paul B Mahol
> >> ---
> >> libavformat/Makefile | 1 +
> >> libavformat/allformats.c | 1 +
> >> libavformat/luodatdec.
On Wed, Sep 16, 2020 at 01:15:34PM +0200, Timo Rothenpieler wrote:
> ---
> src/download | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/download b/src/download
> index 706d402..0f090b8 100644
> --- a/src/download
> +++ b/src/download
> @@ -79,6 +79,9 @@
> Windows EXE
The AV1 decoder has the FF_CODEC_CAP_INIT_CLEANUP flag set and yet
the decoder's close function is called manually on some error paths.
This is unnecessary and has been removed in this commit.
Signed-off-by: Andreas Rheinhardt
---
Unchanged since last time.
libavcodec/av1dec.c | 4 +---
1 file
Up until now, the AV1 decoder always checks before calling its wrapper
around ff_thread_release_buffer() whether the ThreadFrame was used at
all, i.e. it checked whether the first data buffer of the AVFrame
contained therein is NULL or not. Yet this presumes that the AVFrame has
been successfully a
This is a partial revert of f2ad6238e4c0e99e2fc131ee14c586e87b045680
It fixes per-frame color_trc signaling of arib-std-b67 frames.
Reproducible with:
ffprobe -show_frames lg_4k_hlg.ts | grep color_transfer=
---
libavcodec/hevcdec.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavc
On 9/15/20 9:24 PM, James Almer wrote:
On 9/15/2020 10:57 PM, Pavel Koshevoy wrote:
that should be color_transfer=arib-std-b67
Would anyone object if I restored previous behavior? I'd prefer avoid
reimplementing SEI parsing outside of libav just to get the correct
per-frame color_trc...
On 9/16/2020 9:08 PM, Andreas Rheinhardt wrote:
> The AV1 decoder has the FF_CODEC_CAP_INIT_CLEANUP flag set and yet
> the decoder's close function is called manually on some error paths.
> This is unnecessary and has been removed in this commit.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Unch
export_stream_params() may not be called in some scenarios, for example leaving
both the AVCodecContext and subsequent output frames with the color_trc value
taken from the VUI instead of the Alternative Transfer Characteristics SEI.
Signed-off-by: James Almer
---
libavcodec/hevcdec.c | 27 +
On 9/16/2020 9:14 PM, Pavel Koshevoy wrote:
> This is a partial revert of f2ad6238e4c0e99e2fc131ee14c586e87b045680
> It fixes per-frame color_trc signaling of arib-std-b67 frames.
>
> Reproducible with:
> ffprobe -show_frames lg_4k_hlg.ts | grep color_transfer=
> ---
> libavcodec/hevcdec.c | 6 ++
On 9/16/2020 9:08 PM, Andreas Rheinhardt wrote:
> Up until now, the AV1 decoder always checks before calling its wrapper
> around ff_thread_release_buffer() whether the ThreadFrame was used at
> all, i.e. it checked whether the first data buffer of the AVFrame
> contained therein is NULL or not. Ye
On Wed, 2020-09-16 at 20:44 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Xiang, Haihao
> > Sent: Wednesday, September 16, 2020 10:30 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH 0/6] qsv: Fix compiler errors when using
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> xuju...@sjtu.edu.cn
> Sent: 2020年9月16日 18:07
> To: ffmpeg-devel@ffmpeg.org
> Cc: xuju...@sjtu.edu.cn
> Subject: [FFmpeg-devel] [PATCH v3 2/2] dnn_backend_native_layer_conv2d.c:
> refine code.
>
> From: Xu Jun
>
> Move thread are
Tiles have a size field with a length from one to four bytes. As such it
is not possible to read it all at once with a call to get_bits() as this
only allows to read up to 25 bits; this is guarded by an av_assert2. Yet
this is done by the AV1 decoder in get_tiles_info(). It has been done
despite sa
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/ffwavesynth.c | 14 --
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/libavcodec/ffwavesynth.c b/libavcodec/ffwavesynth.c
> index d92bb38c45..c99bac90ea 100644
> --- a/libavcodec/ffwavesyn
On Wed, 16. Sep 18:14, Pavel Koshevoy wrote:
> This is a partial revert of f2ad6238e4c0e99e2fc131ee14c586e87b045680
> It fixes per-frame color_trc signaling of arib-std-b67 frames.
>
> Reproducible with:
> ffprobe -show_frames lg_4k_hlg.ts | grep color_transfer=
> ---
> libavcodec/hevcdec.c | 6 +
On 9/17/2020 12:19 AM, Andreas Rheinhardt wrote:
> Tiles have a size field with a length from one to four bytes. As such it
> is not possible to read it all at once with a call to get_bits() as this
> only allows to read up to 25 bits; this is guarded by an av_assert2. Yet
> this is done by the AV1
65 matches
Mail list logo
