From: Zhao Zhili
So user's fd can be passed to libavformat multiple times in sequence
without changing the position.
Signed-off-by: Zhao Zhili
---
libavformat/file.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/libavformat/file.c b/libavformat/file.c
index
Converting from an integer to HWND (which is a pointer) requires
an explicit cast, otherwise Clang errors out like this:
src/libavdevice/gdigrab.c:280:14: error: incompatible integer to pointer
conversion assigning to 'HWND' (aka 'struct HWND__ *') from 'long'
[-Wint-conversion]
280 |
This way they don't clutter this already-cluttered code even further.
---
fftools/ffmpeg_opt.c | 44 +++-
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index aed20032a8..b545c42818 100644
--- a/ff
Otherwise an unitialized stack value would be copied to FPSConvContext.
As it's then never used, it tends not to be a problem in practice,
however it is UB and some compilers warn about it.
---
fftools/ffmpeg_filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffmp
This option flag only carries nontrivial information for options that
call a function, in all other cases its presence can be inferred from
the option type (bool options do not have arguments, all other types do)
and is thus nothing but useless clutter.
Change the option parsing code to infer its
For consistent namespacing with other option flags. Also, document and
enforce that it can only be set for func-type options.
---
fftools/cmdutils.c | 8 +++-
fftools/cmdutils.h | 8 +++-
fftools/ffmpeg_opt.c | 92 ++--
fftools/ffplay.c | 14 +++---
These values are not actually flags, as only one of them can be
meaningfully set.
---
fftools/cmdutils.c | 51 ++--
fftools/cmdutils.h | 21 +-
fftools/ffmpeg_opt.c | 557 +--
fftools/ffplay.c | 102
fftools/ffprobe.c| 76 +++---
ffto
Currently it requires every single OPT_SPEC option to be accompanied by
an array of alternate names for this option. The vast majority of
options have no alternate names, resulting in a large numbers of
unnecessary single-element arrays that merely contain the option name.
Extend the option parsin
Reduces the basic help output to a reasonable size and stops confusing
users with options the vast majority will not need.
---
fftools/ffmpeg_opt.c | 56 ++--
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmp
Only show it with show_advanced (triggered by -h long), since data
streams themselves are an advanced topic.
---
fftools/ffmpeg_opt.c | 4
1 file changed, 4 insertions(+)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index c8fb9d03e4..87357e8b64 100644
--- a/fftools/ffmpeg_opt.c
+
* filter subtitle/data options out of main, video and audio sections
* add filters that were missing entirely from the subtitle section
* add a missing section for advanced subtitle options
---
fftools/ffmpeg_opt.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git
They were marked as deprecated over 10 years ago.
---
doc/ffmpeg.texi | 4
fftools/ffmpeg_opt.c | 13 ++---
2 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 6ecd5f3cfe..bbe70a4f85 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpe
It causes those options to be parsed as either
* -autofoo 0/1 (with an argument)
* -noautofoo (without an argument)
This is unnecessary, confusing, and against the documentation; these are
also the only two bool options that take an argument.
This should not affect the users, as these options ar
It has already been deprecated over a year ago.
---
fftools/ffmpeg.h | 1 +
fftools/ffmpeg_mux_init.c | 4
fftools/ffmpeg_opt.c | 15 ---
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 1a8254d422..7d55e384d
Also, document them.
---
fftools/cmdutils.h | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index d0242dc6ab..8e22560fc6 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -125,23 +125,31 @@ typ
Significantly simplifies the code dealing with OPT_SPEC.
---
fftools/cmdutils.c| 10 +-
fftools/cmdutils.h| 9 +-
fftools/ffmpeg.h | 197 +-
fftools/ffmpeg_demux.c| 30 +++---
fftools/ffmpeg_mux_init.c | 32 +++
fftools/ffmp
SPEC and OFFSET do not make sense for functions.
---
fftools/cmdutils.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 6ca2efef4a..a52c7c5ae4 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -482,6 +482,9 @@ static void check_options
There is no reason for it to be a macro anymore, this makes the code
using it cleaner and simpler.
---
fftools/cmdutils.c| 6 +-
fftools/cmdutils.h| 2 ++
fftools/ffmpeg.h | 11 ++-
fftools/ffmpeg_demux.c| 16
fftools/ffmpeg_mux_init.c |
Cf. 2244722f1f3
---
fftools/ffmpeg_opt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 8b2c30e2e6..eee12df893 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1254,7 +1254,7 @@ void show_help_default(const char
So they don't clutter the standard help output.
-loglevel is marked because there is no need to show two options (-v and
-loglevel) that do the same thing.
---
fftools/opt_common.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fftools/opt_common.h b/fftools/opt_common.
And analogously OPT_OFFSET in OPT_SPEC. Previously the inclusion would
be implicit and required all code to remember this.
---
fftools/cmdutils.c | 6 +++---
fftools/cmdutils.h | 21 +
fftools/ffmpeg_opt.c | 14 ++
3 files changed, 22 insertions(+), 19 deletion
It's a data, not video option.
---
fftools/ffmpeg_opt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 87357e8b64..d6de997af8 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1955,7 +1955,7 @@ const OptionDef op
On 2023-12-18 09:31 am, Gyan Doshi wrote:
On 2023-12-16 03:44 pm, Gyan Doshi wrote:
During a resampling operation where
1) user has specified first_pts
2) SWR_FLAG_RESAMPLE is not set initially (directly or otherwise)
3) first_pts has been fulfilled (always using hard compensation)
then u
Am 17.12.23 um 23:51 schrieb Michael Niedermayer:
On Sat, Dec 16, 2023 at 09:13:21AM +0100, Thilo Borgmann via ffmpeg-devel wrote:
[...]
+// get number of bytes from cur to '\0'
+static int buf_get_zero(FsyncContext *ctx)
maybe doxygen syntax would make sense for comments descrining functions
Am 18.12.23 um 02:04 schrieb Stefano Sabatini:
On date Saturday 2023-12-16 09:13:21 +0100, ffmpeg-devel Mailing List wrote:
---
Changelog| 1 +
MAINTAINERS | 1 +
configure| 2 +
doc/filters.texi | 33 +
libavfilter/Makefile
Quoting James Almer (2023-12-14 21:14:26)
> +/**
> + * Mix Gain Parameter Data as defined in section 3.8.1 of IAMF.
> + */
> +typedef struct AVIAMFMixGain {
> +const AVClass *av_class;
> +
> +/**
> + * Duration for the given subblock. It must not be 0.
In what units? Same for all durat
> -Original Message-
> From: ffmpeg-devel On Behalf Of Dai,
> Jianhui J
> Sent: Monday, December 18, 2023 3:59 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v1] avcodec/cbs_vp8: Apply clang-format and
> fix typos.
>
> This commit applies clang-format to the source an
Quoting Zhao Zhili (2023-12-17 12:01:08)
> From: Zhao Zhili
>
> A dummy frame is created with format NONE passed to enc_open(),
> which doesn't prepare for it. The null pointer dereference happened
> at av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth.
>
> frame #0: 0x00bc34a4 ffmpeg
Quoting Zhao Zhili (2023-12-17 12:01:09)
> From: Zhao Zhili
>
> Signed-off-by: Zhao Zhili
> ---
> fftools/ffmpeg_enc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
> index 9141dab6a4..ac38e8db75 100644
> --- a/fftools/ffmpeg_enc.c
> +++
Quoting Zhao Zhili (2023-12-18 17:42:39)
> From: Zhao Zhili
>
> So user's fd can be passed to libavformat multiple times in sequence
> without changing the position.
>
> Signed-off-by: Zhao Zhili
> ---
> libavformat/file.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
> -Original Message-
> From: ffmpeg-devel On Behalf Of Michael
> Niedermayer
> Sent: Sunday, December 17, 2023 9:19 PM
> To: FFmpeg development discussions and patches
> Subject: [FFmpeg-devel] [PATCH] avcodec/cbs_vp8: fix GetBitContext setup
>
> Fixes: abort()
> Fixes: 64232/clusterf
> On Mar 21, 2023, at 23:01, Thomas Siedel wrote:
>
> Add demuxer to probe raw vvc and parse vvcc byte stream format.
>
> Co-authored-by: Nuo Mi
> ---
>
> +
> +static int h266_probe(const AVProbeData *p)
> +{
> +uint32_t code = -1;
> +int sps = 0, pps = 0, irap = 0;
> +int i;
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of Michael
> Niedermayer
> Sent: Saturday, December 16, 2023 8:16 PM
> To: FFmpeg development discussions and patches
> Subject: [FFmpeg-devel] [PATCH 2/4] avcodec/cbs_vp8: Do not use assert to
> check for end
>
> Fixes: abort()
> Fi
> On Dec 18, 2023, at 19:19, Anton Khirnov wrote:
>
> Quoting Zhao Zhili (2023-12-17 12:01:08)
>> From: Zhao Zhili
>>
>> A dummy frame is created with format NONE passed to enc_open(),
>> which doesn't prepare for it. The null pointer dereference happened
>> at av_pix_fmt_desc_get(enc_ctx->pi
On Mon, Dec 18, 2023 at 7:43 PM Zhao Zhili wrote:
>
>
> > On Mar 21, 2023, at 23:01, Thomas Siedel
> wrote:
> >
> > Add demuxer to probe raw vvc and parse vvcc byte stream format.
> >
> > Co-authored-by: Nuo Mi
> > ---
> >
>
>
> > +
> > +static int h266_probe(const AVProbeData *p)
> > +{
> > +
> On Dec 18, 2023, at 20:04, Zhao Zhili wrote:
>
>
>
>> On Dec 18, 2023, at 19:19, Anton Khirnov wrote:
>>
>> Quoting Zhao Zhili (2023-12-17 12:01:08)
>>> From: Zhao Zhili
>>>
>>> A dummy frame is created with format NONE passed to enc_open(),
>>> which doesn't prepare for it. The null po
Quoting Zhao Zhili (2023-12-18 13:04:24)
>
>
> > On Dec 18, 2023, at 19:19, Anton Khirnov wrote:
> >
> > Quoting Zhao Zhili (2023-12-17 12:01:08)
> >> From: Zhao Zhili
> >>
> >> A dummy frame is created with format NONE passed to enc_open(),
> >> which doesn't prepare for it. The null pointer
Before this patch being applied the ffprobe just tells the user whether
the H.26[45] User Data Unregistered SEI message is present in the frame side
data
or not. After the patch being appliend it also dumps the contents of the data
similar way as for the other already supported frame side data typ
From 960f70964521e1dc94647d70e2631351c0bb51bb Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Mon, 18 Dec 2023 22:39:13 +0800
Subject: [PATCH 1/6] checkasm/takdsp: add decorrelate_ls test
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 ++
tests/checkasm/checkasm.h | 1 +
t
From 9254ae1f72498568857357059eb514e8cb90b5f1 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Mon, 18 Dec 2023 22:47:29 +0800
Subject: [PATCH 2/6] checkasm/takdsp: add decorrelate_sr test
---
tests/checkasm/takdsp.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a
From 9e09f52403058e1bc87653bfd9980c7d5a6ce33c Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Mon, 18 Dec 2023 22:48:09 +0800
Subject: [PATCH 3/6] checkasm/takdsp: add decorrelate_sm test
---
tests/checkasm/takdsp.c | 29 +
1 file changed, 29 insertions(+)
diff --git
C908:
decorrelate_ls_c: 69.7
decorrelate_ls_rvv_i32: 27.2
From 03fad46e6db1846596c31918fc4e34b58246efc4 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Mon, 18 Dec 2023 22:49:21 +0800
Subject: [PATCH 4/6] lavc/takdsp: R-V V decorrelate_ls
C908:
decorrelate_ls_c: 69.7
decorrelate_ls_rvv_i32: 27.2
-
C908:
decorrelate_sr_c: 95.5
decorrelate_sr_rvv_i32: 28.2
From fa1a84337a7cd2a62c26a9d5f8d707a97e917f77 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Mon, 18 Dec 2023 22:52:20 +0800
Subject: [PATCH 5/6] lavc/takdsp: R-V V decorrelate_sr
C908:
decorrelate_sr_c: 95.5
decorrelate_sr_rvv_i32: 28.2
-
C908:
decorrelate_sm_c: 130.0
decorrelate_sm_rvv_i32: 43.7
From 3dc613feaa6c38a7df47a3fc385e2140716e0ae2 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Mon, 18 Dec 2023 22:53:39 +0800
Subject: [PATCH 6/6] lavc/takdsp: R-V V decorrelate_sm
C908:
decorrelate_sm_c: 130.0
decorrelate_sm_rvv_i32: 43.7
A 'shnadd' should be moved to the front, updated in this reply.
flow gg 于2023年12月18日周一 23:15写道：
> C908:
> decorrelate_ls_c: 69.7
> decorrelate_ls_rvv_i32: 27.2
>
From fdee02eae64ced9a65781fbbeef32c6b8ee2fdce Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Mon, 18 Dec 2023 22:49:21 +0800
Subject:
Le maanantaina 18. joulukuuta 2023, 17.26.58 EET flow gg a écrit :
> A 'shnadd' should be moved to the front, updated in this reply.
Indeed, but please try to interleave scalar and vector instructions. The C908
IP does not really care, but apparently, in-order vector processor are going
to be ha
Le sunnuntaina 17. joulukuuta 2023, 23.57.50 EET Martin Storsjö a écrit :
> > Rounding errors would not cause a constant gap across the different test
> > cases. This is most likely an off-by-one in the x86 code. I don't know if
> > this is a bug in the x86 code, or the test case being a little loo
Okay, updated in the reply.
Rémi Denis-Courmont 于2023年12月19日周二 00:25写道：
> Le maanantaina 18. joulukuuta 2023, 17.26.58 EET flow gg a écrit :
> > A 'shnadd' should be moved to the front, updated in this reply.
>
> Indeed, but please try to interleave scalar and vector instructions. The
> C908
> I
Quoting Martin Storsjö (2023-12-17 22:57:50)
>
> FWIW, we've had these situations elsewhere before as well, in swscale,
> where the existing x86 assembly mismatches the C code in nontrivial ways,
> and we have new assembly (aarch64 in that case) that is missing a test
> (even if one was written
Quoting Leo Izen (2023-12-15 00:33:33)
> On 12/14/23 03:28, Anton Khirnov wrote:
> > This logic seems shady to me.
>
> Which part, specifically? The animated logic, or the non-animated logic?
Aspects of both looked questionable to me (which doesn't necessarily
means it's wrong)
> > The decoder s
On Sun, Dec 17, 2023 at 11:57:50PM +0200, Martin Storsjö wrote:
[...]
> FWIW, we've had these situations elsewhere before as well, in swscale, where
> the existing x86 assembly mismatches the C code in nontrivial ways, and we
> have new assembly (aarch64 in that case) that is missing a test (even i
On 12/18/2023 1:34 PM, Rémi Denis-Courmont wrote:
Le sunnuntaina 17. joulukuuta 2023, 23.57.50 EET Martin Storsjö a écrit :
Rounding errors would not cause a constant gap across the different test
cases. This is most likely an off-by-one in the x86 code. I don't know if
this is a bug in the x86
Quoting Stefano Sabatini (2023-12-16 16:18:07)
> On date Thursday 2023-12-14 10:35:56 +0100, Nicolas George wrote:
> > Anton Khirnov (12023-12-14):
> [...]
> > > I have to strongly disagree. This is neither practically workable,
> > > nor a good goal to aim at.
> >
> > And I strongly agree with St
On 12/18/2023 8:04 AM, Anton Khirnov wrote:
Quoting James Almer (2023-12-14 21:14:26)
+/**
+ * Mix Gain Parameter Data as defined in section 3.8.1 of IAMF.
+ */
+typedef struct AVIAMFMixGain {
+const AVClass *av_class;
+
+/**
+ * Duration for the given subblock. It must not be 0.
I
The current pack_output function pointer is a property of the decoder,
rather than a constant method provided by the DSP code. Indeed, except
for an unused initialisation, the field is never used in DSP code.
---
libavcodec/mlpdec.c | 48 ++---
libavcodec/ml
On Mon, 18 Dec 2023 at 14:59, Petr Matousek
wrote:
> Before this patch being applied the ffprobe just tells the user whether
> the H.26[45] User Data Unregistered SEI message is present in the frame
> side data
> or not. After the patch being appliend it also dumps the contents of the
> data
> si
Avoid taking an ugly detour through the decoder AVCodecContext.
---
fftools/ffmpeg_demux.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index eca3de709c..a28a94b5ed 100644
--- a/fftools/ffmpeg_demux.c
+++ b/ffto
---
libavformat/options.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavformat/options.c b/libavformat/options.c
index bf6113ca95..cc89dd6c72 100644
--- a/libavformat/options.c
+++ b/libavformat/options.c
@@ -229,6 +229,16 @@ static const AVOption stream_options[] = {
On 12/18/2023 4:19 PM, Anton Khirnov wrote:
---
libavformat/options.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavformat/options.c b/libavformat/options.c
index bf6113ca95..cc89dd6c72 100644
--- a/libavformat/options.c
+++ b/libavformat/options.c
@@ -229,6 +229,16 @@ s
On Mon, Dec 18, 2023 at 06:33:45PM +0100, Anton Khirnov wrote:
> Quoting Stefano Sabatini (2023-12-16 16:18:07)
> > On date Thursday 2023-12-14 10:35:56 +0100, Nicolas George wrote:
> > > Anton Khirnov (12023-12-14):
> > [...]
> > > > I have to strongly disagree. This is neither practically workabl
Michael Niedermayer (12023-12-18):
> I think the first question is, does this actually need
> "massive hacks in ffmpeg CLI" ?
Thank you for bringing some sanity.
> If you ignore the recommandition that SDL should be run from the main
> thread then iam not sure what change would be needed in ffmpe
On 12/18/2023 5:54 AM, Martin Storsjö wrote:
Converting from an integer to HWND (which is a pointer) requires
an explicit cast, otherwise Clang errors out like this:
src/libavdevice/gdigrab.c:280:14: error: incompatible integer to pointer
conversion assigning to 'HWND' (aka 'struct HWND__
On date Monday 2023-12-18 19:05:17 -0300, James Almer wrote:
> On 12/18/2023 5:54 AM, Martin Storsjö wrote:
> > Converting from an integer to HWND (which is a pointer) requires
> > an explicit cast, otherwise Clang errors out like this:
> >
> > src/libavdevice/gdigrab.c:280:14: error: incompa
On Sat, 9 Dec 2023, Kalev Lember wrote:
With the way the runtime checks are currently set up, every single
openh264 release, no matter how minor, is considered an ABI break and
requires ffmpeg recompilation. This is unnecessarily strict because it
doesn't allow downstream distributions to ship a
On Mon, 18 Dec 2023, Stefano Sabatini wrote:
On date Monday 2023-12-18 19:05:17 -0300, James Almer wrote:
On 12/18/2023 5:54 AM, Martin Storsjö wrote:
Converting from an integer to HWND (which is a pointer) requires
an explicit cast, otherwise Clang errors out like this:
src/libavdevice/
On date Monday 2023-12-11 02:35:23 +0100, Clément Bœsch wrote:
> This makes the function closer to encode_acs() in proresenc_kostya.
> ---
> libavcodec/proresenc_anatoliy.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/pror
On date Monday 2023-12-11 02:35:24 +0100, Clément Bœsch wrote:
> Both encoders share a lot of code from both authors.
> ---
> libavcodec/proresenc_kostya.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
> index e0aa7cf47a..c6
On date Monday 2023-12-11 02:35:25 +0100, Clément Bœsch wrote:
> This matches the name in proresenc_kostya.
> ---
> libavcodec/proresenc_anatoliy.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
> inde
On date Monday 2023-12-11 02:35:26 +0100, Clément Bœsch wrote:
> This makes the function closer to the same function in proresenc_kostya.
> ---
> libavcodec/proresenc_anatoliy.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
LGTM.
_
On date Monday 2023-12-11 02:35:27 +0100, Clément Bœsch wrote:
> This matches encode_dcs() prototype from proresenc_kostya.
> ---
> libavcodec/proresenc_anatoliy.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
LGTM.
___
ffmpeg-devel ma
Zhao Zhili:
> From: Zhao Zhili
>
> Signed-off-by: Zhao Zhili
> ---
> libavcodec/v4l2_m2m.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
> index 602efb7a16..bac3eb0588 100644
> --- a/libavcodec/v4l2_m2m.c
> +++ b/libavcodec/v4l2_m2m.c
> @
On date Monday 2023-12-18 14:58:58 +, Petr Matousek wrote:
> Before this patch being applied the ffprobe just tells the user whether
> the H.26[45] User Data Unregistered SEI message is present in the frame side
> data
> or not. After the patch being appliend it also dumps the contents of the
---
It's annoying to have to go through the audio visualization modes when you
just want to switch back-and-forth between two video filters. It also makes
the code simpler.
doc/ffplay.texi | 5 -
fftools/ffplay.c | 10 --
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git
> On Dec 19, 2023, at 06:33, Andreas Rheinhardt
> wrote:
>
> Zhao Zhili:
>> From: Zhao Zhili
>>
>> Signed-off-by: Zhao Zhili
>> ---
>> libavcodec/v4l2_m2m.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
>> index 602efb7a16..bac3eb0
> On Dec 19, 2023, at 10:02, Ondřej Fiala wrote:
>
> ---
> It's annoying to have to go through the audio visualization modes when you
> just want to switch back-and-forth between two video filters. It also makes
> the code simpler.
>
> doc/ffplay.texi | 5 -
> fftools/ffplay.c | 10 ---
c908:
dcmul_add_c: 88.0
dcmul_add_rvv_f64: 46.2
Did not use vlseg2e64, because it is much slower than vlse64
Did not use vsseg2e64, because it is slightly slower than vsse64
From 80b6694bc29ed1c37852dc079a6d91a24dd6f18e Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Tue, 19 Dec 2023 09:11:28 +080
> On Dec 18, 2023, at 20:25, Nuo Mi wrote:
>
> On Mon, Dec 18, 2023 at 7:43 PM Zhao Zhili wrote:
>
>>
>>
>>> On Mar 21, 2023, at 23:01, Thomas Siedel
>> wrote:
>>>
>>> Add demuxer to probe raw vvc and parse vvcc byte stream format.
>>>
>>> Co-authored-by: Nuo Mi
>>> ---
>>>
>>
>
> It
On Tue, 2023-11-28 at 03:15 +, Xiang, Haihao wrote:
> On Ma, 2023-11-27 at 13:36 +, Mark Thompson wrote:
> > On 27/11/2023 00:58, fei.w.wang-at-intel@ffmpeg.org wrote:
> > > From: Fei Wang
> > >
> > > Keep same way with librav1e/libsvtav1/qsv_av1.. to make it more
> > > acceptable ins
Le 18 décembre 2023 21:58:39 GMT+02:00, Michael Niedermayer
a écrit :
>On Mon, Dec 18, 2023 at 06:33:45PM +0100, Anton Khirnov wrote:
>> Quoting Stefano Sabatini (2023-12-16 16:18:07)
>> > On date Thursday 2023-12-14 10:35:56 +0100, Nicolas George wrote:
>> > > Anton Khirnov (12023-12-14):
>> >
From: Zhao Zhili
In close_output(), a dummy frame is created with format NONE passed
to enc_open(), which doesn't prepare for it. The NULL pointer
dereference happened at
av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth.
When fgt.graph is NULL, skip fg_output_frame() since there is
nothing t
From: Zhao Zhili
---
fftools/ffmpeg_filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 69a49a071e..7cc7abba64 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -2456,7 +2456,7 @@ static int read
From: Zhao Zhili
---
fftools/ffmpeg_enc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index 57590a43a3..2a7fba0c51 100644
--- a/fftools/ffmpeg_enc.c
+++ b/fftools/ffmpeg_enc.c
@@ -206,6 +206,9 @@ int enc_open(void *opaque, const AVFrame *
Dne 19/12/2023 v 00:01 Stefano Sabatini napsal(a):
On date Monday 2023-12-18 14:58:58 +, Petr Matousek wrote:
Before this patch being applied the ffprobe just tells the user whether
the H.26[45] User Data Unregistered SEI message is present in the frame side
data
or not. After the patch
83 matches
Mail list logo
