Re: [FFmpeg-devel] What is FFmpeg and what should it be
On Sat, Aug 5, 2023 at 8:55 PM Michael Niedermayer wrote: > Hi > > replying to the other question too > > On Wed, Aug 02, 2023 at 04:44:14PM +0200, Jean-Baptiste Kempf wrote: > > On Wed, 2 Aug 2023, at 16:20, Michael Niedermayer wrote: > > > There are multiple problems but the real problem is that > > > How many people discuss an SDR API ? (0) > > > How many people propose an SDR API ? (0) > > > > Did you ask people to do that? > > yes, multiple times. > Also normally patch objections come with a path forward, that was not > the case here. > Not necessarily, sometimes preventing a bad idea from happening is a positive thing in itself, and no path forward is needed. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 1/1] configure: Set WIN32_LEAN_AND_MEAN at configure time
Including winsock2.h or windows.h without WIN32_LEAN_AND_MEAN cause bzlib.h to parse as nonsense, due to an instance of #define char small in rpcndr.h. See: https://stackoverflow.com/a/27794577 Signed-off-by: L. E. Segovia --- compat/atomics/win32/stdatomic.h | 1 - compat/w32pthreads.h | 1 - configure| 1 + libavdevice/dshow_capture.h | 1 - libavdevice/opengl_enc.c | 1 - libavfilter/vsrc_ddagrab.c | 1 - libavformat/os_support.c | 6 ++ libavutil/wchar_filename.h | 1 - libswscale/utils.c | 1 - 9 files changed, 3 insertions(+), 11 deletions(-) diff --git a/compat/atomics/win32/stdatomic.h b/compat/atomics/win32/stdatomic.h index 28a627bfd3..4f8ac2bb60 100644 --- a/compat/atomics/win32/stdatomic.h +++ b/compat/atomics/win32/stdatomic.h @@ -19,7 +19,6 @@ #ifndef COMPAT_ATOMICS_WIN32_STDATOMIC_H #define COMPAT_ATOMICS_WIN32_STDATOMIC_H -#define WIN32_LEAN_AND_MEAN #include #include #include diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h index 6405e72b64..4ea0ce1ff4 100644 --- a/compat/w32pthreads.h +++ b/compat/w32pthreads.h @@ -35,7 +35,6 @@ * As most functions here are used without checking return values, * only implement return values as necessary. */ -#define WIN32_LEAN_AND_MEAN #include #include #include diff --git a/configure b/configure index 99388e7664..881a10bc0c 100755 --- a/configure +++ b/configure @@ -5716,6 +5716,7 @@ case $target_os in fi ! enabled small && test_cmd $windres --version && enable gnu_windres enabled x86_32 && check_ldflags -LARGEADDRESSAWARE +add_cppflags -DWIN32_LEAN_AND_MEAN shlibdir_default="$bindir_default" SLIBPREF="" SLIBSUF=".dll" diff --git a/libavdevice/dshow_capture.h b/libavdevice/dshow_capture.h index b548cd7afc..81e684b9be 100644 --- a/libavdevice/dshow_capture.h +++ b/libavdevice/dshow_capture.h @@ -27,7 +27,6 @@ #include "avdevice.h" #define COBJMACROS -#define WIN32_LEAN_AND_MEAN #include #define NO_DSHOW_STRSAFE #include diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c index f9dc846bf1..1b0cf5aa8f 100644 --- a/libavdevice/opengl_enc.c +++ b/libavdevice/opengl_enc.c @@ -30,7 +30,6 @@ #include "config.h" #if HAVE_WINDOWS_H -#define WIN32_LEAN_AND_MEAN #include #endif #if HAVE_OPENGL_GL3_H diff --git a/libavfilter/vsrc_ddagrab.c b/libavfilter/vsrc_ddagrab.c index 525d48110a..9093b89c5b 100644 --- a/libavfilter/vsrc_ddagrab.c +++ b/libavfilter/vsrc_ddagrab.c @@ -22,7 +22,6 @@ #undef _WIN32_WINNT #define _WIN32_WINNT 0x0A00 #endif -#define WIN32_LEAN_AND_MEAN #include diff --git a/libavformat/os_support.c b/libavformat/os_support.c index 15cea7fa5b..2de6a7c3d9 100644 --- a/libavformat/os_support.c +++ b/libavformat/os_support.c @@ -34,11 +34,9 @@ #if HAVE_SYS_TIME_H #include #endif /* HAVE_SYS_TIME_H */ -#if HAVE_WINSOCK2_H -#include -#elif HAVE_SYS_SELECT_H +#if HAVE_SYS_SELECT_H #include -#endif /* HAVE_WINSOCK2_H */ +#endif /* HAVE_SYS_SELECT_H */ #endif /* !HAVE_POLL_H */ #include "network.h" diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h index fbc0a55146..4f87e6f88b 100644 --- a/libavutil/wchar_filename.h +++ b/libavutil/wchar_filename.h @@ -21,7 +21,6 @@ #ifdef _WIN32 -#define WIN32_LEAN_AND_MEAN #include #include "mem.h" diff --git a/libswscale/utils.c b/libswscale/utils.c index 8fe34a3437..8e74c6603e 100644 --- a/libswscale/utils.c +++ b/libswscale/utils.c @@ -34,7 +34,6 @@ #endif #endif #if HAVE_VIRTUALALLOC -#define WIN32_LEAN_AND_MEAN #include #endif -- 2.41.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 0/1] configure: Set WIN32_LEAN_AND_MEAN at configure time
Thanks Martin for the suggestion, I've implemented it in this version. As for the changes to os_support.c, the removal was intended to avoid duplicating the logic that already exists in os_support.h. I've kept it in this version for consistency. L. E. Segovia (1): configure: Set WIN32_LEAN_AND_MEAN at configure time compat/atomics/win32/stdatomic.h | 1 - compat/w32pthreads.h | 1 - configure| 1 + libavdevice/dshow_capture.h | 1 - libavdevice/opengl_enc.c | 1 - libavfilter/vsrc_ddagrab.c | 1 - libavformat/os_support.c | 6 ++ libavutil/wchar_filename.h | 1 - libswscale/utils.c | 1 - 9 files changed, 3 insertions(+), 11 deletions(-) -- 2.41.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
Your attempts to troll other developers to work on SDR/AVRadio is flawed and disrespectful to other FFmpeg people. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
Hi replying to the other question too On Wed, Aug 02, 2023 at 04:44:14PM +0200, Jean-Baptiste Kempf wrote: > On Wed, 2 Aug 2023, at 16:20, Michael Niedermayer wrote: > > There are multiple problems but the real problem is that > > How many people discuss an SDR API ? (0) > > How many people propose an SDR API ? (0) > > Did you ask people to do that? yes, multiple times. Also normally patch objections come with a path forward, that was not the case here. The first proposal was a simple demuxer in libavformat which used libsoapy That was objected to The second proposal was a simple demuxer in libavformat and a input device in libavdevice which used libsoapy That was objected to The third proposal moved the simple demuxer and input device to libavradio That was accepted, but then the build system changes where objected to so we cannot link to that The forth proposal moves the simple demuxer and input device back out of libavradio (as we cannot link to it without build system changes) this was not objected to but the unrelated bugfixes after that where objected to There is the general theme that a intermediate API should be added but with apparently noone who subscribes to this suggestion knowing or caring how to do that. libsoapy is the external library used by the input device code on top of the hw independant demuxer code. <-- this is a terse description of what we have ATM Is what you ask for, that I develop a general purpose SDR library ? Because i cannot think of anything else that could reasonbly be meant by "API" here. Now please think about this for a moment i should write a general purpose SDR library to be "allowed" to add a SDR module to ffmpeg ? You compared this to libswresample and libswscale but a general purpose SDR library is more like a general purpose multimedia library than a general purpose audio resampler. I dont think demanding i write a general purpose SDR library to be "allowed" to add a SDR module to ffmpeg has a majority behind it. This is not what people where thinking off when they suggested an API If its not about writing a general purpose SDR libraray, then what exactly is the suggestion ? And also does that make sense ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avradio/sdr: Add CQUAM support
NAK ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avradio/sdr: Add CQUAM support
On Fri, Jul 28, 2023 at 12:38:36AM +0200, Michael Niedermayer wrote: > untested as i have no clean signal from a CQUAM station > > Signed-off-by: Michael Niedermayer > --- > libavradio/sdr.h | 1 + > libavradio/sdrdemux.c | 37 +++-- > 2 files changed, 32 insertions(+), 6 deletions(-) will apply patchset [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/tta: fix signed overflow in decorrelate
Fixes: signed integer overflow: 2079654542 - -139267653 cannot be represented
in type 'int'
Fixes:
60811/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TTA_fuzzer-5915858409750528
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/tta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/tta.c b/libavcodec/tta.c
index 3e89571f16..072e86729d 100644
--- a/libavcodec/tta.c
+++ b/libavcodec/tta.c
@@ -342,7 +342,7 @@ static int tta_decode_frame(AVCodecContext *avctx, AVFrame
*frame,
if (s->channels > 1) {
int32_t *r = p - 1;
for (*p += *r / 2; r > (int32_t*)p - s->channels; r--)
-*r = *(r + 1) - *r;
+*r = *(r + 1) - (unsigned)*r;
}
cur_chan = 0;
i++;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/on2avc: use the matching AVTX context for the 512 sized iMDCT
On Sat, 5 Aug 2023, Lynne wrote:
Aug 5, 2023, 11:15 by d...@lynne.ee:
Aug 5, 2023, 10:33 by c...@passwd.hu:
Improves the audio corruption regression caused by
6ba0aa1770ba29eb4126c6a706f6b0cd3809648f reported in ticket #10029.
There is still however a noticable audio glitch, so the FFT conversion to AVTX
probably also needs some modifications.
Signed-off-by: Marton Balint
---
libavcodec/on2avc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/on2avc.c b/libavcodec/on2avc.c
index 74be1dcb60..474adb149d 100644
--- a/libavcodec/on2avc.c
+++ b/libavcodec/on2avc.c
@@ -700,7 +700,7 @@ static int on2avc_reconstruct_channel_ext(On2AVCContext *c,
AVFrame *dst, int of
break;
case WINDOW_TYPE_EXT5:
c->wtf(c, buf, in, 512);
-c->mdct_half_fn(c->mdct, buf + 512, in + 512, sizeof(float));
+c->mdct_half_fn(c->mdct_half, buf + 512, in + 512, sizeof(float));
for (i = 0; i < 256; i++) {
FFSWAP(float, buf[i + 512], buf[1023 - i]);
}
LGTM
Thanks
Actually, looking at it, the WINDOW_TYPE_EXT7 branch, something
weird's going on there as well:
- c->mdct.imdct_half(>mdct, buf, in);
+ c->mdct_fn(c->mdct, buf, in, sizeof(float));
The original misused the context. Maybe this
should be both half as well?
I thought that is just the old API where you have to use the imdct_half
function to get the useful half-sized IMDCT. But the old code really means
to use the 11-bit context to calculate 1024 samples not the 10-bit one
confusingly called c->mdct_half to calculate 512 samples.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/jpeg2000htdec: Check m
On Fri, Aug 04, 2023 at 06:19:46PM -0700, Pierre-Anthony Lemieux wrote:
> On Tue, Aug 1, 2023 at 5:02 PM Michael Niedermayer
> wrote:
> >
> > This also fixes assertion failures
> >
> > Fixes: shift exponent 95 is too large for 64-bit type 'unsigned long long'
> > Fixes:
> > 58299/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5828618092937216
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/jpeg2000htdec.c | 22 --
> > 1 file changed, 20 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c
> > index 3985783f3a..ae2ee6d6ee 100644
> > --- a/libavcodec/jpeg2000htdec.c
> > +++ b/libavcodec/jpeg2000htdec.c
> > @@ -689,6 +689,10 @@ static int jpeg2000_decode_ht_cleanup_segment(const
> > Jpeg2000DecoderContext *s,
> > for (int i = 0; i < 4; i++) {
> > m[J2K_Q1][i] = sigma_n[4 * q1 + i] * U[J2K_Q1] -
> > ((emb_pat_k[J2K_Q1] >> i) & 1);
> > m[J2K_Q2][i] = sigma_n[4 * q2 + i] * U[J2K_Q2] -
> > ((emb_pat_k[J2K_Q2] >> i) & 1);
> > +if (m[J2K_Q1][i] > 63 || m[J2K_Q2][i] > 63) {
>
> AFAIK, m[i], which is m_n in the standard, can never be larger than
> the sample bit depth (including the sign bit, if any). Is it worth
> comparing it to a value more precise than 63?
probably, yes
I think you know the spec better than i do, so you can probably pick
the tightest bound quicker ...
can you submit a patch doing that ?
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/jpeg2000htdec: Consolidate jpeg2000 spec bits in jpeg2000_bitbuf_refill_backwards()
On Fri, Aug 04, 2023 at 06:41:24PM -0700, Pierre-Anthony Lemieux wrote: > On Tue, Aug 1, 2023 at 5:02 PM Michael Niedermayer > wrote: > > > > Code should make more sense now > > > > Fixes: out of array access > > Fixes: > > 58299/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-6627570448465920 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/jpeg2000htdec.c | 13 +++-- > > 1 file changed, 3 insertions(+), 10 deletions(-) > > > > diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c > > index 2b082b3b2f..3985783f3a 100644 > > --- a/libavcodec/jpeg2000htdec.c > > +++ b/libavcodec/jpeg2000htdec.c > > @@ -159,21 +159,14 @@ static int jpeg2000_bitbuf_refill_backwards(StateVars > > *buffer, const uint8_t *ar > > */ > > position -= 4; > > Can't we get rid of this line and the comment above, and instead > replace `int32_t position = buffer->pos;` with `int32_t position = > buffer->pos - 4;`? yes > > LGTM otherwise. will apply with the suggested change thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is a danger to trust the dream we wish for rather than the science we have, -- Dr. Kenneth Brown signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] os_support, network: Fix build failure on Windows with BZIP2
Hey, Yes, doing so directly in the configure script could be more useful. In fact, while I was doing further internal testing, I found two more instances that needed patching up. I'll update this set and let you know. amyspark On 04/08/2023 09:39, Martin Storsjö wrote: > On Fri, 4 Aug 2023, Martin Storsjö wrote: > >> On Thu, 27 Jul 2023, L. E. Segovia wrote: >> >>> Including winsock2.h without WIN32_LEAN_AND_MEAN causes bzlib.h to parse >>> as nonsense, due to an instance of #define char small in rpcndr.h >>> (included transitively from windows.h). >>> >>> See: https://stackoverflow.com/a/27794577 >>> Signed-off-by: L. E. Segovia >>> --- >>> libavformat/network.h | 1 + >>> libavformat/os_support.c | 6 ++ >>> libavformat/os_support.h | 1 + >>> 3 files changed, 4 insertions(+), 4 deletions(-) >> >> The change looks mostly reasonable to me I think, and WIN32_LEAN_AND_MEAN is >> generally beneficial. I've got a couple comments below though. > > Alternatively, I guess we could consider adding WIN32_LEAN_AND_MEAN in > configure somewhere instead? That way we don't need to hunt down any > potential stray includes of windows.h/winsock2.h if they are added elsewhere. > > // Martin > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". -- amyspark https://www.amyspark.me ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/vaapi_encode: Add filler_data option
---
libavcodec/vaapi_encode.c | 1 +
libavcodec/vaapi_encode.h | 9 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index bfca315a7a..f161c76304 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1860,6 +1860,7 @@ rc_mode_found:
#if VA_CHECK_VERSION(1, 3, 0)
.quality_factor = rc_quality,
#endif
+.rc_flags.bits.disable_bit_stuffing = !ctx->filler_data,
};
vaapi_encode_add_global_param(avctx,
VAEncMiscParameterTypeRateControl,
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index a1e639f56b..a2170cb8b0 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -198,6 +198,9 @@ typedef struct VAAPIEncodeContext {
// Max Frame Size
int max_frame_size;
+// Filler Data
+int filler_data;
+
// Explicitly set RC mode (otherwise attempt to pick from
// available modes).
int explicit_rc_mode;
@@ -490,7 +493,11 @@ int ff_vaapi_encode_close(AVCodecContext *avctx);
{ "max_frame_size", \
"Maximum frame size (in bytes)",\
OFFSET(common.max_frame_size), AV_OPT_TYPE_INT, \
- { .i64 = 0 }, 0, INT_MAX, FLAGS }
+ { .i64 = 0 }, 0, INT_MAX, FLAGS }, \
+{ "filler_data", \
+ "Enable filler data", \
+ OFFSET(common.filler_data), AV_OPT_TYPE_BOOL, \
+ { .i64 = 1 }, 0, 1, FLAGS }
#define VAAPI_ENCODE_RC_MODE(name, desc) \
{ #name, desc, 0, AV_OPT_TYPE_CONST, { .i64 = RC_MODE_ ## name }, \
--
2.41.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/5] avcodec/hwconfig: Move HWACCEL_CAP_* to a new header
Andreas Rheinhardt:
> libavcodec/hwconfig.h currently contains HWACCEL_CAP_* flags
> as well as the definition of AVCodecHWConfigInternal and some
> macros to create them.
>
> The users of these two are nearly disjoint: The flags are used
> by files providing AVHWAccels whereas AVCodecHWConfigInternal
> is used by files providing codecs (for FFCodec.hw_configs).
>
> This patch therefore moves these flags to a new file hwaccel_internal.h.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/hwaccel_internal.h | 29 +
> libavcodec/hwconfig.h | 5 -
> libavcodec/pthread_frame.c| 1 +
> libavcodec/vaapi_av1.c| 3 +--
> libavcodec/vaapi_h264.c | 2 +-
> libavcodec/vaapi_hevc.c | 2 +-
> libavcodec/vaapi_mjpeg.c | 2 +-
> libavcodec/vaapi_mpeg2.c | 2 +-
> libavcodec/vaapi_mpeg4.c | 2 +-
> libavcodec/vaapi_vc1.c| 3 +--
> libavcodec/vaapi_vp8.c| 2 +-
> libavcodec/vaapi_vp9.c| 2 +-
> libavcodec/vdpau_av1.c| 2 +-
> libavcodec/vdpau_h264.c | 2 +-
> libavcodec/vdpau_hevc.c | 2 +-
> libavcodec/vdpau_mpeg12.c | 2 +-
> libavcodec/vdpau_mpeg4.c | 2 +-
> libavcodec/vdpau_vc1.c| 2 +-
> libavcodec/vdpau_vp9.c| 3 +--
> libavcodec/vulkan_decode.h| 2 +-
> 20 files changed, 47 insertions(+), 25 deletions(-)
> create mode 100644 libavcodec/hwaccel_internal.h
>
> diff --git a/libavcodec/hwaccel_internal.h b/libavcodec/hwaccel_internal.h
> new file mode 100644
> index 00..6e6f5c7cf9
> --- /dev/null
> +++ b/libavcodec/hwaccel_internal.h
> @@ -0,0 +1,29 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +/**
> + * Header providing the internals of AVHWAccel.
> + */
> +
> +#ifndef AVCODEC_HWACCEL_INTERNAL_H
> +#define AVCODEC_HWACCEL_INTERNAL_H
> +
> +#define HWACCEL_CAP_ASYNC_SAFE (1 << 0)
> +#define HWACCEL_CAP_THREAD_SAFE (1 << 1)
> +
> +#endif /* AVCODEC_HWACCEL_INTERNAL */
> diff --git a/libavcodec/hwconfig.h b/libavcodec/hwconfig.h
> index e8c6186151..3b19d5edad 100644
> --- a/libavcodec/hwconfig.h
> +++ b/libavcodec/hwconfig.h
> @@ -22,11 +22,6 @@
> #include "avcodec.h"
> #include "hwaccels.h"
>
> -
> -#define HWACCEL_CAP_ASYNC_SAFE (1 << 0)
> -#define HWACCEL_CAP_THREAD_SAFE (1 << 1)
> -
> -
> typedef struct AVCodecHWConfigInternal {
> /**
> * This is the structure which will be returned to the user by
> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> index bc305f561f..c14010d803 100644
> --- a/libavcodec/pthread_frame.c
> +++ b/libavcodec/pthread_frame.c
> @@ -31,6 +31,7 @@
> #include "avcodec_internal.h"
> #include "codec_internal.h"
> #include "decode.h"
> +#include "hwaccel_internal.h"
> #include "hwconfig.h"
> #include "internal.h"
> #include "pthread_internal.h"
> diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
> index d0339b2705..67ea6af697 100644
> --- a/libavcodec/vaapi_av1.c
> +++ b/libavcodec/vaapi_av1.c
> @@ -19,8 +19,7 @@
> */
>
> #include "libavutil/frame.h"
> -#include "libavutil/pixdesc.h"
> -#include "hwconfig.h"
> +#include "hwaccel_internal.h"
> #include "vaapi_decode.h"
> #include "internal.h"
> #include "av1dec.h"
> diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
> index 9332aa6f31..e7f8e920b2 100644
> --- a/libavcodec/vaapi_h264.c
> +++ b/libavcodec/vaapi_h264.c
> @@ -22,7 +22,7 @@
>
> #include "h264dec.h"
> #include "h264_ps.h"
> -#include "hwconfig.h"
> +#include "hwaccel_internal.h"
> #include "vaapi_decode.h"
>
> /**
> diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
> index 8b12484fff..87584d1edb 100644
> --- a/libavcodec/vaapi_hevc.c
> +++ b/libavcodec/vaapi_hevc.c
> @@ -25,7 +25,7 @@
>
> #include "avcodec.h"
> #include "hevcdec.h"
> -#include "hwconfig.h"
> +#include "hwaccel_internal.h"
> #include "vaapi_decode.h"
> #include "vaapi_hevc.h"
> #include "h265_profile_level.h"
> diff --git a/libavcodec/vaapi_mjpeg.c b/libavcodec/vaapi_mjpeg.c
> index 81582114b6..1947540ea1 100644
> --- a/libavcodec/vaapi_mjpeg.c
> +++ b/libavcodec/vaapi_mjpeg.c
> @@ -19,7 +19,7 @@
> #include
> #include
>
> -#include
Re: [FFmpeg-devel] [PATCH] avcodec/on2avc: use the matching AVTX context for the 512 sized iMDCT
Aug 5, 2023, 11:15 by d...@lynne.ee:
> Aug 5, 2023, 10:33 by c...@passwd.hu:
>
>> Improves the audio corruption regression caused by
>> 6ba0aa1770ba29eb4126c6a706f6b0cd3809648f reported in ticket #10029.
>>
>> There is still however a noticable audio glitch, so the FFT conversion to
>> AVTX
>> probably also needs some modifications.
>>
>> Signed-off-by: Marton Balint
>> ---
>> libavcodec/on2avc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/on2avc.c b/libavcodec/on2avc.c
>> index 74be1dcb60..474adb149d 100644
>> --- a/libavcodec/on2avc.c
>> +++ b/libavcodec/on2avc.c
>> @@ -700,7 +700,7 @@ static int on2avc_reconstruct_channel_ext(On2AVCContext
>> *c, AVFrame *dst, int of
>> break;
>> case WINDOW_TYPE_EXT5:
>> c->wtf(c, buf, in, 512);
>> -c->mdct_half_fn(c->mdct, buf + 512, in + 512, sizeof(float));
>> +c->mdct_half_fn(c->mdct_half, buf + 512, in + 512,
>> sizeof(float));
>> for (i = 0; i < 256; i++) {
>> FFSWAP(float, buf[i + 512], buf[1023 - i]);
>> }
>>
>
> LGTM
> Thanks
>
Actually, looking at it, the WINDOW_TYPE_EXT7 branch, something
weird's going on there as well:
- c->mdct.imdct_half(>mdct, buf, in);
+ c->mdct_fn(c->mdct, buf, in, sizeof(float));
The original misused the context. Maybe this
should be both half as well?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/on2avc: use the matching AVTX context for the 512 sized iMDCT
Aug 5, 2023, 10:33 by c...@passwd.hu:
> Improves the audio corruption regression caused by
> 6ba0aa1770ba29eb4126c6a706f6b0cd3809648f reported in ticket #10029.
>
> There is still however a noticable audio glitch, so the FFT conversion to AVTX
> probably also needs some modifications.
>
> Signed-off-by: Marton Balint
> ---
> libavcodec/on2avc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/on2avc.c b/libavcodec/on2avc.c
> index 74be1dcb60..474adb149d 100644
> --- a/libavcodec/on2avc.c
> +++ b/libavcodec/on2avc.c
> @@ -700,7 +700,7 @@ static int on2avc_reconstruct_channel_ext(On2AVCContext
> *c, AVFrame *dst, int of
> break;
> case WINDOW_TYPE_EXT5:
> c->wtf(c, buf, in, 512);
> -c->mdct_half_fn(c->mdct, buf + 512, in + 512, sizeof(float));
> +c->mdct_half_fn(c->mdct_half, buf + 512, in + 512,
> sizeof(float));
> for (i = 0; i < 256; i++) {
> FFSWAP(float, buf[i + 512], buf[1023 - i]);
> }
>
LGTM
Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/on2avc: use the matching AVTX context for the 512 sized iMDCT
Improves the audio corruption regression caused by
6ba0aa1770ba29eb4126c6a706f6b0cd3809648f reported in ticket #10029.
There is still however a noticable audio glitch, so the FFT conversion to AVTX
probably also needs some modifications.
Signed-off-by: Marton Balint
---
libavcodec/on2avc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/on2avc.c b/libavcodec/on2avc.c
index 74be1dcb60..474adb149d 100644
--- a/libavcodec/on2avc.c
+++ b/libavcodec/on2avc.c
@@ -700,7 +700,7 @@ static int on2avc_reconstruct_channel_ext(On2AVCContext *c,
AVFrame *dst, int of
break;
case WINDOW_TYPE_EXT5:
c->wtf(c, buf, in, 512);
-c->mdct_half_fn(c->mdct, buf + 512, in + 512, sizeof(float));
+c->mdct_half_fn(c->mdct_half, buf + 512, in + 512, sizeof(float));
for (i = 0; i < 256; i++) {
FFSWAP(float, buf[i + 512], buf[1023 - i]);
}
--
2.35.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avfilter: Deduplicate default audio inputs/outputs
Andreas Rheinhardt: > Lots of audio filters use very simple inputs or outputs: > An array with a single AVFilterPad whose name is "default" > and whose type is AVMEDIA_TYPE_AUDIO; everything else is unset. > > Given that we never use pointer equality for inputs or outputs*, > we can simply use a single AVFilterPad instead of dozens; this > even saves .data.rel.ro (4784B here) as well as relocations. > > *: In fact, several filters (like the filters in af_biquads.c) > already use the same inputs; furthermore, ff_filter_alloc() > duplicates the input and output pads so that we do not even > work with the pads directly. > > Signed-off-by: Andreas Rheinhardt > --- Will apply this patchset (with its potential for many conflicts) the day after tomorrow unless there are objections. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
