Hi,
On Sun, Jan 26, 2025 at 2:32 PM Marton Balint wrote:
>
>
> On Sun, 26 Jan 2025, Gyan Doshi wrote:
>
> >
> >
> > On 2025-01-26 07:09 pm, Ronald S. Bultje wrote:
> >> Hi,
> >>
> >> On Sat, Jan 25, 2025 at 11:06 PM Gyan Doshi wrote:
> >>
> >>>
> >>> On 2025-01-26 12:49 am, Marton Balint wro
James Almer:
> Allow the caller to pass a dictionary with key/value pairs to set encoder
> private options for reinitialization.
> AVCodecContext global options are not affected. For that, specific
> AVSideDataParamChangeFlags should be used, as is currently the case for
> dimensions and sample rat
On 1/27/2025 10:26 AM, Andreas Rheinhardt wrote:
James Almer:
Allow the caller to pass a dictionary with key/value pairs to set encoder
private options for reinitialization.
AVCodecContext global options are not affected. For that, specific
AVSideDataParamChangeFlags should be used, as is curren
>>That’s 404 as the l of html is missing
typo in link, it should be
https://www.amd.com/en/products/accelerators/alveo/ma35d.html
>>Do you have any instructions how to test this with the MA35D card
This work is still in progress, and once it's completed,
I will send separate patches to enable this
On 2025-01-27 05:42 pm, Ronald S. Bultje wrote:
Hi,
On Sun, Jan 26, 2025 at 2:32 PM Marton Balint wrote:
On Sun, 26 Jan 2025, Gyan Doshi wrote:
On 2025-01-26 07:09 pm, Ronald S. Bultje wrote:
Hi,
On Sat, Jan 25, 2025 at 11:06 PM Gyan Doshi wrote:
On 2025-01-26 12:49 am, Marto
James Almer:
> They don't belong anywhere in particular, so move them to a new generic header
> called defs.h, following the same idea as the one from lavc.
>
> Signed-off-by: James Almer
> ---
> libavutil/avutil.h | 94 +++-
> libavutil/defs.h | 149 ++
James Almer:
> With this, callers can signal supported encoders to reinitialize using certain
> parameters, which should allow for more graceful (but potentially more limited
> in scope) reinitialization than closing and reopening the encoder, or even
> simply on-the-fly changes of trivial values t
On 1/27/2025 9:48 AM, Andreas Rheinhardt wrote:
James Almer:
With this, callers can signal supported encoders to reinitialize using certain
parameters, which should allow for more graceful (but potentially more limited
in scope) reinitialization than closing and reopening the encoder, or even
si
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Soft Works
> Sent: Monday, January 27, 2025 11:00 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Marth64 ; Kieran Kunhya
>
> Subject: Re: [FFmpeg-devel] [PATCH v2 00/11] fix broken CC detection
> and
On 2025-01-27 10:10 am, 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-S
>
> While this is a very valid concern for some kinds of frame side data, it
> does not apply to CC data. It's either in every frame or none. If a
> provider generally broadcasts CC, then it's always present in every frame,
> even during programs for which no CC is available - it's always there. Li
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Kieran Kunhya via ffmpeg-devel
> Sent: Monday, January 27, 2025 10:40 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Kieran Kunhya ; Marth64
>
> Subject: Re: [FFmpeg-devel] [PATCH v2 00/11] fix broken C
Hi Marth64,
first of all, thanks for taking on solving this long-standing broken feature.
My earlier submission
(https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=5031) didn't find
much love, so I had given up proposing, yet I can say that multiple millions of
files got probed with it
On Sun, Jan 26, 2025 at 10:24 PM Michael Niedermayer
wrote:
> Hi Kieran
>
> On Sun, Jan 26, 2025 at 07:39:38PM +, Kieran Kunhya via ffmpeg-devel
> wrote:
> > > I remember such a IRC session before the libav fork.
> > > It is very similar to this here
> > > 4+ people, who simply accuse me of e
This fixes the criterion when to split the segments based on the
elapsed time for the current segment instead of using the theoretical
elapsed time since start based on hls_time and the number of written
segments.
hls_time is used to define the minimum length of a segment, however
this is not resp
> On 24 Jan 2025, at 16:30, Gyan Doshi wrote:
>
>
>
> On 2025-01-24 05:29 pm, Ingo Oppermann wrote:
>> This fixes the criterion when to split the segments based on the elapsed time
>> for the current segment instead of using the theoretical elapsed time since
>> start based on hls_time and th
On 2025-01-27 01:56 pm, Ingo Oppermann wrote:
On 24 Jan 2025, at 16:30, Gyan Doshi wrote:
On 2025-01-24 05:29 pm, Ingo Oppermann wrote:
This fixes the criterion when to split the segments based on the elapsed time
for the current segment instead of using the theoretical elapsed time since
On Sun, Jan 26, 2025 at 01:29:38AM +0200, Martin Storsjö wrote:
> With the following diff:
>
> @@ -40,8 +41,8 @@ function ff_aac_quant_bands_neon, export=1
> moviv5.4s, 0x80, lsl #24
> .irp signed,1,0
> \signed:
> -subsw3, w3, #4
> ld1
> Do you have an example stream recording?
> And who are those who wouldn't be following? Broadcasters?
For what it's worth, I have seen this and it can definitely happen.
It's not common though since it both technically violates the spec and
also not best practice (for example, some televisions w
> On 27 Jan 2025, at 11:41, Gyan Doshi wrote:
>
>
>
> On 2025-01-27 01:56 pm, Ingo Oppermann wrote:
>>> On 24 Jan 2025, at 16:30, Gyan Doshi wrote:
>>>
>>>
>>>
>>> On 2025-01-24 05:29 pm, Ingo Oppermann wrote:
This fixes the criterion when to split the segments based on the elapsed
On Mon, Jan 27, 2025 at 9:23 PM Marton Balint wrote:
>
>
>
> On Mon, 27 Jan 2025, Gyan Doshi wrote:
>
> > The ref input may have its frame rate unset, which would then lead to
> > SIGFPE.
> >
> > Related to #11428
> > ---
> > libavfilter/vf_xpsnr.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 de
On Wed, Jan 22, 2025 at 2:39 PM Nicolas George wrote:
>
> 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 experienc
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Devin Heitmueller
> Sent: Monday, January 27, 2025 9:16 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Marth64 ; Kieran Kunhya
>
> Subject: Re: [FFmpeg-devel] [PATCH v2 00/11] fix broken CC detection
On 27.01.2025 21:39, Jan Ekström wrote:
On Wed, Jan 22, 2025 at 2:39 PM Nicolas George wrote:
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
> From: ffmpeg-devel On Behalf Of
> Kieran Kunhya via ffmpeg-devel
> Sent: Monday, January 27, 2025 10:40 AM
> > While this is a very valid concern for some kinds of frame side
> data, it
> > does not apply to CC data. It's either in every frame or none. If a
> > provider generally broadcasts CC,
On Mon, 27 Jan 2025, Gyan Doshi wrote:
The ref input may have its frame rate unset, which would then lead to
SIGFPE.
Related to #11428
---
libavfilter/vf_xpsnr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_xpsnr.c b/libavfilter/vf_xpsnr.c
index 1b2c2a7
On Mon, Jan 27, 2025 at 7:03 PM Soft Works wrote:
>
> > From: ffmpeg-devel On Behalf Of
> > Kieran Kunhya via ffmpeg-devel
> > Sent: Monday, January 27, 2025 10:40 AM
> > > While this is a very valid concern for some kinds of frame side
> > data, it
> > > does not apply to CC data. It's either in
> -Original Message-
> From: Kieran Kunhya
> Sent: Monday, January 27, 2025 8:26 PM
> To: Soft Works
> Cc: FFmpeg development discussions and patches de...@ffmpeg.org>; Marth64
> Subject: Re: [FFmpeg-devel] [PATCH v2 00/11] fix broken CC detection
> and ffprobe fields (cover letter)
>
On Sat, Jan 25, 2025 at 9:38 PM Jan Ekström wrote:
>
> Found out to have been utilized via a user reporting an attached
> image not being available in a player utilizing avformat's demuxing
> capabilities.
> ---
Asked around in the audio player circles of foobar2000, and these sort
of files seem
On Sat, Jan 25, 2025 at 9:38 PM Michael Niedermayer
wrote:
> 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 segm
On Fri, Jan 24, 2025 at 07:40:40PM -0600, Romain Beauxis wrote:
> Hi all!
>
> Le sam. 18 janv. 2025 à 11:54, Romain Beauxis
> a écrit :
> >
> > This patch makes sure that ogg/flac headers are parsed again when
> > encountering a new logic stream inside a chained ogg bistream[1].
> >
> > This patc
Hi
Everyone interested in mentoring a project in 2025, please add your idea(s) to
[1].
during February 11 - 26 "Google program administrators review organization
applications"
That means that by February 11th the list of ideas must be completed
[1] https://trac.ffmpeg.org/wiki/SponsoringProgra
For Fragmented MP4 files where the audio and video streams are written to
seperate fragments, the -ss option will cause the file pointer to be set to the
first available fragment. This is due to an interaction in
search_frag_timestamp() function and get_frag_time() functions.
With this change,
33 matches
Mail list logo
