On Wed, 3 Jan 2024, at 23:21, Marth64 wrote:
> Hi,
> I felt that it was strange in all of documentation, this is the only
> scenario where 0xA0 is used for a space character instead of the ordinary
> space 0x20. It is invisible when viewing in email or many IDE but in my
> editor I was able to
Fixes -Wincompatible-pointer-types warnings.
Signed-off-by: Tong Wu
---
libavcodec/d3d12va_av1.c | 2 +-
libavcodec/d3d12va_h264.c | 2 +-
libavcodec/d3d12va_hevc.c | 2 +-
libavcodec/d3d12va_vc1.c | 2 +-
libavcodec/d3d12va_vp9.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
Signed-off-by: Tong Wu
---
libavcodec/d3d12va_av1.c| 18 +-
libavcodec/d3d12va_decode.c | 9 ++---
libavcodec/d3d12va_h264.c | 4
libavcodec/d3d12va_hevc.c | 5 -
libavcodec/d3d12va_vc1.c| 3 ---
libavcodec/d3d12va_vp9.c| 4
6 files changed,
lavu/thread: add support for setting thread name on *bsd and solaris
FreeBSD/DragonFly/Solaris use pthread_setname_np(). OpenBSD uses
pthread_set_name_np().
Signed-off-by: Brad Smith
---
configure | 10 ++
libavutil/thread.h | 14 --
2 files changed, 22
On Wo, 2024-01-03 at 20:46 +, Mark Thompson wrote:
> hw_frames_ctx on the input link is only set when the input link is
> configured, which hasn't happened yet. This temporarily hacks around
> the problem (in a way no worse than before the format negotiation
> changes) until a proper fix can
On Thu, Jan 04, 2024 at 12:58:43AM +0100, Stefano Sabatini wrote:
> On date Wednesday 2024-01-03 23:24:33 +0100, Michael Niedermayer wrote:
[...]
>
> > +typedef struct KISS64State{
> > +uint64_t x,y,z,c;
> > +}KISS64State;
>
> missing namespace here and in the functions below.
>
> For
Signed-off-by: Aidan O'Connor
---
libavfilter/vf_xfade.c | 266 +
1 file changed, 213 insertions(+), 53 deletions(-)
diff --git a/libavfilter/vf_xfade.c b/libavfilter/vf_xfade.c
index 890995a608..65611beeb5 100644
--- a/libavfilter/vf_xfade.c
+++
Signed-off-by: James Almer
---
tests/Makefile| 1 +
tests/fate/vvc.mak| 50 +++
tests/ref/fate/vvc-conformance-APSALF_A_2 | 13 ++
tests/ref/fate/vvc-conformance-APSLMCS_D_1| 37 +
Thank you!
On Wed, Jan 3, 2024 at 6:15 PM Stefano Sabatini wrote:
> On date Wednesday 2024-01-03 12:45:51 -0600, Marth64 wrote:
> > Signed-off-by: Marth64
> > ---
> > doc/faq.texi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/doc/faq.texi b/doc/faq.texi
> >
On date Wednesday 2024-01-03 12:45:51 -0600, Marth64 wrote:
> Signed-off-by: Marth64
> ---
> doc/faq.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/faq.texi b/doc/faq.texi
> index 8b165eb436..39f28eef08 100644
> --- a/doc/faq.texi
> +++ b/doc/faq.texi
> @@
On 1/3/2024 8:58 PM, Stefano Sabatini wrote:
missing namespace here and in the functions below.
For this you could probably use AVKISS64PRNG (or AVKISS64), and use
av_kiss64prng_ or av_kiss64_ as function prefix (I'd probably go with
the shortest variant).
It's not an installed header, so FF
On date Wednesday 2024-01-03 23:24:33 +0100, Michael Niedermayer wrote:
> This is the 64bit version of George Marsaglias KISS PRNG
>
> Compared to the LCGs these produce much better quality numbers.
> Compared to LFGs this needs less state. (our LFG has 224 byte
> state for its 32bit version)
Kindly disregard. This is not actually a typo, it is valid regional
English. Sorry. Just ignore this one.
On Wed, Jan 3, 2024 at 4:51 PM Marth64 wrote:
> Signed-off-by: Marth64
> ---
> doc/filters.texi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git
Signed-off-by: Marth64
---
doc/filters.texi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index f4084ff494..eff2256fef 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -195,7 +195,7 @@ filtergraph, a link between the
Signed-off-by: Marth64
---
doc/codecs.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/codecs.texi b/doc/codecs.texi
index 5b950b4560..6c6f16a2c8 100644
--- a/doc/codecs.texi
+++ b/doc/codecs.texi
@@ -3,7 +3,7 @@
@c man begin CODEC OPTIONS
libavcodec provides some
Signed-off-by: Marth64
---
doc/muxers.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index f6071484ff..7b705b6a9e 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1397,7 +1397,7 @@ form @file{img%-1.jpg}, @file{img%-2.jpg}, ...,
Signed-off-by: Marth64
---
doc/filters.texi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 264b363642..f4084ff494 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -20101,7 +20101,7 @@ Generate a QR code using the
Signed-off-by: Marth64
---
doc/filters.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 6d00ba2c3f..215cb966ce 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -17887,7 +17887,7 @@ Macroblock size. Default @code{16}.
On Wed, Jan 03, 2024 at 07:36:00PM +0100, Michael Koch wrote:
> Possible better algorithm for the random generator, which might fix the
> problem:
>
> eval.c line 235
>
> if (r == 0)
> r = UINT64_MAX/13;
> else
> r = r*1664525+1013904223;
This modifies the properties of the PRNG as it
---
doc/encoders.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 93586e1aae..f65389f2a0 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2972,7 +2972,7 @@ Set the encoder preset value to determine encoding speed
This is the 64bit version of George Marsaglias KISS PRNG
Compared to the LCGs these produce much better quality numbers.
Compared to LFGs this needs less state. (our LFG has 224 byte
state for its 32bit version) this has 32byte state for the 64bit version
Also the initialization for our LFG is
Hi,
I felt that it was strange in all of documentation, this is the only
scenario where 0xA0 is used for a space character instead of the ordinary
space 0x20. It is invisible when viewing in email or many IDE but in my
editor I was able to see the exact hex character was not a ordinary space
Signed-off-by: Marth64
---
doc/ffmpeg.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 145cbb1032..bb57aeaef4 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -118,7 +118,7 @@ Encoded packets are then passed to the decoder
Why this change?
On Wed, 3 Jan 2024, at 19:47, Marth64 wrote:
> Signed-off-by: Marth64
> ---
> doc/faq.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/faq.texi b/doc/faq.texi
> index 39f28eef08..5998e0d000 100644
> --- a/doc/faq.texi
> +++ b/doc/faq.texi
> @@
hw_frames_ctx on the input link is only set when the input link is
configured, which hasn't happened yet. This temporarily hacks around
the problem (in a way no worse than before the format negotiation
changes) until a proper fix can be applied.
---
Suggested full fix is to carry sw_format
On Wed, Jan 03, 2024 at 05:17:07PM +0100, Stefano Sabatini wrote:
> On date Tuesday 2024-01-02 01:10:28 +0100, Michael Niedermayer wrote:
> > On Mon, Jan 01, 2024 at 08:38:58PM +0100, Stefano Sabatini wrote:
> > > This might be useful, e.g. when setting the random seed expressed as a
> > >
On Tue, Jan 02, 2024 at 12:06:29PM +0100, Stefano Sabatini wrote:
> On date Tuesday 2024-01-02 03:28:45 +0100, Michael Niedermayer wrote:
> > rounding the 64bit integer state to double between each iteration
> > causes a reduction in quality of the random number generator.
> > For example its
Signed-off-by: Marth64
---
doc/codecs.texi | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/doc/codecs.texi b/doc/codecs.texi
index 5b950b4560..98482ff8bf 100644
--- a/doc/codecs.texi
+++ b/doc/codecs.texi
@@ -767,15 +767,9 @@ Set rate-distortion optimal
Signed-off-by: Marth64
---
doc/faq.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/faq.texi b/doc/faq.texi
index 39f28eef08..5998e0d000 100644
--- a/doc/faq.texi
+++ b/doc/faq.texi
@@ -450,7 +450,7 @@ work with streams that were detected during the initial
scan;
Signed-off-by: Marth64
---
doc/faq.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/faq.texi b/doc/faq.texi
index 8b165eb436..39f28eef08 100644
--- a/doc/faq.texi
+++ b/doc/faq.texi
@@ -467,7 +467,7 @@ point acceptable for your tastes. The most common options
to do
On Tue, Jan 02, 2024 at 05:47:53PM +0800, Nuo Mi wrote:
[...]
> maintainer, and any HEVC code change requires a very long review time.
I think changes that just move code around or rename functions would be
quickly reviewed
I dont know if things are 1:1 identical or some complex changes are
Possible better algorithm for the random generator, which might fix the
problem:
eval.c line 235
if (r == 0)
r = UINT64_MAX/13;
else
r = r*1664525+1013904223;
Michael
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Wed, 3 Jan 2024 at 15:44, Stefano Sabatini wrote:
> On date Tuesday 2024-01-02 22:08:54 +, Kieran Kunhya wrote:
> [...]
> > The OP wants to test an implementation they have and they should do it
> > using the API, not using ffprobe to test their third party implementation
> > of
On one hand, it's good that the 10 variables for ld() and st() are
initialized with zero.
But on the other hand, zero is obviously the worst possible seed value
for the random generator.
For example, make a 1000x1000 image with red color, and then fill one
pixel at a random position with
On date Tuesday 2024-01-02 01:10:28 +0100, Michael Niedermayer wrote:
> On Mon, Jan 01, 2024 at 08:38:58PM +0100, Stefano Sabatini wrote:
> > This might be useful, e.g. when setting the random seed expressed as a
> > uint64_t.
> > ---
> > doc/utils.texi | 3 +++
> > libavutil/eval.c | 1 +
> >
On date Wednesday 2024-01-03 12:20:12 +0100, Michael Koch wrote:
> > Possible address trac issue:
>
> > http://trac.ffmpeg.org/ticket/10763
>
> I don't like the random generator as it is, because the first two random
> numbers
> are very close to zero, as can be shown with this command line:
>
On date Wednesday 2024-01-03 11:53:27 +0100, ffmpeg-devel Mailing List wrote:
> Am 03.01.24 um 11:45 schrieb Gyan Doshi:
[...]
> > > I don't really understand. Missing (de)muxer & (de/en)coders
> > > docs are blocking this filter? Do I miss a connection? Is there
> > > some discussion regarding
Thanks for the suggestion from Lynne.
---
libavcodec/vvc/vvc_intra.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/vvc/vvc_intra.c b/libavcodec/vvc/vvc_intra.c
index 43de312a71..214ad38c8c 100644
--- a/libavcodec/vvc/vvc_intra.c
+++ b/libavcodec/vvc/vvc_intra.c
@@ -552,6 +552,8
On date Wednesday 2024-01-03 13:58:14 +0100, Timo Rothenpieler wrote:
> On 16.12.2023 16:35, Stefano Sabatini wrote:
> > Ping, if there are no objections or comments I plan to push this in a
> > week or something.
>
> This broke the build:
>
> > libavfilter/vf_drawtext.c: In function
On date Tuesday 2024-01-02 22:08:54 +, Kieran Kunhya wrote:
[...]
> The OP wants to test an implementation they have and they should do it
> using the API, not using ffprobe to test their third party implementation
> of something.
>
> > "Parsed by FFmpeg" sounds like you are proposing to
---
libavcodec/vvc/vvc_filter_template.c | 82 +---
1 file changed, 3 insertions(+), 79 deletions(-)
diff --git a/libavcodec/vvc/vvc_filter_template.c
b/libavcodec/vvc/vvc_filter_template.c
index 04eb9702dc..98a9005674 100644
--- a/libavcodec/vvc/vvc_filter_template.c
---
libavcodec/hevcdsp_template.c | 96 ++
libavcodec/xvc_deblock_template.c | 99 +++
2 files changed, 116 insertions(+), 79 deletions(-)
create mode 100644 libavcodec/xvc_deblock_template.c
diff --git a/libavcodec/hevcdsp_template.c
---
libavcodec/vvc/vvc_filter_template.c | 193 +--
1 file changed, 2 insertions(+), 191 deletions(-)
diff --git a/libavcodec/vvc/vvc_filter_template.c
b/libavcodec/vvc/vvc_filter_template.c
index a4f1792ec4..04eb9702dc 100644
--- a/libavcodec/vvc/vvc_filter_template.c
---
libavcodec/hevcdsp_template.c | 196 +-
libavcodec/xvc_sao_template.c | 217 ++
2 files changed, 218 insertions(+), 195 deletions(-)
create mode 100644 libavcodec/xvc_sao_template.c
diff --git a/libavcodec/hevcdsp_template.c
SAO is 100% reusable
deblock is partial reusable
Nuo Mi (4):
hevcdec: move sao template to xvc_sao_template.c
vvcdec: reuse xvc_sao_template.c
hevcdec: move deblock template to xvc_deblock_template.c
vvcdec: reuse xvc_deblock_template.c
libavcodec/hevcdsp_template.c| 292
On Wed, Jan 03, 2024 at 04:04:00AM +0100, Lynne wrote:
> Jan 3, 2024, 02:22 by jamr...@gmail.com:
>
> > On 1/2/2024 9:56 PM, Lynne wrote:
> >
> >> As some of you know, my laptop died nearly 2 years ago, and
> >> I've been working on a desktop machine, which is currently a Zen 3.
> >> AVX512 has
From: Zhao Zhili
Signed-off-by: Zhao Zhili
---
libavutil/hwcontext_videotoolbox.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavutil/hwcontext_videotoolbox.c
b/libavutil/hwcontext_videotoolbox.c
index bb5b7e2764..fe469dc161 100644
--- a/libavutil/hwcontext_videotoolbox.c
+++
From: Zhao Zhili
Signed-off-by: Zhao Zhili
---
libavcodec/videotoolboxenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 15e0e1fe29..0ce2b2ddad 100644
--- a/libavcodec/videotoolboxenc.c
+++
On 16.12.2023 16:35, Stefano Sabatini wrote:
Ping, if there are no objections or comments I plan to push this in a
week or something.
This broke the build:
libavfilter/vf_drawtext.c: In function 'shape_text':
libavfilter/vf_drawtext.c:687:13: error: implicit declaration of function
On 12/28/23 21:33, Michael Niedermayer wrote:
On Wed, Dec 27, 2023 at 03:44:09PM +0200, Paul Orlyk wrote:
mode field in Transport header can be sent in upper case so make string
comparison case insensitive.
Also, GStreamer expects to see mode=record instead of mode=receive in
Transport header
On Tue, Jan 2, 2024 at 11:55 PM Lynne wrote:
> Jan 2, 2024, 14:01 by nuomi2...@gmail.com:
>
> > On Mon, Jan 1, 2024 at 10:50 PM Lynne wrote:
> >
> >> Jan 1, 2024, 15:16 by nuomi2...@gmail.com:
> >>
> >> > + */
> >> > +void ff_vvc_inv_dct2_4(int *coeffs, const ptrdiff_t stride, const
> >> size_t
> Possible address trac issue:
http://trac.ffmpeg.org/ticket/10763
I don't like the random generator as it is, because the first two random numbers
are very close to zero, as can be shown with this command line:
ffmpeg -loglevel repeat -f lavfi -i nullsrc=size=1x1,format=gray -vf
Am 03.01.24 um 11:45 schrieb Gyan Doshi:
On 2024-01-03 03:46 pm, Thilo Borgmann via ffmpeg-devel wrote:
Am 03.01.24 um 11:10 schrieb Gyan Doshi:
On 2024-01-03 02:28 pm, Thilo Borgmann via ffmpeg-devel wrote:
Am 01.12.23 um 12:37 schrieb Paul B Mahol:
On Fri, Dec 1, 2023 at 12:24 PM Gyan
On 2024-01-03 03:46 pm, Thilo Borgmann via ffmpeg-devel wrote:
Am 03.01.24 um 11:10 schrieb Gyan Doshi:
On 2024-01-03 02:28 pm, Thilo Borgmann via ffmpeg-devel wrote:
Am 01.12.23 um 12:37 schrieb Paul B Mahol:
On Fri, Dec 1, 2023 at 12:24 PM Gyan Doshi wrote:
On 2023-09-25 11:35 pm,
Am 03.01.24 um 11:10 schrieb Gyan Doshi:
On 2024-01-03 02:28 pm, Thilo Borgmann via ffmpeg-devel wrote:
Am 01.12.23 um 12:37 schrieb Paul B Mahol:
On Fri, Dec 1, 2023 at 12:24 PM Gyan Doshi wrote:
On 2023-09-25 11:35 pm, Paul B Mahol wrote:
On 9/11/23, Harshit Karwal wrote:
1.
On 2024-01-03 02:28 pm, Thilo Borgmann via ffmpeg-devel wrote:
Am 01.12.23 um 12:37 schrieb Paul B Mahol:
On Fri, Dec 1, 2023 at 12:24 PM Gyan Doshi wrote:
On 2023-09-25 11:35 pm, Paul B Mahol wrote:
On 9/11/23, Harshit Karwal wrote:
1. Replaced ring buffer ADT with AVAudioFifo from
Am 01.12.23 um 12:37 schrieb Paul B Mahol:
On Fri, Dec 1, 2023 at 12:24 PM Gyan Doshi wrote:
On 2023-09-25 11:35 pm, Paul B Mahol wrote:
On 9/11/23, Harshit Karwal wrote:
1. Replaced ring buffer ADT with AVAudioFifo from libavutil/audio_fifo.h
2. Fixed potential freeing of uninitialised
57 matches
Mail list logo
