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
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,
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
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
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
> -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 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
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 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
> 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 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
> -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 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
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
> 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 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
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
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 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
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
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 ++
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
>>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
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
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 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
> -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
> -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
>
> 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
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
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
> 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
33 matches
Mail list logo
