> -Original Message-
> From: ffmpeg-devel On Behalf Of Ting
> Fu
> Sent: Sunday, January 19, 2020 11:51 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH V8 2/2] libswscale/x86/yuv2rgb: add ssse3
> version
>
> Tested using this command:
> /ffmpeg -pix_fmt yuv420p -s 1920
Does this pass fate?
If yes i will apply.
On 2/10/20, Fu, Ting wrote:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of Ting
>> Fu
>> Sent: Sunday, January 19, 2020 11:51 AM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: [FFmpeg-devel] [PATCH V8 2/2] libswscale/x86/yuv2rgb: add ss
Currently, ffmpeg inserts scale filter by default in the filter graph
to force the whole decoded stream to scale into the same size with the
first frame. It's not quite make sense in resolution changing cases if
user wants the rawvideo without any scale.
Using autoscale/noautoscale as an output op
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Mark Thompson
> Sent: Saturday, February 1, 2020 22:18
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: add -autoscale
> to disable/enable the default scale
>
> On 15/01/2020 07:05, Linjie F
Hi,
FFmpeg has been accepted again for CLT 2020 in Chemnitz, Germany!
This "Chemnitzer Linux Tage" will take place on 14th and 15th of March.
You can find more details on their homepage:
https://chemnitzer.linux-tage.de/2020/en/
We will man a booth with our staff and are happily waiting for
our
> -Original Message-
> From: ffmpeg-devel On Behalf Of Paul
> B Mahol
> Sent: Monday, February 10, 2020 04:56 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V8 2/2] libswscale/x86/yuv2rgb: add
> ssse3 version
>
> Does this pas
Signed-off-by: Paul B Mahol
---
configure | 1 +
doc/filters.texi| 77 +++
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/opencl/pad.cl | 36
libavfilter/opencl_source.h | 1 +
libavfilter/vf_pad_opencl.c | 397
Commit message summaries like "fix bug [$whatever external identifier]
are evil and should not be accepted IMO. They provide zero useful
information to someone reading the mailing list subjects or git
shortlog.
The commit message summary should be understandable on its own, without
reading the who
On Mon, Feb 10, 2020 at 5:38 PM Anton Khirnov wrote:
>
> Commit message summaries like "fix bug [$whatever external identifier]
> are evil and should not be accepted IMO. They provide zero useful
> information to someone reading the mailing list subjects or git
> shortlog.
>
> The commit message s
> -Original Message-
> From: Sun, Xinpeng
> Sent: Friday, January 17, 2020 11:57 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Sun, Xinpeng
> Subject: [PATCH] avfilter/tonemap_vaapi: pass filter parameters to VA
> parameter buffer
>
> Signed-off-by: Xinpeng Sun
> ---
> libavfilter/vf_tonemap
wtvfile_read_packet did not abide by the requirements of an
AVIOContext's read_packet-function: If it did not read anything,
it returned zero, which currently leads to a warning in read_packet_wrapper
in aviobuf.c. Said warning will be an av_assert2 as soon as
FF_API_OLD_AVIO_EOF_0 is zero (probabl
The WTV demuxer uses a custom AVIOContext internally (complete with own
seeking and read_packet-functions). And opening one of these entailed
several allocations, including the AVIOContext as well as its opaque.
Yet there is no need to allocate these separately on the heap: For those
AVIOContexts
In order for rate control to correctly allocate bitrate to each temporal
layer, correct temporal layer id has to be set to each frame. This
commit provides the ability to set correct temporal layer id for each
frame.
---
doc/encoders.texi | 9 -
libavcodec/libvpxenc.c | 13 ++
Add an initial mvs flag to is, analog to the export_mvs flags2 one.
Signed-off-by: James Almer
---
libavcodec/avcodec.h | 18 ++
libavcodec/mpegpicture.c | 2 +-
libavcodec/mpegutils.c | 2 +-
libavcodec/options_table.h | 2 +
Signed-off-by: James Almer
---
libavcodec/libx264.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index ca8f6c0873..a08fe0ce76 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -322,7 +322,9 @@ static int X264_fram
Signed-off-by: James Almer
---
libavcodec/avcodec.h | 8 +++-
libavcodec/options_table.h | 1 +
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 1280a7ffe2..7a40fa12b5 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcod
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_cas.c | 253 +++
3 files changed, 255 insertions(+)
create mode 100644 libavfilter/vf_cas.c
diff --git a/libavfilter/Makefile b/libavfilter/
On Sun, Feb 9, 2020 at 8:31 AM Mark Thompson wrote:
> On 07/02/2020 17:46, Mohammad Izadi wrote:
> > From: Mohammad Izadi
> >
> > Trying to read HDR10+ metadata from HEVC/SEI and pass it to packet side
> data in the follow-up CLs.
> > ---
> > libavutil/hdr_dynamic_metadata.c | 165 +
From: Mohammad Izadi
Trying to read HDR10+ metadata from HEVC/SEI and pass it to packet side data in
the follow-up CLs.
---
libavutil/hdr_dynamic_metadata.c | 165 +++
libavutil/hdr_dynamic_metadata.h | 13 ++-
libavutil/version.h | 2 +-
3 files chan
Up until e7ddafd5, the Matroska muxer wrote two SeekHeads: One at the
beginning referencing the main level 1 elements (i.e. not the Clusters)
and one at the end, referencing the Clusters. This second SeekHead was
useless and has therefore been removed. Yet the SeekHead-related
functions and structu
matroskaenc.c currently only allows BlockMore elements if the BlockAddID is
1. Recently YouTube has been using BlockAddID == 4 for HDR10+ dynamic
metadata (see [1]), which FFmpeg drops because of its filtering.
The attached patch changes matroskaenc.c so it stops filtering
by BlockAddID, allowing
On Wed, 5 Feb 2020, Martin Storsjö wrote:
The delay is normally zero when the level limiter is disabled,
but if enabled, there's a small delay.
---
libavcodec/libfdk-aacdec.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/libfdk-aacdec.c b/libavcodec/libfdk-aacdec.c
index
On Mon, Feb 10, 2020 at 10:30 AM Wonkap Jang
wrote:
>
> In order for rate control to correctly allocate bitrate to each temporal
> layer, correct temporal layer id has to be set to each frame. This
> commit provides the ability to set correct temporal layer id for each
> frame.
> ---
> doc/encode
On Mon, Feb 10, 2020 at 9:54 PM Michael Bradshaw <
mjbshaw-at-google@ffmpeg.org> wrote:
> matroskaenc.c currently only allows BlockMore elements if the BlockAddID is
> 1. Recently YouTube has been using BlockAddID == 4 for HDR10+ dynamic
> metadata (see [1]), which FFmpeg drops because of its
On Mon, Feb 10, 2020 at 03:26:44PM -0300, James Almer wrote:
> Add an initial mvs flag to is, analog to the export_mvs flags2 one.
>
> Signed-off-by: James Almer
> ---
> libavcodec/avcodec.h | 18 ++
> libavcodec/mpegpicture.c | 2 +-
> libavcodec/mpe
On Sun, Feb 09, 2020 at 08:40:08PM +0100, Nicolas George wrote:
> Michael Niedermayer (12020-02-09):
> > any objections ?
> > if not i will push this in a few days
>
> Please fix the spelling mistake in the commit message:
>
> To loose = to set free.
> To lose = to not have it anymore accidentall
On 2/10/2020 7:14 PM, Michael Niedermayer wrote:
> On Mon, Feb 10, 2020 at 03:26:44PM -0300, James Almer wrote:
>> Add an initial mvs flag to is, analog to the export_mvs flags2 one.
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/avcodec.h | 18 ++
>> libavc
On Sun, Feb 09, 2020 at 10:56:03PM +0100, Paul B Mahol wrote:
> lgtm
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vl
On Tue, 7 Jan 2020, Andreas Rheinhardt wrote:
The AVPacket destined for a demuxer's output has already been
initialized before it reaches the demuxer.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mpjpegdec.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavform
On Sun, 9 Feb 2020, Marton Balint wrote:
On Sun, 9 Feb 2020, Andreas Rheinhardt wrote:
On Tue, Jan 21, 2020 at 9:51 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
On Mon, Jan 13, 2020 at 4:45 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
On Tue, Jan 7, 2020
Hi!
Attached patch probably fixes ticket #8518 and definitely simplifies
*ac3* encoding usage.
Please comment, Carl Eugen
From 6ddde8224f48e9a0648018934ff12961c5d30892 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 11 Feb 2020 00:20:52 +0100
Subject: [PATCH] lavc: Use supported_sampl
On Thu, Feb 6, 2020 at 3:38 PM Michael Niedermayer wrote:
> On Thu, Jan 30, 2020 at 11:23:07AM -0800, Dale Curtis wrote:
> > On Wed, Jan 29, 2020 at 10:23 PM Michael Niedermayer
>
> > wrote:
> >
> > > so i think it works but maybe ive missed something, for which values
> > > of e2_pts do you see
Hi
Ffmpeg libx264 encoder calculates roi for each frame with roi side data,
which is inefficient since roi regions are the same for most frames.
Is it possible to save these calculations?
Thanks
Zhipeng
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.
> -Original Message-
> From: ffmpeg-devel On Behalf Of Fu,
> Ting
> Sent: Monday, February 10, 2020 05:54 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V8 2/2] libswscale/x86/yuv2rgb: add
> ssse3 version
>
>
>
> > -Orig
> From: zhipenggong(龚志鹏) [mailto:zhipengg...@tencent.com]
> Sent: Tuesday, February 11, 2020 10:58 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Guo, Yejun
> Subject: libx264 roi calculation is inefficient
>
> Hi
>
> Ffmpeg libx264 encoder calculates roi for each frame with roi side data,
> which is
35 matches
Mail list logo
