---
libavcodec/mfenc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/mfenc.c b/libavcodec/mfenc.c
index 30531fe3e8..942c75cb9d 100644
--- a/libavcodec/mfenc.c
+++ b/libavcodec/mfenc.c
@@ -148,6 +148,15 @@ static int64_t mf_sample_get_pts(AVCodecContext *avctx,
IMFSamp
On Thu, Jul 17, 2025 at 6:57 PM Desmond Liu wrote:
> > For what it's worth -- I've used the netint.com/contact-us/ contact
> form to
> > submit this request on July 10th, 2025:
> > ```
> > I am interested in purchasing a netint card. Is there price list? Is
> there
> > a model that would work we
On Wed, Jul 9, 2025 at 11:41 AM Desmond Liu wrote:
> Hi Kieran,
>
> > Roughly one year ago I tried to buy one of these and I was asked to sign
> an
> > NDA.
>
>
> That was a "bug". You do not need to sign an NDA. If you have difficulty
> obtaining
> our hardware, contact me.
>
> Desmond
>
For
On Thu, Jul 3, 2025, 16:02 Michael Niedermayer
wrote:
> Hi Pavel
>
> On Mon, Jun 30, 2025 at 11:39:32PM -0600, Pavel Koshevoy wrote:
> > On Mon, Jun 30, 2025, 21:46 Michael Niedermayer
> > wrote:
> >
> > > On Mon, Jun 30, 2025 at 07:32:36PM -0600, Pavel Ko
On Mon, Jun 30, 2025, 21:46 Michael Niedermayer
wrote:
> On Mon, Jun 30, 2025 at 07:32:36PM -0600, Pavel Koshevoy wrote:
> > On Mon, Jun 30, 2025 at 3:46 PM Scott Theisen <
> > scott.the.elm-at-gmail@ffmpeg.org> wrote:
> >
> > > On 2025/06/29 23:55
On Mon, Jun 30, 2025 at 3:46 PM Scott Theisen <
scott.the.elm-at-gmail@ffmpeg.org> wrote:
> On 2025/06/29 23:55, Pavel Koshevoy wrote:
> > Make midstream AVStream.codecpar updates optional and disabled
> > by default, so that avformat API clients can enable this featur
Make midstream AVStream.codecpar updates optional and disabled
by default, so that avformat API clients can enable this feature
explicitly when they add support for midstream codec changes.
---
doc/APIchanges | 3 +++
libavformat/avformat.h | 2 ++
libavformat/mpegts.c| 4 +++-
libav
On Sun, Jun 29, 2025 at 7:01 PM Michael Niedermayer
wrote:
> Hi
>
> On Sat, Jun 28, 2025 at 08:49:08PM -0600, Pavel Koshevoy wrote:
> > On Sat, Jun 28, 2025 at 5:03 PM Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > Hi
> &g
On Sat, Jun 28, 2025 at 5:03 PM Michael Niedermayer
wrote:
> Hi
>
> On Sun, Jun 22, 2025 at 12:10:30PM -0600, Pavel Koshevoy wrote:
> > Make midstream AVStream.codecpar updates optional and disabled
> > by default, so that avformat API clients can enable this feature
> &g
ping
On Sun, Jun 22, 2025 at 12:10 PM Pavel Koshevoy wrote:
> Make midstream AVStream.codecpar updates optional and disabled
> by default, so that avformat API clients can enable this feature
> explicitly when they add support for midstream codec changes.
> ---
>
pushed in commit 59a6660625675c8343f3de858b93c8294f05bb52
On Tue, Jun 24, 2025 at 5:19 PM Pavel Koshevoy wrote:
> If I don't hear any objections in the next 72 hours I will apply this at
> that time, or later if I forget.
>
> Pavel.
>
>
> On Mon, Jun 23, 2025 at 2:37
If I don't hear any objections in the next 72 hours I will apply this at
that time, or later if I forget.
Pavel.
On Mon, Jun 23, 2025 at 2:37 PM Pavel Koshevoy wrote:
> ping ... as this is a segfault fix for `ffplay/ffprobe -i 1_poc.mp4` I
> think it deserves some review/approv
ping ... as this is a segfault fix for `ffplay/ffprobe -i 1_poc.mp4` I
think it deserves some review/approval priority.
On Mon, Jun 9, 2025 at 9:45 PM Pavel Koshevoy wrote:
> Fixes 'ffprobe 1_poc.mp4' segfault introduced with
> commit 0021484d05f9b0f032fa319399de6e24eea0c04f
I don't see this patch on https://patchwork.ffmpeg.org/project/ffmpeg/list/
... is patchwork broken?
On Sat, Jun 21, 2025 at 5:24 PM Pavel Koshevoy wrote:
> Make runtime AVStream.codecpar codec_id updates optional and disabled
> by default, so that avformat API clients can enable t
On Sun, Jun 22, 2025 at 1:26 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Pavel Koshevoy:
> > Make runtime AVStream.codecpar codec_id updates optional and disabled
> > by default, so that avformat API clients can enable this feature
> explicitly
>
Make midstream AVStream.codecpar updates optional and disabled
by default, so that avformat API clients can enable this feature
explicitly when they add support for midstream codec changes.
---
doc/APIchanges | 3 +++
doc/formats.texi| 5 +
libavformat/avformat.h
On Sat, Jun 21, 2025 at 3:38 PM Michael Niedermayer
wrote:
> On Sat, Jun 21, 2025 at 03:26:58PM -0600, Pavel Koshevoy wrote:
> > On Sat, Jun 21, 2025 at 3:21 PM Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > On Tue, Jun 17, 2025 at
ping
On Mon, Jun 9, 2025 at 9:45 PM Pavel Koshevoy wrote:
> Fixes 'ffprobe 1_poc.mp4' segfault introduced with
> commit 0021484d05f9b0f032fa319399de6e24eea0c04f
>
> codec_close should not assume that the codec_id did not change.
> ---
> libavformat/demux.c | 8 +
Make runtime AVStream.codecpar codec_id updates optional and disabled
by default, so that avformat API clients can enable this feature explicitly
when they add support for runtime codec changes.
---
doc/APIchanges | 3 +++
doc/formats.texi| 6 ++
libavformat/avformat
On Sat, Jun 21, 2025 at 3:21 PM Michael Niedermayer
wrote:
> On Tue, Jun 17, 2025 at 08:36:59AM -0600, Pavel Koshevoy wrote:
> > Make runtime AVStream.codecpar codec_id updates optional and disabled
> > by default, so that avformat API clients can enable this feature
> explic
ping
On Tue, Jun 17, 2025 at 8:37 AM Pavel Koshevoy wrote:
> Make runtime AVStream.codecpar codec_id updates optional and disabled
> by default, so that avformat API clients can enable this feature explicitly
> when they add support for runtime codec changes.
>
> Accordingly, cod
On Wed, Jun 11, 2025 at 4:14 AM Michael Niedermayer
wrote:
> Hi Pavel
>
> On Tue, Jun 10, 2025 at 05:36:14PM -0600, Pavel Koshevoy wrote:
> > On Tue, Jun 10, 2025 at 4:11 PM Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > Hi Pa
On Tue, Jun 17, 2025 at 12:42 PM Marton Balint wrote:
>
>
> On Tue, 17 Jun 2025, Pavel Koshevoy wrote:
>
> > Make runtime AVStream.codecpar codec_id updates optional and disabled
> > by default, so that avformat API clients can enable this feature
> explicitly
&g
On Tue, Jun 17, 2025 at 8:00 AM Pavel Koshevoy wrote:
>
>
> On Tue, Jun 17, 2025, 07:55 Pavel Koshevoy wrote:
>
>> Ping. I think I've addressed the concerns raised with the previous
>> patch.
>> Please let me know if I may commit this... it is a segfault fix
Make runtime AVStream.codecpar codec_id updates optional and disabled
by default, so that avformat API clients can enable this feature explicitly
when they add support for runtime codec changes.
Accordingly, codec_close should not assume that the codec_id cannot change.
This fixes 'ffprobe 1_poc.m
On Tue, Jun 17, 2025, 07:55 Pavel Koshevoy wrote:
> Ping. I think I've addressed the concerns raised with the previous
> patch.
> Please let me know if I may commit this... it is a segfault fix, so it
> probably should get some review priority.
>
> Thank you,
>
Ping. I think I've addressed the concerns raised with the previous patch.
Please let me know if I may commit this... it is a segfault fix, so it
probably should get some review priority.
Thank you,
Pavel
On Sun, Jun 15, 2025, 14:50 Pavel Koshevoy wrote:
> Make runtime AVStream.
Make runtime AVStream.codecpar codec_id updates optional and disabled
by default, so that avformat API clients can enable this feature explicitly
when they add support for runtime codec changes.
Accordingly, codec_close should not assume that the codec_id cannot change.
This fixes 'ffprobe 1_poc.m
On Sat, Jun 14, 2025 at 9:24 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Pavel Koshevoy:
> > Make runtime AVStream.codecpar codec_id updates optional and disabled
> > by default, so that avformat API clients can enable this feature
> explicitly
>
On Sat, Jun 14, 2025 at 3:56 PM Michael Niedermayer
wrote:
> On Sat, Jun 14, 2025 at 01:58:28PM -0600, Pavel Koshevoy wrote:
> > Make runtime AVStream.codecpar codec_id updates optional and disabled
> > by default, so that avformat API clients can enable this feature
> explic
Make runtime AVStream.codecpar codec_id updates optional and disabled
by default, so that avformat API clients can enable this feature explicitly
when they add support for runtime codec changes.
---
libavformat/mpegts.c | 8 +++-
tests/fate/demux.mak | 2 +-
2 files changed, 8 insertions(+), 2
On Fri, Jun 13, 2025 at 3:48 PM Pavel Koshevoy wrote:
>
>
> On Fri, Jun 13, 2025 at 2:46 PM Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>>
>>
>
>> Pavel, are you ok with this being reverted or do you want to submit a
>> patch that
demux.c:649)
> > ==1001752==by 0x66B594: read_frame_internal (demux.c:1346)
> > ==1001752==by 0x67085B: avformat_find_stream_info (demux.c:2692)
> > ==1001752==by 0x25157C: ifile_open (ffmpeg_demux.c:1814)
> > ==1001752==by 0x272B15: open_files (ffmpeg_opt.c:1366)
demux.c:649)
> > ==1001752==by 0x66B594: read_frame_internal (demux.c:1346)
> > ==1001752==by 0x67085B: avformat_find_stream_info (demux.c:2692)
> > ==1001752==by 0x25157C: ifile_open (ffmpeg_demux.c:1814)
> > ==1001752==by 0x272B15: open_files (ffmpeg_opt.c:1366)
On Tue, Jun 10, 2025 at 4:11 PM Michael Niedermayer
wrote:
> Hi Pavel
>
> On Tue, Jun 10, 2025 at 11:27:37AM -0600, Pavel Koshevoy wrote:
> > On Tue, Jun 10, 2025 at 9:29 AM Michael Niedermayer <
> mich...@niedermayer.cc>
> [...]
>
> > I have never had any int
On Tue, Jun 10, 2025 at 11:31 AM Nicolas George wrote:
> Pavel Koshevoy (HE12025-06-10):
> > ^ that's inflammatory
>
> No, that is just sarcastic.
>
>
it managed to ruin my morning ... no matter what you call it.
Pavel.
___
On Tue, Jun 10, 2025 at 9:29 AM Michael Niedermayer
wrote:
> Hi Pavel
>
>
>
> is adding an exploitable security issue an option for you ?
>
>
^ that's inflammatory, I have never had any intention of introducing a
security vulnerability.
If people want to keep this, it should be behind a flag
On Tue, Jun 10, 2025 at 9:29 AM Michael Niedermayer
wrote:
> Hi Pavel
>
> On Tue, Jun 10, 2025 at 08:42:08AM -0600, Pavel Koshevoy wrote:
> > On Tue, Jun 10, 2025, 07:39 Michael Niedermayer
> > wrote:
> >
> > > On Mon, Jun 09, 2025 at 09:45:28PM -0600,
On Tue, Jun 10, 2025, 07:39 Michael Niedermayer
wrote:
> On Mon, Jun 09, 2025 at 09:45:28PM -0600, Pavel Koshevoy wrote:
> > Fixes 'ffprobe 1_poc.mp4' segfault introduced with
> > commit 0021484d05f9b0f032fa319399de6e24eea0c04f
> >
> > codec_close should
Fixes 'ffprobe 1_poc.mp4' segfault introduced with
commit 0021484d05f9b0f032fa319399de6e24eea0c04f
codec_close should not assume that the codec_id did not change.
---
libavformat/demux.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavformat/demux.c b/libavformat/d
On Mon, Jun 9, 2025 at 8:58 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Pavel Koshevoy:
> > Fixes 'ffprobe 1_poc.mp4' segfault introduced with
> > commit 0021484d05f9b0f032fa319399de6e24eea0c04f
> > ---
> > libavformat/dem
Fixes 'ffprobe 1_poc.mp4' segfault introduced with
commit 0021484d05f9b0f032fa319399de6e24eea0c04f
---
libavformat/demux.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavformat/demux.c b/libavformat/demux.c
index ecd4f40da9..d74d51e169 100644
--- a/libavformat/
On Sun, May 18, 2025 at 9:00 AM Pavel Koshevoy wrote:
> pushed in commit 0021484d05f9b0f032fa319399de6e24eea0c04f
>
>
also backported to release/7.1, commit
24de8a98cfb33b10992772ba54f650eb61c96d44
and backported to release/6.1, commit
8723e83699471edff046279e5411ca8e6c1a1ea6
pushed in commit 0021484d05f9b0f032fa319399de6e24eea0c04f
Thank you,
Pavel.
On Wed, May 14, 2025 at 4:40 PM Pavel Koshevoy wrote:
> If there are no further comments I'll commit and push this some time
> during the weekend.
>
> Pavel.
>
>
> On Fri, May 9, 2025, 6:0
If there are no further comments I'll commit and push this some time during
the weekend.
Pavel.
On Fri, May 9, 2025, 6:01 PM Pavel Koshevoy wrote:
> I have a several .ts captures where video and audio codec changes
> even though the PMT version does not change and the PIDs st
I have a several .ts captures where video and audio codec changes
even though the PMT version does not change and the PIDs stay the same.
This happens during transition to/from slate (mpeg2 video and audio)
to network broadcast (hevc video and eac3 audio in private PES).
I've updated fate ts-demux
I will send a new patch with additional changes to handle stream_type ==
STREAM_TYPE_PRIVATE_DATA.
Pavel
On Tue, Apr 22, 2025 at 6:51 PM Pavel Koshevoy wrote:
> I have a couple of .ts captures where video and audio codec changes
> even though the PMT version does not change and th
On Sat, Apr 26, 2025 at 5:20 AM Michael Niedermayer
wrote:
> On Fri, Apr 25, 2025 at 11:45:08AM -0600, Pavel Koshevoy wrote:
> > On Fri, Apr 25, 2025 at 7:40 AM Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > On Tue, Apr 22, 2025 at
On Fri, Apr 25, 2025 at 7:40 AM Michael Niedermayer
wrote:
> On Tue, Apr 22, 2025 at 06:51:55PM -0600, Pavel Koshevoy wrote:
> > I have a couple of .ts captures where video and audio codec changes
> > even though the PMT version does not change and the PIDs stay the same.
>
On Fri, Apr 25, 2025 at 7:40 AM Michael Niedermayer
wrote:
> On Tue, Apr 22, 2025 at 06:51:55PM -0600, Pavel Koshevoy wrote:
> > I have a couple of .ts captures where video and audio codec changes
> > even though the PMT version does not change and the PIDs stay the same.
>
On Mon, Apr 21, 2025 at 2:58 PM Michael Niedermayer
wrote:
> Hi Pavel
>
> On Sat, Apr 19, 2025 at 10:18:29AM -0600, Pavel Koshevoy wrote:
> > I have a couple of .ts captures where video and audio codec changes
> > even though the PMT version does not change and t
I have a couple of .ts captures where video and audio codec changes
even though the PMT version does not change and the PIDs stay the same.
I've updated fate ts-demux expected results.
---
libavformat/mpegts.c| 2 +-
tests/ref/fate/ts-demux | 4 ++--
2 files changed, 3 insertions(+), 3 deleti
I have a couple of .ts captures where video and audio codec changes
even though the PMT version does not change and the PIDs stay the same.
---
libavformat/mpegts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 54594b3a11..8a7
On Thu, Feb 27, 2025 at 2:02 PM Michael Niedermayer
wrote:
> On Wed, Feb 26, 2025 at 03:11:13PM +0100, Tomas Härdin wrote:
> > sön 2025-02-23 klockan 22:51 +0100 skrev Michael Niedermayer:
> > > Hi
> > >
> > > On Sun, Feb 23, 2025 at 10:30:03PM +0100, Tomas Härdin wrote:
> > > > lör 2025-02-22 kl
On Wed, Feb 26, 2025 at 8:03 PM Zhao Zhili <
quinkblack-at-foxmail@ffmpeg.org> wrote:
>
>
> > On Feb 24, 2025, at 00:47, Pavel Koshevoy wrote:
> >
> > On Fri, Feb 21, 2025 at 9:49 AM Pavel Koshevoy
> wrote:
> >
> >> If there are no further
On Sun, Feb 23, 2025 at 9:47 AM Pavel Koshevoy wrote:
>
>
> On Fri, Feb 21, 2025 at 9:49 AM Pavel Koshevoy
> wrote:
>
>> If there are no further constructive review comments today and tomorrow
>> then I will commit and push this change on Sunday (if I don't forge
On Fri, Feb 21, 2025 at 9:49 AM Pavel Koshevoy wrote:
> If there are no further constructive review comments today and tomorrow
> then I will commit and push this change on Sunday (if I don't forget).
>
> Pavel.
>
Pushed in commit 5021764413a138f340ba46a9b145215b7535ea83
P
If there are no further constructive review comments today and tomorrow
then I will commit and push this change on Sunday (if I don't forget).
Pavel.
On Thu, Feb 13, 2025 at 2:22 PM Pavel Koshevoy wrote:
> The problem is reproducible with "Test for Quicktime 608 CC file.mov&
On Fri, Feb 14, 2025 at 5:30 AM Pavel Koshevoy wrote:
>
>
> On Thu, Feb 13, 2025, 22:04 Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> Pavel Koshevoy:
>> > The problem is reproducible with "Test for Quicktime 608 CC file.mov"
&g
On Thu, Feb 13, 2025, 22:04 Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Pavel Koshevoy:
> > The problem is reproducible with "Test for Quicktime 608 CC file.mov"
> > from https://samples.ffmpeg.org/MPEG2/subcc/
> >
> > ffmpeg -i &qu
On Thu, Feb 13, 2025, 22:04 Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Pavel Koshevoy:
> > The problem is reproducible with "Test for Quicktime 608 CC file.mov"
> > from https://samples.ffmpeg.org/MPEG2/subcc/
> >
> > ffmpeg -i &qu
On Thu, Feb 13, 2025 at 1:12 PM Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:
> On Thu, Feb 13, 2025 at 3:00 PM Pavel Koshevoy
> wrote:
> > yes, that patch is better in that it doesn't over-allocate.
> > I don't care much which fix gets merge
On Thu, Feb 13, 2025 at 3:04 PM Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:
> On Thu, Feb 13, 2025 at 4:06 PM Pavel Koshevoy
> wrote:
> > I've submitted a 3rd version of the patch that doesn't do as much
> > over-allocation, similar to
>
please disregard v3 patch ... `if (size <= 10 || size % 2 != 0)` statement
is wrong, I've submitted a v4 patch to correct it.
Thank you,
Pavel.
On Thu, Feb 13, 2025 at 2:01 PM Pavel Koshevoy wrote:
> The problem is reproducible with "Test for Quicktime 608 CC file.m
The problem is reproducible with "Test for Quicktime 608 CC file.mov"
from https://samples.ffmpeg.org/MPEG2/subcc/
ffmpeg -i "Test for Quicktime 608 CC file.mov" -map 0 -c copy -y remuxed.mov
Prior to the fix QuickTime Player playback of remuxed.mov would
render garbage text for "English CC" subt
On Thu, Feb 13, 2025 at 1:12 PM Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:
> On Thu, Feb 13, 2025 at 3:00 PM Pavel Koshevoy
> wrote:
> > yes, that patch is better in that it doesn't over-allocate.
> > I don't care much which fix gets merge
I've submitted a v3 patch that doesn't do as much over-allocation, similar
to https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-June/310456.html
On Thu, Feb 13, 2025 at 10:55 AM Pavel Koshevoy wrote:
> The problem is reproducible with "Test for Quicktime 608 CC file
The problem is reproducible with "Test for Quicktime 608 CC file.mov"
from https://samples.ffmpeg.org/MPEG2/subcc/
ffmpeg -i "Test for Quicktime 608 CC file.mov" -map 0 -c copy -y remuxed.mov
Prior to the fix QuickTime Player playback of remuxed.mov would
render garbage text for "English CC" subt
On Thu, Feb 13, 2025 at 12:02 PM Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:
> On Thu, Feb 13, 2025 at 12:57 PM Pavel Koshevoy
> wrote:
> > Thank you, I've submitted a 2nd version of the patch that performs more
> > input validation.
>
> For wha
On Wed, Feb 12, 2025 at 11:47 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Pavel Koshevoy:
> > ---
> > libavformat/mov.c | 40 +++-
> > 1 file changed, 31 insertions(+), 9 deletions(-)
> >
> > diff
The problem is reproducible with "Test for Quicktime 608 CC file.mov"
from https://samples.ffmpeg.org/MPEG2/subcc/
ffmpeg_g -i "Test for Quicktime 608 CC file.mov" -map 0 -c copy -y remuxed.mov
Prior to the fix QuickTime Player playback of remuxed.mov would
render cdt2 atom type tags as part of "
BTW, the problem is reproducible with "Test for Quicktime 608 CC file.mov"
from https://samples.ffmpeg.org/MPEG2/subcc/
Pavel.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit l
---
libavformat/mov.c | 40 +++-
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 85aef33b19..422e515fe8 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -10790,22 +10790,44 @@ static int mov_cha
On Sun, Feb 2, 2025 at 4:04 PM James Almer wrote:
> On 2/2/2025 6:46 PM, James Almer wrote:
> > Limited to the same channels as a native layout, but not constrained by
> channel ordering.
> >
> > Signed-off-by: James Almer
> > ---
> > Untested, as i don't have a sample from which we export a cus
On Sun, Feb 2, 2025 at 9:04 AM James Almer wrote:
> On 1/30/2025 12:29 AM, Pavel Koshevoy wrote:
> > Hi,
> >
> > I have a file which I can't down-mix to stereo due to
> > AV_CHANNEL_ORDER_NATIVE requirement in sane_layout.
>
> Can you share that file? Or
On Wed, Jan 29, 2025 at 8:29 PM Pavel Koshevoy wrote:
> Hi,
>
> I have a file which I can't down-mix to stereo due to
> AV_CHANNEL_ORDER_NATIVE requirement in sane_layout.
>
> ```
> $ ffmpeg -i COMMUNITY_HERO_2.mov -vn -af
> 'aformat=sample_rates=48000:chann
ing the patch here, and hopefully someone more
knowledgeable can come up with a more appropriate fix.
From 8dfd5ac84171d591665f069ec935bdf7b8b69936 Mon Sep 17 00:00:00 2001
From: Pavel Koshevoy
Date: Wed, 29 Jan 2025 20:24:42 -0700
Subject: [PATCH] libswr/rematrix: Do no require AV_CHANNEL_ORDE
On Mon, Nov 25, 2024 at 12:43 PM Niklas Haas wrote:
> On Mon, 25 Nov 2024 14:16:19 +0100 Niklas Haas wrote:
> > From: Niklas Haas
>
> > av_csp_trc_function av_csp_trc_func_inv_from_id(enum
> AVColorTransferCharacteristic trc);
> >
> > +/**
> > + * Struct encapsulating a color in an arbitra
On Sat, Nov 16, 2024 at 10:02 AM James Almer wrote:
> From: Pavel Koshevoy
>
> This avoids unpleasant surprises to av_frame_get_buffer callers
> that explicitly specified 64-byte alignment and didn't get
> AVFrame.data pointers that are 64-byte aligned.
>
> For examp
On Sat, Nov 16, 2024 at 9:00 AM James Almer wrote:
> On 11/16/2024 12:57 PM, Pavel Koshevoy wrote:
> > On Fri, Nov 15, 2024 at 9:25 PM Anton Khirnov wrote:
> >
> >> Quoting Pavel Koshevoy (2024-11-15 20:32:21)
> >>> This avoids unpleasant surprises to av
On Sat, Nov 16, 2024 at 9:25 AM Pavel Koshevoy wrote:
>
>
> On Sat, Nov 16, 2024 at 9:00 AM James Almer wrote:
>
>> On 11/16/2024 12:57 PM, Pavel Koshevoy wrote:
>> > On Fri, Nov 15, 2024 at 9:25 PM Anton Khirnov
>> wrote:
>> >
>> >> Qu
This avoids unpleasant surprises to av_frame_get_buffer callers
that explicitly specified 64-byte alignment and didn't get
AVFrame.data pointers that are 64-byte aligned.
For example, see https://github.com/sekrit-twc/zimg/issues/212
Although the zscale issue has already been resolved by other me
On Fri, Nov 15, 2024 at 9:25 PM Anton Khirnov wrote:
> Quoting Pavel Koshevoy (2024-11-15 20:32:21)
> > This avoids unpleasant surprises to av_frame_get_buffer callers
> > that explicitly specified 64-byte alignment and didn't get
> > AVFrame.data pointers that are 64
This avoids unpleasant surprises to av_frame_get_buffer callers
that explicitly specified 64-byte alignment and didn't get
AVFrame.data pointers that are 64-byte aligned.
For example, see https://github.com/sekrit-twc/zimg/issues/212
Although the zscale issue has already been resolved by other me
On Sat, Nov 9, 2024 at 10:46 AM Pavel Koshevoy wrote:
>
>
> On Sat, Nov 9, 2024 at 10:39 AM James Almer wrote:
>
>> On 11/9/2024 2:34 PM, Pavel Koshevoy wrote:
>> > On Sat, Nov 9, 2024 at 10:27 AM James Almer wrote:
>> >
>> >> On 11/9/2024 1
On Sat, Nov 9, 2024 at 10:31 AM Pavel Koshevoy wrote:
>
>
> On Sat, Nov 9, 2024 at 9:53 AM James Almer wrote:
>
>> On 11/9/2024 12:55 PM, Pavel Koshevoy wrote:
>> > On Sat, Nov 9, 2024 at 6:22 AM James Almer wrote:
>> >
>> >> On 11/9/2024 1:4
On Sat, Nov 9, 2024 at 10:39 AM James Almer wrote:
> On 11/9/2024 2:34 PM, Pavel Koshevoy wrote:
> > On Sat, Nov 9, 2024 at 10:27 AM James Almer wrote:
> >
> >> On 11/9/2024 1:57 PM, Pavel Koshevoy wrote:
> >>> This avoids unpleasant surprises to av
On Sat, Nov 9, 2024 at 10:27 AM James Almer wrote:
> On 11/9/2024 1:57 PM, Pavel Koshevoy wrote:
> > This avoids unpleasant surprises to av_frame_get_buffer callers
> > that explicitly specified 64-byte alignment and didn't get
> > AVFrame.data pointers that are 64-by
On Sat, Nov 9, 2024 at 9:53 AM James Almer wrote:
> On 11/9/2024 12:55 PM, Pavel Koshevoy wrote:
> > On Sat, Nov 9, 2024 at 6:22 AM James Almer wrote:
> >
> >> On 11/9/2024 1:40 AM, Pavel Koshevoy wrote:
> >>> On Fri, Nov 8, 2024 at 7:29 PM James Almer wrote
On Sat, Nov 9, 2024 at 9:47 AM James Almer wrote:
> On 11/9/2024 12:55 PM, Pavel Koshevoy wrote:
> > On Sat, Nov 9, 2024 at 6:22 AM James Almer wrote:
> >
> >> On 11/9/2024 1:40 AM, Pavel Koshevoy wrote:
> >>> On Fri, Nov 8, 2024 at 7:29 PM James Almer wrote
---
libavfilter/vf_zscale.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 4ba059064b..07e295652d 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -630,7 +630,7 @@ static int graphs_build(A
This avoids unpleasant surprises to av_frame_get_buffer callers
that explicitly specified 64-byte alignment and didn't get
AVFrame.data pointers that are 64-byte aligned.
In particular, this fixes an issue in vf_zscale.
https://github.com/sekrit-twc/zimg/issues/212
---
libavutil/frame.c | 4 +++-
On Sat, Nov 9, 2024 at 9:43 AM James Almer wrote:
> On 11/9/2024 1:37 PM, Pavel Koshevoy wrote:
> > ---
> > libavfilter/vf_zscale.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavfilter/vf_zscale.c b/libavfilter
---
libavfilter/vf_zscale.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 4ba059064b..87fe691cfd 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -750,7 +750,9 @@ static int filter_slice(AVFi
realign_frame called av_pix_fmt_count_planes with incorrect parameter.
---
libavfilter/vf_zscale.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 4ba059064b..c29c599000 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilt
On Sat, Nov 9, 2024 at 6:22 AM James Almer wrote:
> On 11/9/2024 1:40 AM, Pavel Koshevoy wrote:
> > On Fri, Nov 8, 2024 at 7:29 PM James Almer wrote:
> >
> >> On 11/8/2024 10:51 PM, Pavel Koshevoy wrote:
> >>> I ran into segfaults in zimg when I attemp
On Fri, Nov 8, 2024 at 7:29 PM James Almer wrote:
> On 11/8/2024 10:51 PM, Pavel Koshevoy wrote:
> > I ran into segfaults in zimg when I attempted to use zscale
> > to convert a 512x538@yuv444p16le(tv) image from HLG to Bt.709
> > with this filter chain:
> >
> &
I ran into segfaults in zimg when I attempted to use zscale
to convert a 512x538@yuv444p16le(tv) image from HLG to Bt.709
with this filter chain:
buffer=width=512:height=538:pix_fmt=yuv444p16le:time_base=1/1:sar=1/1,zscale=min=2020_ncl:rin=limited:pin=2020:tin=arib-std-b67:cin=left:t=linear,format
On Wed, May 22, 2024, 02:59 Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> The earlier code distinguished between a partial reset
> (yae_clear()) and a complete reset (yae_release_buffers()
> which also releases the buffers); this separation existed
> to avoid allocations, as buffer
On Tue, Mar 12, 2024 at 9:01 PM Pavel Koshevoy wrote:
> From: Rajiv Harlalka
>
> Check for zeros equal to the total samples early, because in
> that case we would already be leaving the first few frames out.
>
> Fixes trac ticket #10692
> ---
> liba
1 - 100 of 234 matches
Mail list logo
