Signed-off-by: Cai Fan
---
libavformat/img2enc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
index 41638d92b8..672cfe18fd 100644
--- a/libavformat/img2enc.c
+++ b/libavformat/img2enc.c
@@ -180,6 +180,10 @@ static int write_packet(AVFormatC
This patch fixes strange seeking behavior i have observed in mpv when using the
libopenmpt demuxer, caused by mismatch in position state between the demuxer
and underlying libopenmpt library. Not setting the presentation timestamp
field of the AVPacket caused it to be guessed by libavformat, bu
On 7/27/25 9:38 PM, Stephen Hutchinson wrote:
As a stopgap, yeah, this is probably the cleanest solution.
It does need to be resolved upstream, though at least on the
AviSynth+ side, I don't know how/if the reason this hadn't
already been done was because it would have broken existing
plugin comp
On 7/27/25 21:34, Kacper Michajlow wrote:
> On Mon, 28 Jul 2025 at 02:04, Daniel Bermond wrote:
>>
>> When FFmpeg is compiled with support for both avisynth and libvmaf,
>> a segmentation fault occurs when using avisynth (.avs) input.
>>
>> This happens because both avisynthplus and vmaf have th
On 7/27/25 8:34 PM, Kacper Michajlow wrote:
On Mon, 28 Jul 2025 at 02:04, Daniel Bermond wrote:
When FFmpeg is compiled with support for both avisynth and libvmaf,
a segmentation fault occurs when using avisynth (.avs) input.
This happens because both avisynthplus and vmaf have the exactly
sa
On Mon, 28 Jul 2025 at 02:04, Daniel Bermond wrote:
>
> When FFmpeg is compiled with support for both avisynth and libvmaf,
> a segmentation fault occurs when using avisynth (.avs) input.
>
> This happens because both avisynthplus and vmaf have the exactly
> same C++ symbol 'Cache::~Cache()'[1][2]
Hi Romain
On Wed, Jul 23, 2025 at 02:06:07PM -0500, Romain Beauxis wrote:
> Le sam. 21 juin 2025 à 16:59, Michael Niedermayer
> a écrit :
> >
> > On Sat, Jun 21, 2025 at 10:45:32AM +0200, Romain Beauxis wrote:
> > > Le dim. 15 juin 2025 à 00:57, Michael Niedermayer
> > > a écrit :
> > > >
> > >
When FFmpeg is compiled with support for both avisynth and libvmaf,
a segmentation fault occurs when using avisynth (.avs) input.
This happens because both avisynthplus and vmaf have the exactly
same C++ symbol 'Cache::~Cache()'[1][2], which is a C++ destructor.
When using avisynth input, this des
Hi Niklas
On Thu, Jul 24, 2025 at 01:11:54PM +0200, Niklas Haas wrote:
> On Wed, 23 Jul 2025 19:02:06 +0200 Nicolas George wrote:
> > Niklas Haas (HE12025-07-23):
> > > [PATCH v2 05/18] avcodec/encode: enforce alpha mode compatibility at
> > > encode time
> >
> > That handles it for encoders, I
When FFmpeg is compiled with support for both avisynth and libvmaf,
a segmentation fault occurs when using avisynth (.avs) input.
This happens because both avisynthplus and vmaf have the exactly
same C++ symbol 'Cache::~Cache()'[1][2], which is a C++ destructor.
When using avisynth input, this de
On Sun, 27 Jul 2025 at 22:57, Michael Niedermayer
wrote:
>
> On Wed, Jul 23, 2025 at 05:51:35PM +0200, Kacper Michajlow wrote:
> > On Wed, 23 Jul 2025 at 10:43, Michael Niedermayer
> > wrote:
> > >
> > > Fixes: use of uninitialized memory
> > > Fixes:
> > > 403675492/clusterfuzz-testcase-minimiz
When FFmpeg is compiled with support for both avisynth and libvmaf,
a segmentation fault occurs when using avisynth (.avs) input.
This happens because both avisynthplus and vmaf have the exactly
same C++ symbol 'Cache::~Cache()'[1][2], which is a C++ destructor.
When using avisynth input, this de
On Sun, Jul 27, 2025 at 10:48 PM Michael Niedermayer
wrote:
>
> Imagine people try to game this and we thus have more contributions and
> more reviewed, fewer unreviewed patches. That sounds like a good thing
> to me
>
> [...]
> Maybe iam just odd but i want to know if forgejo or the ML actually w
On Wed, Jul 23, 2025 at 05:51:35PM +0200, Kacper Michajlow wrote:
> On Wed, 23 Jul 2025 at 10:43, Michael Niedermayer
> wrote:
> >
> > Fixes: use of uninitialized memory
> > Fixes:
> > 403675492/clusterfuzz-testcase-minimized-ffmpeg_dem_ASF_fuzzer-4754281823797248
> >
> > Found-by: continuous fuz
Hi Niklas
On Sun, Jul 27, 2025 at 02:07:22PM +0200, Niklas Haas wrote:
> On Wed, 23 Jul 2025 01:04:34 +0200 Michael Niedermayer
> wrote:
> > The announcment should probably mention that performance, as in number of
> > submissions / percentage of applied / not reviewed patches will be
> > monito
On Sun, 27 Jul 2025 at 11:39, Nicolas George wrote:
>
> Kacper Michajlow (HE12025-07-26):
> > I don't think moving over is something that requires significant
> > effort. It just needs clear communication about this.
> >
> > Also, I don't think the current ML workflow is very sophisticated on
> >
Niklas Haas (HE12025-07-27):
> The only thing that should
> matter is what the community *prefers* to use.
Provided it is weighted according to how much work each member of the
community does with it.
(And of course I am aware that means very little f
On Wed, 23 Jul 2025 01:04:34 +0200 Michael Niedermayer
wrote:
> The announcment should probably mention that performance, as in number of
> submissions / percentage of applied / not reviewed patches will be
> monitored compared to the mailing list.
https://en.wikipedia.org/wiki/Goodhart%27s_law
Timo Rothenpieler (HE12025-07-26):
> Here's an idea I had to make the transition a bit more rapid:
>
> - Retire git.videolan.org, make it a pure mirror nobody can push to (except
> the mirror script).
> - Make source.ffmpeg.org point to git.ffmpeg.org instead. This will cause
> host key mismatch
Kacper Michajlow (HE12025-07-26):
> I don't think moving over is something that requires significant
> effort. It just needs clear communication about this.
>
> Also, I don't think the current ML workflow is very sophisticated on
> ffmpeg-devel, so there are likely not many tools to migrate to the
20 matches
Mail list logo
