Re: [FFmpeg-devel] [PATCH 01/14] configure: Remove obsolete wmavoice->rdft, dct dependencies
Sep 29, 2023, 00:10 by andreas.rheinha...@outlook.com: > Lynne: > >> Sep 28, 2023, 23:40 by andreas.rheinha...@outlook.com: >> >>> Andreas Rheinhardt: >>> Forgotten in a810126501e1ef0992d765720ff0d2629c5d1616. Signed-off-by: Andreas Rheinhardt --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index e1afcaa586..762311ae51 100755 --- a/configure +++ b/configure @@ -3033,7 +3033,7 @@ wmav1_decoder_select="sinewin wma_freqs" wmav1_encoder_select="sinewin wma_freqs" wmav2_decoder_select="sinewin wma_freqs" wmav2_encoder_select="sinewin wma_freqs" -wmavoice_decoder_select="lsp rdft dct sinewin" +wmavoice_decoder_select="lsp sinewin" wmv1_decoder_select="msmpeg4dec" wmv1_encoder_select="msmpeg4enc" wmv2_decoder_select="blockdsp error_resilience idctdsp intrax8 msmpeg4dec videodsp wmv2dsp" >>> >>> Unfortunately, patch #5 from this set (the main one) has been rejected >>> by the mailing list as spam. It is here: >>> https://github.com/mkver/FFmpeg/commit/e0ad224d4ccd293617c75a8ba6f5e2cda78b7c56 >>> and a branch for these patches is here: >>> https://github.com/mkver/FFmpeg/commits/fft >>> >> >> Would you mind awfully letting me be the author on this one? I already had a >> patch, but then I got swept up switching mpegaudiodsp to lavu/tx, doing >> a better 32-point DCT, and Cooley-Tukey, and VDD, and I forgot to send it. >> Would just be nice to see after working on lavu/tx for 4 years now. >> > > If you have a patch, why don't you send it now? There is really no need > for this code to be recompiled and relinked all the time? > Your patch is pretty much what my patches did, except you wrap dct32, while I get rid of it, and I also did it one component at a time rather than getting rid of all of it at once. I have no objection with the way this is done either way. I'd just like some credit for deleting something I spent years researching and replacing. After all, it's easy to remove entire files at once and being first, but less so figuring out how to write fast and reasonably small DCT-I/DST-I transforms. ___ 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] SDR lib comments
On Thu, Sep 28, 2023 at 05:07:17PM -0400, Vittorio Giovara wrote: > On Thu, Sep 28, 2023 at 3:28 PM Michael Niedermayer > wrote: > > > On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2023-09-23 18:43:44) > > > > Is a seperate library really the right choice for SDR in FFmpeg at > > this stage ? > > > > > > > > Also code can always be moved into an seperate library > > > > > > we've had postproc in the tree for ages, nobody maintains it or > > > cares about it, yet it seems impossible to get rid of it. > > > > what maintaince does it need ? > > > > making sure that the library builds on all supported system, doesn't have > security holes, etc is it failing to build ? i would expect if it fails to build to be contacted about that. Or well if not that people would not expect it to be fixed by me. are there security holes ? If so i would expect them to be reported to ffmpeg-security or me or something like that. > or for packagers to bundle the library > > > > libpostproc implements part of ISO/IEC 14496-2 > > (that is the spec for an MPEG-4 ASP decoder) > > > > We're going a bit off topic, but you're referring to something preceding > H264 which means is something older than 20 years -- while old formats > surely need to be supported against digital obsolescence, the > code:functionality ratio is certainly not worth it (who uses ASP > nowadays?), There is substantial amounts of existing material in ASP [...] > > > > I have too many other things to work on to do a big refactoring of it > > but if there are small bugs in it or questions about it i can look into > > them > > > > I think the main reason libpostproc was mentioned is that we don't want a > repeat of the history for SDR - so far you're only developer expressing SDR currently is completely self contained in a input device/demuxer. Thats the very opposite of libpostproc which is a bit of video filtering a bit of mpeg4 ASP and neither in libavfilter (which did not exist when libpostproc was created) nor libavcodec The main obstacle to cleanup libpostproc is probably the old style interleaved SIMD code. Again this has no parallel to SDR thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein 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] SDR lib comments
On Fri, Sep 29, 2023 at 12:05:56AM +0300, Rémi Denis-Courmont wrote: > > > Le 28 septembre 2023 22:28:35 GMT+03:00, Michael Niedermayer > a écrit : > >On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote: > >> Quoting Michael Niedermayer (2023-09-23 18:43:44) > >> > Is a seperate library really the right choice for SDR in FFmpeg at this > >> > stage ? > >> > > >> > Also code can always be moved into an seperate library > >> > >> we've had postproc in the tree for ages, nobody maintains it or > >> cares about it, yet it seems impossible to get rid of it. > > > >what maintaince does it need ? > >i mean i know the code is ugly but what _needs_ to be changed? > > This is rather disingenous, TBH. All non-trivial code needs maintenance. > > If there is no formal proof that the code is perfect, then it's probably > bugged. And for the sake of the argument, if there were such a proof, it > would need to be maintained as the code around changes, so either wayw that's > maintenance. > > Then you also can't really ascertain that the code won't need fixes for > future build environments and code auditing tools. > > And then you have all the more or less hidden costs of keeping code around, > especially if it's unmaintained : people will enable it (if it's even > disabled by default), hit problems and look for support. > > And as a downstream OSS application developer, I'd really rather postproc be > officially and properly dropped, so I can justify dropping it downstream as > well. > > > But at least, postproc doesn't engender extra traffic on this mailing list > much at all. More or less nobody here can or wants to review or test your SDR > code. I think, more so than ffmpeg.git being ill-suited a source code > repository for SDR because it is so niche and loosely related, ffmpeg-devel > is simply not suited for SDR. The skills are not here, the time and > motivation are not here, not to speak of the good will. My reply was only about libpostproc, I was intending to just ask what exactly needs to be done in libpostproc (aka maintaince) i had not intended to somehow refer to anything else. I should have snipped the other bits of the quoted thread probably thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle 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 01/14] configure: Remove obsolete wmavoice->rdft, dct dependencies
Lynne: > Sep 28, 2023, 23:40 by andreas.rheinha...@outlook.com: > >> Andreas Rheinhardt: >> >>> Forgotten in a810126501e1ef0992d765720ff0d2629c5d1616. >>> >>> Signed-off-by: Andreas Rheinhardt >>> --- >>> configure | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/configure b/configure >>> index e1afcaa586..762311ae51 100755 >>> --- a/configure >>> +++ b/configure >>> @@ -3033,7 +3033,7 @@ wmav1_decoder_select="sinewin wma_freqs" >>> wmav1_encoder_select="sinewin wma_freqs" >>> wmav2_decoder_select="sinewin wma_freqs" >>> wmav2_encoder_select="sinewin wma_freqs" >>> -wmavoice_decoder_select="lsp rdft dct sinewin" >>> +wmavoice_decoder_select="lsp sinewin" >>> wmv1_decoder_select="msmpeg4dec" >>> wmv1_encoder_select="msmpeg4enc" >>> wmv2_decoder_select="blockdsp error_resilience idctdsp intrax8 msmpeg4dec >>> videodsp wmv2dsp" >>> >> >> Unfortunately, patch #5 from this set (the main one) has been rejected >> by the mailing list as spam. It is here: >> https://github.com/mkver/FFmpeg/commit/e0ad224d4ccd293617c75a8ba6f5e2cda78b7c56 >> and a branch for these patches is here: >> https://github.com/mkver/FFmpeg/commits/fft >> > > Would you mind awfully letting me be the author on this one? I already had a > patch, but then I got swept up switching mpegaudiodsp to lavu/tx, doing > a better 32-point DCT, and Cooley-Tukey, and VDD, and I forgot to send it. > Would just be nice to see after working on lavu/tx for 4 years now. > If you have a patch, why don't you send it now? There is really no need for this code to be recompiled and relinked all the time. > The rest of the configure changes, and the SILK change all LGTM. > Can't comment on the rest, but I think they don't need to all be pushed > at the same time. ___ 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 01/14] configure: Remove obsolete wmavoice->rdft, dct dependencies
Sep 28, 2023, 23:40 by andreas.rheinha...@outlook.com: > Andreas Rheinhardt: > >> Forgotten in a810126501e1ef0992d765720ff0d2629c5d1616. >> >> Signed-off-by: Andreas Rheinhardt >> --- >> configure | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/configure b/configure >> index e1afcaa586..762311ae51 100755 >> --- a/configure >> +++ b/configure >> @@ -3033,7 +3033,7 @@ wmav1_decoder_select="sinewin wma_freqs" >> wmav1_encoder_select="sinewin wma_freqs" >> wmav2_decoder_select="sinewin wma_freqs" >> wmav2_encoder_select="sinewin wma_freqs" >> -wmavoice_decoder_select="lsp rdft dct sinewin" >> +wmavoice_decoder_select="lsp sinewin" >> wmv1_decoder_select="msmpeg4dec" >> wmv1_encoder_select="msmpeg4enc" >> wmv2_decoder_select="blockdsp error_resilience idctdsp intrax8 msmpeg4dec >> videodsp wmv2dsp" >> > > Unfortunately, patch #5 from this set (the main one) has been rejected > by the mailing list as spam. It is here: > https://github.com/mkver/FFmpeg/commit/e0ad224d4ccd293617c75a8ba6f5e2cda78b7c56 > and a branch for these patches is here: > https://github.com/mkver/FFmpeg/commits/fft > Would you mind awfully letting me be the author on this one? I already had a patch, but then I got swept up switching mpegaudiodsp to lavu/tx, doing a better 32-point DCT, and Cooley-Tukey, and VDD, and I forgot to send it. Would just be nice to see after working on lavu/tx for 4 years now. The rest of the configure changes, and the SILK change all LGTM. Can't comment on the rest, but I think they don't need to all be pushed at the same time. ___ 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 01/14] configure: Remove obsolete wmavoice->rdft, dct dependencies
Andreas Rheinhardt: > Forgotten in a810126501e1ef0992d765720ff0d2629c5d1616. > > Signed-off-by: Andreas Rheinhardt > --- > configure | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure b/configure > index e1afcaa586..762311ae51 100755 > --- a/configure > +++ b/configure > @@ -3033,7 +3033,7 @@ wmav1_decoder_select="sinewin wma_freqs" > wmav1_encoder_select="sinewin wma_freqs" > wmav2_decoder_select="sinewin wma_freqs" > wmav2_encoder_select="sinewin wma_freqs" > -wmavoice_decoder_select="lsp rdft dct sinewin" > +wmavoice_decoder_select="lsp sinewin" > wmv1_decoder_select="msmpeg4dec" > wmv1_encoder_select="msmpeg4enc" > wmv2_decoder_select="blockdsp error_resilience idctdsp intrax8 msmpeg4dec > videodsp wmv2dsp" Unfortunately, patch #5 from this set (the main one) has been rejected by the mailing list as spam. It is here: https://github.com/mkver/FFmpeg/commit/e0ad224d4ccd293617c75a8ba6f5e2cda78b7c56 and a branch for these patches is here: https://github.com/mkver/FFmpeg/commits/fft - 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".
[FFmpeg-devel] [PATCH 14/14] avcodec/bgmc: Use void* instead of AVCodecContext* as logctx
Signed-off-by: Andreas Rheinhardt
---
libavcodec/bgmc.c | 4 ++--
libavcodec/bgmc.h | 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavcodec/bgmc.c b/libavcodec/bgmc.c
index 361f7c52e6..0e41a39e00 100644
--- a/libavcodec/bgmc.c
+++ b/libavcodec/bgmc.c
@@ -457,7 +457,7 @@ static uint8_t *bgmc_lut_getp(uint8_t *lut, int
*lut_status, int delta)
/** Initialize the lookup table arrays */
-av_cold int ff_bgmc_init(AVCodecContext *avctx,
+av_cold int ff_bgmc_init(void *logctx,
uint8_t **cf_lut, int **cf_lut_status)
{
*cf_lut= av_malloc(sizeof(**cf_lut)* LUT_BUFF * 16 *
LUT_SIZE);
@@ -465,7 +465,7 @@ av_cold int ff_bgmc_init(AVCodecContext *avctx,
if (!*cf_lut || !*cf_lut_status) {
ff_bgmc_end(cf_lut, cf_lut_status);
-av_log(avctx, AV_LOG_ERROR, "Allocating buffer memory failed.\n");
+av_log(logctx, AV_LOG_ERROR, "Allocating buffer memory failed.\n");
return AVERROR(ENOMEM);
} else {
// initialize lut_status buffer to a value never used to compare
against
diff --git a/libavcodec/bgmc.h b/libavcodec/bgmc.h
index 466df31a2e..81771d4aef 100644
--- a/libavcodec/bgmc.h
+++ b/libavcodec/bgmc.h
@@ -30,11 +30,10 @@
#define AVCODEC_BGMC_H
-#include "avcodec.h"
#include "get_bits.h"
-int ff_bgmc_init(AVCodecContext *avctx, uint8_t **cf_lut, int **cf_lut_status);
+int ff_bgmc_init(void *logctx, uint8_t **cf_lut, int **cf_lut_status);
void ff_bgmc_end(uint8_t **cf_lut, int **cf_lut_status);
--
2.34.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".
[FFmpeg-devel] [PATCH 13/14] avcodec/flac_parse: Use void* instead of AVCodecContext* as logctx
It more directly shows that ff_flac_decode_frame_header() does not
modify the AVCodecContext given to it at all; and it would not be
allowed to do so, given that it is used by the parser when it is
still unknown whether said frame header is even valid.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/flac.c | 18 +-
libavcodec/flac_parse.h | 4 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/libavcodec/flac.c b/libavcodec/flac.c
index 174b4801be..fac4cff9e7 100644
--- a/libavcodec/flac.c
+++ b/libavcodec/flac.c
@@ -48,14 +48,14 @@ static int64_t get_utf8(GetBitContext *gb)
return val;
}
-int ff_flac_decode_frame_header(AVCodecContext *avctx, GetBitContext *gb,
+int ff_flac_decode_frame_header(void *logctx, GetBitContext *gb,
FLACFrameInfo *fi, int log_level_offset)
{
int bs_code, sr_code, bps_code;
/* frame sync code */
if ((get_bits(gb, 15) & 0x7FFF) != 0x7FFC) {
-av_log(avctx, AV_LOG_ERROR + log_level_offset, "invalid sync code\n");
+av_log(logctx, AV_LOG_ERROR + log_level_offset, "invalid sync code\n");
return AVERROR_INVALIDDATA;
}
@@ -75,7 +75,7 @@ int ff_flac_decode_frame_header(AVCodecContext *avctx,
GetBitContext *gb,
fi->channels = 2;
fi->ch_mode -= FLAC_MAX_CHANNELS - 1;
} else {
-av_log(avctx, AV_LOG_ERROR + log_level_offset,
+av_log(logctx, AV_LOG_ERROR + log_level_offset,
"invalid channel mode: %d\n", fi->ch_mode);
return AVERROR_INVALIDDATA;
}
@@ -83,7 +83,7 @@ int ff_flac_decode_frame_header(AVCodecContext *avctx,
GetBitContext *gb,
/* bits per sample */
bps_code = get_bits(gb, 3);
if (bps_code == 3) {
-av_log(avctx, AV_LOG_ERROR + log_level_offset,
+av_log(logctx, AV_LOG_ERROR + log_level_offset,
"invalid sample size code (%d)\n",
bps_code);
return AVERROR_INVALIDDATA;
@@ -92,7 +92,7 @@ int ff_flac_decode_frame_header(AVCodecContext *avctx,
GetBitContext *gb,
/* reserved bit */
if (get_bits1(gb)) {
-av_log(avctx, AV_LOG_ERROR + log_level_offset,
+av_log(logctx, AV_LOG_ERROR + log_level_offset,
"broken stream, invalid padding\n");
return AVERROR_INVALIDDATA;
}
@@ -100,14 +100,14 @@ int ff_flac_decode_frame_header(AVCodecContext *avctx,
GetBitContext *gb,
/* sample or frame count */
fi->frame_or_sample_num = get_utf8(gb);
if (fi->frame_or_sample_num < 0) {
-av_log(avctx, AV_LOG_ERROR + log_level_offset,
+av_log(logctx, AV_LOG_ERROR + log_level_offset,
"sample/frame number invalid; utf8 fscked\n");
return AVERROR_INVALIDDATA;
}
/* blocksize */
if (bs_code == 0) {
-av_log(avctx, AV_LOG_ERROR + log_level_offset,
+av_log(logctx, AV_LOG_ERROR + log_level_offset,
"reserved blocksize code: 0\n");
return AVERROR_INVALIDDATA;
} else if (bs_code == 6) {
@@ -128,7 +128,7 @@ int ff_flac_decode_frame_header(AVCodecContext *avctx,
GetBitContext *gb,
} else if (sr_code == 14) {
fi->samplerate = get_bits(gb, 16) * 10;
} else {
-av_log(avctx, AV_LOG_ERROR + log_level_offset,
+av_log(logctx, AV_LOG_ERROR + log_level_offset,
"illegal sample rate code %d\n",
sr_code);
return AVERROR_INVALIDDATA;
@@ -138,7 +138,7 @@ int ff_flac_decode_frame_header(AVCodecContext *avctx,
GetBitContext *gb,
skip_bits(gb, 8);
if (av_crc(av_crc_get_table(AV_CRC_8_ATM), 0, gb->buffer,
get_bits_count(gb)/8)) {
-av_log(avctx, AV_LOG_ERROR + log_level_offset,
+av_log(logctx, AV_LOG_ERROR + log_level_offset,
"header crc mismatch\n");
return AVERROR_INVALIDDATA;
}
diff --git a/libavcodec/flac_parse.h b/libavcodec/flac_parse.h
index 67a7320bea..b0cbad825e 100644
--- a/libavcodec/flac_parse.h
+++ b/libavcodec/flac_parse.h
@@ -75,13 +75,13 @@ int ff_flac_is_extradata_valid(AVCodecContext *avctx,
/**
* Validate and decode a frame header.
- * @param avctx AVCodecContext to use as av_log() context
+ * @param logctx context for logging
* @param gbGetBitContext from which to read frame header
* @param[out] fiframe information
* @param log_level_offset log level offset. can be used to silence
error messages.
* @return non-zero on error, 0 if ok
*/
-int ff_flac_decode_frame_header(AVCodecContext *avctx, GetBitContext *gb,
+int ff_flac_decode_frame_header(void *logctx, GetBitContext *gb,
FLACFrameInfo *fi, int log_level_offset);
void ff_flac_set_channel_layout(AVCodecContext *avctx, int channels);
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe,
[FFmpeg-devel] [PATCH 12/14] avcodec/lagarith: Use void* instead of AVCodecContext* as logctx
Signed-off-by: Andreas Rheinhardt
---
libavcodec/lagarith.c| 14 +++---
libavcodec/lagarithrac.h | 3 +--
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/libavcodec/lagarith.c b/libavcodec/lagarith.c
index 3288c0517c..9574f78871 100644
--- a/libavcodec/lagarith.c
+++ b/libavcodec/lagarith.c
@@ -166,17 +166,17 @@ static int lag_read_prob_header(lag_rac *rac,
GetBitContext *gb)
/* Read probabilities from bitstream */
for (i = 1; i < 257; i++) {
if (lag_decode_prob(gb, >prob[i]) < 0) {
-av_log(rac->avctx, AV_LOG_ERROR, "Invalid probability
encountered.\n");
+av_log(rac->logctx, AV_LOG_ERROR, "Invalid probability
encountered.\n");
return AVERROR_INVALIDDATA;
}
if ((uint64_t)cumul_prob + rac->prob[i] > UINT_MAX) {
-av_log(rac->avctx, AV_LOG_ERROR, "Integer overflow encountered in
cumulative probability calculation.\n");
+av_log(rac->logctx, AV_LOG_ERROR, "Integer overflow encountered in
cumulative probability calculation.\n");
return AVERROR_INVALIDDATA;
}
cumul_prob += rac->prob[i];
if (!rac->prob[i]) {
if (lag_decode_prob(gb, )) {
-av_log(rac->avctx, AV_LOG_ERROR, "Invalid probability run
encountered.\n");
+av_log(rac->logctx, AV_LOG_ERROR, "Invalid probability run
encountered.\n");
return AVERROR_INVALIDDATA;
}
if (prob > 256 - i)
@@ -189,7 +189,7 @@ static int lag_read_prob_header(lag_rac *rac, GetBitContext
*gb)
}
if (!cumul_prob) {
-av_log(rac->avctx, AV_LOG_ERROR, "All probabilities are 0!\n");
+av_log(rac->logctx, AV_LOG_ERROR, "All probabilities are 0!\n");
return AVERROR_INVALIDDATA;
}
@@ -207,7 +207,7 @@ static int lag_read_prob_header(lag_rac *rac, GetBitContext
*gb)
scaled_cumul_prob += rac->prob[i];
}
if (scaled_cumul_prob <= 0) {
-av_log(rac->avctx, AV_LOG_ERROR, "Scaled probabilities invalid\n");
+av_log(rac->logctx, AV_LOG_ERROR, "Scaled probabilities
invalid\n");
return AVERROR_INVALIDDATA;
}
for (; i < 257; i++) {
@@ -221,7 +221,7 @@ static int lag_read_prob_header(lag_rac *rac, GetBitContext
*gb)
cumulative_target = 1U << scale_factor;
if (scaled_cumul_prob > cumulative_target) {
-av_log(rac->avctx, AV_LOG_ERROR,
+av_log(rac->logctx, AV_LOG_ERROR,
"Scaled probabilities are larger than target!\n");
return AVERROR_INVALIDDATA;
}
@@ -463,7 +463,7 @@ static int lag_decode_arith_plane(LagarithContext *l,
uint8_t *dst,
const uint8_t *src_end = src + src_size;
int ret;
-rac.avctx = l->avctx;
+rac.logctx = l->avctx;
l->zeros = 0;
if(src_size < 2)
diff --git a/libavcodec/lagarithrac.h b/libavcodec/lagarithrac.h
index a31b054dbb..2c8cb7385a 100644
--- a/libavcodec/lagarithrac.h
+++ b/libavcodec/lagarithrac.h
@@ -32,11 +32,10 @@
#include
#include "libavutil/intreadwrite.h"
-#include "avcodec.h"
#include "get_bits.h"
typedef struct lag_rac {
-AVCodecContext *avctx;
+void*logctx;
unsigned low;
unsigned range;
unsigned scale; /**< Number of bits of precision in range. */
--
2.34.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".
[FFmpeg-devel] [PATCH 11/14] avcodec/opus_silk: Use void* instead of AVCodecContext* as logctx
Signed-off-by: Andreas Rheinhardt
---
libavcodec/opus_silk.c | 10 +-
libavcodec/opus_silk.h | 3 +--
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/libavcodec/opus_silk.c b/libavcodec/opus_silk.c
index cf8b16acff..27671516a0 100644
--- a/libavcodec/opus_silk.c
+++ b/libavcodec/opus_silk.c
@@ -48,7 +48,7 @@ typedef struct SilkFrame {
} SilkFrame;
struct SilkContext {
-AVCodecContext *avctx;
+void *logctx;
int output_channels;
int midonly;
@@ -799,7 +799,7 @@ int ff_silk_decode_superframe(SilkContext *s,
OpusRangeCoder *rc,
if (bandwidth > OPUS_BANDWIDTH_WIDEBAND ||
coded_channels > 2 || duration_ms > 60) {
-av_log(s->avctx, AV_LOG_ERROR, "Invalid parameters passed "
+av_log(s->logctx, AV_LOG_ERROR, "Invalid parameters passed "
"to the SILK decoder.\n");
return AVERROR(EINVAL);
}
@@ -879,12 +879,12 @@ void ff_silk_flush(SilkContext *s)
memset(s->prev_stereo_weights, 0, sizeof(s->prev_stereo_weights));
}
-int ff_silk_init(AVCodecContext *avctx, SilkContext **ps, int output_channels)
+int ff_silk_init(void *logctx, SilkContext **ps, int output_channels)
{
SilkContext *s;
if (output_channels != 1 && output_channels != 2) {
-av_log(avctx, AV_LOG_ERROR, "Invalid number of output channels: %d\n",
+av_log(logctx, AV_LOG_ERROR, "Invalid number of output channels: %d\n",
output_channels);
return AVERROR(EINVAL);
}
@@ -893,7 +893,7 @@ int ff_silk_init(AVCodecContext *avctx, SilkContext **ps,
int output_channels)
if (!s)
return AVERROR(ENOMEM);
-s->avctx = avctx;
+s->logctx = logctx;
s->output_channels = output_channels;
ff_silk_flush(s);
diff --git a/libavcodec/opus_silk.h b/libavcodec/opus_silk.h
index 6552c166a4..4b595da2b9 100644
--- a/libavcodec/opus_silk.h
+++ b/libavcodec/opus_silk.h
@@ -23,7 +23,6 @@
#ifndef AVCODEC_OPUS_SILK_H
#define AVCODEC_OPUS_SILK_H
-#include "avcodec.h"
#include "opus.h"
#include "opus_rc.h"
@@ -32,7 +31,7 @@
typedef struct SilkContext SilkContext;
-int ff_silk_init(AVCodecContext *avctx, SilkContext **ps, int output_channels);
+int ff_silk_init(void *logctx, SilkContext **ps, int output_channels);
void ff_silk_free(SilkContext **ps);
void ff_silk_flush(SilkContext *s);
--
2.34.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".
[FFmpeg-devel] [PATCH 10/14] avcodec/roqvideo: Use void*, not AVCodecContext* for logctx
Also stop setting the field once per encode-frame.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/roqvideo.c| 4 ++--
libavcodec/roqvideo.h| 4 ++--
libavcodec/roqvideodec.c | 8
libavcodec/roqvideoenc.c | 8 +++-
4 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/libavcodec/roqvideo.c b/libavcodec/roqvideo.c
index f9a3c8e083..ca8c8de967 100644
--- a/libavcodec/roqvideo.c
+++ b/libavcodec/roqvideo.c
@@ -111,13 +111,13 @@ static inline void apply_motion_generic(RoqContext *ri,
int x, int y, int deltax
/* check MV against frame boundaries */
if ((mx < 0) || (mx > ri->width - sz) ||
(my < 0) || (my > ri->height - sz)) {
-av_log(ri->avctx, AV_LOG_ERROR, "motion vector out of bounds: MV =
(%d, %d), boundaries = (0, 0, %d, %d)\n",
+av_log(ri->logctx, AV_LOG_ERROR, "motion vector out of bounds: MV =
(%d, %d), boundaries = (0, 0, %d, %d)\n",
mx, my, ri->width, ri->height);
return;
}
if (!ri->last_frame->data[0]) {
-av_log(ri->avctx, AV_LOG_ERROR, "Invalid decode type. Invalid
header?\n");
+av_log(ri->logctx, AV_LOG_ERROR, "Invalid decode type. Invalid
header?\n");
return;
}
diff --git a/libavcodec/roqvideo.h b/libavcodec/roqvideo.h
index 8318b6e5a0..2c2e42884d 100644
--- a/libavcodec/roqvideo.h
+++ b/libavcodec/roqvideo.h
@@ -22,7 +22,7 @@
#ifndef AVCODEC_ROQVIDEO_H
#define AVCODEC_ROQVIDEO_H
-#include "avcodec.h"
+#include "libavutil/frame.h"
typedef struct roq_cell {
unsigned char y[4];
@@ -39,7 +39,7 @@ typedef struct motion_vect {
typedef struct RoqContext {
const AVClass *class;
-AVCodecContext *avctx;
+void *logctx;
AVFrame *last_frame;
AVFrame *current_frame;
int width, height;
diff --git a/libavcodec/roqvideodec.c b/libavcodec/roqvideodec.c
index 6f2e48d2f3..bfc69a65c9 100644
--- a/libavcodec/roqvideodec.c
+++ b/libavcodec/roqvideodec.c
@@ -72,7 +72,7 @@ static void roqvideo_decode_frame(RoqContext *ri,
GetByteContext *gb)
xpos = ypos = 0;
if (chunk_size > bytestream2_get_bytes_left(gb)) {
-av_log(ri->avctx, AV_LOG_ERROR, "Chunk does not fit in input
buffer\n");
+av_log(ri->logctx, AV_LOG_ERROR, "Chunk does not fit in input
buffer\n");
chunk_size = bytestream2_get_bytes_left(gb);
}
@@ -80,7 +80,7 @@ static void roqvideo_decode_frame(RoqContext *ri,
GetByteContext *gb)
for (yp = ypos; yp < ypos + 16; yp += 8)
for (xp = xpos; xp < xpos + 16; xp += 8) {
if (bytestream2_tell(gb) >= chunk_start + chunk_size) {
-av_log(ri->avctx, AV_LOG_VERBOSE, "Chunk is too short\n");
+av_log(ri->logctx, AV_LOG_VERBOSE, "Chunk is too short\n");
return;
}
if (vqflg_pos < 0) {
@@ -114,7 +114,7 @@ static void roqvideo_decode_frame(RoqContext *ri,
GetByteContext *gb)
if(k & 0x02) y += 4;
if (bytestream2_tell(gb) >= chunk_start + chunk_size) {
-av_log(ri->avctx, AV_LOG_VERBOSE, "Chunk is too
short\n");
+av_log(ri->logctx, AV_LOG_VERBOSE, "Chunk is too
short\n");
return;
}
if (vqflg_pos < 0) {
@@ -169,7 +169,7 @@ static av_cold int roq_decode_init(AVCodecContext *avctx)
{
RoqContext *s = avctx->priv_data;
-s->avctx = avctx;
+s->logctx = avctx;
if (avctx->width % 16 || avctx->height % 16) {
avpriv_request_sample(avctx, "Dimensions not being a multiple of 16");
diff --git a/libavcodec/roqvideoenc.c b/libavcodec/roqvideoenc.c
index c25aa39b73..0933abf4f9 100644
--- a/libavcodec/roqvideoenc.c
+++ b/libavcodec/roqvideoenc.c
@@ -911,10 +911,10 @@ static int roq_encode_video(RoqEncContext *enc)
/* Quake 3 can't handle chunks bigger than 65535 bytes */
if (tempData->mainChunkSize/8 > 65535 && enc->quake3_compat) {
if (enc->lambda > 10) {
-av_log(roq->avctx, AV_LOG_ERROR, "Cannot encode video in Quake
compatible form\n");
+av_log(roq->logctx, AV_LOG_ERROR, "Cannot encode video in Quake
compatible form\n");
return AVERROR(EINVAL);
}
-av_log(roq->avctx, AV_LOG_ERROR,
+av_log(roq->logctx, AV_LOG_ERROR,
"Warning, generated a frame too big for Quake (%d > 65535), "
"now switching to a bigger qscale value.\n",
tempData->mainChunkSize/8);
@@ -972,7 +972,7 @@ static av_cold int roq_encode_init(AVCodecContext *avctx)
av_lfg_init(>randctx, 1);
-roq->avctx = avctx;
+roq->logctx = avctx;
enc->framesSinceKeyframe = 0;
if ((avctx->width & 0xf) || (avctx->height & 0xf)) {
@@ -1057,8 +1057,6 @@ static int roq_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
RoqContext*const roq = >common;
int
[FFmpeg-devel] [PATCH 09/14] avcodec/sipr: Remove write-only AVCodecContext*
Signed-off-by: Andreas Rheinhardt
---
libavcodec/sipr.c | 1 -
libavcodec/sipr.h | 3 ---
2 files changed, 4 deletions(-)
diff --git a/libavcodec/sipr.c b/libavcodec/sipr.c
index 692b59b3e8..3ddc579f09 100644
--- a/libavcodec/sipr.c
+++ b/libavcodec/sipr.c
@@ -532,7 +532,6 @@ static int sipr_decode_frame(AVCodecContext *avctx, AVFrame
*frame,
int subframe_size = ctx->mode == MODE_16k ? L_SUBFR_16k : SUBFR_SIZE;
int i, ret;
-ctx->avctx = avctx;
if (avpkt->size < (mode_par->bits_per_frame >> 3)) {
av_log(avctx, AV_LOG_ERROR,
"Error processing packet: packet size (%d) too small\n",
diff --git a/libavcodec/sipr.h b/libavcodec/sipr.h
index e1ef35d658..e7073987ed 100644
--- a/libavcodec/sipr.h
+++ b/libavcodec/sipr.h
@@ -24,7 +24,6 @@
#ifndef AVCODEC_SIPR_H
#define AVCODEC_SIPR_H
-#include "avcodec.h"
#include "acelp_pitch_delay.h"
#include "libavutil/mem_internal.h"
@@ -63,8 +62,6 @@ typedef struct SiprParameters {
} SiprParameters;
typedef struct SiprContext {
-AVCodecContext *avctx;
-
SiprMode mode;
float past_pitch_gain;
--
2.34.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".
[FFmpeg-devel] [PATCH 08/14] avcodec/utvideo: Split UTvideoContext into decoder and encoder contexts
In particular the encoder used only a small part of the context:
The new encoder context is only 128B here. It used to be 32992.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/utvideo.h| 35 +--
libavcodec/utvideodec.c | 28
libavcodec/utvideoenc.c | 18 +-
3 files changed, 46 insertions(+), 35 deletions(-)
diff --git a/libavcodec/utvideo.h b/libavcodec/utvideo.h
index e5160aa394..b081b50a2f 100644
--- a/libavcodec/utvideo.h
+++ b/libavcodec/utvideo.h
@@ -27,12 +27,7 @@
* Common Ut Video header
*/
-#include "libavutil/common.h"
-#include "avcodec.h"
-#include "bswapdsp.h"
-#include "utvideodsp.h"
-#include "lossless_videodsp.h"
-#include "lossless_videoencdsp.h"
+#include "libavutil/macros.h"
enum {
PRED_NONE = 0,
@@ -61,32 +56,4 @@ enum {
UTVIDEO_444 = MKTAG('Y', 'V', '2', '4'),
};
-typedef struct UtvideoContext {
-const AVClass *class;
-AVCodecContext *avctx;
-UTVideoDSPContext utdsp;
-BswapDSPContext bdsp;
-LLVidDSPContext llviddsp;
-LLVidEncDSPContext llvidencdsp;
-
-uint32_t frame_info_size, flags, frame_info, offset;
-int planes;
-int slices;
-int compression;
-int interlaced;
-int frame_pred;
-int pro;
-int pack;
-
-ptrdiff_t slice_stride;
-uint8_t *slice_bits, *slice_buffer[4];
-int slice_bits_size;
-void*buffer;
-
-const uint8_t *packed_stream[4][256];
-size_t packed_stream_size[4][256];
-const uint8_t *control_stream[4][256];
-size_t control_stream_size[4][256];
-} UtvideoContext;
-
#endif /* AVCODEC_UTVIDEO_H */
diff --git a/libavcodec/utvideodec.c b/libavcodec/utvideodec.c
index 7ee07209d4..fa80cc577c 100644
--- a/libavcodec/utvideodec.c
+++ b/libavcodec/utvideodec.c
@@ -37,8 +37,36 @@
#include "bytestream.h"
#include "codec_internal.h"
#include "get_bits.h"
+#include "lossless_videodsp.h"
#include "thread.h"
#include "utvideo.h"
+#include "utvideodsp.h"
+
+typedef struct UtvideoContext {
+const AVClass *class;
+AVCodecContext *avctx;
+UTVideoDSPContext utdsp;
+BswapDSPContext bdsp;
+LLVidDSPContext llviddsp;
+
+uint32_t frame_info_size, flags, frame_info, offset;
+int planes;
+int slices;
+int compression;
+int interlaced;
+int frame_pred;
+int pro;
+int pack;
+
+uint8_t *slice_bits;
+int slice_bits_size;
+void*buffer;
+
+const uint8_t *packed_stream[4][256];
+size_t packed_stream_size[4][256];
+const uint8_t *control_stream[4][256];
+size_t control_stream_size[4][256];
+} UtvideoContext;
typedef struct HuffEntry {
uint8_t len;
diff --git a/libavcodec/utvideoenc.c b/libavcodec/utvideoenc.c
index 6e87bbc2b6..c2a7728574 100644
--- a/libavcodec/utvideoenc.c
+++ b/libavcodec/utvideoenc.c
@@ -33,11 +33,28 @@
#include "encode.h"
#include "bswapdsp.h"
#include "bytestream.h"
+#include "lossless_videoencdsp.h"
#include "put_bits.h"
#include "mathops.h"
#include "utvideo.h"
#include "huffman.h"
+typedef struct UtvideoContext {
+const AVClass *class;
+BswapDSPContext bdsp;
+LLVidEncDSPContext llvidencdsp;
+
+uint32_t frame_info_size, flags;
+int planes;
+int slices;
+int compression;
+int frame_pred;
+
+ptrdiff_t slice_stride;
+uint8_t *slice_bits, *slice_buffer[4];
+int slice_bits_size;
+} UtvideoContext;
+
typedef struct HuffEntry {
uint16_t sym;
uint8_t len;
@@ -76,7 +93,6 @@ static av_cold int utvideo_encode_init(AVCodecContext *avctx)
int i, subsampled_height;
uint32_t original_format;
-c->avctx = avctx;
c->frame_info_size = 4;
c->slice_stride= FFALIGN(avctx->width, 32);
--
2.34.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".
[FFmpeg-devel] [PATCH 07/14] avcodec/vorbis: Use void* logctx instead of AVCodecContext*
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vorbis.c | 8 +---
libavcodec/vorbis.h | 4 +---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vorbis.c b/libavcodec/vorbis.c
index d0b660b44a..3d85997576 100644
--- a/libavcodec/vorbis.c
+++ b/libavcodec/vorbis.c
@@ -27,8 +27,10 @@
*/
#include "libavutil/common.h"
+#include "libavutil/error.h"
+#include "libavutil/log.h"
+#include "libavutil/macros.h"
-#include "avcodec.h"
#include "vorbis.h"
#include "vorbis_data.h"
@@ -104,7 +106,7 @@ int ff_vorbis_len2vlc(uint8_t *bits, uint32_t *codes,
unsigned num)
return 0;
}
-int ff_vorbis_ready_floor1_list(AVCodecContext *avctx,
+int ff_vorbis_ready_floor1_list(void *logctx,
vorbis_floor1_entry *list, int values)
{
int i;
@@ -130,7 +132,7 @@ int ff_vorbis_ready_floor1_list(AVCodecContext *avctx,
int j;
for (j = i + 1; j < values; j++) {
if (list[i].x == list[j].x) {
-av_log(avctx, AV_LOG_ERROR,
+av_log(logctx, AV_LOG_ERROR,
"Duplicate value found in floor 1 X coordinates\n");
return AVERROR_INVALIDDATA;
}
diff --git a/libavcodec/vorbis.h b/libavcodec/vorbis.h
index aa1ec5719d..7190465f0d 100644
--- a/libavcodec/vorbis.h
+++ b/libavcodec/vorbis.h
@@ -23,8 +23,6 @@
#include
-#include "avcodec.h"
-
typedef struct vorbis_floor1_entry {
uint16_t x;
uint16_t sort;
@@ -32,7 +30,7 @@ typedef struct vorbis_floor1_entry {
uint16_t high;
} vorbis_floor1_entry;
-int ff_vorbis_ready_floor1_list(AVCodecContext *avctx,
+int ff_vorbis_ready_floor1_list(void *logctx,
vorbis_floor1_entry *list, int values);
unsigned int ff_vorbis_nth_root(unsigned int x, unsigned int n); // x^(1/n)
int ff_vorbis_len2vlc(uint8_t *bits, uint32_t *codes, unsigned num);
--
2.34.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".
[FFmpeg-devel] [PATCH 06/14] configure: Remove dct, fft, mdct, rdft subsystems
This may break some command lines, because the --disable-* options are no longer recognized. Signed-off-by: Andreas Rheinhardt --- This could be squashed together with the preceding commit. configure | 8 1 file changed, 8 deletions(-) diff --git a/configure b/configure index 885c58b631..5499da3594 100755 --- a/configure +++ b/configure @@ -136,13 +136,9 @@ Component options: --disable-w32threads disable Win32 threads [autodetect] --disable-os2threads disable OS/2 threads [autodetect] --disable-networkdisable network support [no] - --disable-dctdisable DCT code --disable-dwtdisable DWT code --disable-error-resilience disable error resilience code --disable-lspdisable LSP code - --disable-mdct disable MDCT code - --disable-rdft disable RDFT code - --disable-fftdisable FFT code --disable-faan disable floating point AAN (I)DCT code --disable-pixelutils disable pixel utils in libavutil @@ -2004,17 +2000,13 @@ PROGRAM_LIST=" " SUBSYSTEM_LIST=" -dct dwt error_resilience faan fast_unaligned -fft lsp -mdct pixelutils network -rdft " # COMPONENT_LIST needs to come last to ensure correct dependency checking -- 2.34.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".
[FFmpeg-devel] [PATCH 04/14] avcodec/mpegaudiodsp: Init dct32 directly
This avoids using dct.c and will allow removing it.
Signed-off-by: Andreas Rheinhardt
---
configure | 1 -
libavcodec/Makefile | 3 ++-
libavcodec/mpegaudiodsp.c | 6 +-
libavcodec/x86/Makefile | 2 +-
libavcodec/x86/mpegaudiodsp.c | 6 ++
5 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/configure b/configure
index 28f1753ecb..f64086186c 100755
--- a/configure
+++ b/configure
@@ -2790,7 +2790,6 @@ mdct_select="fft"
me_cmp_select="idctdsp"
mpeg_er_select="error_resilience"
mpegaudio_select="mpegaudiodsp mpegaudioheader"
-mpegaudiodsp_select="dct"
mpegvideo_select="blockdsp hpeldsp idctdsp videodsp"
mpegvideodec_select="h264chroma mpegvideo mpeg_er"
mpegvideoenc_select="aandcttables fdctdsp me_cmp mpegvideo pixblockdsp"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index cae2e773a1..0a3a8fcdf9 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -134,7 +134,8 @@ OBJS-$(CONFIG_MPEGAUDIO) += mpegaudio.o
mpegaudiodec_common.o \
OBJS-$(CONFIG_MPEGAUDIODSP)+= mpegaudiodsp.o\
mpegaudiodsp_data.o \
mpegaudiodsp_fixed.o \
- mpegaudiodsp_float.o
+ mpegaudiodsp_float.o \
+ dct32_fixed.o dct32_float.o
OBJS-$(CONFIG_MPEGAUDIOHEADER) += mpegaudiodecheader.o mpegaudiotabs.o
OBJS-$(CONFIG_MPEG4AUDIO) += mpeg4audio.o
mpeg4audio_sample_rates.o
OBJS-$(CONFIG_MPEGVIDEO) += mpegvideo.o rl.o \
diff --git a/libavcodec/mpegaudiodsp.c b/libavcodec/mpegaudiodsp.c
index 5a5a679d91..0971c28734 100644
--- a/libavcodec/mpegaudiodsp.c
+++ b/libavcodec/mpegaudiodsp.c
@@ -23,7 +23,6 @@
#include "libavutil/thread.h"
#include "mpegaudio.h"
#include "mpegaudiodsp.h"
-#include "dct.h"
#include "dct32.h"
static AVOnce mpadsp_table_init = AV_ONCE_INIT;
@@ -81,15 +80,12 @@ static av_cold void mpadsp_init_tabs(void)
av_cold void ff_mpadsp_init(MPADSPContext *s)
{
-DCTContext dct;
-
-ff_dct_init(, 5, DCT_II);
ff_thread_once(_table_init, _init_tabs);
s->apply_window_float = ff_mpadsp_apply_window_float;
s->apply_window_fixed = ff_mpadsp_apply_window_fixed;
-s->dct32_float = dct.dct32;
+s->dct32_float = ff_dct32_float;
s->dct32_fixed = ff_dct32_fixed;
s->imdct36_blocks_float = ff_imdct36_blocks_float;
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index b4cc5e0d08..2ceb88968f 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -126,7 +126,7 @@ X86ASM-OBJS-$(CONFIG_LLVIDDSP) +=
x86/lossless_videodsp.o
X86ASM-OBJS-$(CONFIG_LLVIDENCDSP) += x86/lossless_videoencdsp.o
X86ASM-OBJS-$(CONFIG_LPC) += x86/lpc.o
X86ASM-OBJS-$(CONFIG_ME_CMP) += x86/me_cmp.o
-X86ASM-OBJS-$(CONFIG_MPEGAUDIODSP) += x86/imdct36.o
+X86ASM-OBJS-$(CONFIG_MPEGAUDIODSP) += x86/dct32.o x86/imdct36.o
X86ASM-OBJS-$(CONFIG_MPEGVIDEOENC) += x86/mpegvideoencdsp.o
X86ASM-OBJS-$(CONFIG_OPUS_DECODER) += x86/opusdsp.o
X86ASM-OBJS-$(CONFIG_OPUS_ENCODER) += x86/celt_pvq_search.o
diff --git a/libavcodec/x86/mpegaudiodsp.c b/libavcodec/x86/mpegaudiodsp.c
index 6586fe0726..43662cd279 100644
--- a/libavcodec/x86/mpegaudiodsp.c
+++ b/libavcodec/x86/mpegaudiodsp.c
@@ -45,6 +45,9 @@ void ff_four_imdct36_float_sse(float *out, float *buf, float
*in, float *win,
void ff_four_imdct36_float_avx(float *out, float *buf, float *in, float *win,
float *tmpbuf);
+void ff_dct32_float_sse2(float *out, const float *in);
+void ff_dct32_float_avx (float *out, const float *in);
+
DECLARE_ALIGNED(16, static float, mdct_win_sse)[2][4][4*40];
#if HAVE_6REGS && HAVE_SSE_INLINE
@@ -267,6 +270,7 @@ av_cold void ff_mpadsp_init_x86(MPADSPContext *s)
#if HAVE_SSE
if (EXTERNAL_SSE2(cpu_flags)) {
s->imdct36_blocks_float = imdct36_blocks_sse2;
+s->dct32_float = ff_dct32_float_sse2;
}
if (EXTERNAL_SSE3(cpu_flags)) {
s->imdct36_blocks_float = imdct36_blocks_sse3;
@@ -279,6 +283,8 @@ av_cold void ff_mpadsp_init_x86(MPADSPContext *s)
if (EXTERNAL_AVX(cpu_flags)) {
s->imdct36_blocks_float = imdct36_blocks_avx;
}
+if (EXTERNAL_AVX_FAST(cpu_flags))
+s->dct32_float = ff_dct32_float_avx;
#endif
#endif /* HAVE_X86ASM */
}
--
2.34.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".
[FFmpeg-devel] [PATCH 03/14] configure: Remove unnecessary vf_spp->fft dependency
The AVDCT API used by this filter does in no way depend upon the FFT subsystem. Signed-off-by: Andreas Rheinhardt --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 11f232165f..28f1753ecb 100755 --- a/configure +++ b/configure @@ -3809,7 +3809,7 @@ smartblur_filter_deps="gpl swscale" sobel_opencl_filter_deps="opencl" sofalizer_filter_deps="libmysofa" spp_filter_deps="gpl avcodec" -spp_filter_select="fft idctdsp fdctdsp me_cmp pixblockdsp" +spp_filter_select="idctdsp fdctdsp me_cmp pixblockdsp" sr_filter_deps="avformat swscale" sr_filter_select="dnn" stereo3d_filter_deps="gpl" -- 2.34.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".
[FFmpeg-devel] [PATCH 02/14] configure: Remove obsolete ffplay->rdft dependency
Forgotten in 4acd08be6c4f39736179a3d90fd56b508e42ff6d. Signed-off-by: Andreas Rheinhardt --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 762311ae51..11f232165f 100755 --- a/configure +++ b/configure @@ -3915,7 +3915,7 @@ ffmpeg_select="aformat_filter anull_filter atrim_filter format_filter transpose_filter trim_filter vflip_filter" ffmpeg_suggest="ole32 psapi shell32" ffplay_deps="avcodec avformat avfilter swscale swresample sdl2" -ffplay_select="rdft crop_filter transpose_filter hflip_filter vflip_filter rotate_filter" +ffplay_select="crop_filter transpose_filter hflip_filter vflip_filter rotate_filter" ffplay_suggest="shell32" ffprobe_deps="avcodec avformat" ffprobe_suggest="shell32" -- 2.34.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".
[FFmpeg-devel] [PATCH 01/14] configure: Remove obsolete wmavoice->rdft, dct dependencies
Forgotten in a810126501e1ef0992d765720ff0d2629c5d1616. Signed-off-by: Andreas Rheinhardt --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index e1afcaa586..762311ae51 100755 --- a/configure +++ b/configure @@ -3033,7 +3033,7 @@ wmav1_decoder_select="sinewin wma_freqs" wmav1_encoder_select="sinewin wma_freqs" wmav2_decoder_select="sinewin wma_freqs" wmav2_encoder_select="sinewin wma_freqs" -wmavoice_decoder_select="lsp rdft dct sinewin" +wmavoice_decoder_select="lsp sinewin" wmv1_decoder_select="msmpeg4dec" wmv1_encoder_select="msmpeg4enc" wmv2_decoder_select="blockdsp error_resilience idctdsp intrax8 msmpeg4dec videodsp wmv2dsp" -- 2.34.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".
[FFmpeg-devel] [PATCH] lavc/h274: transpose IDCT
From: Niklas Haas
This is mathematically equivalent to what we were doing before, but
gives subtly different results due to rounding (rows first vs columns
first). Doing it this way makes our film grain database generation match
reference implementation and now produces bit-exact outputs in my
testing.
Rename the transposed variables to be a bit less confusing.
---
libavcodec/h274.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavcodec/h274.c b/libavcodec/h274.c
index a5caf09564d..5709200322e 100644
--- a/libavcodec/h274.c
+++ b/libavcodec/h274.c
@@ -59,13 +59,13 @@ static void init_slice_c(int8_t out[64][64], uint8_t h,
uint8_t v,
//
// Note: To make the subsequent matrix multiplication cache friendlier, we
// store each *column* of the starting image in a *row* of `out`
-for (int y = 0; y <= freq_v; y++) {
-for (int x = 0; x <= freq_h; x += 4) {
+for (int l = 0; l <= freq_v; l++) {
+for (int k = 0; k <= freq_h; k += 4) {
uint16_t offset = seed % 2048;
-out[x + 0][y] = Gaussian_LUT[offset + 0];
-out[x + 1][y] = Gaussian_LUT[offset + 1];
-out[x + 2][y] = Gaussian_LUT[offset + 2];
-out[x + 3][y] = Gaussian_LUT[offset + 3];
+out[l][k + 0] = Gaussian_LUT[offset + 0];
+out[l][k + 1] = Gaussian_LUT[offset + 1];
+out[l][k + 2] = Gaussian_LUT[offset + 2];
+out[l][k + 3] = Gaussian_LUT[offset + 3];
prng_shift();
}
}
@@ -74,9 +74,9 @@ static void init_slice_c(int8_t out[64][64], uint8_t h,
uint8_t v,
// 64x64 inverse integer transform
for (int y = 0; y < 64; y++) {
-for (int x = 0; x <= freq_h; x++) {
+for (int x = 0; x <= freq_v; x++) {
int32_t sum = 0;
-for (int p = 0; p <= freq_v; p++)
+for (int p = 0; p <= freq_h; p++)
sum += R64T[y][p] * out[x][p];
tmp[y][x] = (sum + 128) >> 8;
}
@@ -85,8 +85,8 @@ static void init_slice_c(int8_t out[64][64], uint8_t h,
uint8_t v,
for (int y = 0; y < 64; y++) {
for (int x = 0; x < 64; x++) {
int32_t sum = 0;
-for (int p = 0; p <= freq_h; p++)
-sum += tmp[y][p] * R64T[x][p]; // R64T^T = R64
+for (int p = 0; p <= freq_v; p++)
+sum += tmp[x][p] * R64T[y][p]; // R64T^T = R64
// Renormalize and clip to [-127, 127]
out[y][x] = av_clip((sum + 128) >> 8, -127, 127);
}
--
2.42.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] SDR lib comments
On Thu, Sep 28, 2023 at 3:28 PM Michael Niedermayer wrote: > On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2023-09-23 18:43:44) > > > Is a seperate library really the right choice for SDR in FFmpeg at > this stage ? > > > > > > Also code can always be moved into an seperate library > > > > we've had postproc in the tree for ages, nobody maintains it or > > cares about it, yet it seems impossible to get rid of it. > > what maintaince does it need ? > making sure that the library builds on all supported system, doesn't have security holes, etc or for packagers to bundle the library > libpostproc implements part of ISO/IEC 14496-2 > (that is the spec for an MPEG-4 ASP decoder) > We're going a bit off topic, but you're referring to something preceding H264 which means is something older than 20 years -- while old formats surely need to be supported against digital obsolescence, the code:functionality ratio is certainly not worth it (who uses ASP nowadays?), and as you suggest, it's code that could definitely live in libavfilter or libavcodec and not in a separate library. > I have too many other things to work on to do a big refactoring of it > but if there are small bugs in it or questions about it i can look into > them > I think the main reason libpostproc was mentioned is that we don't want a repeat of the history for SDR - so far you're only developer expressing active interest to work on it, and nobody knows if you will be continuing to work on it after releasing it, or for how long, and in which depth. The community at large (except one vocal member) seems to prefer that this code live in a separate repository, and not into ffmpeg mainline, so that we could avoid risking repeating history of having "ugly code" (your words) in the main repo for who knows how long, possibly forever. Once the SDR code is better defined, as library, executable or whatever, and there are users needing it, we could discuss bringing it back in FFmpeg, in a more defined and clean form. -- 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".
Re: [FFmpeg-devel] SDR lib comments
Le 28 septembre 2023 22:28:35 GMT+03:00, Michael Niedermayer a écrit : >On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote: >> Quoting Michael Niedermayer (2023-09-23 18:43:44) >> > Is a seperate library really the right choice for SDR in FFmpeg at this >> > stage ? >> > >> > Also code can always be moved into an seperate library >> >> we've had postproc in the tree for ages, nobody maintains it or >> cares about it, yet it seems impossible to get rid of it. > >what maintaince does it need ? >i mean i know the code is ugly but what _needs_ to be changed? This is rather disingenous, TBH. All non-trivial code needs maintenance. If there is no formal proof that the code is perfect, then it's probably bugged. And for the sake of the argument, if there were such a proof, it would need to be maintained as the code around changes, so either wayw that's maintenance. Then you also can't really ascertain that the code won't need fixes for future build environments and code auditing tools. And then you have all the more or less hidden costs of keeping code around, especially if it's unmaintained : people will enable it (if it's even disabled by default), hit problems and look for support. And as a downstream OSS application developer, I'd really rather postproc be officially and properly dropped, so I can justify dropping it downstream as well. But at least, postproc doesn't engender extra traffic on this mailing list much at all. More or less nobody here can or wants to review or test your SDR code. I think, more so than ffmpeg.git being ill-suited a source code repository for SDR because it is so niche and loosely related, ffmpeg-devel is simply not suited for SDR. The skills are not here, the time and motivation are not here, not to speak of the good will. If the project grows and develops to become better accepted as a fit for FFmpeg, it can be merged (like btrfs.git got merged into Linux, with full git history). Honestly I think that probably will never happen, especially not after at least two distinct attempts to make it a fait accompli in spite of FFmpeg-devel. But I'm not a medium. In the end, cool but controversial new features being rejected due to poor community acceptance, and continuing their life elsewhere, is quite common and mundane. It happened to me more than once (not in FFmpeg, obviously). >libpostproc implements part of ISO/IEC 14496-2 >(that is the spec for an MPEG-4 ASP decoder) > >its content could be moved in libavfilter and or the mpeg4 decoder >(there are arguments to be made for either) >but it doesnt belong in a lib external to FFmpeg. >(and in the process some bits probably can be droped as they > no longer serve a purpose compared to other filters) > >I have too many other things to work on to do a big refactoring of it >but if there are small bugs in it or questions about it i can look into them > >thx > >[...] > ___ 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] [RFC] Anual Committee Report
tor 2023-09-28 klockan 16:19 +0200 skrev Michael Niedermayer: > Hi all > > I think the 2 commmittteees we have should produce an anual report > so that the developers who vote for members know the perfomance and > what the last comite did > like # of cases, # of times people where contacted, % where committi > intervention produced a noticable improvment ... > > # of cases where both parties where happy with the outcome, # of > cases > where one party only was happy, # of cases where neither party was > happy > > Of course in some years there may be nothing at all, which then would > be a rather simple report Sounds like a step in the right direction. As a Swede we have a strong voluntary association culture (föreningskultur) where most of this stuff is routine. You hold regular meetings, elect a board, define membership criteria, reasons for expulsion etc. /Tomas ___ 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/ffv1*: add more pixel formats support
Attached.
From 80e70d4cde1734b01809352d280f43a9d4ba79dc Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Thu, 28 Sep 2023 21:22:34 +0200
Subject: [PATCH] avcodec/ffv1*: add GBRAP14, GRAY14, YUVA422P12, YUVA444P12
formats support
Signed-off-by: Paul B Mahol
---
libavcodec/ffv1dec.c | 11 +++
libavcodec/ffv1enc.c | 9 +++--
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 54cf075b8f..cdf72a25dd 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -626,6 +626,9 @@ static int read_header(FFV1Context *f)
} else if (f->avctx->bits_per_raw_sample == 12) {
f->packed_at_lsb = 1;
f->avctx->pix_fmt = AV_PIX_FMT_GRAY12;
+} else if (f->avctx->bits_per_raw_sample == 14) {
+f->packed_at_lsb = 1;
+f->avctx->pix_fmt = AV_PIX_FMT_GRAY14;
} else if (f->avctx->bits_per_raw_sample == 16) {
f->packed_at_lsb = 1;
f->avctx->pix_fmt = AV_PIX_FMT_GRAY16;
@@ -690,6 +693,12 @@ static int read_header(FFV1Context *f)
case 0x10: f->avctx->pix_fmt = AV_PIX_FMT_YUV422P12; break;
case 0x11: f->avctx->pix_fmt = AV_PIX_FMT_YUV420P12; break;
}
+} else if (f->avctx->bits_per_raw_sample == 12 && f->transparency) {
+f->packed_at_lsb = 1;
+switch(16 * f->chroma_h_shift + f->chroma_v_shift) {
+case 0x00: f->avctx->pix_fmt = AV_PIX_FMT_YUVA444P12; break;
+case 0x10: f->avctx->pix_fmt = AV_PIX_FMT_YUVA422P12; break;
+}
} else if (f->avctx->bits_per_raw_sample == 14 && !f->transparency) {
f->packed_at_lsb = 1;
switch(16 * f->chroma_h_shift + f->chroma_v_shift) {
@@ -734,6 +743,8 @@ static int read_header(FFV1Context *f)
f->avctx->pix_fmt = AV_PIX_FMT_GBRAP12;
else if (f->avctx->bits_per_raw_sample == 14 && !f->transparency)
f->avctx->pix_fmt = AV_PIX_FMT_GBRP14;
+else if (f->avctx->bits_per_raw_sample == 14 && f->transparency)
+f->avctx->pix_fmt = AV_PIX_FMT_GBRAP14;
else if (f->avctx->bits_per_raw_sample == 16 && !f->transparency) {
f->avctx->pix_fmt = AV_PIX_FMT_GBRP16;
f->use32bit = 1;
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 746f717568..2778c63012 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -585,8 +585,11 @@ static av_cold int encode_init(AVCodecContext *avctx)
case AV_PIX_FMT_YUV440P12:
case AV_PIX_FMT_YUV420P12:
case AV_PIX_FMT_YUV422P12:
+case AV_PIX_FMT_YUVA444P12:
+case AV_PIX_FMT_YUVA422P12:
if (!avctx->bits_per_raw_sample && !s->bits_per_raw_sample)
s->bits_per_raw_sample = 12;
+case AV_PIX_FMT_GRAY14:
case AV_PIX_FMT_YUV444P14:
case AV_PIX_FMT_YUV420P14:
case AV_PIX_FMT_YUV422P14:
@@ -667,6 +670,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
if (!avctx->bits_per_raw_sample && !s->bits_per_raw_sample)
s->bits_per_raw_sample = 12;
case AV_PIX_FMT_GBRP14:
+case AV_PIX_FMT_GBRAP14:
if (!avctx->bits_per_raw_sample && !s->bits_per_raw_sample)
s->bits_per_raw_sample = 14;
case AV_PIX_FMT_GBRP16:
@@ -1284,13 +1288,14 @@ const FFCodec ff_ffv1_encoder = {
AV_PIX_FMT_YUV420P9, AV_PIX_FMT_YUV420P10, AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV444P10,
AV_PIX_FMT_YUV420P12, AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV444P12,
AV_PIX_FMT_YUVA444P16, AV_PIX_FMT_YUVA422P16, AV_PIX_FMT_YUVA420P16,
+AV_PIX_FMT_YUVA444P12, AV_PIX_FMT_YUVA422P12,
AV_PIX_FMT_YUVA444P10, AV_PIX_FMT_YUVA422P10, AV_PIX_FMT_YUVA420P10,
AV_PIX_FMT_YUVA444P9, AV_PIX_FMT_YUVA422P9, AV_PIX_FMT_YUVA420P9,
AV_PIX_FMT_GRAY16,AV_PIX_FMT_GRAY8, AV_PIX_FMT_GBRP9, AV_PIX_FMT_GBRP10,
-AV_PIX_FMT_GBRP12,AV_PIX_FMT_GBRP14,
+AV_PIX_FMT_GBRP12,AV_PIX_FMT_GBRP14, AV_PIX_FMT_GBRAP14,
AV_PIX_FMT_GBRAP10, AV_PIX_FMT_GBRAP12,
AV_PIX_FMT_YA8,
-AV_PIX_FMT_GRAY10, AV_PIX_FMT_GRAY12,
+AV_PIX_FMT_GRAY10, AV_PIX_FMT_GRAY12, AV_PIX_FMT_GRAY14,
AV_PIX_FMT_GBRP16, AV_PIX_FMT_RGB48,
AV_PIX_FMT_GBRAP16, AV_PIX_FMT_RGBA64,
AV_PIX_FMT_GRAY9,
--
2.42.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] SDR lib comments
On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-09-23 18:43:44) > > Is a seperate library really the right choice for SDR in FFmpeg at this > > stage ? > > > > Also code can always be moved into an seperate library > > we've had postproc in the tree for ages, nobody maintains it or > cares about it, yet it seems impossible to get rid of it. what maintaince does it need ? i mean i know the code is ugly but what _needs_ to be changed? libpostproc implements part of ISO/IEC 14496-2 (that is the spec for an MPEG-4 ASP decoder) its content could be moved in libavfilter and or the mpeg4 decoder (there are arguments to be made for either) but it doesnt belong in a lib external to FFmpeg. (and in the process some bits probably can be droped as they no longer serve a purpose compared to other filters) I have too many other things to work on to do a big refactoring of it but if there are small bugs in it or questions about it i can look into them thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data 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/3] lavc/h274: fix PRNG definition
On Thu, 28 Sep 2023 12:03:08 -0400 Vittorio Giovara wrote: > On Thu, Sep 28, 2023 at 11:08 AM Niklas Haas wrote: > > > On Wed, 27 Sep 2023 21:07:55 +0200 Michael Niedermayer < > > mich...@niedermayer.cc> wrote: > > > where can i find the text describing this that you refer to ? > > > > It is in SMPTE RDD 5 (DOI 10.5594/SMPTE.RDD5.2006), you can find it on > > the usual places. > > > > Could it maybe be mentioned in the commit log? Or documented in a comment > (not familiar with the file, apologies if it's already so) Hi, it is mentioned in the commit message attached to the initial implementation of this file, and also linked multiple times throughout the source code. ___ 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/3] lavc/h274: fix PRNG definition
On Thu, 28 Sep 2023 20:53:44 +0200 Michael Niedermayer
wrote:
> On Wed, Sep 27, 2023 at 03:56:15PM +0200, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > The spec specifies x^31 + x^3 + 1 as the polynomial, but the diagram in
> > Figure 1-1 omits the +1 offset. The initial implementation was based on
> > the diagram, but this is wrong (produces subtly incorrect results).
>
> the +1 changes "nothing"
> if you take the prng with and without the +1 the 2 will produce 2
> sequences that are negations of each other
>
> or said different if you start one from 1 and the other from ~1
> they will produce the same sequence just 0 and 1 swaped
>
> you can also compute 32 bits at once using this:
> (this needs 64bits of the sequence as input though)
> not sure how useful it is, but it produces more bits quicker
>
> static void prng_shift32(uint64_t *state)
> {
> uint64_t x = *state;
> uint64_t y = x ^ x>>3;
> y ^= y>>6;
> y ^= y>>12;
> uint32_t feedback = (x >> 1) ^ (y >> 5) ^ (x >> 29) ^ (x >> 30);
> *state = (x << 32) | feedback;
> }
Thanks for the explanation and tip.
In this case, PRNG output is by far not the bottleneck (we only need one
32-bit random value per 16x16 block), so I don't think it needs to be
modified further.
___
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/3] lavc/h274: fix PRNG definition
On Wed, Sep 27, 2023 at 03:56:15PM +0200, Niklas Haas wrote:
> From: Niklas Haas
>
> The spec specifies x^31 + x^3 + 1 as the polynomial, but the diagram in
> Figure 1-1 omits the +1 offset. The initial implementation was based on
> the diagram, but this is wrong (produces subtly incorrect results).
the +1 changes "nothing"
if you take the prng with and without the +1 the 2 will produce 2
sequences that are negations of each other
or said different if you start one from 1 and the other from ~1
they will produce the same sequence just 0 and 1 swaped
you can also compute 32 bits at once using this:
(this needs 64bits of the sequence as input though)
not sure how useful it is, but it produces more bits quicker
static void prng_shift32(uint64_t *state)
{
uint64_t x = *state;
uint64_t y = x ^ x>>3;
y ^= y>>6;
y ^= y>>12;
uint32_t feedback = (x >> 1) ^ (y >> 5) ^ (x >> 29) ^ (x >> 30);
*state = (x << 32) | feedback;
}
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
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] [RFC] Anual Committee Report
Le torstaina 28. syyskuuta 2023, 17.19.18 EEST Michael Niedermayer a écrit : > Hi all > > I think the 2 commmittteees we have should produce an anual report > so that the developers who vote for members know the perfomance and > what the last comite did > like # of cases, # of times people where contacted, % where committi > intervention produced a noticable improvment ... The commitees should post the result of their deliberations. This seems evident for the TC. But the CC should also do it to avoid seeming like they are not acting, that the CoC is only for show. And based on negative experience in other projects, I would also emphasise that the CC also needs to avoid making public statements about some cases or people and not others as well. That being said, I don't think annual reports are necessary or even useful on top of per-case summaries. The number of cases _should_ be low enough that year-on-year statistics should not be very meaningful. Also that seems like useless paperwork added on top of what is already free and not particularly fun community service. -- Rémi Denis-Courmont http://www.remlab.net/ ___ 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] [RFC] Release 6.1
Le torstaina 28. syyskuuta 2023, 19.43.57 EEST Nicolas George a écrit : > Rémi Denis-Courmont (12023-09-28): > > Calling BBB, Kieran and myself dishonest is. > > I call your arguments dishonest. You almost had me doubting my recollection for a minute. But: Michael wrote: > > People did not ask that to be put in a seperate general purpose fractal > > library. > > With SDR they do ask for a seperate library. And you then wrote: > And they are being dishonest in that Arguments cannot "ask for separate library". "They" were explicitly "people", specifically people asking for a separate library. Later on: > Nobody honest would seriously try to argue the opposite. [after I had indeed argued the opposite] Feel free to call me captain obvious: "nobody" is a negative pronoun for people, not for abstract concepts such as arguments, for which the pronoun would be "nothing". But hey, I shall not reproduce Paul's mistake that got him admonished by JB. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ 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/2] libavutil/hwcontect_cuda: add option to use current CUDA context
On 14.09.2023 18:52, Roman Arzumanyan wrote: Got it, thanks. Please find the patches in attachment. Just for my own understanding - could you please explain how this magic works in the configure script? I mean this section: if ! disabled ffnvcodec; then ffnv_hdr_list="ffnvcodec/nvEncodeAPI.h ffnvcodec/dynlink_cuda.h ffnvcodec/dynlink_cuviddec.h ffnvcodec/dynlink_nvcuvid.h" check_pkg_config ffnvcodec "ffnvcodec >= 12.1.14.0" "$ffnv_hdr_list" "" || \ check_pkg_config ffnvcodec "ffnvcodec >= 12.0.16.0 ffnvcodec < 12.1" "$ffnv_hdr_list" "" || \ check_pkg_config ffnvcodec "ffnvcodec >= 11.1.5.2 ffnvcodec < 12.0" "$ffnv_hdr_list" "" || \ check_pkg_config ffnvcodec "ffnvcodec >= 11.0.10.2 ffnvcodec < 11.1" "$ffnv_hdr_list" "" || \ check_pkg_config ffnvcodec "ffnvcodec >= 8.1.24.14 ffnvcodec < 8.2" "$ffnv_hdr_list" "" fi Applied with various amendments: - Added missing version bump. - Added missing APIchanges entry. - Made the "both options are set"-check actually check both options, and not the same one twice. - Dropped "if != 0" checks, FFmpeg generally just does "if (variable)" in those cases. - Updated version checks in configure. ___ 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] [RFC] Anual Committee Report
Hi, I think the 2 commmittteees we have should produce an anual report so that the developers who vote for members know the perfomance and what the last comite did like # of cases, # of times people where contacted, % where committi intervention produced a noticable improvment ... not sure about performance but reports should be done, +1. # of cases where both parties where happy with the outcome, # of cases where one party only was happy, # of cases where neither party was happy Of course in some years there may be nothing at all, which then would be a rather simple report thx PS: no i dont remember how to spell committee, if i got one corrrect that is unintentional. -Thilo ___ 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] [RFC] Release 6.1
Rémi Denis-Courmont (12023-09-28): > Calling BBB, Kieran and myself dishonest is. I call your arguments dishonest. > I take that as an admission of guilt. Take it as you want. -- Nicolas George 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] [RFC] Release 6.1
Rémi Denis-Courmont (12023-09-28): > And this puts me in a bit of a conundrum. See, if you did figure that much > out, > then you would be willfully committing defamation against me, by calling me > dishonest. I am calling your argument dishonest. I stand by it. >I suppose that I am going to have to assume that you are somehow ^^^ > temporarily incapacitated. Now, *this* is an ad-hominem argument indeed. -- Nicolas George 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] [RFC] Release 6.1
Le torstaina 28. syyskuuta 2023, 19.41.06 EEST Nicolas George a écrit : > (1) There was no violations in my message. Calling your arguments > bullshit is not a personal attack, by definition. Calling BBB, Kieran and myself dishonest is. > (2) Even if there were any violation, there is nobody to report it to > anyway. I take that as an admission of guilt. -- レミ・デニ-クールモン http://www.remlab.net/ ___ 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] [RFC] Release 6.1
Rémi Denis-Courmont (12023-09-28): > Literally the exact same verb even. So what are you saying, that I noticed you moved the goalposts one message too late? > P.S.: Your repeated CoC violations will be reported shortly. So, for your information: (1) There was no violations in my message. Calling your arguments bullshit is not a personal attack, by definition. (2) Even if there were any violation, there is nobody to report it to anyway. -- Nicolas George 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] [RFC] Release 6.1
Le torstaina 28. syyskuuta 2023, 19.32.44 EEST Nicolas George a écrit : > Rémi Denis-Courmont (12023-09-28): > > Err, it is very much an issue w.r.t. "catching on". > > Moving the goalpost much. I think obviously not, considering the original quote (EMPHASIS ADDED): > In fact, the SDR code has quite a number of impediments that all but > guarantee that IT WILL NOT CATCH ON in FFmpeg: > - it requires niche hardware, > - it only works on some limited set of OSes (if not only Linux), Literally the exact same verb even. P.S.: Your repeated CoC violations will be reported shortly. -- レミ・デニ-クールモン http://www.remlab.net/ ___ 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] [RFC] Release 6.1
On 9/28/23, Nicolas George wrote: > Rémi Denis-Courmont (12023-09-28): >> Err, it is very much an issue w.r.t. "catching on". > > Moving the goalpost much. > >> Also that's an ad hominem attack, which violates the CC. > > No it is not. > > This mail is no longer part of a honest discussion, and therefore I will > save myself the time of answering it in details. > > Stop moving the goalposts, stop wasting everybody's time by turning > arguments on their head and emptying them of their value at the same > time. > > You can sate what you want about SDR and why you want it, that might > make the discussion progress. Or you can continue wasting your time with > bullshit arguments. This is again against the CC. > > -- > Nico > ___ 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] [RFC] Release 6.1
Le torstaina 28. syyskuuta 2023, 19.13.37 EEST Nicolas George a écrit : > Rémi Denis-Courmont (12023-09-28): > > Thanks for making my point. > > Stealing the other person rhetoric device does not make you right. > > > That does not change the fact that it won't make it any popular, and thus > > your postulate is wrong. > > It reach more popular included in FFmpeg than if users have to download > it separately. If this were a feature that would be somehow automatically enabled or highly visible, that would make sense. But not only is it no such thing, it requires special hardware. With that noted, for any reasonable understanding of "popularity", it would be less popular. That is the point. People who want to do SDR will be burdened with the other 99% of FFmpeg that they don't need for SDR. And that's if they find out that FFmpeg can actually do SDR - but in all likelihood, they wouldn't, because of the brand recognition of FFmpeg. Instead, they'd end up with some SDR-specific projects. That's why, if Michael does not want to join an existing SDR project, he is much better off making a new one, than bundling in FFmpeg. > Nobody honest would seriously try to argue the opposite. I believe that you have high IQ, and good English skill, enough that you should be able to more or less figure out what was noted above and up-thread. And this puts me in a bit of a conundrum. See, if you did figure that much out, then you would be willfully committing defamation against me, by calling me dishonest. I suppose that I am going to have to assume that you are somehow temporarily incapacitated. -- Rémi Denis-Courmont http://www.remlab.net/ ___ 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] [RFC] Release 6.1
Rémi Denis-Courmont (12023-09-28): > Err, it is very much an issue w.r.t. "catching on". Moving the goalpost much. > Also that's an ad hominem attack, which violates the CC. No it is not. This mail is no longer part of a honest discussion, and therefore I will save myself the time of answering it in details. Stop moving the goalposts, stop wasting everybody's time by turning arguments on their head and emptying them of their value at the same time. You can sate what you want about SDR and why you want it, that might make the discussion progress. Or you can continue wasting your time with bullshit arguments. -- Nico 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] [RFC] Release 6.1
Le torstaina 28. syyskuuta 2023, 18.28.50 EEST Nicolas George a écrit : > Rémi Denis-Courmont (12023-09-28): > > You can repeat the contrary as much as you want, we do not believe that > > your SDR code fits in FFmpeg. Why do you not understand this? > > We understand that very well. Once again, it is you who do not > understand something: your BELIEF that SDR does not belong in ffmpeg is > nothing more than that, a belief, an opinion, and it weighs nothing in > front of the argument that some users want it. "We understand that very well. Once again, it is you who do not understand something: your BELIEF tha SDR does beling in FFmpeg is nothing more than that, a belief, an opinion, and it weighs" very little in the face of repeated technical arguments by several members of the development community as well as common sense. > it weighs nothing in front of the argument that some users want it. Literally ABSOLUTELY ZERO *users* said that they wanted it, except for Michael himself. Other people (including you) did say that they wanted it, yes, but none of them were users or even potential users of SDR. Some even explicitly said that (although it sounded cool) they would not use it. So you fail at logical argumentation again. > > Like no, seriously. If you really want to generic support for AM and FM RX > > in FFmpeg, then you should use implement frontends for the already > > *existing* HAL (that would be V4L radio and ALSA on Linux), or perhaps, > > write a new user- space HAL library that would accomodate both hardware > > radio RX devices and SDR. > > Did you miss the part where he explained he was not interesting in doing > it like that? He said that he did not want to join an existing SDR project. That's completely orthogonal. And in any case, this is one of several technical argument. You cannot "disprove" it with the subjective opinions and authority fallacies. > > In fact, the SDR code has quite a number of impediments that all but > > guarantee that it will not "catch on" in FFmpeg: > > - it requires niche hardware, > > Like a few components of libavdevice, that is not an issue. Err, it is very much an issue w.r.t. "catching on". You even left the original quote up there. This makes your highly intellectually dishonest attempt at distorting my statements all the more blatant. > > - it only works on some limited set of OSes (if not only Linux), > > Like a few components of libavdevice, that is not an issue. Same thing. > > - it will be subject to all the FFmpeg processes and drama, > > This problem does not come from SDR, it comes from you. I was not the one to start this drama (on either side of the argument), and there have been plenty more people on my side than yours. I am indeed part of the problem in a sense. Though if I follow that logic, you are a proportionally bigger part of the problem, FWIW. Now you could argue that my argument si a self-realising prophecy. But regardless of who is to blame, my argument holds: the drame will continue (with or without me, by the way) unless Michael compromises and takes SDR out of FFmpeg.git and FFmpeg-devel. > > - it will be obscured by FFmpeg's existing own fame, remaining an obscure > > feature set that hardly anybody outside FFmpeg-devel knows about. > > Like a lot of features. Probably indeed like a lot of features, who failed to catch on and will continue to fail to catch on. My point exactly! > Scrapping the bottom of drawers for arguments are you? I think that I made it clear that this was about how/why SDR will not be *popular* inside FFmpeg. Maybe those are bottom of the drawer arguments against SDR in FFmpeg. That does not exactly matter in this context, since that is not what they were about. Also that's an ad hominem attack, which violates the CC. -- Rémi Denis-Courmont http://www.remlab.net/ ___ 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] [RFC] Release 6.1
Rémi Denis-Courmont (12023-09-28): > Thanks for making my point. Stealing the other person rhetoric device does not make you right. > That does not change the fact that it won't make it any popular, and thus > your > postulate is wrong. It reach more popular included in FFmpeg than if users have to download it separately. Nobody honest would seriously try to argue the opposite. > It should be blatantly obvious to anybody with a modicum of modesty that "fit > nicely together" is intrinsically a very subjective value judgement, not a > technical argument in favor or disfavor of anything. What you are describing here is your “does not belong”. “Fit nicely together” means it allows to do things that were not possible previously or required more work and were more fragile (pipelines and shell scripts). It is a technical argument. -- Nicolas George 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/3] lavc/h274: fix PRNG definition
On Thu, Sep 28, 2023 at 11:08 AM Niklas Haas wrote: > On Wed, 27 Sep 2023 21:07:55 +0200 Michael Niedermayer < > mich...@niedermayer.cc> wrote: > > where can i find the text describing this that you refer to ? > > It is in SMPTE RDD 5 (DOI 10.5594/SMPTE.RDD5.2006), you can find it on > the usual places. > Could it maybe be mentioned in the commit log? Or documented in a comment (not familiar with the file, apologies if it's already so) -- 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".
Re: [FFmpeg-devel] [RFC] Release 6.1
Le torstaina 28. syyskuuta 2023, 18.33.33 EEST Nicolas George a écrit : > Rémi Denis-Courmont (12023-09-28): > > Strange, I thought FFmpeg really became popular as a back-end library for > > mplayer, before it was picked up by all other OSS multimedia at the time > > (gstreamer, VLC, Xine, etc.). > > Fortunately, I know the history of our projects better than you: > > First, FFmpeg was already a feature-rich self-contained program when > MPlayer started using it. Just being feature-rich does not make it popular. I never said anything about being or not being feature-rich at that point in time. But congratulations on disproving a point that nobody made anyway. > Second, MPlayer did not start using it FFmpeg as a library, it started — > and still does in part — using it as embedded code. Sure and that is in fact one way to use a software library. There is even a name for that practice nowadays: vendoring. Thanks for making my point. > Too bad your attempt at disproving my point just proves it. Just providing some historical facts (that I don't challenge) does not disprove my point. You pretty much confirmed my point actually. And besides, one example (FFmpeg) does not prove a general rule, such as you up-thread postulate that started-as-library software is never popular. Indeed, anybody who knows open-source in general knows that there are plenty of libraries that are popular. In fact, there are far more popular libraries than popular applications in terms of user base, and often in terms of development activity and community strength. (And I don't count libraries with reference command line tools as applications, otherwise everything is an application and your implied dichotomy would not make sense to begin with.) > > Force-feeding the SDR code to all FFmpeg packagers is not going to make it > > popular. Most of them will just disable it, especially if it brings new > > dependencies and/or doesn't work on the popular proprietary platforms. > > So, they can “just disable it” and ignore it. That does not change the fact that it won't make it any popular, and thus your postulate is wrong. > They have no ground to oppose, and neither do you. I neither needed nor sought new ground here. I just disprove your postulate, not that I expect you to be able to grasp the possibility of such occurrence, in light of your past and present show of self-assurance (to put it politely). > > FWIW, Fabrice Bellard didn't bundle all his initially hobby projects > > together. Several of them became popular. > > He bundled together the things that fit nicely together. > Once again an argument in favor of SDR integration. It should be blatantly obvious to anybody with a modicum of modesty that "fit nicely together" is intrinsically a very subjective value judgement, not a technical argument in favor or disfavor of anything. -- レミ・デニ-クールモン http://www.remlab.net/ ___ 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 04/42] avcodec/h264_ps: Use RefStruct API for SPS/PPS
Anton Khirnov:
> Quoting Andreas Rheinhardt (2023-09-19 21:56:56)
>> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
>> index 5657327f0c..632f5b23b2 100644
>> --- a/libavcodec/h264_slice.c
>> +++ b/libavcodec/h264_slice.c
>> @@ -363,25 +361,16 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
>>
>> // SPS/PPS
>> for (i = 0; i < FF_ARRAY_ELEMS(h->ps.sps_list); i++) {
>> -ret = av_buffer_replace(>ps.sps_list[i], h1->ps.sps_list[i]);
>> -if (ret < 0)
>> -return ret;
>> +ff_refstruct_replace(>ps.sps_list[i], h1->ps.sps_list[i]);
>> }
>> for (i = 0; i < FF_ARRAY_ELEMS(h->ps.pps_list); i++) {
>> -ret = av_buffer_replace(>ps.pps_list[i], h1->ps.pps_list[i]);
>> -if (ret < 0)
>> -return ret;
>> +ff_refstruct_replace(>ps.pps_list[i], h1->ps.pps_list[i]);
>> }
>>
>> -ret = av_buffer_replace(>ps.pps_ref, h1->ps.pps_ref);
>> -if (ret < 0)
>> -return ret;
>> -h->ps.pps = NULL;
>> +ff_refstruct_replace(>ps.pps, h1->ps.pps);
>> h->ps.sps = NULL;
>> -if (h1->ps.pps_ref) {
>> -h->ps.pps = (const PPS*)h->ps.pps_ref->data;
>> +if (h1->ps.pps)
>> h->ps.sps = h->ps.pps->sps;
>
> nit: this would look better as
>h->ps.sps = h->ps.pps ? h->ps.pps->sps : NULL
>
Is there actually a reason not to just use h->ps.sps = h1->ps.sps?
- 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".
Re: [FFmpeg-devel] [RFC] Release 6.1
Rémi Denis-Courmont (12023-09-28): > Strange, I thought FFmpeg really became popular as a back-end library for > mplayer, before it was picked up by all other OSS multimedia at the time > (gstreamer, VLC, Xine, etc.). Fortunately, I know the history of our projects better than you: First, FFmpeg was already a feature-rich self-contained program when MPlayer started using it. Second, MPlayer did not start using it FFmpeg as a library, it started — and still does in part — using it as embedded code. Too bad your attempt at disproving my point just proves it. > Force-feeding the SDR code to all FFmpeg packagers is not going to make it > popular. Most of them will just disable it, especially if it brings new > dependencies and/or doesn't work on the popular proprietary platforms. So, they can “just disable it” and ignore it. They have no ground to oppose, and neither do you. > FWIW, Fabrice Bellard didn't bundle all his initially hobby projects > together. > Several of them became popular. He bundled together the things that fit nicely together. Once again an argument in favor of SDR integration. -- Nicolas George 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] [RFC] Release 6.1
Rémi Denis-Courmont (12023-09-28): > You can repeat the contrary as much as you want, we do not believe that your > SDR code fits in FFmpeg. Why do you not understand this? We understand that very well. Once again, it is you who do not understand something: your BELIEF that SDR does not belong in ffmpeg is nothing more than that, a belief, an opinion, and it weighs nothing in front of the argument that some users want it. > Like no, seriously. If you really want to generic support for AM and FM RX in > FFmpeg, then you should use implement frontends for the already *existing* > HAL > (that would be V4L radio and ALSA on Linux), or perhaps, write a new user- > space HAL library that would accomodate both hardware radio RX devices and > SDR. Did you miss the part where he explained he was not interesting in doing it like that? > In fact, the SDR code has quite a number of impediments that all but > guarantee > that it will not "catch on" in FFmpeg: > - it requires niche hardware, Like a few components of libavdevice, that is not an issue. > - it only works on some limited set of OSes (if not only Linux), Like a few components of libavdevice, that is not an issue. > - it will be subject to all the FFmpeg processes and drama, This problem does not come from SDR, it comes from you. > - it will be obscured by FFmpeg's existing own fame, remaining an obscure > feature set that hardly anybody outside FFmpeg-devel knows about. Like a lot of features. Scrapping the bottom of drawers for arguments are you? -- Nicolas George 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] [RFC] Anual Committee Report
Michael Niedermayer (12023-09-28): > I think the 2 commmittteees we have We do not have two committees, their mandate expired more than a year ago. Regards, -- Nicolas George 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 v2 1/3] avcodec/fflcms2: add ff_icc_profile_sanitize
From: Niklas Haas
Buggy ICCv4 profiles are unfortunately used in the wild, and it's quite
easy to work around them by just forcing the white point to the correct
value. Display a warning just in case.
See-Also: https://trac.ffmpeg.org/ticket/9673
---
libavcodec/fflcms2.c | 51
libavcodec/fflcms2.h | 7 ++
2 files changed, 58 insertions(+)
diff --git a/libavcodec/fflcms2.c b/libavcodec/fflcms2.c
index 5443f178bc9..3b67e62d3af 100644
--- a/libavcodec/fflcms2.c
+++ b/libavcodec/fflcms2.c
@@ -201,6 +201,57 @@ static av_always_inline void XYZ_xy(cmsCIEXYZ XYZ, AVCIExy
*xy)
xy->y = av_d2q(k * XYZ.Y, 10);
}
+static av_always_inline AVRational abs_sub_q(AVRational r1, AVRational r2)
+{
+AVRational diff = av_sub_q(r1, r2);
+/* denominator assumed to be positive */
+return av_make_q(abs(diff.num), diff.den);
+}
+
+static const AVCIExy wp_d50 = { {3457, 1}, {3585, 1} }; /* CIE D50 */
+
+int ff_icc_profile_sanitize(FFIccContext *s, cmsHPROFILE profile)
+{
+cmsCIEXYZ *white, fixed;
+AVCIExy wpxy;
+AVRational diff, z;
+if (!profile)
+return 0;
+
+if (cmsGetEncodedICCversion(profile) >= 0x400) { // ICC v4
+switch (cmsGetHeaderRenderingIntent(profile)) {
+case INTENT_RELATIVE_COLORIMETRIC:
+case INTENT_ABSOLUTE_COLORIMETRIC: ;
+/* ICC v4 colorimetric profiles are specified to always use D50
+ * media white point, anything else is a violation of the spec.
+ * Sadly, such profiles are incredibly common (Apple...), so make
+ * an effort to fix them. */
+if (!(white = cmsReadTag(profile, cmsSigMediaWhitePointTag)))
+return AVERROR_INVALIDDATA;
+XYZ_xy(*white, );
+diff = av_add_q(abs_sub_q(wpxy.x, wp_d50.x), abs_sub_q(wpxy.y,
wp_d50.y));
+if (av_cmp_q(diff, av_make_q(1, 1000)) > 0) {
+av_log(s->avctx, AV_LOG_WARNING, "Invalid colorimetric ICCv4 "
+ "profile media white point tag (expected %.4f %.4f, "
+ "got %.4f %.4f)\n",
+ av_q2d(wp_d50.x), av_q2d(wp_d50.y),
+ av_q2d(wpxy.x), av_q2d(wpxy.y));
+/* x+y+z = 1 */
+z = av_sub_q(av_sub_q(av_make_q(1, 1), wp_d50.x), wp_d50.y);
+fixed.X = av_q2d(av_div_q(wp_d50.x, wp_d50.y)) * white->Y;
+fixed.Y = white->Y;
+fixed.Z = av_q2d(av_div_q(z, wp_d50.y)) * white->Y;
+if (!cmsWriteTag(profile, cmsSigMediaWhitePointTag, ))
+return AVERROR_EXTERNAL;
+}
+break;
+default: break;
+}
+}
+
+return 0;
+}
+
int ff_icc_profile_read_primaries(FFIccContext *s, cmsHPROFILE profile,
AVColorPrimariesDesc *out_primaries)
{
diff --git a/libavcodec/fflcms2.h b/libavcodec/fflcms2.h
index af63c9a13c8..b54173e50e2 100644
--- a/libavcodec/fflcms2.h
+++ b/libavcodec/fflcms2.h
@@ -65,6 +65,13 @@ int ff_icc_profile_generate(FFIccContext *s,
*/
int ff_icc_profile_attach(FFIccContext *s, cmsHPROFILE profile, AVFrame
*frame);
+/**
+ * Sanitize an ICC profile to try and fix badly broken values.
+ *
+ * Returns 0 on success, or a negative error code.
+ */
+int ff_icc_profile_sanitize(FFIccContext *s, cmsHPROFILE profile);
+
/**
* Read the color primaries and white point coefficients encoded by an ICC
* profile, and return the raw values in `out_primaries`.
--
2.42.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 v2 3/3] avcodec/decode: use ff_icc_profile_sanitize
From: Niklas Haas Fixes: https://trac.ffmpeg.org/ticket/9673 --- libavcodec/decode.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libavcodec/decode.c b/libavcodec/decode.c index 466c393c1e2..6f4ef7da0c2 100644 --- a/libavcodec/decode.c +++ b/libavcodec/decode.c @@ -536,7 +536,9 @@ static int detect_colorspace(AVCodecContext *avctx, AVFrame *frame) if (!profile) return AVERROR_INVALIDDATA; -ret = ff_icc_profile_read_primaries(>icc, profile, ); +ret = ff_icc_profile_sanitize(>icc, profile); +if (!ret) +ret = ff_icc_profile_read_primaries(>icc, profile, ); if (!ret) ret = ff_icc_profile_detect_transfer(>icc, profile, ); cmsCloseProfile(profile); -- 2.42.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 v2 2/3] avfilter/vf_iccdetect: use ff_icc_profile_sanitize
From: Niklas Haas --- libavfilter/vf_iccdetect.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libavfilter/vf_iccdetect.c b/libavfilter/vf_iccdetect.c index 5288b0320d2..16eacbbb560 100644 --- a/libavfilter/vf_iccdetect.c +++ b/libavfilter/vf_iccdetect.c @@ -93,7 +93,9 @@ static int iccdetect_filter_frame(AVFilterLink *inlink, AVFrame *frame) if (!profile) return AVERROR_INVALIDDATA; -ret = ff_icc_profile_read_primaries(>icc, profile, ); +ret = ff_icc_profile_sanitize(>icc, profile); +if (!ret) +ret = ff_icc_profile_read_primaries(>icc, profile, ); if (!ret) ret = ff_icc_profile_detect_transfer(>icc, profile, >profile_trc); cmsCloseProfile(profile); -- 2.42.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 1/3] lavc/h274: fix PRNG definition
On Wed, 27 Sep 2023 21:07:55 +0200 Michael Niedermayer wrote: > where can i find the text describing this that you refer to ? It is in SMPTE RDD 5 (DOI 10.5594/SMPTE.RDD5.2006), you can find it on the usual places. ___ 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/audiodsp: unroll RISC-V clip functions
audiodsp.vector_clip_int32_c: 17500.7 audiodsp.vector_clip_int32_rvv_i32: 8404.7 (m1) audiodsp.vector_clip_int32_rvv_i32: 2689.9 (m8) audiodsp.vector_clipf_c: 33679.7 audiodsp.vector_clipf_rvf: 7019.7 audiodsp.vector_clipf_rvv_f32: 8328.0 (m1) audiodsp.vector_clipf_rvv_f32: 2209.4 (m8) --- libavcodec/riscv/audiodsp_rvv.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/riscv/audiodsp_rvv.S b/libavcodec/riscv/audiodsp_rvv.S index f7eba2114f..f0b23bab5e 100644 --- a/libavcodec/riscv/audiodsp_rvv.S +++ b/libavcodec/riscv/audiodsp_rvv.S @@ -42,7 +42,7 @@ endfunc func ff_vector_clip_int32_rvv, zve32x 1: -vsetvli t0, a4, e32, m1, ta, ma +vsetvli t0, a4, e32, m8, ta, ma vle32.v v8, (a1) sub a4, a4, t0 vmax.vx v8, v8, a2 @@ -59,7 +59,7 @@ func ff_vector_clipf_rvv, zve32f NOHWF fmv.w.x fa0, a3 NOHWF fmv.w.x fa1, a4 1: -vsetvli t0, a2, e32, m1, ta, ma +vsetvli t0, a2, e32, m8, ta, ma vle32.v v8, (a1) sub a2, a2, t0 vfmax.vf v8, v8, fa0 -- 2.40.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] [RFC] Release 6.1
Le keskiviikkona 27. syyskuuta 2023, 23.27.40 EEST Nicolas George a écrit : > Michael Niedermayer (12023-09-27): > > With SDR they do ask for a seperate library. > > And they are being dishonest in that. Nothing successful starts as a > library, Strange, I thought FFmpeg really became popular as a back-end library for mplayer, before it was picked up by all other OSS multimedia at the time (gstreamer, VLC, Xine, etc.). Force-feeding the SDR code to all FFmpeg packagers is not going to make it popular. Most of them will just disable it, especially if it brings new dependencies and/or doesn't work on the popular proprietary platforms. FWIW, Fabrice Bellard didn't bundle all his initially hobby projects together. Several of them became popular. > Demanding you make a separate library and a separate project is a > hypocritical ploy to have you spend your time on boring things like > build system and packaging, so that you lose interest in SDR and go back > to doing useful things for them, like fixing fuzzing bugs and > backporting the fixes. To the contrary, I would much rather Michael uses his free time on his hobbies, including SDR-outside-FFmpeg. He can stick to spending his "time on boring things" if/when he gets paid. That will add incentives for big tech corps to actually fund FFmpeg. This community, and presumably Michael in particular, are way too good at doing those "boring things" for free. -- Rémi Denis-Courmont http://www.remlab.net/ ___ 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 10/20] avcodec/snow: Move initializing QpelDSPContext to snowenc.c
Andreas Rheinhardt:
> Only used by the encoder.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/snow.c| 25 -
> libavcodec/snowenc.c | 26 ++
> 2 files changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/libavcodec/snow.c b/libavcodec/snow.c
> index cde09902c3..c9bc4dbab9 100644
> --- a/libavcodec/snow.c
> +++ b/libavcodec/snow.c
> @@ -438,31 +438,6 @@ av_cold int ff_snow_common_init(AVCodecContext *avctx){
> ff_dwt_init(>dwt);
> ff_h264qpel_init(>h264qpel, 8);
>
> -#define mcf(dx,dy)\
> -s->qdsp.put_qpel_pixels_tab [0][dy+dx/4]=\
> -s->qdsp.put_no_rnd_qpel_pixels_tab[0][dy+dx/4]=\
> -s->h264qpel.put_h264_qpel_pixels_tab[0][dy+dx/4];\
> -s->qdsp.put_qpel_pixels_tab [1][dy+dx/4]=\
> -s->qdsp.put_no_rnd_qpel_pixels_tab[1][dy+dx/4]=\
> -s->h264qpel.put_h264_qpel_pixels_tab[1][dy+dx/4];
> -
> -mcf( 0, 0)
> -mcf( 4, 0)
> -mcf( 8, 0)
> -mcf(12, 0)
> -mcf( 0, 4)
> -mcf( 4, 4)
> -mcf( 8, 4)
> -mcf(12, 4)
> -mcf( 0, 8)
> -mcf( 4, 8)
> -mcf( 8, 8)
> -mcf(12, 8)
> -mcf( 0,12)
> -mcf( 4,12)
> -mcf( 8,12)
> -mcf(12,12)
> -
> #define mcfh(dx,dy)\
> s->hdsp.put_pixels_tab [0][dy/4+dx/8]=\
> s->hdsp.put_no_rnd_pixels_tab[0][dy/4+dx/8]=\
> diff --git a/libavcodec/snowenc.c b/libavcodec/snowenc.c
> index ea0d4fc27f..929edc1340 100644
> --- a/libavcodec/snowenc.c
> +++ b/libavcodec/snowenc.c
> @@ -67,6 +67,32 @@ static av_cold int encode_init(AVCodecContext *avctx)
> if ((ret = ff_snow_common_init(avctx)) < 0) {
> return ret;
> }
> +
> +#define mcf(dx,dy)\
> +s->qdsp.put_qpel_pixels_tab [0][dy+dx/4]=\
> +s->qdsp.put_no_rnd_qpel_pixels_tab[0][dy+dx/4]=\
> +s->h264qpel.put_h264_qpel_pixels_tab[0][dy+dx/4];\
> +s->qdsp.put_qpel_pixels_tab [1][dy+dx/4]=\
> +s->qdsp.put_no_rnd_qpel_pixels_tab[1][dy+dx/4]=\
> +s->h264qpel.put_h264_qpel_pixels_tab[1][dy+dx/4];
> +
> +mcf( 0, 0)
> +mcf( 4, 0)
> +mcf( 8, 0)
> +mcf(12, 0)
> +mcf( 0, 4)
> +mcf( 4, 4)
> +mcf( 8, 4)
> +mcf(12, 4)
> +mcf( 0, 8)
> +mcf( 4, 8)
> +mcf( 8, 8)
> +mcf(12, 8)
> +mcf( 0,12)
> +mcf( 4,12)
> +mcf( 8,12)
> +mcf(12,12)
> +
> ff_me_cmp_init(>mecc, avctx);
> ff_mpegvideoencdsp_init(>mpvencdsp, avctx);
>
Will apply patches 10-13 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".
Re: [FFmpeg-devel] [RFC] Release 6.1
Le keskiviikkona 27. syyskuuta 2023, 23.18.29 EEST Michael Niedermayer a écrit : > And you can repeat it as often as you want, iam not interrested. > Why do you not understand this ? You can repeat the contrary as much as you want, we do not believe that your SDR code fits in FFmpeg. Why do you not understand this? (...) > Then i looked at SDR and wrote the AM/FM demodulation. It added a feature > that was and is IMO usefull to FFmpeg and libavdevice users. Like no, seriously. If you really want to generic support for AM and FM RX in FFmpeg, then you should use implement frontends for the already *existing* HAL (that would be V4L radio and ALSA on Linux), or perhaps, write a new user- space HAL library that would accomodate both hardware radio RX devices and SDR. In fact, the SDR code has quite a number of impediments that all but guarantee that it will not "catch on" in FFmpeg: - it requires niche hardware, - it only works on some limited set of OSes (if not only Linux), - it will be subject to all the FFmpeg processes and drama, - it will be obscured by FFmpeg's existing own fame, remaining an obscure feature set that hardly anybody outside FFmpeg-devel knows about. You are doing your own work a disservice by pushing it in FFmpeg, IMO. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ 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] [RFC] Anual Committee Report
Hi all I think the 2 commmittteees we have should produce an anual report so that the developers who vote for members know the perfomance and what the last comite did like # of cases, # of times people where contacted, % where committi intervention produced a noticable improvment ... # of cases where both parties where happy with the outcome, # of cases where one party only was happy, # of cases where neither party was happy Of course in some years there may be nothing at all, which then would be a rather simple report thx PS: no i dont remember how to spell committee, if i got one corrrect that is unintentional. -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. 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] af_afir: RISC-V V fcmul_add
Le 28 septembre 2023 08:45:44 GMT+03:00, flow gg a écrit : >Okay, I revert the volatile in ff_read_time > >How about this version? It's still using register stride which is all but guaranteed to be slow on any hardware and should only be used as a last resort. The code is also missing scheduling for multi-issue and unrolling with the group multiplier. And lastly, while that probably won't change much, there are no reasons to use mul here. You can use shNadd like existing code does. > >use vls instead vlseg, and use vfmacc > >The benchmark is sometimes better, sometimes the same > >fcmul_add_c: 3.5 >fcmul_add_rvv_f32: 3.5 > - af_afir.fcmul_add [OK] >fcmul_add_c: 4.5 >fcmul_add_rvv_f32: 4.2 > - af_afir.fcmul_add [OK] >fcmul_add_c: 4.2 >fcmul_add_rvv_f32: 4.2 > - af_afir.fcmul_add [OK] >fcmul_add_c: 4.5 >fcmul_add_rvv_f32: 4.2 > - af_afir.fcmul_add [OK] >fcmul_add_c: 4.7 >fcmul_add_rvv_f32: 3.5 > > >Rémi Denis-Courmont 于2023年9月28日周四 00:41写道： > >> Le tiistaina 26. syyskuuta 2023, 12.24.58 EEST flow gg a écrit : >> > benchmark: >> > fcmul_add_c: 19.7 >> > fcmul_add_rvv_f32: 6.7 >> >> With optimisations enabled and the benchmarking fix, I get this (on the >> same >> hardware, I believe): >> >> fcmul_add_c: 3.5 >> fcmul_add_rvv_f32: 6.7 >> >> For sure unfortunate design limitations of T-Head C910 are to blame to no >> small extent. It is not the first occurrence of an RVV optimisation that >> turns >> out worse than scalar due to those, and I still have honest hopes that >> newer >> (and conformant) IP would give saner results, but... I also believe that >> the >> code could be improved regardless. >> >> -- >> Rémi Denis-Courmont >> http://www.remlab.net/ >> >> >> >> ___ >> 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 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 05/42] avcodec/hevc_ps: Use RefStruct API for parameter sets
Quoting Andreas Rheinhardt (2023-09-19 21:56:57) > Avoids allocations and error checks for these allocations; > e.g. syncing buffers across threads can't fail any more > and needn't be checked. It also gets rid of casts and > indirections. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/hevc_parser.c | 8 ++-- > libavcodec/hevc_ps.c | 80 -- > libavcodec/hevc_ps.h | 10 ++--- > libavcodec/hevc_sei.c | 5 +-- > libavcodec/hevcdec.c | 36 +++-- > libavcodec/mediacodecdec.c | 6 +-- > libavcodec/videotoolbox.c | 4 +- > libavcodec/vulkan_hevc.c | 16 > 8 files changed, 72 insertions(+), 93 deletions(-) LGTM -- Anton Khirnov ___ 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 04/42] avcodec/h264_ps: Use RefStruct API for SPS/PPS
Quoting Andreas Rheinhardt (2023-09-19 21:56:56)
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index 5657327f0c..632f5b23b2 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -363,25 +361,16 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
>
> // SPS/PPS
> for (i = 0; i < FF_ARRAY_ELEMS(h->ps.sps_list); i++) {
> -ret = av_buffer_replace(>ps.sps_list[i], h1->ps.sps_list[i]);
> -if (ret < 0)
> -return ret;
> +ff_refstruct_replace(>ps.sps_list[i], h1->ps.sps_list[i]);
> }
> for (i = 0; i < FF_ARRAY_ELEMS(h->ps.pps_list); i++) {
> -ret = av_buffer_replace(>ps.pps_list[i], h1->ps.pps_list[i]);
> -if (ret < 0)
> -return ret;
> +ff_refstruct_replace(>ps.pps_list[i], h1->ps.pps_list[i]);
> }
>
> -ret = av_buffer_replace(>ps.pps_ref, h1->ps.pps_ref);
> -if (ret < 0)
> -return ret;
> -h->ps.pps = NULL;
> +ff_refstruct_replace(>ps.pps, h1->ps.pps);
> h->ps.sps = NULL;
> -if (h1->ps.pps_ref) {
> -h->ps.pps = (const PPS*)h->ps.pps_ref->data;
> +if (h1->ps.pps)
> h->ps.sps = h->ps.pps->sps;
nit: this would look better as
h->ps.sps = h->ps.pps ? h->ps.pps->sps : NULL
Otherwise LGTM
--
Anton Khirnov
___
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 03/42] avcodec/get_buffer: Use RefStruct API for FramePool
Quoting Andreas Rheinhardt (2023-09-19 21:56:55) > Avoids allocations and frees and error checks for said allocations; > also avoids a few indirections and casts. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/avcodec.c | 3 ++- > libavcodec/get_buffer.c| 44 ++ > libavcodec/internal.h | 2 +- > libavcodec/pthread_frame.c | 7 +++--- > 4 files changed, 17 insertions(+), 39 deletions(-) LGTM -- Anton Khirnov ___ 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] [RFC]avformat: introduce AVStreamGroup
fre 2023-09-15 klockan 15:10 -0300 skrev James Almer:
> On 9/13/2023 6:34 AM, Tomas Härdin wrote:
> > ons 2023-09-06 klockan 16:16 -0300 skrev James Almer:
> > > On 9/6/2023 2:53 PM, Tomas Härdin wrote:
> > > > ons 2023-09-06 klockan 11:38 -0300 skrev James Almer:
> > > > > Signed-off-by: James Almer
> > > > > ---
> > > > > This is an initial proof of concept for AVStream groups,
> > > > > something
> > > > > that's
> > > > > needed for quite a few existing and upcoming formats that
> > > > > lavf
> > > > > has no
> > > > > way to
> > > > > currently export. Said formats define a single video or audio
> > > > > stream
> > > > > composed
> > > > > by merging several individualy multiplexed streams within a
> > > > > media
> > > > > file.
> > > > > This is the case of HEIF, a format defining a tiled image
> > > > > where
> > > > > each
> > > > > tile is a
> > > > > separate image (either hevc, av1, etc) all of which need to
> > > > > be
> > > > > decoded
> > > > > individualy and then stitched together for presentation using
> > > > > container level
> > > > > information;
> > > >
> > > > I remember this blocking HEIF as a GSoC project. Honestly the
> > > > way
> > > > that
> > > > format is designed is immensely horrible.
> > > >
> > > > > MPEG-TS programs, currently exported as
> > > > > AVProgram, which this new general purpose API would replace.
> > > >
> > > > I can foresee this being a nuisance for users accustomed to
> > > > AVProgram.
> > > > Also this feature borders on NLE territory. Not necessarily a
> > > > bad
> > > > thing, but FFmpeg is overall poorly architectured for NLE
> > > > stuff. I
> > > > believe I raised this issue back when lavfi was proposed, it
> > > > being
> > > > wholly unsuitable for NLE work.
> > > >
> > > >
> > > > > +typedef struct AVStreamGroup {
> > > > > + /**
> > > > > + * A class for @ref avoptions. Set on stream creation.
> > > > > + */
> > > > > + const AVClass *av_class;
> > > > > +
> > > > > + /**
> > > > > + * Group index in AVFormatContext.
> > > > > + */
> > > > > + int index;
> > > > > +
> > > > > + /**
> > > > > + * Format-specific group ID.
> > > > > + * decoding: set by libavformat
> > > > > + * encoding: set by the user, replaced by libavformat if
> > > > > left
> > > > > unset
> > > > > + */
> > > > > + int id;
> > > > > +
> > > > > + /**
> > > > > + * Codec parameters associated with this stream group.
> > > > > Allocated
> > > > > and freed
> > > > > + * by libavformat in avformat_new_stream_group() and
> > > > > avformat_free_context()
> > > > > + * respectively.
> > > > > + *
> > > > > + * - demuxing: filled by libavformat on stream group
> > > > > creation or
> > > > > in
> > > > > + * avformat_find_stream_info()
> > > > > + * - muxing: filled by the caller before
> > > > > avformat_write_header()
> > > > > + */
> > > > > + AVCodecParameters *codecpar;
> > > > > +
> > > > > + void *priv_data;
> > > > > +
> > > > > + /**
> > > > > + * Number of elements in AVStreamGroup.stream_index.
> > > > > + *
> > > > > + * Set by av_stream_group_add_stream() and
> > > > > av_stream_group_new_stream(), must not
> > > > > + * be modified by any other code.
> > > > > + */
> > > > > + int nb_stream_indexes;
> > > > > +
> > > > > + /**
> > > > > + * A list of indexes of streams in the group. New
> > > > > entries
> > > > > are
> > > > > created with
> > > > > + * av_stream_group_add_stream() and
> > > > > av_stream_group_new_stream().
> > > > > + *
> > > > > + * - demuxing: entries are created by libavformat in
> > > > > avformat_open_input().
> > > > > + * If AVFMTCTX_NOHEADER is set in ctx_flags,
> > > > > then
> > > > > new entries may also
> > > > > + * appear in av_read_frame().
> > > > > + * - muxing: entries are created by the user before
> > > > > avformat_write_header().
> > > > > + *
> > > > > + * Freed by libavformat in avformat_free_context().
> > > > > + */
> > > > > + int *stream_index;
> > > > > +} AVStreamGroup;
> > > >
> > > > I see no provisions for attaching metadata, for example HEIF
> > > > stitching.
> > > > Putting it in coderpar seems wrong, since it is container-level
> > > > metadata. We could just have an HEIF specific struct as
> > > > container
> > > > metadata.
> > >
> > > The doxy for AVCodecParameters says "This struct describes the
> > > properties of an encoded stream.", so It's not about container
> > > level
> > > props.
> >
> > It *is* container level props. The underlying codecs have no
> > concept of
> > this kind of stitching. The closest you're going to get is tiles in
> > JPEG2000, but I doubt HEIF support JPEG2000.
> >
> > We might say "well the resulting stream group has resolution so
> > it's
> > like a codec" but see below.
> >
> > > Although codecpar will be used to export the merged/stitched
> > > stream
> > >
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: fix static building
tis 2023-09-19 klockan 17:12 +0200 skrev Michael Riedl: > MXF muxer requires rangecoder otherwise static linking fails. > > Signed-off-by: Michael Riedl > --- > configure | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure b/configure > index 3bb68d3f20c..9d4297ea68f 100755 > --- a/configure > +++ b/configure > @@ -3532,7 +3532,7 @@ mp4_muxer_select="mov_muxer" > mpegts_demuxer_select="iso_media" > mpegts_muxer_select="ac3_parser adts_muxer latm_muxer > h264_mp4toannexb_bsf hevc_mp4toannexb_bsf" > mpegtsraw_demuxer_select="mpegts_demuxer" > -mxf_muxer_select="pcm_rechunk_bsf" > +mxf_muxer_select="pcm_rechunk_bsf rangecoder" > mxf_d10_muxer_select="mxf_muxer" > mxf_opatom_muxer_select="mxf_muxer" > nut_muxer_select="riffenc" Seems like this is for FFV1 parsing. Looks OK. /Tomas ___ 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 v3] avformat/mxfdec: Remove this_partition
ons 2023-09-27 klockan 23:12 +0200 skrev Michael Niedermayer:
> Hi
>
> On Wed, Sep 27, 2023 at 01:37:40PM +0200, Tomas Härdin wrote:
> > fre 2023-09-22 klockan 21:13 +0200 skrev Michael Niedermayer:
> > > Suggested-by: Tomas Härdin
> > > Fixes: 51896/clusterfuzz-testcase-minimized-
> > > ffmpeg_dem_MXF_fuzzer-
> > > 5130394286817280
> > >
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavformat/mxfdec.c | 28 ++--
> > > 1 file changed, 18 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > index 4846c5d206a..1313f14fa03 100644
> > > --- a/libavformat/mxfdec.c
> > > +++ b/libavformat/mxfdec.c
> > > @@ -102,7 +102,6 @@ typedef struct MXFPartition {
> > > uint64_t previous_partition;
> > > int index_sid;
> > > int body_sid;
> > > - int64_t this_partition;
> > > int64_t essence_offset; ///< absolute offset of
> > > essence
> > > int64_t essence_length;
> > > int32_t kag_size;
> > > @@ -727,10 +726,13 @@ static int mxf_read_partition_pack(void
> > > *arg,
> > > AVIOContext *pb, int tag, int size
> > > UID op;
> > > uint64_t footer_partition;
> > > uint32_t nb_essence_containers;
> > > + uint64_t this_partition;
> > >
> > > if (mxf->partitions_count >= INT_MAX / 2)
> > > return AVERROR_INVALIDDATA;
> > >
> > > + av_assert0(klv_offset >= mxf->run_in);
> > > +
> > > tmp_part = av_realloc_array(mxf->partitions, mxf-
> > > > partitions_count + 1, sizeof(*mxf->partitions));
> > > if (!tmp_part)
> > > return AVERROR(ENOMEM);
> > > @@ -773,7 +775,13 @@ static int mxf_read_partition_pack(void
> > > *arg,
> > > AVIOContext *pb, int tag, int size
> > > partition->complete = uid[14] > 2;
> > > avio_skip(pb, 4);
> > > partition->kag_size = avio_rb32(pb);
> > > - partition->this_partition = avio_rb64(pb);
> > > + this_partition = avio_rb64(pb);
> > > + if (this_partition != klv_offset - mxf->run_in) {
> > > + av_log(mxf->fc, AV_LOG_WARNING,
> > > + "this_partition %"PRId64" mismatches
> > > %"PRId64"\n",
> > > + this_partition, klv_offset - mxf->run_in);
> >
> > We might want to error out here, since this means offsets are
> > likely to
> > be incorrect across the entire file. We have no files in FATE that
> > demonstrate this problem, and it pays to be strict when it comes to
> > MXF. This helps people writing new MXF muxers from writing broken
> > ones.
>
> ok, should i ask for a sample here (so we maybe get a sample)
> or just error out with this message at AV_LOG_ERROR ?
Nah, just error out
/Tomas
___
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 6/6] avformat/mov: Check avif_info
Quoting Michael Niedermayer (2023-09-21 20:09:12)
> Fixes: leak
> Fixes:
> 62164/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6674082962997248
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mov.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 93c1f9e929a..52939a373ec 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -7767,7 +7767,7 @@ static int mov_read_iloc(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> return 0;
> }
>
> -if (c->fc->nb_streams) {
> +if (c->fc->nb_streams || c->avif_info) {
I remember seeing this patch before and asking whether the first
condition is not redundant now.
--
Anton Khirnov
___
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 v2 1/3] avformat/avformat: Deprecate AVFMT_ALLOW_FLUSH
Martin Storsjö:
> On Tue, 26 Sep 2023, Andreas Rheinhardt wrote:
>
>> Martin Storsjö:
>>> On Tue, 26 Sep 2023, Anton Khirnov wrote:
>>>
Quoting Andreas Rheinhardt (2023-09-26 01:54:30)
> It is of no value to the user, because every muxer can always
> be flushed with a NULL packet. As its documentation shows
> ("If not set, the muxer will not receive a NULL packet in
> the write_packet function") it is actually an internal flag
> that has been publically exposed because there was no internal
> flags field for output formats for a long time. But now there is
> and so use it by replacing the public flag with a private one.
Is there any value for the callers in knowing whether flushing is a
no-op or actually does something?
>>>
>>> Hypthetically, in theory, I guess one could make a case for that. But
>>> most of the codepaths where one use this anyway, one is pretty closely
>>> tied to the specific muxer one is using (usually mov/mp4 or maybe mkv),
>>> so in practice I don't think that's needed.
>>>
>>> I don't remember there being a specific demand for that back when this
>>> was added, it was only a case of us not having internal flags at the
>>> time.
>>>
>>
>> So if we had them back then, you would not have made the flag public?
>
> Exactly; if we have had private muxer flags at the time, I would
> probably not have made this a public flag.
>
> So I think this patch is fine.
>
Ok, will push this on October 3 then 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".
Re: [FFmpeg-devel] SDR lib comments
Quoting Michael Niedermayer (2023-09-23 18:43:44) > Is a seperate library really the right choice for SDR in FFmpeg at this stage > ? > > Also code can always be moved into an seperate library we've had postproc in the tree for ages, nobody maintains it or cares about it, yet it seems impossible to get rid of it. > but its much harder to move or change it once such library is public. Compatibility rules you choose for your new library are entirely up to you, they can (and probably should) be very loose at the beginning. -- Anton Khirnov ___ 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] x265 rpu processing
What list would you suggest instead, main? The command was just a snipped, normally would do something like this: /usr/bin/ffmpeg -i "/home/robin/dolby_vision_test_8_1 - [2160p].mp4" -map 0:0 -c:v libx265 -preset slower -ss 00:00:00 -to 00:00:10 -crf 20 -vf zscale=3840:2160,hqdn3d=0.4:0.4:1.25:1.25 -x265-params "aq-mode=2:aq-strength=0.8:early-skip=1:ref=4:me=star:subme=4:merange=64:rc-lookahead=5:wpp=1:strong-intra-smoothing=1:rect=0:rd=4:psy-rd=0.1:psy-rdoq=0.20:rdoq-level=2:rskip=2:bframes=4:b-adapt=2:analyze-src-pics=1:colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:hdr10_opt=1:master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(1000,50):max-cll=2738,90:hdr10=1:chromaloc=2:dhdr10-info='/path/to/metadata.json':vbv-maxrate=2400:vbv-bufsize=4800:dolby-vision-profile='8.1':dolby-vision-rpu='/path/to/dolby_vision.bin'" -pix_fmt yuv420p10le -color_trc smpte2084 -profile:v main10 -vtag hvc1 -force_key_frames "expr:gte(t,n_forced*4)" -g 100 -keyint_min 100 -r 25 -use_timeline 1 -use_template 1 -map_metadata -1 -map_chapters -1 -f hls -seg_duration 4 -hls_time 4 -segment_format mp4 -streaming 1 -hls_list_size 0 -hls_segment_filename "/home/robin/test/output/test - [2160p]/v-hevc-2160p/%04d.m4s" -hls_fmp4_init_filename "init-v-hevc-2160p.m4s" -hls_segment_type fmp4 -hls_playlist_type vod -movflags frag_keyframe+frag_every_frame+write_colr+prefer_icc+skip_trailer+faststart -hls_flags independent_segments "/home/robin/test/output/test - [2160p]/v-hevc-2160/master.m3u8" But ffmpeg returns the following for the command above: [libx265 @ 0x6aa6f00] Unknown option: dolby-vision-rpu. x265 [info]: HEVC encoder version 3.5+1-f0c1022b6 x265 [info]: build info [Linux][GCC 9.4.0][64 bit] 10bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 x265 [warning]: Turning on repeat-headers for HDR compatibility x265 [info]: Main 10 profile, Level-5 (Main tier) x265 [info]: Thread pool created using 16 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 4 / wpp(34 rows) x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra x265 [info]: ME / range / subpel / merge : star / 64 / 4 / 4 x265 [info]: Keyframe min / max / scenecut / bias : 100 / 100 / 40 / 5.00 x265 [info]: Lookahead / bframes / badapt: 5 / 4 / 2 x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1 x265 [info]: References / ref-limit cu / depth : 4 / off / on x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 0.8 / 32 / 1 x265 [info]: Rate Control / qCompress: CRF-20.0 / 0.60 x265 [info]: VBV/HRD buffer / max-rate / init: 4800 / 2400 / 0.900 x265 [info]: tools: limit-modes rd=4 psy-rd=0.10 rdoq=2 psy-rdoq=0.20 x265 [info]: tools: early-skip rskip mode=2 rskip-edge-threshold=0.05 x265 [info]: tools: limit-tu=4 signhide tmvp b-intra strong-intra-smoothing x265 [info]: tools: deblock sao dhdr10-info [hls @ 0x6b32dc0] Opening '/home/robin/test/output/test - [2160p]/v-hevc-2160/init-v-hevc-2160p.m4s' for writing Output #0, hls, to '/home/robin/test/output/test - [2160p]/v-hevc-2160/master.m3u8': Metadata: encoder : Lavf60.3.100 Stream #0:0(eng): Video: hevc (hvc1 / 0x31637668), yuv420p10le(tv, bt2020nc/bt2020/smpte2084, progressive), 3840x2160 [SAR 1:1 DAR 16:9], q=2-31, 25 fps, 12800 tbn (default) Metadata: creation_time : 2023-08-03T22:42:18.00Z vendor_id : [0][0][0][0] encoder : Lavc60.3.100 libx265 Side data: cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A DOVI configuration record: version: 1.0, profile: 8, level: 7, rpu flag: 1, el flag: 0, bl flag: 1, compatibility id: 1 [hls @ 0x6b32dc0] Opening '/home/robin/test/output/test - [2160p]/v-hevc-2160p/.m4s' for writingeed=N/A [hls @ 0x6b32dc0] Opening /home/robin/test/output/test - [2160p]/v-hevc-2160p/0001.m4s' for writing [hls @ 0x6b32dc0] Opening '/home/robin/test/output/test - [2160p]/v-hevc-2160p/0002.m4s' for writing frame= 250 fps= 11 q=27.9 Lsize=N/A time=00:00:09.88 bitrate=N/A dup=10 drop=0 speed=0.433x video:869kB audio:0kB subtitle:0kB other streams:0kB global headers:3kB muxing overhead: unknown x265 [info]: frame I: 3, Avg QP:22.17 kb/s: 12159.67 x265 [info]: frame P: 56, Avg QP:24.70 kb/s: 1912.89 x265 [info]: frame B:191, Avg QP:27.52 kb/s: 147.61 x265 [info]: Weighted P-Frames: Y:26.8% UV:25.0% x265 [info]: Weighted B-Frames: Y:30.9% UV:27.7% encoded 250 frames in 22.55s (11.08 fps), 687.17 kb/s, Avg QP:26.82 Thanks in advance, Robin Am 2023-09-28 12:01, schrieb Andreas Rheinhardt: Robin van der Linden via ffmpeg-devel: Hello, I've observed that the "-x265-params dolby-vision-rpu /path/to/rpu" doesn't seem to work in my ffmpeg command. Though the libx265 documentation indicates the presence
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/codec_par: Move enum AVFieldOrder to defs.h
Quoting Andreas Rheinhardt (2023-09-26 11:17:25) > James Almer: > > On 9/25/2023 8:55 PM, Andreas Rheinhardt wrote: > >> It is also used by AVCodecContext. > >> > >> Signed-off-by: Andreas Rheinhardt > >> --- > >> doc/APIchanges | 3 +++ > >> libavcodec/codec_par.h | 10 +- > >> libavcodec/defs.h | 8 > >> 3 files changed, 12 insertions(+), 9 deletions(-) > >> > >> diff --git a/doc/APIchanges b/doc/APIchanges > >> index ca7ffbb97e..c1ea3b7dc1 100644 > >> --- a/doc/APIchanges > >> +++ b/doc/APIchanges > >> @@ -2,6 +2,9 @@ The last version increases of all libraries were on > >> 2023-02-09 > >> API changes, most recent first: > >> +2023-09-26 - xx - lavc 60.xx.100 - codec_par.h defs.h > >> + Move the definition of enum AVFieldOrder from codec_par.h to defs.h. > > > > Does this need an entry? If codec_par.h includes defs.h, it's basically > > transparent for the API user. > > > > It does not break existing users, but existing users may take advantage > of it. Probably not in this case, but for moving stuff in general and > therefore we add these APIchanges entries. > But if you insist, I can omit it. I think it should be mentioned. -- Anton Khirnov ___ 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] GBRAP14 support for MagicYUV
On Wed, Sep 27, 2023 at 07:24:50PM +0200, Paul B Mahol wrote:
> Attached.
> pixdesc.c | 28
> pixfmt.h |4
> 2 files changed, 32 insertions(+)
> dc323faf13db2ffbefdd8ce2c25ba3a97633e0eb
> 0001-avutil-add-GBRAP14-format-support.patch
> From 3e58da932f88e6781eb772d883efa6f0997de936 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Wed, 27 Sep 2023 16:06:02 +0200
> Subject: [PATCH 1/4] avutil: add GBRAP14 format support
>
> Signed-off-by: Paul B Mahol
> ---
> libavutil/pixdesc.c | 28
> libavutil/pixfmt.h | 4
> 2 files changed, 32 insertions(+)
>
> diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> index e1e0dd2a9e..6ded9467b0 100644
> --- a/libavutil/pixdesc.c
> +++ b/libavutil/pixdesc.c
> @@ -2223,6 +2223,34 @@ static const AVPixFmtDescriptor
> av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
> },
> .flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_BE,
> },
> +[AV_PIX_FMT_GBRAP14LE] = {
> +.name = "gbrap14le",
> +.nb_components = 4,
> +.log2_chroma_w = 0,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 2, 2, 0, 0, 14 }, /* R */
> +{ 0, 2, 0, 0, 14 }, /* G */
> +{ 1, 2, 0, 0, 14 }, /* B */
> +{ 3, 2, 0, 0, 14 }, /* A */
> +},
> +.flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_RGB |
> + AV_PIX_FMT_FLAG_ALPHA,
> +},
> +[AV_PIX_FMT_GBRAP14BE] = {
> +.name = "gbrap14be",
> +.nb_components = 4,
> +.log2_chroma_w = 0,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 2, 2, 0, 0, 14 }, /* R */
> +{ 0, 2, 0, 0, 14 }, /* G */
> +{ 1, 2, 0, 0, 14 }, /* B */
> +{ 3, 2, 0, 0, 14 }, /* A */
> +},
> +.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR |
> + AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_ALPHA,
> +},
> [AV_PIX_FMT_GBRAP12LE] = {
> .name = "gbrap12le",
> .nb_components = 4,
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index 63e07ba64f..a26c72d56b 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -426,6 +426,9 @@ enum AVPixelFormat {
> AV_PIX_FMT_P412BE, ///< interleaved chroma YUV 4:4:4, 36bpp, data
> in the high bits, big-endian
> AV_PIX_FMT_P412LE, ///< interleaved chroma YUV 4:4:4, 36bpp, data
> in the high bits, little-endian
>
> +AV_PIX_FMT_GBRAP14BE, ///< planar GBR 4:4:4:4 56bpp, big-endian
> +AV_PIX_FMT_GBRAP14LE, ///< planar GBR 4:4:4:4 56bpp, little-endian
> +
> AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if
> you want to link with shared libav* because the number of formats might
> differ between versions
> };
>
> @@ -484,6 +487,7 @@ enum AVPixelFormat {
> #define AV_PIX_FMT_GBRP16AV_PIX_FMT_NE(GBRP16BE,GBRP16LE)
> #define AV_PIX_FMT_GBRAP10 AV_PIX_FMT_NE(GBRAP10BE, GBRAP10LE)
> #define AV_PIX_FMT_GBRAP12 AV_PIX_FMT_NE(GBRAP12BE, GBRAP12LE)
> +#define AV_PIX_FMT_GBRAP14 AV_PIX_FMT_NE(GBRAP14BE, GBRAP14LE)
> #define AV_PIX_FMT_GBRAP16 AV_PIX_FMT_NE(GBRAP16BE, GBRAP16LE)
>
> #define AV_PIX_FMT_BAYER_BGGR16 AV_PIX_FMT_NE(BAYER_BGGR16BE,
> BAYER_BGGR16LE)
> --
> 2.42.0
>
> libavformat/nut.c|2 ++
> libswscale/input.c |7 +++
> libswscale/output.c |2 ++
> libswscale/swscale_unscaled.c|3 +++
> libswscale/utils.c |6 ++
> tests/ref/fate/filter-pixdesc-gbrap14be |1 +
> tests/ref/fate/filter-pixdesc-gbrap14le |1 +
> tests/ref/fate/filter-pixfmts-copy |2 ++
> tests/ref/fate/filter-pixfmts-crop |2 ++
> tests/ref/fate/filter-pixfmts-field |2 ++
> tests/ref/fate/filter-pixfmts-fieldorder |2 ++
> tests/ref/fate/filter-pixfmts-hflip |2 ++
> tests/ref/fate/filter-pixfmts-il |2 ++
> tests/ref/fate/filter-pixfmts-null |2 ++
> tests/ref/fate/filter-pixfmts-pad|1 +
> tests/ref/fate/filter-pixfmts-scale |2 ++
> tests/ref/fate/filter-pixfmts-transpose |2 ++
> tests/ref/fate/filter-pixfmts-vflip |2 ++
> 18 files changed, 43 insertions(+)
> 025cfa7df85fab9943d3049f729c25db5934eb3f
> 0002-swscale-add-GBRAP14-format-support.patch
> From 517fc54c52cfdcdbc6920ede04b215ed27429b00 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Wed, 27 Sep 2023 16:13:16 +0200
> Subject: [PATCH 2/4] swscale: add GBRAP14 format support
LGTM assuming you vissually confirmed output look correct
fate tests also pass on x86 32/64 mingw32/64 (arm/mips still running, if you
hear nothing more then they passed too)
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No great genius has ever existed without some
Re: [FFmpeg-devel] [PATCH] avcodec/photocd: allow decoding vlc with errors
Quoting Paul B Mahol (2023-09-28 11:48:14) > On 9/28/23, Anton Khirnov wrote: > > Quoting Paul B Mahol (2023-09-27 21:53:54) > >> Attached. > >> > >> From 6b7e51e2b4facead9c45fb94647c85b58e6fdf22 Mon Sep 17 00:00:00 2001 > >> From: Paul B Mahol > >> Date: Wed, 27 Sep 2023 21:48:49 +0200 > >> Subject: [PATCH] avcodec/photocd: allow decoding vlc with errors > >> > >> Also rename option that no longer works. > >> Also make tables finding more robust. > > > > Why do all these things in a single patch? > > > > I can boost my commits if you prefer that way. Feel welcome. > >> +s->streampos = (AV_RB16(avpkt->data + 2048 + 1536 + 3) + 12) > >> * 2048; > > > > Where do these magic numbers come from? Same below. > > From offset from internal image file bitstream table structure. Please describe that in a comment above that line then. -- Anton Khirnov ___ 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] x265 rpu processing
Robin van der Linden via ffmpeg-devel: > Hello, > > I've observed that the "-x265-params dolby-vision-rpu /path/to/rpu" > doesn't seem to work in my ffmpeg command. Though the libx265 > documentation indicates the presence of this parameter, ffmpeg appears > to be having trouble recognizing it. In fact, ffmpeg reports it as an > unknown parameter. Is this option exclusive to CLI currently? Is there > any anticipated support for it in the future? > > For reference, here's the x265 documentation: > https://x265.readthedocs.io/en/master/cli.html > 1. Wrong list. 2. That's not how x265-params is supposed to be set: "set the x265 configuration using a :-separated list of key=value parameters" - 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".
[FFmpeg-devel] x265 rpu processing
Hello, I've observed that the "-x265-params dolby-vision-rpu /path/to/rpu" doesn't seem to work in my ffmpeg command. Though the libx265 documentation indicates the presence of this parameter, ffmpeg appears to be having trouble recognizing it. In fact, ffmpeg reports it as an unknown parameter. Is this option exclusive to CLI currently? Is there any anticipated support for it in the future? For reference, here's the x265 documentation: https://x265.readthedocs.io/en/master/cli.html -- Kind regards, Robin van der Linden ___ 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/photocd: allow decoding vlc with errors
On 9/28/23, Anton Khirnov wrote:
> Quoting Paul B Mahol (2023-09-27 21:53:54)
>> Attached.
>>
>> From 6b7e51e2b4facead9c45fb94647c85b58e6fdf22 Mon Sep 17 00:00:00 2001
>> From: Paul B Mahol
>> Date: Wed, 27 Sep 2023 21:48:49 +0200
>> Subject: [PATCH] avcodec/photocd: allow decoding vlc with errors
>>
>> Also rename option that no longer works.
>> Also make tables finding more robust.
>
> Why do all these things in a single patch?
>
I can boost my commits if you prefer that way.
> And why are there no tests for this decoder?
Its complicated.
>
>> Signed-off-by: Paul B Mahol
>> ---
>> libavcodec/photocd.c | 7 +++
>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavcodec/photocd.c b/libavcodec/photocd.c
>> index 07e8d460bd..a9e42bb86a 100644
>> --- a/libavcodec/photocd.c
>> +++ b/libavcodec/photocd.c
>> @@ -277,8 +277,6 @@ static av_noinline int decode_huff(AVCodecContext
>> *avctx, AVFrame *frame,
>> if (get_bits_left() <= 0)
>> return AVERROR_INVALIDDATA;
>> m = get_vlc2(, s->vlc[idx].table, s->vlc[idx].bits, 2);
>> -if (m < 0)
>> -return AVERROR_INVALIDDATA;
>
> Shouldn't this error be at least logged? Perhaps it should still fail on
> AV_EF_EXPLODE.
>
>> m = sign_extend(m, 8);
>> data[x] = av_clip_uint8(data[x] + m);
>> }
>> @@ -389,6 +387,7 @@ static int photocd_decode_frame(AVCodecContext *avctx,
>> AVFrame *p,
>> return AVERROR_INVALIDDATA;
>>
>> if (s->resolution == 4) {
>> +s->streampos = (AV_RB16(avpkt->data + 2048 + 1536 + 3) + 12)
>> * 2048;
>
> Where do these magic numbers come from? Same below.
>From offset from internal image file bitstream table structure.
>
> --
> Anton Khirnov
> ___
> 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 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] tools: Don't include the direct library names when linking
When linking the main tools, the object files to link are set up via the variable OBJS-, but for the tools, we've only used the target's list of dependencies. In most cases, this has been fine, but it has caused specifying the libraries to link in a duplicate fashion; the linking command has looked like this: $CC -Llibavutil ... tools/tool.o libavutil/libavutil.a -lavutil Normally, the libraries to link are handled with "-Llibavutil -lavutil"; when linking the main fftools, this is how they are linked. In the case of the binaries under the "tools" directory (within the make variable TOOLS), we've passed the full set of dependencies to the linker, via $^, which does contain the names of the dependency libraries as well. When libraries are built as regular static libraries, or shared unix libraries, this has all worked fine. When libraries are built as DLLs for Windows, though, the norm is not to pass the actual DLL to the linker, but an import library. Mingw tools generally can handle linking directly against a DLL as well, but MSVC tools don't support that, and error out with a very cryptic error message: libavdevice\avdevice.dll : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2D8 By omitting these parts of the dependencies, linking of these tool executables succeed in MSVC builds with shared libraries enabled. --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index bf1b69f96b..78652c47bd 100644 --- a/Makefile +++ b/Makefile @@ -47,7 +47,7 @@ FF_DEP_LIBS := $(DEP_LIBS) FF_STATIC_DEP_LIBS := $(STATIC_DEP_LIBS) $(TOOLS): %$(EXESUF): %.o - $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(EXTRALIBS-$(*F)) $(EXTRALIBS) $(ELIBS) + $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter-out $(FF_DEP_LIBS), $^) $(EXTRALIBS-$(*F)) $(EXTRALIBS) $(ELIBS) target_dec_%_fuzzer$(EXESUF): target_dec_%_fuzzer.o $(FF_DEP_LIBS) $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS) $(LIBFUZZER_PATH) -- 2.34.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/photocd: allow decoding vlc with errors
Quoting Paul B Mahol (2023-09-27 21:53:54)
> Attached.
>
> From 6b7e51e2b4facead9c45fb94647c85b58e6fdf22 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Wed, 27 Sep 2023 21:48:49 +0200
> Subject: [PATCH] avcodec/photocd: allow decoding vlc with errors
>
> Also rename option that no longer works.
> Also make tables finding more robust.
Why do all these things in a single patch?
And why are there no tests for this decoder?
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/photocd.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/photocd.c b/libavcodec/photocd.c
> index 07e8d460bd..a9e42bb86a 100644
> --- a/libavcodec/photocd.c
> +++ b/libavcodec/photocd.c
> @@ -277,8 +277,6 @@ static av_noinline int decode_huff(AVCodecContext *avctx,
> AVFrame *frame,
> if (get_bits_left() <= 0)
> return AVERROR_INVALIDDATA;
> m = get_vlc2(, s->vlc[idx].table, s->vlc[idx].bits, 2);
> -if (m < 0)
> -return AVERROR_INVALIDDATA;
Shouldn't this error be at least logged? Perhaps it should still fail on
AV_EF_EXPLODE.
> m = sign_extend(m, 8);
> data[x] = av_clip_uint8(data[x] + m);
> }
> @@ -389,6 +387,7 @@ static int photocd_decode_frame(AVCodecContext *avctx,
> AVFrame *p,
> return AVERROR_INVALIDDATA;
>
> if (s->resolution == 4) {
> +s->streampos = (AV_RB16(avpkt->data + 2048 + 1536 + 3) + 12) *
> 2048;
Where do these magic numbers come from? Same below.
--
Anton Khirnov
___
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/svt-av1: Set pic_type only when gop_size == 1
Hi Vignesh, On Thu, Sep 28, 2023 at 12:14 AM Vignesh Venkatasubramanian via ffmpeg-devel wrote: > SVT-AV1 does not support requesting keyframes at arbitrary points > by setting pic_type to EB_AV1_KEY_PICTURE. > > This patch changes the following: > * Set pic_type to EB_AV1_KEY_PICTURE only when gop_size == 1. This >only has an effect in this case (combined with force_key_frames). >In all other cases, setting this has no effect. > * Set force_key_frames to 1 only when gop_size == 1, this is >needed for pic_type request above to work. > > Please see the comments in > https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2076 for a bit more > details. > Right. So, if I put my archeologist hat on, is it fair to say that what probably happened is that force_key_frames used to not exist, and pic_type worked as per above code. Then force_key_frames was required (because of quality implications), breaking the above code. And now we're removing the broken code because otherwise there's a quality penalty. Is that fair? I agree it's probably unfair to ask you to fix the broken use case that was previously possible (I suppose this comes down to exposing an option to set force_key_frames by having the user indicate s/he'll be using pic_type). However, maybe we should not remove the dead code, because it's functionally OK. Maybe we even need a FIXME above the line where we set force_key_frames only if gop_size==1, explaining this is a bug. WDYT? (It feels a bit weird to remove it because it's broken, is what I'm trying to say, especially because we know how to fix it.) Ronald ___ 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] [RFC] Release 6.1
Hi, On Wed, Sep 27, 2023 at 10:27 PM Nicolas George wrote: > Michael Niedermayer (12023-09-27): > > With SDR they do ask for a seperate library. > > And they are being dishonest in that. Nothing successful starts as a > library > Didn't dav1d start as a library? (Or maybe it's not very successful by your standards.) x264/5 are external libs, also. I don't think we have to be absolutist about these things. Nothing's quite so black/white. Ronald ___ 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] framequeue: Remove redundant logic code
杨亚磊 via ffmpeg-devel (12023-09-14): > Hello everyone. > I submitted a patch, the details are as follows: > > framequeue: Remove redundant logic code > > In this logical branch, fq->queued and fq->allocated must be equal. > Deleting this code will make it easier to understand the logic ( > copy the data before tail to the newly requested space) > > >Please review as soon as possible, thank you very much！ Hi. Thanks for the patch. Good catch. Applied. Regards, -- Nicolas George ___ 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".
