Ping for the patchset. Is there any comment on adding this auto hwmap filter?
Thanks,
Tong
> -Original Message-
> From: Wu, Tong1
> Sent: Monday, July 4, 2022 4:10 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Wu, Tong1
> Subject: [PATCH v4 5/5] lavfi/format: add a hwmap auto conversion filter
On Thu, 2022-07-14 at 03:56 +, Xiang, Haihao wrote:
> On Tue, 2022-06-14 at 09:23 +0800, Fei Wang wrote:
> > From: Xu Guangxin
> >
> > We will generate a new frame for a missed reference. The frame can
> > only
> > be used for reference. We assign an invalid decode sequence to it,
> > so
> >
From: Xu Guangxin
Even resolution or number of picture stores changes, we still need
follow no_output_of_prior_pics_flag in next IDR.
Tested-by: Fei Wang
Signed-off-by: Xu Guangxin
---
libavcodec/hevcdec.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavc
From: Xu Guangxin
suppose
a. You have 3 frames, 0, 1, 4096.
b. The ltMask is 0xfff and use_msb is 0.
c. The 0, 1 are lt refs for 4096.
d. you are decoding frame 4096, and get the 0 frame.
Since 4096 & ltMask is 0 too, even you want get 0, find_ref_idx may give you
4096.
add_candidate_ref will re
From: Xu Guangxin
We will generate a new frame for a missed reference. The frame can only
be used for reference. We assign an invalid decode sequence to it, so
it will not be involved in any dpb process.
Tested-by: Fei Wang
Signed-off-by: Fei Wang
Signed-off-by: Xu Guangxin
---
libavcodec/he
From: Xu Guangxin
According to C.5.2.2, item 2. When we got an IRAP, and the
NoOutputOfPriorPicsFlag = 0, we need bump all outputable frames.
Tested-by: Fei Wang
Signed-off-by: Xu Guangxin
---
update:
1. clean and replace 0xff with HEVC_SEQUENCE_COUNTER_MASK
libavcodec/hevc_refs.c | 23 +
Any thoughts on my previous reply?
On Mon, 4 Jul 2022 at 23:33, Steven Hartland
wrote:
> I'm not sure we're on the same page, so let me try and clarify.
>
> The files have multiple tracks, the standard audio and video and 3
> metadata tracks. I'm using the command line option -map
> 0:m:handler_
The AArch64 assembly accesses those symbols directly, without
indirection via e.g. the GOT on ELF. In order for this not to
require text relocations, those symbols need to be resolved fully
at link time, i.e. those symbols can't be interposable.
Normally, so far, this is achieved when linking shar
On Thu, 14 Jul 2022, Michael Niedermayer wrote:
On Thu, Jul 14, 2022 at 12:14:38AM +0300, Martin Storsjö wrote:
The AArch64 assembly accesses those symbols directly, without
indirection via e.g. the GOT on ELF. In order for this not to
require text relocations, those symbols need to be resolved
On 7/7/22 14:32, Leo Izen wrote:
This patch prevents the libjxl encoder wrapper from failing to
encode images when the input video has untagged primaries. It will
instead assume BT.709/sRGB primaries and print a warning.
Signed-off-by: Leo Izen
---
libavcodec/libjxlenc.c | 7 +--
1 file
On Wed, Jul 13, 2022 at 09:49:05AM +0200, Paul B Mahol wrote:
> On Tue, Jul 12, 2022 at 8:43 PM Michael Niedermayer
> wrote:
>
> > Fixes: out of array access
> > Fixes:
> > 48799/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LAGARITH_fuzzer-4764457825337344
> >
> > Found-by: continuous fuzzin
On Fri, Jul 01, 2022 at 10:08:14AM +0200, Matthieu Bouron wrote:
> On Sat, Jun 11, 2022 at 5:35 PM Michael Niedermayer
> wrote:
>
> > On Fri, Jun 10, 2022 at 04:11:10PM +0200, Matthieu Bouron wrote:
> > > On Thu, Jun 2, 2022 at 9:13 PM Michael Niedermayer <
> > mich...@niedermayer.cc>
> > > wrote
On Thu, Feb 17, 2022 at 11:04:20AM +0100, Alan Kelly wrote:
> ff_shuffle_filter_coefficients shuffles the tail as required.
> ---
> libswscale/utils.c | 19 ---
> libswscale/x86/swscale.c | 6 ++
> 2 files changed, 18 insertions(+), 7 deletions(-)
it seems patch 3 and 4
On Thu, Jul 14, 2022 at 12:14:38AM +0300, Martin Storsjö wrote:
> The AArch64 assembly accesses those symbols directly, without
> indirection via e.g. the GOT on ELF. In order for this not to
> require text relocations, those symbols need to be resolved fully
> at link time, i.e. those symbols can'
On 14/07/2022 15:56, Gyan Doshi wrote:
On 2022-07-14 07:21 pm, Timo Rothenpieler wrote:
Seems like the release was missed, and the heap overflow is still
unfixed.
The release hasn't been tagged yet.
It's been branched though, and this isn't a patchset I'd feel
comfortable porting to a re
On 2022-07-14 07:21 pm, Timo Rothenpieler wrote:
Seems like the release was missed, and the heap overflow is still
unfixed.
The release hasn't been tagged yet.
In any case, I plan to push this within the next couple days if no
objections are raised.
The changes in the d3d11 hwcontext
Seems like the release was missed, and the heap overflow is still unfixed.
In any case, I plan to push this within the next couple days if no
objections are raised.
The changes in the d3d11 hwcontext are minimal and otherwise entirely
unrelated to the QSV hwcontext (if at all, it makes the si
Anton Khirnov:
> Quoting Andreas Rheinhardt (2022-07-12 16:12:16)
>> Anton really dislikes the av_fast_* naming and instead wants this to be
>> called av_realloc_array_reuse(). I don't care either way. Any more
>> opinions on this (or on the patch itself)?
>
> If people dislike _reuse(), I am open
On Wednesday, July 13, 2022 at 06:16:15 PM GMT+2, James Almer
wrote:
On 7/13/2022 12:54 PM, Marco Vianini wrote:
> Sorry, my mail client was using html format.
> I hope now the mail will be sent correctly.
>
>
> You can get a very big improvement of performances in the special (but
James Almer:
> Should fix ticket #3361
>
> Signed-off-by: James Almer
> ---
> This also needs an update to some fate ref samples i'll upload before pushing
> (fate-aac-al_sbr_ps_04_ur and fate-aac-al_sbr_ps_06_ur which are now decoded
> properly as he_aac mono, so the .s16 files need to be replac
On 7/14/2022 6:34 AM, Anton Khirnov wrote:
Quoting James Almer (2022-07-13 14:39:20)
You should probably add new entries to the schema file instead.
https://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/ffprobe.xsd;h=3af621a17ae884adfeacb7cd50c60e1553808188;hb=HEAD#l93
Once frame->pkt_duration i
> On Jul 6, 2022, at 3:05 PM, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> Streams with all zero sample_delta in 'stts' have all zero dts.
> They have higher chance be chose by mov_find_next_sample(), which
> leads to seek again and again.
>
> For example, GoPro created a 'GoPro SOS' stream:
On 2022-07-14 04:01 pm, Paul B Mahol wrote:
On Thu, Jul 14, 2022 at 12:21 PM Gyan Doshi wrote:
Pushed as 882aac99d2a7d15492ce1da9859676b0c04295b8
and cherry-picked to 5.1
Why?
The cherry-pick? Because 5.1 hasn't been tagged yet as already explained
in my last msg in v3 thread.
Regard
On Thu, Jul 14, 2022 at 12:21 PM Gyan Doshi wrote:
> Pushed as 882aac99d2a7d15492ce1da9859676b0c04295b8
> and cherry-picked to 5.1
>
Why?
>
> On 2022-07-14 01:46 pm, Gyan Doshi wrote:
> > This is a per-file input option that adjusts an input's timestamps
> > with reference to another input, so
Pushed as 882aac99d2a7d15492ce1da9859676b0c04295b8
and cherry-picked to 5.1
On 2022-07-14 01:46 pm, Gyan Doshi wrote:
This is a per-file input option that adjusts an input's timestamps
with reference to another input, so that emitted packet timestamps
account for the difference between the start
Quoting James Almer (2022-07-13 14:39:20)
> You should probably add new entries to the schema file instead.
>
> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/ffprobe.xsd;h=3af621a17ae884adfeacb7cd50c60e1553808188;hb=HEAD#l93
>
> Once frame->pkt_duration is gone, ffprobe shouldn't keep print
On Tue, 2022-06-14 at 09:22 +0800, Fei Wang wrote:
> From: Xu Guangxin
>
> According to C.5.2.2, item 2. When we got an IRAP, and the
> NoOutputOfPriorPicsFlag = 0, we need bump all outputable frames.
>
> Tested-by: Fei Wang
> Signed-off-by: Xu Guangxin
> ---
> Update:
> 1. fixed segment fault
Using parameter from AVCodecContext to reset qsv codec is more suitable
for MFXVideoENCODE_Reset()'s usage. Per-frame metadata is more suitable
for the usage of mfxEncodeCtrl being passed to
MFXVideoENCODE_EncodeFrameAsync(). Now change it to use the value
from AVCodecContext.
Because q->param is p
Quoting Nicolas George (2022-07-13 17:02:04)
> Anton Khirnov (12022-07-13):
> > ---
> > doc/filters.texi| 2 +-
> > libavfilter/buffersrc.c | 7 +++
> > libavfilter/f_loop.c| 14 ++
> > libavfilter/vf_deshake_opencl.c | 7 +++
> > libavfil
On 2022-07-14 01:45 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2022-07-14 09:47:17)
On 2022-07-14 12:16 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2022-07-10 20:02:38)
On 2022-07-10 10:46 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2022-07-08 05:56:21)
On 2022-07-07 03:11 pm, Anton
This is a per-file input option that adjusts an input's timestamps
with reference to another input, so that emitted packet timestamps
account for the difference between the start times of the two inputs.
Typical use case is to sync two or more live inputs such as from capture
devices. Both the tar
Quoting Gyan Doshi (2022-07-14 09:47:17)
>
>
> On 2022-07-14 12:16 pm, Anton Khirnov wrote:
> > Quoting Gyan Doshi (2022-07-10 20:02:38)
> >>
> >> On 2022-07-10 10:46 pm, Anton Khirnov wrote:
> >>> Quoting Gyan Doshi (2022-07-08 05:56:21)
> On 2022-07-07 03:11 pm, Anton Khirnov wrote:
>
Quoting Andreas Rheinhardt (2022-07-12 16:12:16)
> Anton really dislikes the av_fast_* naming and instead wants this to be
> called av_realloc_array_reuse(). I don't care either way. Any more
> opinions on this (or on the patch itself)?
If people dislike _reuse(), I am open to other reasonable sug
On 2022-07-14 12:16 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2022-07-10 20:02:38)
On 2022-07-10 10:46 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2022-07-08 05:56:21)
On 2022-07-07 03:11 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2022-07-04 18:29:12)
This is a per-file input optio
From: Zhao Zhili
---
libavformat/flvenc.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 1c4ffb985a..5d574fa790 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -993,12 +993,9 @@ static int flv_write_p
35 matches
Mail list logo
