In f121d95, the outlink framerate was unconditionally unset.
This breaks/bloats outputs from CFR muxers unless the user explicitly
set 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
form `PTS+constant` wh
Pls. ignore. Typo corrected in v2
On 2025-01-23 11:03 am, Gyan Doshi wrote:
In f121d95, the outlink framerate was unconditionally unset.
This breaks/bloats outputs from CFR muxers unless the user explicitly
set a sane framerate. And the most common invocation for setpts seen in
workflows, our do
In f121d95, the outlink framerate was unconditionally unset.
This breaks/bloats outputs from CFR muxers unless the user explicitly
set 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
form `PTS+constant` wh
Ping, would appreciate it, if somebody would comment / push the patch.
---
Kirill Gavrilov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe,
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 was disabled in da60b99a8857d5ca236f32c1799a066e0135a866 and then
> > > accidentally
In f121d95, the outlink framerate was unconditionally unset.
This breaks/bloats outputs from CFR muxers unless the user explicitly
set 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
form `PTS+constant` wh
Hi Kieran
On Wed, Jan 22, 2025 at 10:47:52PM +, Kieran Kunhya via ffmpeg-devel wrote:
> On Wed, 22 Jan 2025, 20:36 Michael Niedermayer,
> wrote:
>
> > This blocks disallowed extensions from probing
> > It also requires all available segments to have matching extensions to the
> > format
> >
On Wed, 22 Jan 2025, 20:36 Michael Niedermayer,
wrote:
> This blocks disallowed extensions from probing
> It also requires all available segments to have matching extensions to the
> format
> mpegts is treated independent of the extension
>
Potentially this is a stupid question but what stops an
On 22 Jan 2025, at 22:59, Alexander Strasser via ffmpeg-devel wrote:
> Since av_match_list was added in commit 0d92b0d5f445d4f2 , this
> function changed its semantics shortly after, especially with
> commit 3c0b98dced394da3 .
>
> Signed-off-by: Alexander Strasser
> ---
> libavutil/avstring.h
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Wednesday, January 22, 2025 9:51 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Democratization
>
> Michael Niedermayer (12025-01-21):
> > You have worded
Since av_match_list was added in commit 0d92b0d5f445d4f2 , this
function changed its semantics shortly after, especially with
commit 3c0b98dced394da3 .
Signed-off-by: Alexander Strasser
---
libavutil/avstring.h | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git
On 22 Jan 2025, at 20:32, Dmitrii Ovchinnikov wrote:
> Adds hwcontext_amf, enabling a shared AMF context for encoders,
> decoders, and AMF-based filters, without copy to the host memory.
> Code also was tested in HandBrake.
>
> Benefits:
> - Optimizations for direct video memory access from CP
Nicolas George (12025-01-22):
> That limitation of side data is very annoying. We should get rid of it,
> especially since it is not that hard.
>
> The issue is that side data has to be flat because its refcounting is
> built on top of AVBufferRef when AVBufferRef if only good for flat data
> (if
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Wednesday, January 22, 2025 9:01 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Is the GA democratic ?
>
> Michael Niedermayer (12025-01-21):
> > Being a "
James Almer (12025-01-22):
> Actually, i just realized i can't store an AVDictionary or a string in a
> struct like this that's meant to be stored as side data. It has a to be a
> flat array with no pointers to separate arrays.
Hum, good point.
That limitation of side data is very annoying. We sh
On 1/22/2025 5:18 PM, Nicolas George wrote:
James Almer (12025-01-22):
Ok, will implement a new struct.
Thanks.
I think this code would work:
typedef struct AVSideDataParamChange
…
intmax_t end_padding;
} AVSideDataSomethingType;
Actually, i just realized i can't store an AVDicti
Michael Niedermayer (12025-01-21):
> You have worded this well
Thanks (assuming you are not saying it to the “+1”).
> Id like to add that this matches my understanding of what maintainers should
> be. (actual "leaders" in their areas)
>
> As side effect this would make things more scaleable too.
On Sat, Nov 9, 2024 at 5:40 PM Michael Niedermayer
wrote:
>
> On Fri, Nov 08, 2024 at 01:09:34PM -0800, p...@sandflow.com wrote:
> > From: Pierre-Anthony Lemieux
> >
> > ---
> > tests/fate/jpeg2000.mak | 122 ++-
> > tests/ref/fate/jpeg2000dec-ds0_hm_15_b8 |
James Almer (12025-01-20):
> Partial support for MV-HEVC, partial support for IAMF (no rendering, only
> demuxing/muxing), partial support for tiled HEIF (no stitching), the new VVC
> decoder that's afaik not 100% complete, a PTS reorder bsf that's missing
> some edge cases and support for HEVC and
The next commit implements the hls fix in a way that doesnt need this
This reverts commit 54897da7ce8ae6e349cd56d0f11cb2404e264efa.
---
libavformat/mpegts.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 1337aa12030..765bedec5cc 100644
--- a/l
This blocks disallowed extensions from probing
It also requires all available segments to have matching extensions to the
format
mpegts is treated independent of the extension
It is recommended to set the whitelists correctly
instead of depending on extensions, but this should help a bit,
and thi
James Almer (12025-01-22):
> Ok, will implement a new struct.
Thanks.
I think this code would work:
typedef struct AVSideDataParamChange
…
intmax_t end_padding;
} AVSideDataSomethingType;
static const AVSideDataParamChange default = { ... };
AVSideDataParamChange pc;
av_assert
Michael Niedermayer (12025-01-21):
> Being a "member of the commuity" should give them a vote if you want to
> call it a democracy in relation to the FFmpeg community
At this point I think it would be very useful if you took the time to
write down the reasons you think this whole thing is a good i
On 1/22/2025 4:49 PM, Nicolas George wrote:
James Almer (12025-01-22):
New fields can be added this way too. The reason i didn't make it a struct
is that i wanted to introduce the least amount of new public
defines/symbols, thus reusing the packet side data implementation.
Let us make the pack
James Almer (12025-01-22):
> New fields can be added this way too. The reason i didn't make it a struct
> is that i wanted to introduce the least amount of new public
> defines/symbols, thus reusing the packet side data implementation.
Let us make the packet side data a struct too. This version is
Co-authored-by: Evgeny Pavlov
v3: cleanup code
---
libavcodec/amfenc.c | 873 +--
libavcodec/amfenc.h | 34 +-
libavcodec/amfenc_av1.c | 8 +-
libavcodec/amfenc_h264.c | 6 +-
libavcodec/amfenc_hevc.c | 6 +-
5 files changed, 305 insertions(+)
From: Evgeny Pavlov
Signed-off-by: Evgeny Pavlov
---
doc/filters.texi | 236 +++
1 file changed, 236 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index b926b865ae..39f54f5e0c 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -
From: Evgeny Pavlov
Added AMF based h264, hevc, av1 decoders.
Co-authored-by: Dmitrii Ovchinnikov
v2: added encoder reinitialisation
v3: use AMF_SURFACE_UNKNOWN to int decoder(ctx->output_format before)
---
configure | 3 +
libavcodec/Makefile| 7 +-
libavcodec/allcodecs.c
From: Evgeny Pavlov
This commit adds two AMF filters: vpp_amf & sr_amf.
Both filters are using AMF hardware acceleration.
vpp_amf supports simple scaling algorithms & color conversion.
sr_amf supports advanced scaling algorithms such as FSR & can
be used for upscaling only.
---
configure
Adds hwcontext_amf, enabling a shared AMF context for encoders,
decoders, and AMF-based filters, without copy to the host memory.
Code also was tested in HandBrake.
Benefits:
- Optimizations for direct video memory access from CPU
- Significant performance boost in full AMF pipelines with filte
On Tue, Jan 14, 2025 at 2:02 PM Abdulrahman Saber wrote:
>
> Signed-off-by: abdo
> ---
> libavfilter/vf_signalstats.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_signalstats.c b/libavfilter/vf_signalstats.c
> index b1451cc465..9b6af8becd 100644
> -
> Can you please stop this "my way or no way"
The irony is not lost on me of this sentence (from the person banning
people, censoring people, creating paranoid theories about the GA).
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://
On Thu, Jan 16, 2025 at 8:15 PM Romain Beauxis wrote:
>
> This patch implements the decoding logic for the FEC error-
> correction method described in the Pro-MPEG CoP #3-R2 FEC[1]
>
> We are still in the process of testing this patch with our encoders but
> I wanted to send it now in case it coul
Hi
On Tue, Jan 21, 2025 at 08:05:05PM -0300, James Almer wrote:
> On 1/21/2025 6:10 PM, Michael Niedermayer wrote:
> > Hi
> >
> > On Tue, Jan 21, 2025 at 02:53:36PM -0300, James Almer wrote:
> > > On 1/21/2025 2:41 PM, Michael Niedermayer wrote:
> > > > Hi
> > > >
> > > > As people likely know i
On Wed, Jan 22, 2025 at 4:37 PM Michael Niedermayer
wrote:
>
> Hi
>
> On Mon, Jan 20, 2025 at 03:00:17PM +, Kieran Kunhya via ffmpeg-devel
> wrote:
> [...]
>
> > Error recovery protocols are complicated -
>
> everything is complicated
>
>
> > this project lacks
> > experience in them
>
> The
On Wed, Jan 22, 2025 at 4:53 PM Romain Beauxis wrote:
>
> Le mer. 22 janv. 2025 à 10:29, Kieran Kunhya via ffmpeg-devel
> a écrit :
> >
> > On Wed, Jan 22, 2025 at 3:33 PM Michael Niedermayer
> > wrote:
> > >
> > > On Mon, Jan 20, 2025 at 06:46:46AM +, Kieran Kunhya via ffmpeg-devel
> > > w
On Wed, Jan 22, 2025 at 4:37 PM Michael Niedermayer
wrote:
>
> Hi
>
> On Mon, Jan 20, 2025 at 03:00:17PM +, Kieran Kunhya via ffmpeg-devel
> wrote:
> [...]
>
> > Error recovery protocols are complicated -
>
> everything is complicated
>
>
> > this project lacks
> > experience in them
>
> The
Le mer. 22 janv. 2025 à 10:29, Kieran Kunhya via ffmpeg-devel
a écrit :
>
> On Wed, Jan 22, 2025 at 3:33 PM Michael Niedermayer
> wrote:
> >
> > On Mon, Jan 20, 2025 at 06:46:46AM +, Kieran Kunhya via ffmpeg-devel
> > wrote:
> > > >
> > > > > The data arrives on multiple sockets, leading to
Hi
On Mon, Jan 20, 2025 at 03:00:17PM +, Kieran Kunhya via ffmpeg-devel wrote:
[...]
> Error recovery protocols are complicated -
everything is complicated
> this project lacks
> experience in them
The project is made of many developers, and several of them do have
experience in protocols
On Wed, Jan 22, 2025 at 3:33 PM Michael Niedermayer
wrote:
>
> On Mon, Jan 20, 2025 at 06:46:46AM +, Kieran Kunhya via ffmpeg-devel
> wrote:
> > >
> > > > The data arrives on multiple sockets, leading to all sorts
> > > > of opportunities for timing behavior and reordering issues.
> > >
> > >
On Mon, Jan 20, 2025 at 06:46:46AM +, Kieran Kunhya via ffmpeg-devel wrote:
> >
> > > The data arrives on multiple sockets, leading to all sorts
> > > of opportunities for timing behavior and reordering issues.
> >
> > how does this matter?
> >
>
> There are routers that put traffic on a diffe
On Fri, 17 Jan 2025 22:38:03 -0300 James Almer wrote:
> Values in csp, prim, trc, etc, are irrelevant if there's no conversion needed.
>
> Signed-off-by: James Almer
> ---
> ./ffmpeg -i https://0x0.st/8Hr_.mp4 -vf "scale=1920:1080" -f null -
>
> Fails without this patch, because swscale lacks con
Hi Peter
On Wed, Jan 22, 2025 at 07:02:07PM +1100, Peter Ross wrote:
> On Tue, Jan 21, 2025 at 09:57:43PM +, Michael Niedermayer wrote:
> > ffmpeg | branch: master | Michael Niedermayer |
> > Thu Dec 26 02:53:45 2024 +0100| [17b019c517af26c6d2f0c6266938c60d36db1fa3]
> > | committer: Michael
On 1/22/2025 12:13 AM, Lynne wrote:
On 22/01/2025 11:53, James Almer wrote:
Equivalent to the one from packet side data using
AVSideDataParamChangeFlags,
and will be used for the same purpose with encoders.
Signed-off-by: James Almer
---
libavutil/frame.c | 1 +
libavutil/frame.h | 13 +
Marth64 (12025-01-20):
> This is fine and your preferences are understandable. Everyone has
> their tools of choice.
>
> That said, I did try Forgejo on a local instance today without
> JavaScript and it was not a usable experience for a contributor.
> I could do some limited functions but not rai
Le 17/01/2025 à 21:43, Michael Niedermayer a écrit :
On Fri, Jan 17, 2025 at 12:38:02PM +0100, Jerome Martinez wrote:
[...]
Subject: [PATCH] avformat: add DAT demuxer
breaks fate-cdxl-pal8-small
I guess the probe function is not working as expected
cdxl parser provides a read_probe value of
The table is only set when f->ac is set to CUSTOM. Setting it
for default range coder tables simplifies hardware accelerator code.
---
libavcodec/ffv1dec.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 46db9c..f5ccf41f38 10064
On Tue, Jan 21, 2025 at 09:57:43PM +, Michael Niedermayer wrote:
> ffmpeg | branch: master | Michael Niedermayer | Thu
> Dec 26 02:53:45 2024 +0100| [17b019c517af26c6d2f0c6266938c60d36db1fa3] |
> committer: Michael Niedermayer
>
> avformat/wtvdec: Initialize buf
>
> ff_parse_mpeg2_descript
48 matches
Mail list logo
