Signed-off-by: Shreesh Adiga <16567adigashre...@gmail.com>
---
v2: Tried to align operands and improve indentation for ASM routine.
libswscale/x86/rgb2rgb.c | 21 +
libswscale/x86/rgb_2_rgb.asm | 90 +++-
2 files changed, 80 insertions(+), 31 deletions(
On 2025-01-26 12:49 am, Marton Balint wrote:
On Sat, 25 Jan 2025, Gyan Doshi wrote:
In f121d95, the outlink framerate was unconditionally unset.
This breaks/bloats outputs from CFR muxers unless the user explicitly
sets a sane framerate. And the most common invocation for setpts seen in
wor
On Sat, Jan 25, 2025 at 6:24 PM Michael Niedermayer
wrote:
>
> Hi
>
> On Tue, Jan 21, 2025 at 06:20:27PM -0800, Pierre-Anthony Lemieux wrote:
> > You will need to add "c1p1_04-0.j2c" [1] to
> > "fate-suite\jpeg2000\itu-iso\codestreams_profile1".
> >
> > [1] https://github.com/user-attachments/fil
On Sat, Jan 18, 2025 at 11:12 PM Nuo Mi wrote:
>
>
> On Sat, Jan 18, 2025 at 4:18 AM Frank Plowman
> wrote:
>
>> When the chroma format changes mid-sequence, c->pix_fmt and s->pix_fmt
>> can get out-of-sync. More specifically,
>> 1. export_frame_params is called.
>>c->pix_fmt and s->pix_fmt
AVCodecContext->sw_pix_fmt is used to hold the software pixel format.
Co-authored-by: Frank Plowman
---
libavcodec/vvc/dec.c | 17 ++---
libavcodec/vvc/dec.h | 2 --
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index daf
fixes https://github.com/ffvvc/tests/tree/main/fuzz/passed/000323.bit
Co-authored-by: Frank Plowman
---
libavcodec/vvc/ps.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index c9f7c5c80f..01b4615eda 100644
--- a/libavcod
Downstream can determine the format from the output frame format
Co-authored-by: Frank Plowman
---
libavcodec/vvc/dec.c | 23 ++-
1 file changed, 2 insertions(+), 21 deletions(-)
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index 1cb168de7e..daf537294f 100644
---
Hi
On Tue, Jan 21, 2025 at 06:20:27PM -0800, Pierre-Anthony Lemieux wrote:
> You will need to add "c1p1_04-0.j2c" [1] to
> "fate-suite\jpeg2000\itu-iso\codestreams_profile1".
>
> [1] https://github.com/user-attachments/files/18033833/c1p1_04-0.zip
on x86-32 this fails:
--- src/tests/ref/fate/jp
Looks dead to me
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Marth64
> Sent: Sunday, January 26, 2025 1:14 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg12dec.c: rename
> 0x0502 CC format
>
> > they are broadcasting
> they are broadcasting using a variation of DVB-S (there is no US standard for
> sat tv), so the current naming is actually valid.
This is my understanding also, but I do believe there was 1 other
network that used the same variation.
Hence why I suggested a generic name. The counter argument fr
Hi Manuel
On Fri, Jan 24, 2025 at 11:58:00AM +0100, Manuel Lauss wrote:
> Thanks for the offer, but I know not nearly enough about the codec or
> ffmpeg to be a maintainer,
well, theres nothing you need to know about ffmpeg.
and about sanm you are the one working on it
> and this is also the la
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Scott Theisen
> Sent: Sunday, January 26, 2025 12:54 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg12dec.c: rename
> 0x0502 CC format
>
> On 1/25/25 18:28, Kieran Kunhya via ffmpeg-devel wrote
On Thu, Jan 23, 2025 at 12:46:50AM -0500, Sean McGovern wrote:
> Hi,
>
> On Thu, Jan 16, 2025 at 8:17 PM Michael Niedermayer
> wrote:
> >
> > Hi
> >
> > On Thu, Jan 16, 2025 at 04:57:13PM -0500, Sean McGovern wrote:
> > > On Thu, Jan 16, 2025 at 4:30 PM Sean McGovern wrote:
> > > >
> > > > This
On 1/25/25 18:28, Kieran Kunhya via ffmpeg-devel wrote:
On Sat, 25 Jan 2025, 22:53 Marth64, wrote:
Hello,
I am to blame here for suggesting DVB_0502 as the name.
I realize it was not the best choice and apologize for wasting your
cycles on this.
Looping in Keiran as we had discussed this ove
On Sat, 25 Jan 2025, 22:53 Marth64, wrote:
> Hello,
>
> I am to blame here for suggesting DVB_0502 as the name.
> I realize it was not the best choice and apologize for wasting your
> cycles on this.
>
> Looping in Keiran as we had discussed this over IRC briefly a few weeks
> back.
> As I don't
On Fri, 24 Jan 2025, Krzysztof Pyrkosz via ffmpeg-devel wrote:
This patch supplies handwritten NEON code for AAC.
The benchmarks below were collected by invoking these two commands on
each of my boards, A78, A72 and Thinkpad x13s:
1) ./tests/checkasm/checkasm --test=aacencdsp --bench --runs=12
On Sat, 25 Jan 2025, 21:49 Rémi Denis-Courmont, wrote:
> Le lauantaina 25. tammikuuta 2025, 22.26.44 UTC+2 Michael Niedermayer a
> écrit
> :
> > I had posted one joke on my personal twitter that i deleted a few hours
> > later as people seem to have misunderstood it.
>
> It is completely irreleva
Hello,
I am to blame here for suggesting DVB_0502 as the name.
I realize it was not the best choice and apologize for wasting your
cycles on this.
Looping in Keiran as we had discussed this over IRC briefly a few weeks back.
As I don't know how many networks actually use this in the wild, it
coul
Hello Michael,
Complaint acknowledged. In the spirit of moving forward and de-escalating:
Would you be open to a scheduled IRC meeting where we can talk through
some of the project issues in real time?
Ideally it is moderated by a neutral party to keep it civil and to the
point of project problem
Hi,
On Sat, Jan 25, 2025 at 9:26 AM Shreesh Adiga <16567adigashre...@gmail.com>
wrote:
> @@ -64,6 +64,18 @@ cglobal shuffle_bytes_%1%2%3%4, 3, 5, 2, src, dst, w,
> tmp, x
> adddstq, wq
> neg wq
>
> +%if mmsize == 64
> +and xq, mmsize-4
> +shr xq, 2
> +mov tm
Hello,
Just wanted to say thank you to everyone for participating, proposing
ideas, and even spinning up demo systems.
It's refreshing to see collective rallying and interest toward a goal.
We still have a ways to figure out details, but I think this is a
positive moment of collaboration.
__
Hello,
I would like to call for this thread to dissolve, it's getting ugly.
It's become a swirl of different grievances and the tone is toxic all around.
What is this good for besides draining away energy?
The thread's original scope has been outgrown.
We have some unresolved issues, sure.
Can w
Hello,
Looking forward to it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Le lauantaina 25. tammikuuta 2025, 22.26.44 UTC+2 Michael Niedermayer a écrit
:
> I had posted one joke on my personal twitter that i deleted a few hours
> later as people seem to have misunderstood it.
It is completely irrelevant whether you intended it as a joke or not. How
would you react if
Le lauantaina 25. tammikuuta 2025, 22.26.44 UTC+2 Michael Niedermayer a écrit
:
> On Fri, Jan 24, 2025 at 09:36:50PM +0200, Rémi Denis-Courmont wrote:
> I have not complained about "FFmpeg community members attending conferences
> and discussing FFmpeg". Your statement suggests i did that, which i
On Sat, 25 Jan 2025, Scott Theisen wrote:
The format is used by at least one DVB-S provider, but is not defined in any DVB
standard, so remove references to DVB. Since I don't have any standard that
does define this format, using the magic number as the name seems most
appropriate.
This is
On Thu, Jan 23, 2025 at 10:27:47PM +0100, Michael Niedermayer wrote:
> On Wed, Jan 22, 2025 at 09:36:09PM +0100, Michael Niedermayer wrote:
> > This blocks disallowed extensions from probing
> > It also requires all available segments to have matching extensions to the
> > format
> > mpegts is tre
Hi CC
please see my complaints inline below
On Fri, Jan 24, 2025 at 09:36:50PM +0200, Rémi Denis-Courmont wrote:
> Hello,
>
> Le tiistaina 21. tammikuuta 2025, 2.36.47 UTC+2 Michael Niedermayer a écrit :
> > Hi
> >
> > On Mon, Jan 20, 2025 at 10:38:17AM -0600, Marth64 wrote:
> > > All this time
The format is used by at least one DVB-S provider, but is not defined in any DVB
standard, so remove references to DVB. Since I don't have any standard that
does define this format, using the magic number as the name seems most
appropriate.
This is a simple rename, no functional change.
Th
It's no longer needed after the addition of av_frame_side_data_new_struct()
Signed-off-by: James Almer
---
libavutil/stereo3d.c | 2 ++
libavutil/stereo3d.h | 6 ++
2 files changed, 8 insertions(+)
diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
index d6de476532..8a21cfd407 100644
It's no longer needed after the addition of av_frame_side_data_new_struct()
Signed-off-by: James Almer
---
libavutil/mastering_display_metadata.c | 4
libavutil/mastering_display_metadata.h | 10 ++
2 files changed, 14 insertions(+)
diff --git a/libavutil/mastering_display_metadat
It's no longer needed after the addition of av_frame_side_data_new_struct()
Signed-off-by: James Almer
---
libavutil/hdr_dynamic_vivid_metadata.c | 2 ++
libavutil/hdr_dynamic_vivid_metadata.h | 6 ++
2 files changed, 8 insertions(+)
diff --git a/libavutil/hdr_dynamic_vivid_metadata.c
b/li
It's no longer needed after the addition of av_frame_side_data_new_struct()
Signed-off-by: James Almer
---
libavutil/hdr_dynamic_metadata.c | 2 ++
libavutil/hdr_dynamic_metadata.h | 6 ++
2 files changed, 8 insertions(+)
diff --git a/libavutil/hdr_dynamic_metadata.c b/libavutil/hdr_dynamic
Similar in purpose as the packet side data of the same name, but for encoders.
Signed-off-by: James Almer
---
An example of RefCount used for side data, including a copy and uninit callback
to handle allocations within the entry.
libavutil/frame.h | 14 ++
libavutil/side_data.c
With this, complex structs can be used as side data entries.
Signed-off-by: James Almer
---
libavutil/frame.c | 7 +-
libavutil/side_data.c | 209 +-
libavutil/side_data.h | 3 +
3 files changed, 210 insertions(+), 9 deletions(-)
diff --git a/liba
It's no longer needed after the addition of av_frame_side_data_new_struct()
Signed-off-by: James Almer
---
libavutil/downmix_info.c | 2 ++
libavutil/downmix_info.h | 6 ++
2 files changed, 8 insertions(+)
diff --git a/libavutil/downmix_info.c b/libavutil/downmix_info.c
index c634c6a79f..73
As well as the AV_SIDE_DATA_PROP_STRUCT prop, to define types that describe
a fixed-size C struct and not a flat byte array.
This excludes types like VIDEO_ENC_PARAMS as the struct it describes may have
extra bytes allocated past the end of the struct.
Signed-off-by: James Almer
---
libavutil/am
It's no longer needed after the addition of av_frame_side_data_new_struct()
Signed-off-by: James Almer
---
libavutil/ambient_viewing_environment.c | 2 ++
libavutil/ambient_viewing_environment.h | 6 ++
libavutil/version.h | 1 +
3 files changed, 9 insertions(+)
diff --g
Signed-off-by: James Almer
---
libavutil/frame.h | 19 ++
libavutil/side_data.c | 45 +++
2 files changed, 64 insertions(+)
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 019adaac0e..aa4e619ad2 100644
--- a/libavutil/frame.h
+
This is in preparation for a new type of backing for the side data that will be
introduced in a following commit. The user only cares about the data pointer.
Signed-off-by: James Almer
---
libavutil/frame.h | 3 +++
libavutil/side_data.c | 48 +++
lib
Will be useful in the following commits to add fields that don't need to be
exposed.
Signed-off-by: James Almer
---
libavutil/side_data.c | 70 +++
1 file changed, 37 insertions(+), 33 deletions(-)
diff --git a/libavutil/side_data.c b/libavutil/side_data.
Will be useful in the following commits to add fields that don't need to be
exposed.
Signed-off-by: James Almer
---
libavutil/side_data.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavutil/side_data.c b/libavutil/side_data.c
index 5770be0639..eb6e001f94 1006
Should reduce clutter in frame.c, plus allow us to make opaque changes to
side data handling.
Signed-off-by: James Almer
---
libavutil/Makefile| 1 +
libavutil/frame.c | 318 +-
libavutil/side_data.c | 313
Signed-off-by: Marton Balint
---
libavcodec/libxvid.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/libxvid.c b/libavcodec/libxvid.c
index fbd33b7065..850e691403 100644
--- a/libavcodec/libxvid.c
+++ b/libavcodec/libxvid.c
@@ -617,6 +617,10 @@ static av_cold int xvid_encode_i
Found out to have been utilized via a user reporting an attached
image not being available in a player utilizing avformat's demuxing
capabilities.
---
libavformat/id3v2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
index 3507885706..29ee59e1f4 1006
On Sun, 12 Jan 2025, Michael Niedermayer wrote:
On Sat, Jan 11, 2025 at 02:11:33PM +0100, Marton Balint wrote:
Make the checker functions available for all codecs.
Signed-off-by: Marton Balint
---
libavcodec/encode.c| 19 +++
libavcodec/encode.h| 9 +++
On Sat, 25 Jan 2025, Gyan Doshi wrote:
In f121d95, the outlink framerate was unconditionally unset.
This breaks/bloats outputs from CFR muxers unless the user explicitly
sets a sane framerate. And the most common invocation for setpts seen in
workflows, our docs and across the web is `PTS-STA
On 25.01.25 08:54, Soft Works wrote:
Gitea
https://gitea.com/ffstaging/FFmpeg
forgejo
https://v10.next.forgejo.org/ffstaging/FFmpeg
GitLab
https://gitlab.com/ffstaging/FFmpeg
Perhaps you should also add a `radicle` (https://radicle.xyz/) test
repo
This was nothing official nor plann
Hi Soft Works
On Tue, Jan 21, 2025 at 06:52:27AM +, Soft Works wrote:
[...]
> > We need plugins
> > please lobby for a plugin architecture
>
> I'd love to see an extensibility model, I have one or two things for which
> there's clearly no place in the ffmpeg codebase.
> But this can't be a r
Hi Lynne
On Sat, Jan 25, 2025 at 11:06:43AM +0900, Lynne wrote:
>
>
> On 25/01/2025 06:54, Michael Niedermayer wrote:
> > On Tue, Jan 21, 2025 at 03:10:47PM +, Lynne wrote:
> > > ffmpeg | branch: master | Lynne | Sun Jan 5 13:42:47
> > > 2025 +0900| [7187eadf8c0f0c640f1d23811c55fad0cba60a
On 1/25/2025 12:50 PM, Shreesh Adiga wrote:
Try running it several times using the same seed, so
"tests/checkasm/checkasm --test=sw_rgb --bench 17575157", and make sure
no power saving feature is enabled (so the CPU frequency doesn't change
based on load). That may help getting consistent results
> Try running it several times using the same seed, so
> "tests/checkasm/checkasm --test=sw_rgb --bench 17575157", and make sure
> no power saving feature is enabled (so the CPU frequency doesn't change
> based on load). That may help getting consistent results.
After running "echo performance | t
On 1/25/2025 12:11 PM, Shreesh Adiga wrote:
Thanks for the patch. Could you please compile and run
tests/checkasm/checkasm with "--test=sw_rgb --bench" and paste the
results for the shuffle_bytes functions, to see if there's a speed up
compared to the AVX2 implementation?
I ran the command "tes
> Thanks for the patch. Could you please compile and run
> tests/checkasm/checkasm with "--test=sw_rgb --bench" and paste the
> results for the shuffle_bytes functions, to see if there's a speed up
> compared to the AVX2 implementation?
I ran the command "tests/checkasm/checkasm --test=sw_rgb --be
On 1/25/2025 11:25 AM, Shreesh Adiga wrote:
Signed-off-by: Shreesh Adiga <16567adigashre...@gmail.com>
---
libswscale/x86/rgb2rgb.c | 21 +
libswscale/x86/rgb_2_rgb.asm | 28
2 files changed, 49 insertions(+)
Thanks for the patch. Could y
Signed-off-by: Shreesh Adiga <16567adigashre...@gmail.com>
---
libswscale/x86/rgb2rgb.c | 21 +
libswscale/x86/rgb_2_rgb.asm | 28
2 files changed, 49 insertions(+)
diff --git a/libswscale/x86/rgb2rgb.c b/libswscale/x86/rgb2rgb.c
index 6790551a
> On Jan 24, 2025, at 10:40 PM, Martin Storsjö wrote:
>
> Traditionally, macOS has shipped an old version of rsync that lacked
> support for this version, hence this check (added in
> a8b3f0c5cf548f654e30c981988bb71981a3f8d3).
>
> However, in macOS 15.x, they have switched to providing rsync a
In f121d95, the outlink framerate was unconditionally unset.
This breaks/bloats outputs from CFR muxers unless the user explicitly
sets a sane framerate. And the most common invocation for setpts seen in
workflows, our docs and across the web is `PTS-STARTPTS` or others of the
general form `PTS+con
59 matches
Mail list logo
