---
Sorry I forgot this fixup to the previous patch, that I had in my work tree but
not committed...
tests/fate-run.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 72251ec571..bed8f7127c 100755
--- a/tests/fate-run.sh
+++ b/test
On Fri, Oct 18, 2024 at 2:09 PM Alexander Strasser via ffmpeg-devel
wrote:
> This caused differences
> with 2 fate tests depending on the zlib version used.
2 fate tests?
https://fate.ffmpeg.org/report.cgi?time=20241016173824&slot=x86_32-msvc14-dll-md-windows-native
This entire approach feels ex
On 18/10/2024 14:41, Hendrik Leppkes wrote:
On Fri, Oct 18, 2024 at 2:09 PM Alexander Strasser via ffmpeg-devel
wrote:
This caused differences
with 2 fate tests depending on the zlib version used.
2 fate tests?
https://fate.ffmpeg.org/report.cgi?time=20241016173824&slot=x86_32-msvc14-dll-md-w
The problems that caused the revert will be fixed with the follow-up
change right after this commit.
This reverts commit e206e72b83a0e512e21694a43af4df2b53f6d045.
---
tests/fate/cover-art.mak | 6 ++--
tests/fate/image.mak | 4 +--
tests/fate/lavf-image.mak
Michael Niedermayer (12024-10-15):
> The question: Should anyone be able to write a filter (which
> other people can use) ?
> Or should only we be able to add filters ?
There are two sides to the issue: making the filter work and registering
it.
To make the filter work, it needs to access APIs th
On 15/10/2024 21:23, Frank Plowman wrote:
> On 14/10/2024 23:26, Michael Niedermayer wrote:
>> On Sat, Oct 05, 2024 at 03:38:05PM -0700, Frank Plowman wrote:
>>> The first branch of this ternary expression was intended to avoid
>>> having two shift operations in the case the RHS is not known at
>>>
---
libavfilter/vf_scale_vt.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/libavfilter/vf_scale_vt.c b/libavfilter/vf_scale_vt.c
index 3da46a6cd5..3785b884d9 100644
--- a/libavfilter/vf_scale_vt.c
+++ b/libavfilter/vf_scale_vt.c
@@ -33,8 +33,6 @@ typedef struct
The crop filter has no effect on scale_cuda:
-vf crop=100:100,scale_cuda=300x300
Hardware frames (AV_PIX_FMT_FLAG_HWACCEL) are expected to use the crop_*
properties,
as seen in the implementation vf_crop.c.
The current workaround is to hwdownload the full frame
and perform the crop on CPU.
---
The crop filter has no effect on scale_vt:
-vf crop=100:100,scale_vt=300x300
Hardware frames (AV_PIX_FMT_FLAG_HWACCEL) are expected to use the crop_*
properties,
as seen in the implementation vf_crop.c.
The current workaround is to hwdownload the full frame
and perform the crop on CPU.
---
lib
The crop filter has no effect on scale_qsv:
-vf crop=100:100,scale_qsv=300x300
Hardware frames (AV_PIX_FMT_FLAG_HWACCEL) are expected to use the crop_*
properties,
as seen in the implementation vf_crop.c.
This patch is slightly different from the previously submitted patches
since qsv supports
I checked the crop filter and scale_vaapi implementation. The crop
filter omits the requested crop width and height from the link, and
expects the filter to know the final size ahead of time. So it seems
the user is expected to provide the hardware scale filter with a final
width and the height. sc
On 2024-10-18 13:16 +0200, Anton Khirnov wrote:
> Quoting Alexander Strasser via ffmpeg-devel (2024-10-18 12:55:49)
> > FTR and FWIW it was useful for me for identifying filters that can do
> > more with commands than timeline enable/disable.
>
> And then what do you do with this list of filters?
On 2024-10-18 16:36 +0200, Lynne via ffmpeg-devel wrote:
> On 18/10/2024 14:41, Hendrik Leppkes wrote:
> > On Fri, Oct 18, 2024 at 2:09 PM Alexander Strasser via ffmpeg-devel
> > wrote:
> > > This caused differences
> > > with 2 fate tests depending on the zlib version used.
> >
> > 2 fate tests?
Quoting Derek Buitenhuis (2024-10-18 16:55:58)
> On 10/18/2024 1:02 PM, Alexander Strasser via ffmpeg-devel wrote:
> > Alexander Strasser (2):
> > Reapply "tests/fate: disable compression for zlib-based codecs"
> > fate: Make it possible to have alternative reference files
>
> I want to add th
>From d7863bab8e1028b6cfb3ce848e216e86ff00eca0 Mon Sep 17 00:00:00 2001
From: cynthia2006
Date: Tue, 28 May 2024 22:03:50 +0530
Subject: [PATCH] lavc/mjpegdec: Add option for ignorning malformed APPx segments
X-Unsent: 1
To: ffmpeg-devel@ffmpeg.org
A few cameras, namely Logitech C270 or similar p
Fixes: integer overflow: -2147483648 - 1 cannot be represented in type 'int'
Fixes:
373971762/clusterfuzz-testcase-minimized-ffmpeg_dem_DXA_fuzzer-4880491112103936
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermay
This makes the unscaled output of p010le and p016le match the generic path.
Signed-off-by: James Almer
---
libswscale/swscale_unscaled.c | 6 +++---
tests/ref/fate/filter-pixdesc-p010le| 2 +-
tests/ref/fate/filter-pixdesc-p016le| 2 +-
tests/ref/fate/filter-pixfmts-copy |
This helps detecting inconsistencies in swscale input/output code and
a av_read_image_line()/av_write_image_line() pass.
Signed-off-by: James Almer
---
tests/fate-run.sh | 21 +
tests/fate/filter-video.mak | 2 +-
2 files changed, 22 insertions(+), 1 deletion(-)
d
And add a few more tests to ensure all the pixfmts affected by this change
are tested.
Signed-off-by: James Almer
---
libavfilter/vsrc_testsrc.c | 7 ++-
tests/fate/filter-video.mak | 6 ++
tests/ref/fate/filter-yuvtestsrc-ayuv64 | 10 ++
tests/ref/fate
This can be useful to simplify certain processes that need to know how many
reserved bits there are and where they are placed, even if they are ultimately
unused, as will be shown in the next commit.
For any other case where the user simply looks at nb_components components, it
will make no differe
Ensure those bits are copied, which will result in the output being the same as
the input, where swscale set them to the equivalent of fully opaque.
Signed-off-by: James Almer
---
libavfilter/vf_pixdesctest.c| 2 +-
tests/ref/fate/filter-pixdesc-0bgr | 2 +-
tests/ref/fate/filte
If depth is 0, then the component is invalid/unset.
Signed-off-by: James Almer
---
No changes since last version.
libavutil/pixdesc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index d73c3f0d58..4d61e32a1e 100644
--- a/libavutil/pixdesc.c
Fixes: use of uninitialized memory in hScale16To15_c()
Fixes:
373924007/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-5841199968092160
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libswscale/slice.
Rémi Denis-Courmont (12024-10-17):
> It should be obvious that his question is much broader than that, a.k.a. "no".
For me it was obvious that “yes”, but I was being polite.
> In fact that specific point is hardly a benefit. If someone needs to ship a
> custom filter, they are almost certainly e
On Fri, Oct 18, 2024 at 5:09 PM Alexander Strasser via ffmpeg-devel
wrote:
>
> On 2024-10-18 16:36 +0200, Lynne via ffmpeg-devel wrote:
> > On 18/10/2024 14:41, Hendrik Leppkes wrote:
> > > On Fri, Oct 18, 2024 at 2:09 PM Alexander Strasser via ffmpeg-devel
> > > wrote:
> > > > This caused differ
As there's no guarantee that the output will be exactly the same across
implementations,
just don't test it at all.
Signed-off-by: James Almer
---
Marked as WIP beuse i can't get enc_dec() to work like transcode() and the
rest. My bash-fu isn't good and the twopass argument handling in vcodec.ma
On 10/18/2024 1:02 PM, Alexander Strasser via ffmpeg-devel wrote:
> Alexander Strasser (2):
> Reapply "tests/fate: disable compression for zlib-based codecs"
> fate: Make it possible to have alternative reference files
I want to add this here, since I brought it up on IRC.
I think this entire
On Fri, Oct 18, 2024 at 03:55:58PM +0100, Derek Buitenhuis wrote:
> On 10/18/2024 1:02 PM, Alexander Strasser via ffmpeg-devel wrote:
[...]
> For a lossles encoder, especially one that uses external deps, but this
> applies to internal ones too, almost no value is provided by ensuring
> that its o
---
samples files to be copied into $SAMPLES/vp6/
https://pross.sdf.org/sandpit/interlaced32x32.avi
https://pross.sdf.org/sandpit/interlaced32x64.avi
tests/fate/vpx.mak | 6 ++
tests/ref/fate/vp60-interlace1 | 156 +
tests/ref/fate/vp60-interlace2 |
Sometimes deps (external from FFmpeg) can cause different results
either because of bugs or because of drop in replacements.
This feature of alternate reference files should only be used
where absolutely necessary because other solutions are not
feasible in practice. Maintaining two reference file
This is as subject notes an RFC. I wanted to send it out quickly.
Didn't actually test on zlib systems yet (old and new).
So it is not that heavily tested yet and maybe has rough edges I
didn't notice.
I hope this would help to unbreak zlib-ng systems and not disturb
systems with older zlib versi
Quoting Alexander Strasser via ffmpeg-devel (2024-10-18 12:55:49)
> FTR and FWIW it was useful for me for identifying filters that can do
> more with commands than timeline enable/disable.
And then what do you do with this list of filters?
--
Anton Khirnov
___
Modification of patch submitted by Aurelien Jacobs (November 2007).
Fixes ticket #5581.
---
v2: vp56_mc() modified to reproduce behaviour of reference VP6 decoder
libavcodec/vp5.c | 5 +---
libavcodec/vp56.c| 54 +++-
libavcodec/vp56.h| 6 +++
On Fri, Oct 18, 2024 at 02:02:48PM +0200, Alexander Strasser via ffmpeg-devel
wrote:
> This is as subject notes an RFC. I wanted to send it out quickly.
> Didn't actually test on zlib systems yet (old and new).
>
> So it is not that heavily tested yet and maybe has rough edges I
> didn't notice.
I think the passthrough flag should be validated at filter processing
time as well. Currently passthrough is checked at filter creation
time, when only input/output sizes are available. During
cudascale_filter_frame, the frame crop values should also be verified
to determine if it is truly a no-op
On 2024-10-17 20:23 +0200, Marvin Scholz wrote:
> The way the linked list of images was freed caused a
> use after free, by accessing pic->next after pic was
> already freed.
>
> Regression from 48a1a12968345bf673db1e1cbb5c64bd3529c50c
>
> Fix CID1633236
> ---
> libavcodec/hw_base_encode.c | 6 +++
Hi all ,
We understand your concern behind marking x265 as experimental but we
wanted to let you know that our x265 development team is actively working
on resolving multiple issues that have been brought to our notice so far
through bitbucket issue tracker(including issue #482) and are planning t
On 17/10/2024 20:23, Marvin Scholz wrote:
The way the linked list of images was freed caused a
use after free, by accessing pic->next after pic was
already freed.
Regression from 48a1a12968345bf673db1e1cbb5c64bd3529c50c
Fix CID1633236
---
libavcodec/hw_base_encode.c | 6 +++---
1 file change
On 2024-10-15 21:24 +0200, Anton Khirnov wrote:
> Quoting Alexander Strasser via ffmpeg-devel (2024-10-15 21:05:54)
> > Still that functionality is useful
>
> How is it useful? It gives you no actionable information.
Seems this was just applied already.
FTR and FWIW it was useful for me for ident
39 matches
Mail list logo
