Re: [FFmpeg-devel] [PATCH 1/5] avcodec/decode: Check for more invalid channel counts

2022-09-15 Thread James Almer

On 9/15/2022 10:10 PM, Andreas Rheinhardt wrote:

Signed-off-by: Andreas Rheinhardt 
---
Maybe use av_channel_layout_check?

  libavcodec/decode.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 2961705c9d..e24005cc44 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1595,7 +1595,7 @@ FF_DISABLE_DEPRECATION_WARNINGS
  FF_ENABLE_DEPRECATION_WARNINGS
  #endif
  
-if (avctx->codec_type == AVMEDIA_TYPE_AUDIO && avctx->ch_layout.nb_channels == 0 &&

+if (avctx->codec_type == AVMEDIA_TYPE_AUDIO && avctx->ch_layout.nb_channels <= 0 
&&
  !(avctx->codec->capabilities & AV_CODEC_CAP_CHANNEL_CONF)) {
  av_log(avctx, AV_LOG_ERROR, "Decoder requires channel count but channels 
not set\n");
  return AVERROR(EINVAL);


This is a AV_CODEC_CAP_CHANNEL_CONF specific check to see if a channel 
count is set. A general sanity check like < 0 should be in 
avcodec_open2() before the ff_decode_preinit() call, next to (or as part 
of) the similar FF_SANE_NB_CHANNELS check, IMO.

___
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 5/5] fate/lavf-audio: Add dfpwm test

2022-09-15 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 tests/fate/lavf-audio.mak | 2 ++
 tests/ref/lavf/dfpwm  | 3 +++
 2 files changed, 5 insertions(+)
 create mode 100644 tests/ref/lavf/dfpwm

diff --git a/tests/fate/lavf-audio.mak b/tests/fate/lavf-audio.mak
index 68fca35298..d557d43c08 100644
--- a/tests/fate/lavf-audio.mak
+++ b/tests/fate/lavf-audio.mak
@@ -14,6 +14,7 @@ FATE_LAVF_AUDIO-$(call ENCDEC,  PCM_S16LE,W64)
  += w64
 FATE_LAVF_AUDIO-$(call ENCDEC,  TTA,  TTA)  += tta
 FATE_LAVF_AUDIO-$(call ENCMUX,  TTA,  MATROSKA_AUDIO)   += mka
 FATE_LAVF_AUDIO_RESAMPLE-$(call ENCDEC,  PCM_S16BE_PLANAR, AST) += ast
+FATE_LAVF_AUDIO_RESAMPLE-$(call ENCDEC,  PCM_S16BE_PLANAR, AST) += dfpwm
 FATE_LAVF_AUDIO_RESAMPLE-$(call ENCDEC,  PCM_U8,   RSO) += rso
 FATE_LAVF_AUDIO_RESAMPLE-$(call ENCDEC,  PCM_S16LE,SOX) += sox
 FATE_LAVF_AUDIO_RESAMPLE-$(call ENCDEC,  PCM_U8,   VOC) += voc
@@ -28,6 +29,7 @@ $(FATE_LAVF_AUDIO): REF = 
$(SRC_PATH)/tests/ref/lavf/$(@:fate-lavf-%=%)
 $(FATE_LAVF_AUDIO): $(AREF)
 
 fate-lavf-al fate-lavf-ul: CMD = lavf_audio "" "" "-ar 44100"
+fate-lavf-dfpwm: CMD = lavf_audio "" "" "-sample_rate 44100"
 fate-lavf-ogg: CMD = lavf_audio "" "-c:a flac"
 fate-lavf-s16.voc: CMD = lavf_audio "-ac 2" "-c:a pcm_s16le"
 fate-lavf-ast: CMD = lavf_audio "-ac 2" "-loopstart 1 -loopend 10"
diff --git a/tests/ref/lavf/dfpwm b/tests/ref/lavf/dfpwm
new file mode 100644
index 00..b9423bc1c1
--- /dev/null
+++ b/tests/ref/lavf/dfpwm
@@ -0,0 +1,3 @@
+c216a2b5576f3e7f31516854bbb41eb8 *tests/data/lavf/lavf.dfpwm
+5513 tests/data/lavf/lavf.dfpwm
+tests/data/lavf/lavf.dfpwm CRC=0x226be6b3
-- 
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 4/5] avformat/dfpwmdec: Remove unnecessary headers

2022-09-15 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavformat/dfpwmdec.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavformat/dfpwmdec.c b/libavformat/dfpwmdec.c
index 98fb4102e3..2244aa99fe 100644
--- a/libavformat/dfpwmdec.c
+++ b/libavformat/dfpwmdec.c
@@ -20,13 +20,11 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-#include "libavutil/avstring.h"
 #include "avformat.h"
 #include "internal.h"
 #include "pcm.h"
 #include "libavutil/log.h"
 #include "libavutil/opt.h"
-#include "libavutil/avassert.h"
 
 typedef struct DFPWMAudioDemuxerContext {
 AVClass *class;
-- 
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 3/5] avformat/dfpwmdec: Inline raw_codec_id

2022-09-15 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavformat/dfpwmdec.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavformat/dfpwmdec.c b/libavformat/dfpwmdec.c
index 685b95148c..98fb4102e3 100644
--- a/libavformat/dfpwmdec.c
+++ b/libavformat/dfpwmdec.c
@@ -50,7 +50,7 @@ static int dfpwm_read_header(AVFormatContext *s)
 par = st->codecpar;
 
 par->codec_type  = AVMEDIA_TYPE_AUDIO;
-par->codec_id= s->iformat->raw_codec_id;
+par->codec_id= AV_CODEC_ID_DFPWM;
 par->sample_rate = s1->sample_rate;
 #if FF_API_OLD_CHANNEL_LAYOUT
 if (s1->ch_layout.nb_channels) {
@@ -95,6 +95,5 @@ const AVInputFormat ff_dfpwm_demuxer = {
 .read_seek  = ff_pcm_read_seek,
 .flags  = AVFMT_GENERIC_INDEX,
 .extensions = "dfpwm",
-.raw_codec_id   = AV_CODEC_ID_DFPWM,
 .priv_class = _demuxer_class,
 };
-- 
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 2/5] avcodec/dfpwmdec: Remove always-false check

2022-09-15 Thread Andreas Rheinhardt
This decoder does not have the AV_CODEC_CAP_CHANNEL_CONF set,
so that number of channels has to be set by the user before
avcodec_open2().

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/dfpwmdec.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/libavcodec/dfpwmdec.c b/libavcodec/dfpwmdec.c
index 532a955b4c..4ddb806561 100644
--- a/libavcodec/dfpwmdec.c
+++ b/libavcodec/dfpwmdec.c
@@ -85,11 +85,6 @@ static av_cold int dfpwm_dec_init(struct AVCodecContext *ctx)
 {
 DFPWMState *state = ctx->priv_data;
 
-if (ctx->ch_layout.nb_channels <= 0) {
-av_log(ctx, AV_LOG_ERROR, "Invalid number of channels\n");
-return AVERROR(EINVAL);
-}
-
 state->fq = 0;
 state->q = 0;
 state->s = 0;
-- 
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 1/5] avcodec/decode: Check for more invalid channel counts

2022-09-15 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
Maybe use av_channel_layout_check?

 libavcodec/decode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 2961705c9d..e24005cc44 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1595,7 +1595,7 @@ FF_DISABLE_DEPRECATION_WARNINGS
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 
-if (avctx->codec_type == AVMEDIA_TYPE_AUDIO && 
avctx->ch_layout.nb_channels == 0 &&
+if (avctx->codec_type == AVMEDIA_TYPE_AUDIO && 
avctx->ch_layout.nb_channels <= 0 &&
 !(avctx->codec->capabilities & AV_CODEC_CAP_CHANNEL_CONF)) {
 av_log(avctx, AV_LOG_ERROR, "Decoder requires channel count but 
channels not set\n");
 return AVERROR(EINVAL);
-- 
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] configure: Remove obsolete APTX decoder dependencies

2022-09-15 Thread Andreas Rheinhardt
Forgotten in 18e55de45a4d0ea197eaeae3a3a9daea186159b9.

Signed-off-by: Andreas Rheinhardt 
---
 configure | 2 --
 1 file changed, 2 deletions(-)

diff --git a/configure b/configure
index 240ae942d1..c157338b1f 100755
--- a/configure
+++ b/configure
@@ -2775,9 +2775,7 @@ amv_encoder_select="jpegtables mpegvideoenc"
 ape_decoder_select="bswapdsp llauddsp"
 apng_decoder_select="inflate_wrapper"
 apng_encoder_select="deflate_wrapper llvidencdsp"
-aptx_decoder_select="audio_frame_queue"
 aptx_encoder_select="audio_frame_queue"
-aptx_hd_decoder_select="audio_frame_queue"
 aptx_hd_encoder_select="audio_frame_queue"
 asv1_decoder_select="blockdsp bswapdsp idctdsp"
 asv1_encoder_select="aandcttables bswapdsp fdctdsp pixblockdsp"
-- 
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] MAINTAINERS: add maintainer for the imf demuxer

2022-09-15 Thread Pierre-Anthony Lemieux
On Thu, Sep 15, 2022 at 4:07 PM Lynne  wrote:
>
> Sep 16, 2022, 00:46 by p...@sandflow.com:
>
> > From: Pierre-Anthony Lemieux 
> >
> > ---
> >  MAINTAINERS | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index ed2ec0b90c..2d37f0b86a 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -436,6 +436,7 @@ Muxers/Demuxers:
> >  idcin.c   Mike Melanson
> >  idroqdec.cMike Melanson
> >  iff.c Jaikrishnan Menon
> > +  imf*  Pierre-Anthony Lemieux
> >  img2*.c   Michael Niedermayer
> >  ipmovie.c Mike Melanson
> >  ircam*Paul B Mahol
> > @@ -633,6 +634,7 @@ Nikolay Aleksandrov   8978 1D8C FB71 588E 4B27 
> > EAA8 C4F0 B5FC E011 13B1
> >  Panagiotis Issaris6571 13A3 33D9 3726 F728 AA98 F643 B12E ECF3 
> > E029
> >  Peter RossA907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 
> > DD6B
> >  Philip Langdale   5DC5 8D66 5FBA 3A43 18EC 045E F8D6 B194 6A75 
> > 682E
> > +Pierre-Anthony Lemieux (pal)  F4B3 9492 E6F2 E4AF AEC8 46CB 698F A1F0 F8D4 
> > EED4
> >  Ramiro Polla  7859 C65B 751B 1179 792E DAE8 8E95 8B2F 9B6C 
> > 5700
> >  Reimar Doeffinger C61D 16E5 9E2C D10C 8958 38A4 0899 A2B9 06D4 
> > D9C7
> >  Reinhard Tartler  9300 5DC2 7E87 6C37 ED7B CA9A 9808 3544 9453 
> > 48A4
> >
>
> That list is for those with push access. Are you sure you want that?

You make it sound unpleasant :)

In all seriousness, my objective is being responsive to issues filed
against the IMF demuxer.

I am happy to set aside the time to be a maintainer if it helps
achieve that objective.

I am also happy to not be a maintainer if it will not help.

> We don't have strict requirements for that, but you're just past
> the #commits to get a vote on TC questions.
> Reviewing patches takes a while, but that's just how it is when
> they're of little interest to most.

Yes.

Isn't this particularly true when there is no maintainer for that
module -- as is currently the case for the IMF demuxer?

On a related note, I would think that review of narrow bug fixes like
[1] would require relatively less time than, say, the addition of an
imf muxer.

[1] https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=7416

In any case thanks for your help/input since the beginning of my
involvement with the codebase.

> ___
> 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] MAINTAINERS: add maintainer for the imf demuxer

2022-09-15 Thread Lynne
Sep 16, 2022, 00:46 by p...@sandflow.com:

> From: Pierre-Anthony Lemieux 
>
> ---
>  MAINTAINERS | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ed2ec0b90c..2d37f0b86a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -436,6 +436,7 @@ Muxers/Demuxers:
>  idcin.c   Mike Melanson
>  idroqdec.cMike Melanson
>  iff.c Jaikrishnan Menon
> +  imf*  Pierre-Anthony Lemieux
>  img2*.c   Michael Niedermayer
>  ipmovie.c Mike Melanson
>  ircam*Paul B Mahol
> @@ -633,6 +634,7 @@ Nikolay Aleksandrov   8978 1D8C FB71 588E 4B27 
> EAA8 C4F0 B5FC E011 13B1
>  Panagiotis Issaris6571 13A3 33D9 3726 F728 AA98 F643 B12E ECF3 
> E029
>  Peter RossA907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 
> DD6B
>  Philip Langdale   5DC5 8D66 5FBA 3A43 18EC 045E F8D6 B194 6A75 
> 682E
> +Pierre-Anthony Lemieux (pal)  F4B3 9492 E6F2 E4AF AEC8 46CB 698F A1F0 F8D4 
> EED4
>  Ramiro Polla  7859 C65B 751B 1179 792E DAE8 8E95 8B2F 9B6C 
> 5700
>  Reimar Doeffinger C61D 16E5 9E2C D10C 8958 38A4 0899 A2B9 06D4 
> D9C7
>  Reinhard Tartler  9300 5DC2 7E87 6C37 ED7B CA9A 9808 3544 9453 
> 48A4
>

That list is for those with push access. Are you sure you want that?
We don't have strict requirements for that, but you're just past
the #commits to get a vote on TC questions.
Reviewing patches takes a while, but that's just how it is when
they're of little interest to most.
___
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] MAINTAINERS: add maintainer for the imf demuxer

2022-09-15 Thread pal
From: Pierre-Anthony Lemieux 

---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ed2ec0b90c..2d37f0b86a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -436,6 +436,7 @@ Muxers/Demuxers:
   idcin.c   Mike Melanson
   idroqdec.cMike Melanson
   iff.c Jaikrishnan Menon
+  imf*  Pierre-Anthony Lemieux
   img2*.c   Michael Niedermayer
   ipmovie.c Mike Melanson
   ircam*Paul B Mahol
@@ -633,6 +634,7 @@ Nikolay Aleksandrov   8978 1D8C FB71 588E 4B27 EAA8 
C4F0 B5FC E011 13B1
 Panagiotis Issaris6571 13A3 33D9 3726 F728 AA98 F643 B12E ECF3 E029
 Peter RossA907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B
 Philip Langdale   5DC5 8D66 5FBA 3A43 18EC 045E F8D6 B194 6A75 682E
+Pierre-Anthony Lemieux (pal)  F4B3 9492 E6F2 E4AF AEC8 46CB 698F A1F0 F8D4 EED4
 Ramiro Polla  7859 C65B 751B 1179 792E DAE8 8E95 8B2F 9B6C 5700
 Reimar Doeffinger C61D 16E5 9E2C D10C 8958 38A4 0899 A2B9 06D4 D9C7
 Reinhard Tartler  9300 5DC2 7E87 6C37 ED7B CA9A 9808 3544 9453 48A4
-- 
2.25.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/x86/Makefile: Don't build empty files

2022-09-15 Thread Andreas Rheinhardt
Carl Eugen Hoyos:
> Am Mo., 12. Sept. 2022 um 17:04 Uhr schrieb Andreas Rheinhardt
> :
>>
>> Should fix ticket #9909, fixing a regression since
>> bfb28b5ce89f3e950214b67ea95b45e3355c2caf.
>>
>> Thanks to Carl Eugen Hoyos for analyzing the issue.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> This would be my solution. What do you think of it?
> 
> No objection but I do not consider this patch cleaner.
> 
> Thank you, Carl Eugen

Then please apply yours.

- 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] [PATCH] avcodec/x86/Makefile: Don't build empty files

2022-09-15 Thread Carl Eugen Hoyos
Am Mo., 12. Sept. 2022 um 17:04 Uhr schrieb Andreas Rheinhardt
:
>
> Should fix ticket #9909, fixing a regression since
> bfb28b5ce89f3e950214b67ea95b45e3355c2caf.
>
> Thanks to Carl Eugen Hoyos for analyzing the issue.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
> This would be my solution. What do you think of it?

No objection but I do not consider this patch cleaner.

Thank you, Carl Eugen
___
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: lavu/pixdesc: favour formats where depth and subsampling exactly match

2022-09-15 Thread Michael Niedermayer
On Wed, Sep 14, 2022 at 04:20:02PM -0700, Philip Langdale wrote:
> Since introducing the various packed formats used by VAAPI (and p012),
> we've noticed that there's actually a gap in how
> av_find_best_pix_fmt_of_2 works. It doesn't actually assign any value
> to having the same bit depth as the source format, when comparing
> against formats with a higher bit depth. This usually doesn't matter,
> because av_get_padded_bits_per_pixel() will account for it.
> 
> However, as many of these formats use padding internally, we find that
> av_get_padded_bits_per_pixel() actually returns the same value for the
> 10 bit, 12 bit, 16 bit flavours, etc. In these tied situations, we end
> up just picking the first of the two provided formats, even if the
> second one should be preferred because it matches the actual bit depth.
> 
> This bug already existed if you tried to compare yuv420p10 against p016
> and p010, for example, but it simply hadn't come up before so we never
> noticed.
> 
> But now, we actually got a situation in the VAAPI VP9 decoder where it
> offers both p010 and p012 because Profile 3 could be either depth and
> ends up picking p012 for 10 bit content due to the ordering of the
> testing.
> 
> In addition, in the process of testing the fix, I realised we have the
> same gap when it comes to chroma subsampling - we do not favour a
> format that has exactly the same subsampling vs one with less
> subsampling when all else is equal.
> 
> To fix this, I'm introducing a small score penalty if the bit depth or
> subsampling doesn't exactly match the source format. This will break
> the tie in favour of the format with the exact match, but not offset
> any of the other scoring penalties we already have.
> 
> I have added a set of tests around these formats which will fail
> without this fix.
> 
> v2: Rework penalty system to scale penalty based on how different the
> two formats are, and add new loss categories for them.
> 
> v3: Remove leftover bits of v1.
> Remove bit depth penalty scaling to avoid the value being too large
> in extreme cases (1 bit vs 16 bit).
> 
> Signed-off-by: Philip Langdale 
> ---
>  libavutil/pixdesc.c   |  31 +-
>  libavutil/pixdesc.h   |  15 +++--
>  libavutil/tests/pixfmt_best.c | 111 --
>  tests/ref/fate/pixfmt_best|   2 +-
>  4 files changed, 132 insertions(+), 27 deletions(-)
> 
> diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> index d7c6ebfdc4..6377224c64 100644
> --- a/libavutil/pixdesc.c
> +++ b/libavutil/pixdesc.c
> @@ -3013,9 +3013,16 @@ static int get_pix_fmt_score(enum AVPixelFormat 
> dst_pix_fmt,
>  
>  for (i = 0; i < nb_components; i++) {
>  int depth_minus1 = (dst_pix_fmt == AV_PIX_FMT_PAL8) ? 
> 7/nb_components : (dst_desc->comp[i].depth - 1);
> -if (src_desc->comp[i].depth - 1 > depth_minus1 && (consider & 
> FF_LOSS_DEPTH)) {
> +int depth_delta = src_desc->comp[i].depth - 1 - depth_minus1;
> +if (depth_delta > 0 && (consider & FF_LOSS_DEPTH)) {
>  loss |= FF_LOSS_DEPTH;
>  score -= 65536 >> depth_minus1;
> +} else if (depth_delta < 0 && (consider & FF_LOSS_EXCESS_DEPTH)) {
> +// Favour formats where bit depth exactly matches. If all other
> +// scoring is equal, we'd rather use the bit depth that most 
> closely
> +// matches the source.
> +loss |= FF_LOSS_EXCESS_DEPTH;
> +score += depth_delta;
>  }
>  }
>  
> @@ -3035,6 +3042,28 @@ static int get_pix_fmt_score(enum AVPixelFormat 
> dst_pix_fmt,
>  }
>  }
>  
> +if (consider & FF_LOSS_EXCESS_RESOLUTION) {
> +// Favour formats where chroma subsampling exactly matches. If all 
> other
> +// scoring is equal, we'd rather use the subsampling that most 
> closely
> +// matches the source.
> +if (dst_desc->log2_chroma_w < src_desc->log2_chroma_w) {
> +loss |= FF_LOSS_EXCESS_RESOLUTION;
> +score -= 32 << (src_desc->log2_chroma_w - 
> dst_desc->log2_chroma_w);
> +}
> +
> +if (dst_desc->log2_chroma_h < src_desc->log2_chroma_h) {
> +loss |= FF_LOSS_EXCESS_RESOLUTION;
> +score -= 32 << (src_desc->log2_chroma_h - 
> dst_desc->log2_chroma_h);
> +}

with 16bit 4:2:0 
to
14bit 4:2:0
vs.
16bit 4:4:4

more data is preserved in the later but the 420->444 would have a loss of 64
i think and 16->14 i think 8. I didnt try this just reading the code so i may
be missing something but i think the code would favor the lower bitdepth
That may be unexpected

thx


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing 

Re: [FFmpeg-devel] [PATCH v5 3/3] fate/flac: Add test of 32 bps encoding/decoding

2022-09-15 Thread Martijn van Beurden
Op do 15 sep. 2022 om 20:20 schreef Andreas Rheinhardt <
andreas.rheinha...@outlook.com>:

> (In any case, I don't get why there are two samples: The flac decoder is
> intra-only, so if you made the samples so that one of the frames had a
> wasted bit, you could test all the codepaths that two samples test. And
> it would even have the advantage that it tests what happens when it
> swiches from >0 wasted bits to 0 wasted bits to >0 wasted bits and back.)
>

It seemed easier for anyone triggering a problem with wasted bits to figure
where the problem came from. A problem in the second file but not in the
first is quite certain to be related to the wasted bits handling. But
perhaps the probability of this happening is so low that it is not worth
increasing the size of the fate sample collection. I'll create a new file
and ask for a replacement.
___
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/13] avcodec/dolby_e_parser: Remove unnecessary headers

2022-09-15 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Possible since 81d070dd09ce154d635414fd07d80a591266b421.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/dolby_e_parser.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/libavcodec/dolby_e_parser.c b/libavcodec/dolby_e_parser.c
> index 9f54627356..d2566e5446 100644
> --- a/libavcodec/dolby_e_parser.c
> +++ b/libavcodec/dolby_e_parser.c
> @@ -21,8 +21,6 @@
>  #include "libavutil/channel_layout.h"
>  #include "avcodec.h"
>  #include "dolby_e.h"
> -#include "get_bits.h"
> -#include "put_bits.h"
>  
>  typedef struct DBEParseContext {
>  DBEContext dectx;

Will apply this patchset 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".


[FFmpeg-devel] [PATCH 9/9] avcodec/aptxenc: Process data in complete blocks of four samples only

2022-09-15 Thread Andreas Rheinhardt
Do this by setting AVCodecInternal.pad_samples.
This prevents reading into the frame's padding and writing
into the packet's padding.

This actually happened in our FATE tests (where the number of samples
is 2 mod 4), which therefore needed to be updated.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/aptxenc.c   | 6 --
 tests/ref/fate/aptx| 4 ++--
 tests/ref/fate/aptx-hd | 4 ++--
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/libavcodec/aptxenc.c b/libavcodec/aptxenc.c
index 434a9abf0f..114e286fe2 100644
--- a/libavcodec/aptxenc.c
+++ b/libavcodec/aptxenc.c
@@ -27,6 +27,7 @@
 #include "audio_frame_queue.h"
 #include "codec_internal.h"
 #include "encode.h"
+#include "internal.h"
 
 typedef struct AptXEncContext {
 AptXContext common;
@@ -259,6 +260,7 @@ static av_cold int aptx_encode_init(AVCodecContext *avctx)
 
 if (!avctx->frame_size || avctx->frame_size % 4)
 avctx->frame_size = 1024;
+avctx->internal->pad_samples = 4;
 
 return ff_aptx_init(avctx);
 }
@@ -269,7 +271,7 @@ const FFCodec ff_aptx_encoder = {
 CODEC_LONG_NAME("aptX (Audio Processing Technology for Bluetooth)"),
 .p.type= AVMEDIA_TYPE_AUDIO,
 .p.id  = AV_CODEC_ID_APTX,
-.p.capabilities= AV_CODEC_CAP_DR1 | AV_CODEC_CAP_SMALL_LAST_FRAME,
+.p.capabilities= AV_CODEC_CAP_DR1,
 .priv_data_size= sizeof(AptXEncContext),
 .init  = aptx_encode_init,
 FF_CODEC_ENCODE_CB(aptx_encode_frame),
@@ -290,7 +292,7 @@ const FFCodec ff_aptx_hd_encoder = {
 CODEC_LONG_NAME("aptX HD (Audio Processing Technology for Bluetooth)"),
 .p.type= AVMEDIA_TYPE_AUDIO,
 .p.id  = AV_CODEC_ID_APTX_HD,
-.p.capabilities= AV_CODEC_CAP_DR1 | AV_CODEC_CAP_SMALL_LAST_FRAME,
+.p.capabilities= AV_CODEC_CAP_DR1,
 .priv_data_size= sizeof(AptXEncContext),
 .init  = aptx_encode_init,
 FF_CODEC_ENCODE_CB(aptx_encode_frame),
diff --git a/tests/ref/fate/aptx b/tests/ref/fate/aptx
index 4d20b7df9a..7917399297 100644
--- a/tests/ref/fate/aptx
+++ b/tests/ref/fate/aptx
@@ -1,5 +1,5 @@
-b5d8a297c0e8d9854f19d9d3e8b82859 *tests/data/fate/aptx.aptx
-418950 tests/data/fate/aptx.aptx
+97dfd7f32d34fb74337c0f6c66e26e2d *tests/data/fate/aptx.aptx
+418952 tests/data/fate/aptx.aptx
 #tb 0: 1/44100
 #media_type 0: audio
 #codec_id 0: pcm_s16le
diff --git a/tests/ref/fate/aptx-hd b/tests/ref/fate/aptx-hd
index 498b9131a6..d74c1059c2 100644
--- a/tests/ref/fate/aptx-hd
+++ b/tests/ref/fate/aptx-hd
@@ -1,5 +1,5 @@
-48ecaa81ee5adaaa62ed3ff6574b *tests/data/fate/aptx-hd.aptx_hd
-628425 tests/data/fate/aptx-hd.aptx_hd
+6126e414af1acb193e24fdf33c7cac2e *tests/data/fate/aptx-hd.aptx_hd
+628428 tests/data/fate/aptx-hd.aptx_hd
 #tb 0: 1/44100
 #media_type 0: audio
 #codec_id 0: pcm_s32le
-- 
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 8/9] avcodec/encode: Enable encoders to control padding of last frame

2022-09-15 Thread Andreas Rheinhardt
Some audio codecs work with atomic units that decode to a fixed
number of audio samples with this number being so small that it is
common to put multiple of these atoms into one packet. In these
cases it makes no sense to pad the last frame to the big frame_size,
so allow encoders to set the number of samples that they want
the last frame to be padded to instead.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/encode.c   | 17 +++--
 libavcodec/internal.h |  6 ++
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 9bd9f9bc08..049b71c6f4 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -127,12 +127,12 @@ static int encode_make_refcounted(AVCodecContext *avctx, 
AVPacket *avpkt)
 /**
  * Pad last frame with silence.
  */
-static int pad_last_frame(AVCodecContext *s, AVFrame *frame, const AVFrame 
*src)
+static int pad_last_frame(AVCodecContext *s, AVFrame *frame, const AVFrame 
*src, int out_samples)
 {
 int ret;
 
 frame->format = src->format;
-frame->nb_samples = s->frame_size;
+frame->nb_samples = out_samples;
 ret = av_channel_layout_copy(>ch_layout, >ch_layout);
 if (ret < 0)
 goto fail;
@@ -406,10 +406,15 @@ static int encode_send_frame_internal(AVCodecContext 
*avctx, const AVFrame *src)
 if (src->nb_samples < avctx->frame_size) {
 avctx->internal->last_audio_frame = 1;
 if (!(avctx->codec->capabilities & 
AV_CODEC_CAP_SMALL_LAST_FRAME)) {
-ret = pad_last_frame(avctx, dst, src);
-if (ret < 0)
-return ret;
-goto finish;
+int pad_samples = avci->pad_samples ? avci->pad_samples : 
avctx->frame_size;
+int out_samples = (src->nb_samples + pad_samples - 1) / 
pad_samples * pad_samples;
+
+if (out_samples != src->nb_samples) {
+ret = pad_last_frame(avctx, dst, src, out_samples);
+if (ret < 0)
+return ret;
+goto finish;
+}
 }
 }
 }
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 45aec38a60..76a6ea6bc6 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -62,6 +62,12 @@ typedef struct AVCodecInternal {
  */
 int last_audio_frame;
 
+/**
+ * Audio encoders can set this flag during init to indicate that they
+ * want the small last frame to be padded to a multiple of pad_samples.
+ */
+int pad_samples;
+
 AVBufferRef *pool;
 
 void *thread_ctx;
-- 
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 7/9] avcodec/encode: Redo checks for small last audio frame

2022-09-15 Thread Andreas Rheinhardt
In particular, check that there is only one small last frame
in case the encoder has the AV_CODEC_CAP_SMALL_LAST_FRAME set.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/encode.c   | 21 +
 libavcodec/internal.h |  4 ++--
 2 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index ade4d458e7..9bd9f9bc08 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -157,6 +157,7 @@ static int pad_last_frame(AVCodecContext *s, AVFrame 
*frame, const AVFrame *src)
 
 fail:
 av_frame_unref(frame);
+s->internal->last_audio_frame = 0;
 return ret;
 }
 
@@ -392,28 +393,24 @@ static int encode_send_frame_internal(AVCodecContext 
*avctx, const AVFrame *src)
 avctx->audio_service_type = *(enum AVAudioServiceType*)sd->data;
 
 /* check for valid frame size */
-if (avctx->codec->capabilities & AV_CODEC_CAP_SMALL_LAST_FRAME) {
-if (src->nb_samples > avctx->frame_size) {
-av_log(avctx, AV_LOG_ERROR, "more samples than frame size\n");
-return AVERROR(EINVAL);
-}
-} else if (!(avctx->codec->capabilities & 
AV_CODEC_CAP_VARIABLE_FRAME_SIZE)) {
+if (!(avctx->codec->capabilities & AV_CODEC_CAP_VARIABLE_FRAME_SIZE)) {
 /* if we already got an undersized frame, that must have been the 
last */
 if (avctx->internal->last_audio_frame) {
 av_log(avctx, AV_LOG_ERROR, "frame_size (%d) was not respected 
for a non-last frame\n", avctx->frame_size);
 return AVERROR(EINVAL);
 }
-
+if (src->nb_samples > avctx->frame_size) {
+av_log(avctx, AV_LOG_ERROR, "nb_samples (%d) > frame_size 
(%d)\n", src->nb_samples, avctx->frame_size);
+return AVERROR(EINVAL);
+}
 if (src->nb_samples < avctx->frame_size) {
+avctx->internal->last_audio_frame = 1;
+if (!(avctx->codec->capabilities & 
AV_CODEC_CAP_SMALL_LAST_FRAME)) {
 ret = pad_last_frame(avctx, dst, src);
 if (ret < 0)
 return ret;
-
-avctx->internal->last_audio_frame = 1;
 goto finish;
-} else if (src->nb_samples > avctx->frame_size) {
-av_log(avctx, AV_LOG_ERROR, "nb_samples (%d) != frame_size 
(%d)\n", src->nb_samples, avctx->frame_size);
-return AVERROR(EINVAL);
+}
 }
 }
 }
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 35e3dd303a..45aec38a60 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -57,8 +57,8 @@ typedef struct AVCodecInternal {
 int is_copy;
 
 /**
- * An audio frame with less than required samples has been submitted and
- * padded with silence. Reject all subsequent frames.
+ * An audio frame with less than required samples has been submitted (and
+ * potentially padded with silence). Reject all subsequent frames.
  */
 int last_audio_frame;
 
-- 
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 6/9] avcodec/aptxdec: Process data in complete blocks only

2022-09-15 Thread Andreas Rheinhardt
The APTX (HD) decoder decodes blocks of four (six) bytes to four
output samples. It makes no sense to handle incomplete blocks:
They would just lead to synchronization errors, in which case
the complete frame is discarded. So only handle complete blocks.
This also avoids reading from the packet's padding and writing
into the frame's padding.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/aptxdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/aptxdec.c b/libavcodec/aptxdec.c
index 878c9ffe1b..d254b3026b 100644
--- a/libavcodec/aptxdec.c
+++ b/libavcodec/aptxdec.c
@@ -151,7 +151,7 @@ static int aptx_decode_frame(AVCodecContext *avctx, AVFrame 
*frame,
 /* get output buffer */
 frame->ch_layout.nb_channels = NB_CHANNELS;
 frame->format = AV_SAMPLE_FMT_S32P;
-frame->nb_samples = 4 * avpkt->size / s->block_size;
+frame->nb_samples = 4 * (avpkt->size / s->block_size);
 if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
 return ret;
 
-- 
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 5/9] avformat/aptxdec: Don't set AV_PKT_FLAG_CORRUPT mistakenly

2022-09-15 Thread Andreas Rheinhardt
Just because we try to put multiple units of block_align bytes
(the atomic units for APTX and APTX HD) into one packet
does not mean that packets with fewer units than the
one we wanted are corrupt; only those packets that are not
a multiple of block_align are.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/aptxdec.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/libavformat/aptxdec.c b/libavformat/aptxdec.c
index aa86bfe330..0637a8afde 100644
--- a/libavformat/aptxdec.c
+++ b/libavformat/aptxdec.c
@@ -74,12 +74,18 @@ static int aptx_hd_read_header(AVFormatContext *s)
 
 static int aptx_read_packet(AVFormatContext *s, AVPacket *pkt)
 {
-return av_get_packet(s->pb, pkt, APTX_PACKET_SIZE);
+int ret = av_get_packet(s->pb, pkt, APTX_PACKET_SIZE);
+if (ret >= 0 && !(ret % APTX_BLOCK_SIZE))
+pkt->flags &= ~AV_PKT_FLAG_CORRUPT;
+return ret >= 0 ? 0 : ret;
 }
 
 static int aptx_hd_read_packet(AVFormatContext *s, AVPacket *pkt)
 {
-return av_get_packet(s->pb, pkt, APTX_HD_PACKET_SIZE);
+int ret = av_get_packet(s->pb, pkt, APTX_HD_PACKET_SIZE);
+if (ret >= 0 && !(ret % APTX_HD_BLOCK_SIZE))
+pkt->flags &= ~AV_PKT_FLAG_CORRUPT;
+return ret >= 0 ? 0 : ret;
 }
 
 static const AVOption aptx_options[] = {
-- 
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 4/9] avformat/aptxdec: Don't set AVCodecParameters.frame_size

2022-09-15 Thread Andreas Rheinhardt
This field was misunderstood: It gives the number of samples
in a packet, not the number of bytes. Its usage was wrong for APTX HD.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/aptxdec.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavformat/aptxdec.c b/libavformat/aptxdec.c
index 693316eeb0..aa86bfe330 100644
--- a/libavformat/aptxdec.c
+++ b/libavformat/aptxdec.c
@@ -58,7 +58,6 @@ static int aptx_read_header(AVFormatContext *s)
 st->codecpar->codec_id = AV_CODEC_ID_APTX;
 st->codecpar->bits_per_coded_sample = 4;
 st->codecpar->block_align = APTX_BLOCK_SIZE;
-st->codecpar->frame_size = APTX_PACKET_SIZE;
 return 0;
 }
 
@@ -70,7 +69,6 @@ static int aptx_hd_read_header(AVFormatContext *s)
 st->codecpar->codec_id = AV_CODEC_ID_APTX_HD;
 st->codecpar->bits_per_coded_sample = 6;
 st->codecpar->block_align = APTX_HD_BLOCK_SIZE;
-st->codecpar->frame_size = APTX_HD_PACKET_SIZE;
 return 0;
 }
 
-- 
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 3/9] avcodec/aptx: Use AVCodecContext.frame_size according to the API

2022-09-15 Thread Andreas Rheinhardt
Currently the APTX (HD) codecs set frame_size if unset and check
whether it is divisible by block_size (corresponding to block_align
as used by other codecs). But this is based upon a misunderstanding
of the API: frame_size is not in bytes, but in samples.

Said value is also not intended to be set by the user at all,
but set by encoders and (possibly) decoders if the number of channels
in a frame is constant. The latter condition is not fulfilled here,
so only set it for encoders. Given that the encoder can handle any
number of samples as long as it is divisible by four and given that
it worked to set a custom frame size before, the encoders accept
any multiple of four; otherwise the value is set to the value
that it already had for APTX: 1024 samples (per channel).

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/aptx.c| 9 -
 libavcodec/aptxenc.c | 3 +++
 2 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/libavcodec/aptx.c b/libavcodec/aptx.c
index 8e110acc97..ed814ad1c0 100644
--- a/libavcodec/aptx.c
+++ b/libavcodec/aptx.c
@@ -516,15 +516,6 @@ av_cold int ff_aptx_init(AVCodecContext *avctx)
 s->hd = avctx->codec->id == AV_CODEC_ID_APTX_HD;
 s->block_size = s->hd ? 6 : 4;
 
-if (avctx->frame_size == 0)
-avctx->frame_size = 256 * s->block_size;
-
-if (avctx->frame_size % s->block_size) {
-av_log(avctx, AV_LOG_ERROR,
-   "Frame size must be a multiple of %d samples\n", s->block_size);
-return AVERROR(EINVAL);
-}
-
 for (chan = 0; chan < NB_CHANNELS; chan++) {
 Channel *channel = >channels[chan];
 for (subband = 0; subband < NB_SUBBANDS; subband++) {
diff --git a/libavcodec/aptxenc.c b/libavcodec/aptxenc.c
index f9347853d2..434a9abf0f 100644
--- a/libavcodec/aptxenc.c
+++ b/libavcodec/aptxenc.c
@@ -257,6 +257,9 @@ static av_cold int aptx_encode_init(AVCodecContext *avctx)
 
 ff_af_queue_init(avctx, >afq);
 
+if (!avctx->frame_size || avctx->frame_size % 4)
+avctx->frame_size = 1024;
+
 return ff_aptx_init(avctx);
 }
 
-- 
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 2/9] avcodec/utils: Support APTX (HD) in av_get_audio_frame_duration()

2022-09-15 Thread Andreas Rheinhardt
APTX decodes four bytes of input to four stereo samples; APTX HD
does the same with six bytes of input. So it can be easily supported
in av_get_audio_frame_duration().

This fixes invalid durations and (derived) timestamps of demuxed
APTX HD packets and therefore fixed the timestamp in the aptx-hd
FATE test.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/utils.c |  4 
 tests/ref/fate/aptx-hd | 17 ++---
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 2f57418ff7..ba64aaf32d 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -682,6 +682,10 @@ static int get_audio_frame_duration(enum AVCodecID id, int 
sr, int ch, int ba,
 return 256 * (frame_bytes / 64);
 if (id == AV_CODEC_ID_RA_144)
 return 160 * (frame_bytes / 20);
+if (id == AV_CODEC_ID_APTX)
+return 4 * (frame_bytes / 4);
+if (id == AV_CODEC_ID_APTX_HD)
+return 4 * (frame_bytes / 6);
 
 if (bps > 0) {
 /* calc from frame_bytes and bits_per_coded_sample */
diff --git a/tests/ref/fate/aptx-hd b/tests/ref/fate/aptx-hd
index 0691f33c86..498b9131a6 100644
--- a/tests/ref/fate/aptx-hd
+++ b/tests/ref/fate/aptx-hd
@@ -6,10 +6,13 @@
 #sample_rate 0: 44100
 #channel_layout_name 0: 2 channels
 0,  0,  0, 1024, 8192, 0xa99888c6
-0,   1536,   1536, 1024, 8192, 0xc3e03a3c
-0,   3072,   3072, 1024, 8192, 0x3f06e090
-0,   4608,   4608, 1024, 8192, 0x92fb18f3
-0,   6144,   6144, 1024, 8192, 0x3d5603a2
-0,   7680,   7680, 1024, 8192, 0xcc3d3101
-0,   9216,   9216, 1024, 8192, 0xbcc022ef
-0,  10752,  10752,  273, 2184, 0x9873af57
+0,   1024,   1024, 1024, 8192, 0xc3e03a3c
+0,   2048,   2048, 1024, 8192, 0x3f06e090
+0,   3072,   3072, 1024, 8192, 0x92fb18f3
+0,   4096,   4096, 1024, 8192, 0x3d5603a2
+0,   5120,   5120, 1024, 8192, 0xcc3d3101
+0,   6144,   6144, 1024, 8192, 0xbcc022ef
+0,   7168,   7168, 1024, 8192, 0x600cbb73
+0,   8192,   8192, 1024, 8192, 0xdc938cbb
+0,   9216,   9216, 1024, 8192, 0x37d968bc
+0,  10240,  10240,  785, 6280, 0x48243144
-- 
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 1/9] fate/audio: Add tests for APTX (HD)

2022-09-15 Thread Andreas Rheinhardt
We have de- and encoders for APTX and APTX HD, yet not FATE tests.
This commit therefore adds a transcoding test to utilize them.

Furthermore, during creating these tests it turned out that
the duration is set incorrectly for APTX HD. This will be fixed
in a future commit.

(Thanks to Andriy Gelman for finding an issue in an earlier version
that used a 192kHz input sample which does not work reliably accross
platforms.)

Signed-off-by: Andreas Rheinhardt 
---
 tests/fate/audio.mak   |  7 +++
 tests/ref/fate/aptx| 18 ++
 tests/ref/fate/aptx-hd | 15 +++
 3 files changed, 40 insertions(+)
 create mode 100644 tests/ref/fate/aptx
 create mode 100644 tests/ref/fate/aptx-hd

diff --git a/tests/fate/audio.mak b/tests/fate/audio.mak
index fd9905ca0a..9d39eeace3 100644
--- a/tests/fate/audio.mak
+++ b/tests/fate/audio.mak
@@ -1,3 +1,10 @@
+FATE_SAMPLES_AUDIO-$(call TRANSCODE, APTX, APTX, WAV_DEMUXER PCM_S16LE_DECODER 
ARESAMPLE_FILTER) += fate-aptx
+fate-aptx: CMD = transcode wav 
$(TARGET_SAMPLES)/audio-reference/luckynight_2ch_44kHz_s16.wav aptx "-af 
aresample -c aptx" "-af aresample -c:a pcm_s16le -t 0.25" "" "" "-f aptx 
-sample_rate 44100"
+
+FATE_SAMPLES_AUDIO-$(call TRANSCODE, APTX_HD, APTX_HD, WAV_DEMUXER 
PCM_S16LE_DECODER \
+  ARESAMPLE_FILTER PCM_S32LE_ENCODER) += fate-aptx-hd
+fate-aptx-hd: CMD = transcode wav 
$(TARGET_SAMPLES)/audio-reference/luckynight_2ch_44kHz_s16.wav aptx_hd "-af 
aresample -c aptx_hd" "-af aresample -c:a pcm_s32le -t 0.25" "" "" "-f aptx_hd 
-sample_rate 44100"
+
 FATE_BINKAUDIO-$(call DEMDEC, BINK, BINKAUDIO_DCT) += fate-binkaudio-dct
 fate-binkaudio-dct: CMD = pcm -i $(TARGET_SAMPLES)/bink/binkaudio_dct.bik
 fate-binkaudio-dct: REF = $(SAMPLES)/bink/binkaudio_dct.pcm
diff --git a/tests/ref/fate/aptx b/tests/ref/fate/aptx
new file mode 100644
index 00..4d20b7df9a
--- /dev/null
+++ b/tests/ref/fate/aptx
@@ -0,0 +1,18 @@
+b5d8a297c0e8d9854f19d9d3e8b82859 *tests/data/fate/aptx.aptx
+418950 tests/data/fate/aptx.aptx
+#tb 0: 1/44100
+#media_type 0: audio
+#codec_id 0: pcm_s16le
+#sample_rate 0: 44100
+#channel_layout_name 0: 2 channels
+0,  0,  0, 1024, 4096, 0xcbb4ceff
+0,   1024,   1024, 1024, 4096, 0xa66533e7
+0,   2048,   2048, 1024, 4096, 0x4f22ec39
+0,   3072,   3072, 1024, 4096, 0x45f117f9
+0,   4096,   4096, 1024, 4096, 0xad6c0b7a
+0,   5120,   5120, 1024, 4096, 0x611618fd
+0,   6144,   6144, 1024, 4096, 0x0ec02f2b
+0,   7168,   7168, 1024, 4096, 0x2cf9ae5c
+0,   8192,   8192, 1024, 4096, 0xfb008ac0
+0,   9216,   9216, 1024, 4096, 0x25068495
+0,  10240,  10240,  785, 3140, 0x5a260589
diff --git a/tests/ref/fate/aptx-hd b/tests/ref/fate/aptx-hd
new file mode 100644
index 00..0691f33c86
--- /dev/null
+++ b/tests/ref/fate/aptx-hd
@@ -0,0 +1,15 @@
+48ecaa81ee5adaaa62ed3ff6574b *tests/data/fate/aptx-hd.aptx_hd
+628425 tests/data/fate/aptx-hd.aptx_hd
+#tb 0: 1/44100
+#media_type 0: audio
+#codec_id 0: pcm_s32le
+#sample_rate 0: 44100
+#channel_layout_name 0: 2 channels
+0,  0,  0, 1024, 8192, 0xa99888c6
+0,   1536,   1536, 1024, 8192, 0xc3e03a3c
+0,   3072,   3072, 1024, 8192, 0x3f06e090
+0,   4608,   4608, 1024, 8192, 0x92fb18f3
+0,   6144,   6144, 1024, 8192, 0x3d5603a2
+0,   7680,   7680, 1024, 8192, 0xcc3d3101
+0,   9216,   9216, 1024, 8192, 0xbcc022ef
+0,  10752,  10752,  273, 2184, 0x9873af57
-- 
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 1/2] lavc/videotoolbox: do not pass AVCodecContext to decoder output callback

2022-09-15 Thread Thilo Borgmann

Am 15.09.22 um 15:56 schrieb Anton Khirnov:

The opaque parameter for the callback is set in videotoolbox_start(),
called when the hwaccel is initialized. When frame threading is used,
avctx will be the context corresponding to the frame thread currently
doing the decoding. Using this same codec context in all subsequent
invocations of the decoder callback (even those triggered by a different
frame thread) is unsafe, and broken after
cc867f2c09d2b69cee8a0eccd62aff002cbbfe11, since each frame thread now
cleans up its hwaccel state after decoding each frame.

Fix this by passing hwaccel_priv_data as the opaque parameter, which
exists in a single instance forwarded between all frame threads.

The only other use of AVCodecContext in the decoder output callback is
as a logging context. For this purpose, store a logging context in
hwaccel_priv_data.
---
Initial version of this patch tested by Marvin on IRC.
Someone please test this final version, as I don't have the HW to do it
myself.
---
  libavcodec/videotoolbox.c | 10 ++
  libavcodec/vt_internal.h  |  2 ++
  2 files changed, 8 insertions(+), 4 deletions(-)


Confirmed, fixes the crash for me as well!

Thx,
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".


[FFmpeg-devel] [PATCH] lavc/videotoolboxenc: Fix crash by uninitialized value

2022-09-15 Thread Thilo Borgmann
If create_cv_pixel_buffer() fails, pixel_buffer_info might get into CFRelease() 
containing an arbitrary value.
---
 libavcodec/videotoolboxenc.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index bb3065d1d5..dc9e321d3d 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -1440,7 +1440,7 @@ static int vtenc_create_encoder(AVCodecContext   *avctx,
 static int vtenc_configure_encoder(AVCodecContext *avctx)
 {
 CFMutableDictionaryRef enc_info;
-CFMutableDictionaryRef pixel_buffer_info;
+CFMutableDictionaryRef pixel_buffer_info = NULL;
 CMVideoCodecType   codec_type;
 VTEncContext   *vtctx = avctx->priv_data;
 CFStringRefprofile_level = NULL;
@@ -1517,8 +1517,6 @@ static int vtenc_configure_encoder(AVCodecContext *avctx)
 status = create_cv_pixel_buffer_info(avctx, _buffer_info);
 if (status)
 goto init_cleanup;
-} else {
-pixel_buffer_info = NULL;
 }
 
 vtctx->dts_delta = vtctx->has_b_frames ? -1 : 0;
-- 
2.20.1 (Apple Git-117)

___
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] lavu/riscv: fix off-by-one in bit-magnitude clip

2022-09-15 Thread remi
From: Rémi Denis-Courmont 

---
 libavutil/riscv/intmath.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavutil/riscv/intmath.h b/libavutil/riscv/intmath.h
index 3263a79dc4..45bce9a0e7 100644
--- a/libavutil/riscv/intmath.h
+++ b/libavutil/riscv/intmath.h
@@ -61,8 +61,8 @@ static av_always_inline av_const int32_t 
av_clipl_int32_rvi(int64_t a)
 #define av_clip_intp2 av_clip_intp2_rvi
 static av_always_inline av_const int av_clip_intp2_rvi(int a, int p)
 {
-const int shift = 32 - p;
-int b = (a << shift) >> shift;
+const int shift = 31 - p;
+int b = ((int)(((unsigned)a) << shift)) >> shift;
 
 if (a != b)
 b = (a >> 31) ^ ((1 << p) - 1);
-- 
2.37.2

___
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 v5 3/3] fate/flac: Add test of 32 bps encoding/decoding

2022-09-15 Thread Andreas Rheinhardt
Martijn van Beurden:
> Op do 15 sep. 2022 om 18:58 schreef Andreas Rheinhardt <
> andreas.rheinha...@outlook.com>:
> 
>> Martijn van Beurden:
>>> ---
>>>  tests/fate/flac.mak | 9 +
>>>  1 file changed, 9 insertions(+)
>>>
>>> diff --git a/tests/fate/flac.mak b/tests/fate/flac.mak
>>> index 115cc965e1..4db28b1e1d 100644
>>> --- a/tests/fate/flac.mak
>>> +++ b/tests/fate/flac.mak
>>> @@ -6,6 +6,8 @@ FATE_FLAC += fate-flac-16-chmode-indep
>> \
>>>   fate-flac-16-lpc-cholesky
>> \
>>>   fate-flac-16-lpc-levinson
>> \
>>>   fate-flac-24-comp-8
>> \
>>> + fate-flac-32
>>  \
>>> + fate-flac-32-wasted-bits
>>  \
>>>   fate-flac-rice-params
>> \
>>>
>>>  fate-flac-16-chmode-%: OPTS = -ch_mode $(@:fate-flac-16-chmode-%=%)
>>> @@ -20,6 +22,13 @@ fate-flac-24-comp-%: OPTS = -compression_level
>> $(@:fate-flac-24-comp-%=%)
>>>  fate-flac-24-%: REF =
>> $(SAMPLES)/audio-reference/divertimenti_2ch_96kHz_s24.wav
>>>  fate-flac-24-%: CMD = enc_dec_pcm flac wav s24le $(subst
>> $(SAMPLES),$(TARGET_SAMPLES),$(REF)) -c flac $(OPTS)
>>>
>>> +
>>> +fate-flac-32: REF = $(SAMPLES)/audio-reference/drums_2ch_44kHz_s32.wav
>>> +fate-flac-32: CMD = enc_dec_pcm flac wav s32le $(subst
>> $(SAMPLES),$(TARGET_SAMPLES),$(REF)) -c flac -strict -2
>>
>> We already have 32bit samples in the fate-suite, namely
>> wavpack/lossless/32bit_int_partial.wv. Why don't you use these?
>> (Anyway, don't hardcode the numerical value of 'experimental'.)
>>
> 
> I wasn't sure that was possible. If for example the build is configured to
> leave wavpack out that wouldn't work. Or is it assumed that fate is only
> run with a ffmpeg build configured with default and some additions but
> nothing default left out?
> 

The wavpack decoder would have to be a requirement of this test.
(The wav demuxer is btw needed as a requirement for the current tests,
but has been left out; the pcm_s16le decoder is also needed for the
tests with s16 input samples and the pcm_s24le decoder for the with s24
input samples, but checking for this has been forgotten.)
Notice that the test functions would have to be tweaked  (the flac tests
use CMP = oneoff, i.e. they do not check checksums of the encoded file,
but instead test that the decoded audio data coincides with what has
been sent to the decoder).
(In any case, I don't get why there are two samples: The flac decoder is
intra-only, so if you made the samples so that one of the frames had a
wasted bit, you could test all the codepaths that two samples test. And
it would even have the advantage that it tests what happens when it
swiches from >0 wasted bits to 0 wasted bits to >0 wasted bits and back.)

> Considering the strict value, I guess I should also change the help text
> then? Now it reads: encoding as 24 bits-per-sample, more is considered
> experimental. Add -strict -2 if you want to encode more than 24
> bits-per-sample

Yes, that should also be changed.

- 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] [PATCH] fftools: allow decoders to set AVFrame time_base

2022-09-15 Thread Marton Balint




On Sat, 10 Sep 2022, Leo Izen wrote:


This patch allows decoders to set AVFrame->time_base, which
determines the units that AVFrame->pts will use. Currently
no decoders do this, but it will allow it in the future.


This is patch is wrong, because it implies that decoders can output frames 
in time base different to stream time base. They can't, because that would 
be a breaking change. AVFrame->time_base was not introduced for that use 
case.


Regards,
Marton


---
fftools/ffmpeg.c | 3 ++-
fftools/ffplay.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 0e1477299d..e3ea7a6c29 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2274,7 +2274,8 @@ static int decode_video(InputStream *ist, AVPacket *pkt, 
int *got_output, int64_
}

if(best_effort_timestamp != AV_NOPTS_VALUE) {
-int64_t ts = av_rescale_q(decoded_frame->pts = best_effort_timestamp, 
ist->st->time_base, AV_TIME_BASE_Q);
+int64_t ts = av_rescale_q(decoded_frame->pts = best_effort_timestamp,
+decoded_frame->time_base.num ? decoded_frame->time_base : 
ist->st->time_base, AV_TIME_BASE_Q);

if (ts != AV_NOPTS_VALUE)
ist->next_pts = ist->pts = ts;
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 9242047f5c..986b0831ac 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -1771,7 +1771,7 @@ static int get_video_frame(VideoState *is, AVFrame *frame)
double dpts = NAN;

if (frame->pts != AV_NOPTS_VALUE)
-dpts = av_q2d(is->video_st->time_base) * frame->pts;
+dpts = av_q2d(frame->time_base.num ? frame->time_base : 
is->video_st->time_base) * frame->pts;

frame->sample_aspect_ratio = av_guess_sample_aspect_ratio(is->ic, 
is->video_st, frame);

--
2.37.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


___
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: lavu/pixdesc: favour formats where depth and subsampling exactly match

2022-09-15 Thread Michael Niedermayer
On Wed, Sep 14, 2022 at 03:43:04PM -0700, Philip Langdale wrote:
> On Wed, 14 Sep 2022 23:08:16 +0200
> Michael Niedermayer  wrote:
[...]
> > > +// Favour formats where bit depth exactly matches. If
> > > all other
> > > +// scoring is equal, we'd rather use the bit depth
> > > that most closely
> > > +// matches the source.  
> > 
> > ok
> > 
> > 
> > > +loss |= FF_LOSS_EXCESS_DEPTH;
> > > +score -= 1 << -depth_delta;  
> > 
> > but does that do that ?
> > a 1bpp -> 16bpp has a considerable -depth_delta
> > 
> > do we need the << at all ?
> 
> The idea here is to have the scoring reflect the gap. Are you saying
> you'd just apply the depth_delta as-is (just a small number 1 <= n <=
> 15)?

yes it makes this less constrained
with the shifts there are only 32 distinct values with a int

I presume the shifts where there to give the loss some material sense
as in PSNR or SAD or something like that, 8 bits output having 4 times
worse precission than 10 bit for example. 

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.


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/1] opus_silk: reset midonly flag after skipping LBRR

2022-09-15 Thread Tristan Matthews
On Wed, Aug 31, 2022 at 2:32 PM Tristan Matthews  wrote:
>
> Fix suggested by Mark Harris. Fixes ticket #9890
> ---
>  libavcodec/opus_silk.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/opus_silk.c b/libavcodec/opus_silk.c
> index 8523b55ada..0b4438388e 100644
> --- a/libavcodec/opus_silk.c
> +++ b/libavcodec/opus_silk.c
> @@ -828,11 +828,16 @@ int ff_silk_decode_superframe(SilkContext *s, 
> OpusRangeCoder *rc,
>
>  /* decode the LBRR frames */
>  for (i = 0; i < nb_frames; i++) {
> +int skipped = 0;
>  for (j = 0; j < coded_channels; j++)
>  if (redundancy[j] & (1 << i)) {
>  int active1 = (j == 0 && !(redundancy[1] & (1 << i))) ? 0 : 
> 1;
>  silk_decode_frame(s, rc, i, j, coded_channels, 1, active1, 
> 1);
> +skipped = 1;
>  }
> +/* reset midonly if needed */
> +if (skipped)
> +s->midonly = 0;
>  }
>
>  for (i = 0; i < nb_frames; i++) {
> --
> 2.34.1
>

Ping
___
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 v5 3/3] fate/flac: Add test of 32 bps encoding/decoding

2022-09-15 Thread Martijn van Beurden
Op do 15 sep. 2022 om 18:58 schreef Andreas Rheinhardt <
andreas.rheinha...@outlook.com>:

> Martijn van Beurden:
> > ---
> >  tests/fate/flac.mak | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/tests/fate/flac.mak b/tests/fate/flac.mak
> > index 115cc965e1..4db28b1e1d 100644
> > --- a/tests/fate/flac.mak
> > +++ b/tests/fate/flac.mak
> > @@ -6,6 +6,8 @@ FATE_FLAC += fate-flac-16-chmode-indep
> \
> >   fate-flac-16-lpc-cholesky
> \
> >   fate-flac-16-lpc-levinson
> \
> >   fate-flac-24-comp-8
> \
> > + fate-flac-32
>  \
> > + fate-flac-32-wasted-bits
>  \
> >   fate-flac-rice-params
> \
> >
> >  fate-flac-16-chmode-%: OPTS = -ch_mode $(@:fate-flac-16-chmode-%=%)
> > @@ -20,6 +22,13 @@ fate-flac-24-comp-%: OPTS = -compression_level
> $(@:fate-flac-24-comp-%=%)
> >  fate-flac-24-%: REF =
> $(SAMPLES)/audio-reference/divertimenti_2ch_96kHz_s24.wav
> >  fate-flac-24-%: CMD = enc_dec_pcm flac wav s24le $(subst
> $(SAMPLES),$(TARGET_SAMPLES),$(REF)) -c flac $(OPTS)
> >
> > +
> > +fate-flac-32: REF = $(SAMPLES)/audio-reference/drums_2ch_44kHz_s32.wav
> > +fate-flac-32: CMD = enc_dec_pcm flac wav s32le $(subst
> $(SAMPLES),$(TARGET_SAMPLES),$(REF)) -c flac -strict -2
>
> We already have 32bit samples in the fate-suite, namely
> wavpack/lossless/32bit_int_partial.wv. Why don't you use these?
> (Anyway, don't hardcode the numerical value of 'experimental'.)
>

I wasn't sure that was possible. If for example the build is configured to
leave wavpack out that wouldn't work. Or is it assumed that fate is only
run with a ffmpeg build configured with default and some additions but
nothing default left out?

Considering the strict value, I guess I should also change the help text
then? Now it reads: encoding as 24 bits-per-sample, more is considered
experimental. Add -strict -2 if you want to encode more than 24
bits-per-sample
___
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] avformat/bonk: Don't set data_offset to what it would be set to anyway

2022-09-15 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/bonk.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/libavformat/bonk.c b/libavformat/bonk.c
> index fc400979b3..0fff0b5bda 100644
> --- a/libavformat/bonk.c
> +++ b/libavformat/bonk.c
> @@ -79,7 +79,6 @@ static int bonk_read_header(AVFormatContext *s)
>  return AVERROR_INVALIDDATA;
>  st->duration  = AV_RL32(st->codecpar->extradata + 1) / 
> st->codecpar->ch_layout.nb_channels;
>  avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
> -ffformatcontext(s)->data_offset = avio_tell(s->pb);
>  
>  return 0;
>  }

Will apply 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] [PATCH] avcodec: Micronas SC-4 decoder and parser

2022-09-15 Thread Paul B Mahol
On 9/10/22, Paul B Mahol  wrote:
> Patches attached.
>

will apply soon.
___
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] avformat: add Limitless Audio Format demuxer

2022-09-15 Thread Paul B Mahol
On 9/12/22, Paul B Mahol  wrote:
> On 9/12/22, Paul B Mahol  wrote:
>> Patch attached.
>>
>
> Updated patch attached.
>

Will apply soon.
___
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 v5 3/3] fate/flac: Add test of 32 bps encoding/decoding

2022-09-15 Thread Andreas Rheinhardt
Martijn van Beurden:
> ---
>  tests/fate/flac.mak | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/tests/fate/flac.mak b/tests/fate/flac.mak
> index 115cc965e1..4db28b1e1d 100644
> --- a/tests/fate/flac.mak
> +++ b/tests/fate/flac.mak
> @@ -6,6 +6,8 @@ FATE_FLAC += fate-flac-16-chmode-indep
>   \
>   fate-flac-16-lpc-cholesky  \
>   fate-flac-16-lpc-levinson  \
>   fate-flac-24-comp-8\
> + fate-flac-32   \
> + fate-flac-32-wasted-bits   \
>   fate-flac-rice-params  \
>  
>  fate-flac-16-chmode-%: OPTS = -ch_mode $(@:fate-flac-16-chmode-%=%)
> @@ -20,6 +22,13 @@ fate-flac-24-comp-%: OPTS = -compression_level 
> $(@:fate-flac-24-comp-%=%)
>  fate-flac-24-%: REF = 
> $(SAMPLES)/audio-reference/divertimenti_2ch_96kHz_s24.wav
>  fate-flac-24-%: CMD = enc_dec_pcm flac wav s24le $(subst 
> $(SAMPLES),$(TARGET_SAMPLES),$(REF)) -c flac $(OPTS)
>  
> +
> +fate-flac-32: REF = $(SAMPLES)/audio-reference/drums_2ch_44kHz_s32.wav
> +fate-flac-32: CMD = enc_dec_pcm flac wav s32le $(subst 
> $(SAMPLES),$(TARGET_SAMPLES),$(REF)) -c flac -strict -2

We already have 32bit samples in the fate-suite, namely
wavpack/lossless/32bit_int_partial.wv. Why don't you use these?
(Anyway, don't hardcode the numerical value of 'experimental'.)

> +
> +fate-flac-32-wasted-bits: REF = 
> $(SAMPLES)/audio-reference/drums_2ch_44kHz_s32_1wastedbit.wav
> +fate-flac-32-wasted-bits: CMD = enc_dec_pcm flac wav s32le $(subst 
> $(SAMPLES),$(TARGET_SAMPLES),$(REF)) -c flac -strict -2
> +
>  fate-flac-rice-params: REF = 
> $(SAMPLES)/audio-reference/chorusnoise_2ch_44kHz_s16.wav
>  fate-flac-rice-params: CMD = enc_dec_pcm flac wav s16le $(subst 
> $(SAMPLES),$(TARGET_SAMPLES),$(REF)) -c flac
>  

___
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 v5 3/3] fate/flac: Add test of 32 bps encoding/decoding

2022-09-15 Thread Martijn van Beurden
---
 tests/fate/flac.mak | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tests/fate/flac.mak b/tests/fate/flac.mak
index 115cc965e1..4db28b1e1d 100644
--- a/tests/fate/flac.mak
+++ b/tests/fate/flac.mak
@@ -6,6 +6,8 @@ FATE_FLAC += fate-flac-16-chmode-indep  
\
  fate-flac-16-lpc-cholesky  \
  fate-flac-16-lpc-levinson  \
  fate-flac-24-comp-8\
+ fate-flac-32   \
+ fate-flac-32-wasted-bits   \
  fate-flac-rice-params  \
 
 fate-flac-16-chmode-%: OPTS = -ch_mode $(@:fate-flac-16-chmode-%=%)
@@ -20,6 +22,13 @@ fate-flac-24-comp-%: OPTS = -compression_level 
$(@:fate-flac-24-comp-%=%)
 fate-flac-24-%: REF = $(SAMPLES)/audio-reference/divertimenti_2ch_96kHz_s24.wav
 fate-flac-24-%: CMD = enc_dec_pcm flac wav s24le $(subst 
$(SAMPLES),$(TARGET_SAMPLES),$(REF)) -c flac $(OPTS)
 
+
+fate-flac-32: REF = $(SAMPLES)/audio-reference/drums_2ch_44kHz_s32.wav
+fate-flac-32: CMD = enc_dec_pcm flac wav s32le $(subst 
$(SAMPLES),$(TARGET_SAMPLES),$(REF)) -c flac -strict -2
+
+fate-flac-32-wasted-bits: REF = 
$(SAMPLES)/audio-reference/drums_2ch_44kHz_s32_1wastedbit.wav
+fate-flac-32-wasted-bits: CMD = enc_dec_pcm flac wav s32le $(subst 
$(SAMPLES),$(TARGET_SAMPLES),$(REF)) -c flac -strict -2
+
 fate-flac-rice-params: REF = 
$(SAMPLES)/audio-reference/chorusnoise_2ch_44kHz_s16.wav
 fate-flac-rice-params: CMD = enc_dec_pcm flac wav s16le $(subst 
$(SAMPLES),$(TARGET_SAMPLES),$(REF)) -c flac
 
-- 
2.30.2

___
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 v5 2/3] libavcodec/flacenc: Implement encoding of 32 bit-per-sample PCM

2022-09-15 Thread Martijn van Beurden
Add encoding of 32 bit-per-sample PCM to FLAC files to libavcodec.
Coding to this format is at this point considered experimental and
-strict -2 is needed to get ffmpeg to encode such files.
---
 libavcodec/flacenc.c| 519 
 libavcodec/put_bits.h   |   7 +
 libavcodec/put_golomb.h |  14 --
 3 files changed, 424 insertions(+), 116 deletions(-)

diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
index 5d8c3f82be..2bc3976f4e 100644
--- a/libavcodec/flacenc.c
+++ b/libavcodec/flacenc.c
@@ -31,7 +31,6 @@
 #include "codec_internal.h"
 #include "encode.h"
 #include "put_bits.h"
-#include "put_golomb.h"
 #include "lpc.h"
 #include "flac.h"
 #include "flacdata.h"
@@ -95,6 +94,7 @@ typedef struct FlacSubframe {
 
 typedef struct FlacFrame {
 FlacSubframe subframes[FLAC_MAX_CHANNELS];
+int64_t samples_33bps[FLAC_MAX_BLOCKSIZE];
 int blocksize;
 int bs_code[2];
 uint8_t crc8;
@@ -282,10 +282,23 @@ static av_cold int flac_encode_init(AVCodecContext *avctx)
 s->bps_code= 4;
 break;
 case AV_SAMPLE_FMT_S32:
-if (avctx->bits_per_raw_sample != 24)
-av_log(avctx, AV_LOG_WARNING, "encoding as 24 bits-per-sample\n");
-avctx->bits_per_raw_sample = 24;
-s->bps_code= 6;
+if (avctx->bits_per_raw_sample <= 24) {
+if (avctx->bits_per_raw_sample < 24)
+av_log(avctx, AV_LOG_WARNING, "encoding as 24 
bits-per-sample\n");
+avctx->bits_per_raw_sample = 24;
+s->bps_code= 6;
+} else if (avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL) {
+av_log(avctx, AV_LOG_WARNING,
+   "encoding as 24 bits-per-sample, more is considered "
+   "experimental. Add -strict %d if you want to encode "
+   "more than 24 bits-per-sample\n",
+   FF_COMPLIANCE_EXPERIMENTAL);
+avctx->bits_per_raw_sample = 24;
+s->bps_code= 6;
+} else {
+avctx->bits_per_raw_sample = 32;
+s->bps_code = 7;
+}
 break;
 }
 
@@ -533,8 +546,7 @@ static uint64_t rice_count_exact(const int32_t *res, int n, 
int k)
 uint64_t count = 0;
 
 for (i = 0; i < n; i++) {
-int32_t v = -2 * res[i] - 1;
-v ^= v >> 31;
+unsigned v = ((unsigned)(res[i]) << 1) ^ (res[i] >> 31);
 count += (v >> k) + 1 + k;
 }
 return count;
@@ -713,8 +725,8 @@ static uint64_t calc_rice_params(RiceContext *rc,
 
 tmp_rc.coding_mode = rc->coding_mode;
 
-for (i = 0; i < n; i++)
-udata[i] = (2 * data[i]) ^ (data[i] >> 31);
+for (i = pred_order; i < n; i++)
+udata[i] = ((unsigned)(data[i]) << 1) ^ (data[i] >> 31);
 
 calc_sum_top(pmax, exact ? kmax : 0, udata, n, pred_order, sums);
 
@@ -812,6 +824,180 @@ static void encode_residual_fixed(int32_t *res, const 
int32_t *smp, int n,
 }
 
 
+static int encode_residual_fixed_with_residual_limit(int32_t *res, const 
int32_t *smp,
+  int n, int order)
+{
+/* This function checks for every residual whether it can be
+ * contained in  INT32_MAX)
+return 1;
+res[i] = res64;
+}
+} else if (order == 2) {
+for (i = order; i < n; i++) {
+res64 = (int64_t)smp[i] - 2*(int64_t)smp[i-1] + smp[i-2];
+if (res64 <= INT32_MIN || res64 > INT32_MAX)
+return 1;
+res[i] = res64;
+}
+} else if (order == 3) {
+for (i = order; i < n; i++) {
+res64 = (int64_t)smp[i] - 3*(int64_t)smp[i-1] + 
3*(int64_t)smp[i-2] - smp[i-3];
+if (res64 <= INT32_MIN || res64 > INT32_MAX)
+return 1;
+res[i] = res64;
+}
+} else {
+for (i = order; i < n; i++) {
+res64 = (int64_t)smp[i] - 4*(int64_t)smp[i-1] + 
6*(int64_t)smp[i-2] - 4*(int64_t)smp[i-3] + smp[i-4];
+if (res64 <= INT32_MIN || res64 > INT32_MAX)
+return 1;
+res[i] = res64;
+}
+}
+return 0;
+}
+
+
+static int encode_residual_fixed_with_residual_limit_33bps(int32_t *res, const 
int64_t *smp,
+   int n, int order)
+{
+/* This function checks for every residual whether it can be
+ * contained in  INT32_MAX)
+return 1;
+res[i] = smp[i];
+}
+} else if (order == 1) {
+for (i = order; i < n; i++) {
+res64 = smp[i] - smp[i-1];
+if (res64 <= INT32_MIN || res64 > INT32_MAX)
+return 1;
+res[i] = res64;
+}
+} else if (order == 2) {
+for (i = order; i < n; i++) {
+res64 = smp[i] - 2*smp[i-1] + smp[i-2];
+if (res64 <= INT32_MIN || res64 > INT32_MAX)
+

[FFmpeg-devel] [PATCH v5 1/3] libavcodec/flacdec: Implement decoding of 32 bit-per-sample PCM

2022-09-15 Thread Martijn van Beurden
Add decoding of FLAC files coding for 32 bit-per-sample PCM to libavcodec.
---
 libavcodec/flac.c |   4 +-
 libavcodec/flacdec.c  | 250 ++
 libavcodec/get_bits.h |  12 ++
 libavcodec/mathops.h  |   9 ++
 4 files changed, 251 insertions(+), 24 deletions(-)

diff --git a/libavcodec/flac.c b/libavcodec/flac.c
index 352d663c67..174b4801be 100644
--- a/libavcodec/flac.c
+++ b/libavcodec/flac.c
@@ -28,7 +28,7 @@
 #include "flacdata.h"
 #include "flac_parse.h"
 
-static const int8_t sample_size_table[] = { 0, 8, 12, 0, 16, 20, 24, 0 };
+static const int8_t sample_size_table[] = { 0, 8, 12, 0, 16, 20, 24, 32 };
 
 static const AVChannelLayout flac_channel_layouts[8] = {
 AV_CHANNEL_LAYOUT_MONO,
@@ -82,7 +82,7 @@ int ff_flac_decode_frame_header(AVCodecContext *avctx, 
GetBitContext *gb,
 
 /* bits per sample */
 bps_code = get_bits(gb, 3);
-if (bps_code == 3 || bps_code == 7) {
+if (bps_code == 3) {
 av_log(avctx, AV_LOG_ERROR + log_level_offset,
"invalid sample size code (%d)\n",
bps_code);
diff --git a/libavcodec/flacdec.c b/libavcodec/flacdec.c
index 5b8547a98f..bc5c06b73d 100644
--- a/libavcodec/flacdec.c
+++ b/libavcodec/flacdec.c
@@ -64,6 +64,9 @@ typedef struct FLACContext {
 int32_t *decoded[FLAC_MAX_CHANNELS];///< decoded samples
 uint8_t *decoded_buffer;
 unsigned int decoded_buffer_size;
+int64_t *decoded_33bps;  ///< decoded samples for a 33 bps 
subframe
+uint8_t *decoded_buffer_33bps;
+unsigned int decoded_buffer_size_33bps;
 int buggy_lpc;  ///< use workaround for old lavc 
encoded files
 
 FLACDSPContext dsp;
@@ -154,6 +157,24 @@ static int allocate_buffers(FLACContext *s)
  s->stream_info.channels,
  s->stream_info.max_blocksize,
  AV_SAMPLE_FMT_S32P, 0);
+if (ret >= 0 && s->stream_info.bps == 32 && s->stream_info.channels == 2) {
+buf_size = av_samples_get_buffer_size(NULL, 1,
+  s->stream_info.max_blocksize,
+  AV_SAMPLE_FMT_S64P, 0);
+if (buf_size < 0)
+return buf_size;
+
+av_fast_malloc(>decoded_buffer_33bps, 
>decoded_buffer_size_33bps, buf_size);
+if (!s->decoded_buffer_33bps)
+return AVERROR(ENOMEM);
+
+ret = av_samples_fill_arrays((uint8_t **)>decoded_33bps, NULL,
+ s->decoded_buffer_33bps,
+ 1,
+ s->stream_info.max_blocksize,
+ AV_SAMPLE_FMT_S64P, 0);
+
+}
 return ret < 0 ? ret : 0;
 }
 
@@ -331,6 +352,94 @@ static int decode_subframe_fixed(FLACContext *s, int32_t 
*decoded,
 return 0;
 }
 
+static int decode_subframe_fixed_wide(FLACContext *s, int32_t *decoded,
+  int pred_order, int bps)
+{
+const int blocksize = s->blocksize;
+int i;
+int ret;
+
+/* warm up samples */
+for (i = 0; i < pred_order; i++) {
+decoded[i] = get_sbits_long(>gb, bps);
+}
+
+if ((ret = decode_residuals(s, decoded, pred_order)) < 0)
+return ret;
+
+switch (pred_order) {
+case 0:
+break;
+case 1:
+for (i = pred_order; i < blocksize; i++)
+decoded[i] += decoded[i-1];
+break;
+case 2:
+for (i = pred_order; i < blocksize; i++)
+decoded[i] = (int64_t)decoded[i] + 2*(int64_t)decoded[i-1] - 
(int64_t)decoded[i-2];
+break;
+case 3:
+for (i = pred_order; i < blocksize; i++)
+decoded[i] = (int64_t)decoded[i] + 3*(int64_t)decoded[i-1] - 
3*(int64_t)decoded[i-2] + (int64_t)decoded[i-3];
+break;
+case 4:
+for (i = pred_order; i < blocksize; i++)
+decoded[i] = (int64_t)decoded[i] + 4*(int64_t)decoded[i-1] - 
6*(int64_t)decoded[i-2] + 4*(int64_t)decoded[i-3] - (int64_t)decoded[i-4];
+break;
+default:
+av_log(s->avctx, AV_LOG_ERROR, "illegal pred order %d\n", pred_order);
+return AVERROR_INVALIDDATA;
+}
+
+return 0;
+}
+
+
+static int decode_subframe_fixed_33bps(FLACContext *s, int64_t *decoded,
+   int32_t *residual, int pred_order)
+{
+const int blocksize = s->blocksize;
+int i;
+int ret;
+
+/* warm up samples */
+for (i = 0; i < pred_order; i++) {
+decoded[i] = get_sbits64(>gb, 33);
+av_log(s->avctx, AV_LOG_DEBUG, "warm-up %d = %" PRId64 "\n", i, 
decoded[i]);
+}
+
+if ((ret = decode_residuals(s, residual, pred_order)) < 0)
+return ret;
+
+switch (pred_order) {
+case 0:
+for (i = pred_order; i < blocksize; i++)
+decoded[i] = residual[i];
+break;
+case 1:
+for (i = 

[FFmpeg-devel] [PATCH v5 0/3] 32bps FLAC patches

2022-09-15 Thread Martijn van Beurden
Recently libFLAC gained the ability (first released in FLAC 1.4.0)
to create FLAC files containing 32-bit int PCM samples. To
keep complexity reasonable, the choice was made to limit residuals
to 32-bit integers, which the encoder must make sure of. In case
the encoder cannot find any predictor of which the residuals fit
this limit, it must default to using a verbatim subframe. Tests have
shown that this does not happen often (<0.1% of subframes on a
music corpus of various styles). See also discussion here:
https://github.com/ietf-wg-cellar/flac-specification/pull/148

These two patches implement decoding and encoding following this
format.

Changes since v1:
fix copy-paste error in encoder, several invocations of
lpc_encode_choose_datapath used wrong parameters, making FATE fail as
compression was less than it should be

Changes since v2:
Rebased decoder part as it didn't apply anymore

Changes since v3:
Moved put_golomb part to flacenc.c (as it is now quite specific to FLAC)
and renamed put_sbits64 to put_sbits63 (and changed assert accordingly)

Changes since v4:
Fix check of decoded_buffer_33bps malloc. Fix reading of wasted bits
for 33bps subframe. Add fate test


Martijn van Beurden (3):
  libavcodec/flacdec: Implement decoding of 32 bit-per-sample PCM
  libavcodec/flacenc: Implement encoding of 32 bit-per-sample PCM
  fate/flac: Add test of 32 bps encoding/decoding

 libavcodec/flac.c   |   4 +-
 libavcodec/flacdec.c| 250 +--
 libavcodec/flacenc.c| 519 
 libavcodec/get_bits.h   |  12 +
 libavcodec/mathops.h|   9 +
 libavcodec/put_bits.h   |   7 +
 libavcodec/put_golomb.h |  14 --
 tests/fate/flac.mak |   9 +
 8 files changed, 684 insertions(+), 140 deletions(-)

-- 
2.30.2

___
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/adpcmenc: Round up required buffer size

2022-09-15 Thread Paul B Mahol
On 9/15/22, Andreas Rheinhardt  wrote:
> Otherwise the buffer might be too small. Fixes assert violations
> when encoding mono audio with exactly one sample.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/adpcmenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/adpcmenc.c b/libavcodec/adpcmenc.c
> index 1ffc5b410f..57709b19a1 100644
> --- a/libavcodec/adpcmenc.c
> +++ b/libavcodec/adpcmenc.c
> @@ -614,7 +614,7 @@ static int adpcm_encode_frame(AVCodecContext *avctx,
> AVPacket *avpkt,
>  avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_ALP ||
>  avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_APM ||
>  avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_WS)
> -pkt_size = (frame->nb_samples * channels) / 2;
> +pkt_size = (frame->nb_samples * channels + 1) / 2;
>  else
>  pkt_size = avctx->block_align;
>  if ((ret = ff_get_encode_buffer(avctx, avpkt, pkt_size, 0)) < 0)
> --
> 2.34.1

Nice catch, LGTM.

>
> ___
> 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] avcodec/adpcmenc: Round up required buffer size

2022-09-15 Thread Andreas Rheinhardt
Otherwise the buffer might be too small. Fixes assert violations
when encoding mono audio with exactly one sample.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/adpcmenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/adpcmenc.c b/libavcodec/adpcmenc.c
index 1ffc5b410f..57709b19a1 100644
--- a/libavcodec/adpcmenc.c
+++ b/libavcodec/adpcmenc.c
@@ -614,7 +614,7 @@ static int adpcm_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_ALP ||
 avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_APM ||
 avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_WS)
-pkt_size = (frame->nb_samples * channels) / 2;
+pkt_size = (frame->nb_samples * channels + 1) / 2;
 else
 pkt_size = avctx->block_align;
 if ((ret = ff_get_encode_buffer(avctx, avpkt, pkt_size, 0)) < 0)
-- 
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] avcodec/mlpdec: fix decoding of overlapping channels in substreams

2022-09-15 Thread Paul B Mahol
Patch attached.

There are cases when previously decoded substreams
would, if they have overlapping channels with final substream, cause
incorrect decoding results.
From adf5fd3bdb397f88a52d7ce0cf76491a55d33eef Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Thu, 15 Sep 2022 16:14:08 +0200
Subject: [PATCH] avcodec/mlpdec: fix decoding of overlapping channels in
 substreams

Fixes #5039

Signed-off-by: Paul B Mahol 
---
 libavcodec/mlpdec.c | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/libavcodec/mlpdec.c b/libavcodec/mlpdec.c
index 0a97fae26c..bb72134b09 100644
--- a/libavcodec/mlpdec.c
+++ b/libavcodec/mlpdec.c
@@ -67,6 +67,8 @@ typedef struct SubStream {
 uint8_t min_channel;
 /// The index of the last channel coded in this substream.
 uint8_t max_channel;
+/// The coded channels mask in this substream.
+uint64_tcoded_channels;
 /// The number of channels input into the rematrix stage.
 uint8_t max_matrix_channel;
 /// For each channel output by the matrix, the output channel to map it to
@@ -563,6 +565,7 @@ static int read_restart_header(MLPDecodeContext *m, GetBitContext *gbp,
 
 s->min_channel= min_channel;
 s->max_channel= max_channel;
+s->coded_channels = ((1LL << (max_channel - min_channel + 1)) - 1) << min_channel;
 s->max_matrix_channel = max_matrix_channel;
 s->noise_type = noise_type;
 
@@ -1272,11 +1275,6 @@ static int read_access_unit(AVCodecContext *avctx, AVFrame *frame,
 for (substr = 0; substr <= m->max_decoded_substream; substr++) {
 SubStream *s = >substream[substr];
 
-if (substr != m->max_decoded_substream &&
-m->substream[m->max_decoded_substream].min_channel == 0 &&
-m->substream[m->max_decoded_substream].max_channel == avctx->ch_layout.nb_channels - 1)
-goto skip_substr;
-
 init_get_bits(, buf, substream_data_len[substr] * 8);
 
 m->matrix_changed = 0;
@@ -1301,6 +1299,22 @@ static int read_access_unit(AVCodecContext *avctx, AVFrame *frame,
 if (!s->restart_seen)
 goto next_substr;
 
+if (substr > 0 && substr < m->max_decoded_substream &&
+(s->min_channel <= m->substream[substr - 1].max_channel)) {
+av_log(avctx, AV_LOG_DEBUG,
+   "Previous substream(%d) channels overlaps current substream(%d) channels, skipping.\n",
+   substr - 1, substr);
+goto next_substr;
+}
+
+if (substr != m->max_decoded_substream &&
+((s->coded_channels & m->substream[m->max_decoded_substream].coded_channels) != 0)) {
+av_log(avctx, AV_LOG_DEBUG,
+   "Current substream(%d) channels overlaps final substream(%d) channels, skipping.\n",
+   substr, m->max_decoded_substream);
+goto next_substr;
+}
+
 if ((ret = read_block_data(m, , substr)) < 0)
 return ret;
 
@@ -1350,7 +1364,6 @@ next_substr:
 av_log(m->avctx, AV_LOG_ERROR,
"No restart header present in substream %d.\n", substr);
 
-skip_substr:
 buf += substream_data_len[substr];
 }
 
-- 
2.37.2

___
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] lfg: fix comment typo

2022-09-15 Thread Gyan Doshi



On 2022-09-15 08:35 pm, r...@remlab.net wrote:

From: Rémi Denis-Courmont 

---
  libavutil/lfg.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/lfg.h b/libavutil/lfg.h
index 2b669205d1..9a1e277acd 100644
--- a/libavutil/lfg.h
+++ b/libavutil/lfg.h
@@ -27,7 +27,7 @@
  /**
   * Context structure for the Lagged Fibonacci PRNG.
   * The exact layout, types and content of this struct may change and should
- * not be accessed directly. Only its sizeof() is guranteed to stay the same
+ * not be accessed directly. Only its sizeof() is guaranteed to stay the same
   * to allow easy instanciation.
   */
  typedef struct AVLFG {


Will apply.

Regards,
Gyan
___
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] lfg: fix comment typo

2022-09-15 Thread remi
From: Rémi Denis-Courmont 

---
 libavutil/lfg.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/lfg.h b/libavutil/lfg.h
index 2b669205d1..9a1e277acd 100644
--- a/libavutil/lfg.h
+++ b/libavutil/lfg.h
@@ -27,7 +27,7 @@
 /**
  * Context structure for the Lagged Fibonacci PRNG.
  * The exact layout, types and content of this struct may change and should
- * not be accessed directly. Only its sizeof() is guranteed to stay the same
+ * not be accessed directly. Only its sizeof() is guaranteed to stay the same
  * to allow easy instanciation.
  */
 typedef struct AVLFG {
-- 
2.37.2

___
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 1/2] lavc/videotoolbox: do not pass AVCodecContext to decoder output callback

2022-09-15 Thread Anton Khirnov
The opaque parameter for the callback is set in videotoolbox_start(),
called when the hwaccel is initialized. When frame threading is used,
avctx will be the context corresponding to the frame thread currently
doing the decoding. Using this same codec context in all subsequent
invocations of the decoder callback (even those triggered by a different
frame thread) is unsafe, and broken after
cc867f2c09d2b69cee8a0eccd62aff002cbbfe11, since each frame thread now
cleans up its hwaccel state after decoding each frame.

Fix this by passing hwaccel_priv_data as the opaque parameter, which
exists in a single instance forwarded between all frame threads.

The only other use of AVCodecContext in the decoder output callback is
as a logging context. For this purpose, store a logging context in
hwaccel_priv_data.
---
Initial version of this patch tested by Marvin on IRC.
Someone please test this final version, as I don't have the HW to do it
myself.
---
 libavcodec/videotoolbox.c | 10 ++
 libavcodec/vt_internal.h  |  2 ++
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index ce83c2594a..d61d310600 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -690,8 +690,7 @@ static void videotoolbox_decoder_callback(void *opaque,
   CMTime pts,
   CMTime duration)
 {
-AVCodecContext *avctx = opaque;
-VTContext *vtctx = avctx->internal->hwaccel_priv_data;
+VTContext *vtctx = opaque;
 
 if (vtctx->frame) {
 CVPixelBufferRelease(vtctx->frame);
@@ -699,7 +698,8 @@ static void videotoolbox_decoder_callback(void *opaque,
 }
 
 if (!image_buffer) {
-av_log(avctx, status ? AV_LOG_WARNING : AV_LOG_DEBUG, "vt decoder cb: 
output image buffer is null: %i\n", status);
+av_log(vtctx->logctx, status ? AV_LOG_WARNING : AV_LOG_DEBUG,
+   "vt decoder cb: output image buffer is null: %i\n", status);
 return;
 }
 
@@ -949,7 +949,7 @@ static int videotoolbox_start(AVCodecContext *avctx)
  
videotoolbox->cv_pix_fmt_type);
 
 decoder_cb.decompressionOutputCallback = videotoolbox_decoder_callback;
-decoder_cb.decompressionOutputRefCon   = avctx;
+decoder_cb.decompressionOutputRefCon   = 
avctx->internal->hwaccel_priv_data;
 
 status = VTDecompressionSessionCreate(NULL,  // 
allocator
   videotoolbox->cm_fmt_desc, // 
videoFormatDescription
@@ -1179,6 +1179,8 @@ int ff_videotoolbox_common_init(AVCodecContext *avctx)
 AVHWFramesContext *hw_frames;
 int err;
 
+vtctx->logctx = avctx;
+
 // Old API - do nothing.
 if (avctx->hwaccel_context)
 return 0;
diff --git a/libavcodec/vt_internal.h b/libavcodec/vt_internal.h
index 54a11fd1b5..9502d7c7dc 100644
--- a/libavcodec/vt_internal.h
+++ b/libavcodec/vt_internal.h
@@ -45,6 +45,8 @@ typedef struct VTContext {
 // Current H264 parameters (used to trigger decoder restart on SPS 
changes).
 uint8_t sps[3];
 boolreconfig_needed;
+
+void *logctx;
 } VTContext;
 
 int ff_videotoolbox_alloc_frame(AVCodecContext *avctx, AVFrame *frame);
-- 
2.35.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 2/2] lavc/videotoolbox: deprecate write-only output_callback

2022-09-15 Thread Anton Khirnov
This field has never been used for anything, so stop setting it and
deprecate it.
---
 libavcodec/version_major.h | 1 +
 libavcodec/videotoolbox.c  | 2 --
 libavcodec/videotoolbox.h  | 5 +
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavcodec/version_major.h b/libavcodec/version_major.h
index 1ec815a7bc..d9386792de 100644
--- a/libavcodec/version_major.h
+++ b/libavcodec/version_major.h
@@ -51,5 +51,6 @@
 #define FF_API_IDCT_NONE   (LIBAVCODEC_VERSION_MAJOR < 60)
 #define FF_API_SVTAV1_OPTS (LIBAVCODEC_VERSION_MAJOR < 60)
 #define FF_API_AYUV_CODECID(LIBAVCODEC_VERSION_MAJOR < 60)
+#define FF_API_VT_OUTPUT_CALLBACK  (LIBAVCODEC_VERSION_MAJOR < 60)
 
 #endif /* AVCODEC_VERSION_MAJOR_H */
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index d61d310600..1b1be8ddb4 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -1377,8 +1377,6 @@ static AVVideotoolboxContext 
*av_videotoolbox_alloc_context_with_pix_fmt(enum AV
 AVVideotoolboxContext *ret = av_mallocz(sizeof(*ret));
 
 if (ret) {
-ret->output_callback = videotoolbox_decoder_callback;
-
 OSType cv_pix_fmt_type = 
av_map_videotoolbox_format_from_pixfmt2(pix_fmt, full_range);
 if (cv_pix_fmt_type == 0) {
 cv_pix_fmt_type = kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange;
diff --git a/libavcodec/videotoolbox.h b/libavcodec/videotoolbox.h
index af2db0d580..fd8a5b7982 100644
--- a/libavcodec/videotoolbox.h
+++ b/libavcodec/videotoolbox.h
@@ -37,6 +37,8 @@
 
 #include "libavcodec/avcodec.h"
 
+#include "libavutil/attributes.h"
+
 /**
  * This struct holds all the information that needs to be passed
  * between the caller and libavcodec for initializing Videotoolbox decoding.
@@ -50,11 +52,14 @@ typedef struct AVVideotoolboxContext {
  */
 VTDecompressionSessionRef session;
 
+#if FF_API_VT_OUTPUT_CALLBACK
 /**
  * The output callback that must be passed to the session.
  * Set by av_videottoolbox_default_init()
  */
+attribute_deprecated
 VTDecompressionOutputCallback output_callback;
+#endif
 
 /**
  * CVPixelBuffer Format Type that Videotoolbox will use for decoded frames.
-- 
2.35.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] qmax limit 28 in mpegvideo_enc.c

2022-09-15 Thread Jaka Bac
Hello,

mpegvideo_enc.c contains this check in ff_mpv_encode_init:

if (s->q_scale_type == 1) {
if (avctx->qmax > 28) {
av_log(avctx, AV_LOG_ERROR,
   "non linear quant only supports qmax <= 28 currently\n");
return AVERROR_PATCHWELCOME;
}
}

This was added in:
avcodec/mpeg12enc: extend QP range to 28 for non linear quantizers
https://github.com/FFmpeg/FFmpeg/commit/bf2474c74f2c0b956c069f50483c7d104d856d8b


After a while there was another commit:
avcodec/mpeg12enc: Basic support for encoding non even QPs for
-non_linear_quant 1
https://github.com/FFmpeg/FFmpeg/commit/58fe57d5a05ad8d15c320b2bd163debbc412bdd3

I may be completely wrong, but to me it looks like that the second commit
lifts the "qmax <= 28 restriction".
Or am I missing something?

Thanks,
Jaka
___
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/intrax8: Remove reference to inexistent parameter

2022-09-15 Thread Andreas Rheinhardt
Forgotten in eb5c5ae658aaf8cd7c03e1d0a6c84274d3a39a66.

Signed-off-by: Andreas Rheinhardt 
---
Will apply this tonight unless there are objections.

 libavcodec/intrax8.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/intrax8.h b/libavcodec/intrax8.h
index 966f1b18a0..9ef2fc3dd3 100644
--- a/libavcodec/intrax8.h
+++ b/libavcodec/intrax8.h
@@ -77,7 +77,6 @@ typedef struct IntraX8Context {
  * Initialize IntraX8 frame decoder.
  * @param avctx pointer to AVCodecContext
  * @param w pointer to IntraX8Context
- * @param idsp pointer to IDCTDSPContext
  * @param block pointer to block array
  * @param block_last_index pointer to index array
  * @param mb_width macroblock width
-- 
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] libavfilter/f_select: switch to activate and properly handle EOF pts

2022-09-15 Thread Nicolas George
Li-Heng Chen (12022-09-14):
> Please allow me to explain again with your example. That's say we have
> an input with 20 frames (0-19), and we want to keep prime number frames
> with select filter, -vf select='eq(n\,2)+eq(n\,3)+...+eq(n\,13)+eq(n\,17)'
> 
> In the activation function, select->eof_pts is updated to n at n=4, 6,
> 8, 12, 14, 18
> However, select->eof_pts is passed into ff_outlink_set_status only at
> n=20, since
> ff_inlink_acknowledge_status returns 1.

I understood that. And I argue it is wrong.

> Regardless of my logic, this behavior looks weird to me. In my opinion,
> -vf select='eq(n\,24),fps=25/1' should produce the same result as just having
> -vf select='eq(n\,24)'. However, select='eq(n\,24),fps=25/1' generates
> 22 identical
> frames while select='eq(n\,24)' only outputs one frame...

Trick question:

testsrc=r=25:d=4,select='gte(n\,0)*gte(24\,n)+gte(n\,50)*gte(74\,n)',fps=25

How many frames do you expect on the output?

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".


Re: [FFmpeg-devel] [PATCH v3] fftools/ffplay: fix rotation incorrect when frame contains the displaymatrix

2022-09-15 Thread Steven Liu
Zhao Zhili  于2022年9月6日周二 14:38写道:
>
> On Mon, 2022-09-05 at 18:40 +0800, 1035567...@qq.com wrote:
> > From: Wang Yaqiang 
> >
> > For example, if the jpeg contains exif information
> > and the rotation direction is included in the exif,
> > the displaymatrix will be set on the side_data of the frame when
> > decoding.
> > However, when ffplay is used to play the image,
> > only the side data in the stream will be determined.
> > It does not check whether the frame also contains rotation
> > information,
> > causing it to play in the wrong direction
> >
> > Signed-off-by: Wang Yaqiang 
> > ---
> >  fftools/ffplay.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> > index 9242047f5c..bcc00afe31 100644
> > --- a/fftools/ffplay.c
> > +++ b/fftools/ffplay.c
> > @@ -1915,8 +1915,14 @@ static int
> > configure_video_filters(AVFilterGraph *graph, VideoState *is, const c
> >  } while (0)
> >
> >  if (autorotate) {
> > -int32_t *displaymatrix = (int32_t
> > *)av_stream_get_side_data(is->video_st, AV_PKT_DATA_DISPLAYMATRIX,
> > NULL);
> > -double theta = get_rotation(displaymatrix);
> > +double theta = 0.0;
> > +int32_t *displaymatrix = NULL;
> > +AVFrameSideData *sd = av_frame_get_side_data(frame,
> > AV_FRAME_DATA_DISPLAYMATRIX);
> > +if (sd)
> > +displaymatrix = (int32_t *)sd->data;
> > +if (!displaymatrix)
> > +displaymatrix = (int32_t *)av_stream_get_side_data(is-
> > >video_st, AV_PKT_DATA_DISPLAYMATRIX, NULL);
> > +theta = get_rotation(displaymatrix);
> >
> >  if (fabs(theta - 90) < 1.0) {
> >  INSERT_FILT("transpose", "clock");
>
> LGTM.

Applied!


Thanks
Steven
___
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] lavc/pthread_frame: avoid leaving stale hwaccel state in worker threads

2022-09-15 Thread Marvin Scholz
On 12 Sep 2022, at 8:59, Wang Bin wrote:

> Wang Bin  于2022年9月12日周一 10:02写道:
>
>>
>>>  av_packet_unref(p->avpkt);
>>> @@ -655,6 +670,14 @@ void ff_thread_finish_setup(AVCodecContext *avctx) {
>>>  async_lock(p->parent);
>>>  }
>>>
>>> +/* save hwaccel state for passing to the next thread;
>>> + * this is done here so that this worker thread can wipe its own
>>> hwaccel
>>> + * state after decoding, without requiring synchronization */
>>> +av_assert0(!p->parent->stash_hwaccel);
>>> +p->parent->stash_hwaccel = avctx->hwaccel;
>>> +p->parent->stash_hwaccel_context = avctx->hwaccel_context;
>>> +p->parent->stash_hwaccel_priv=
>>> avctx->internal->hwaccel_priv_data;
>>>
>>
>> Assertion failure when seeking. Step to reproduce:
>> ./ffmpeg -stream_loop -1 -an -hwaccel vaapi -i test.mp4 -f null >/dev/null
>>
>> Regards
>>
>>
>
> The change breaks hwaccel on all platforms. videotoolbox has another crash.
>

Can confirm this breaks videotoolbox, to reproduce simply do:

./ffmpeg -v debug -hwaccel videotoolbox -i ~/Downloads/HDR\ Mix\ 8k\ Dolby\ 
Vision-sLs6yYYDpTw.webm  -f null /dev/null

Trace:

* thread #30, name = 'com.apple.coremedia.rootQueue.47', queue = 
'vtdecoder-callback-queue-0x10331f520', stop reason = EXC_BAD_ACCESS (code=1, 
address=0x10)
frame #0: 0x000100d376b8 
ffmpeg_g`videotoolbox_decoder_callback(opaque=0x000108c079c0, 
sourceFrameRefCon=0x, status=0, flags=0, 
image_buffer=0x6330, pts=CMTime @ 0x75db5a00, duration=0 
seconds) at videotoolbox.c:696:16 [opt]
   693  AVCodecContext *avctx = opaque;
   694  VTContext *vtctx = avctx->internal->hwaccel_priv_data;
   695  
-> 696  if (vtctx->frame) {
   697  CVPixelBufferRelease(vtctx->frame);
   698  vtctx->frame = NULL;
   699  }
Target 0: (ffmpeg_g) stopped.

The hwaccel_priv_data is NULL here. It works fine when using -threads 1.

> Regards
> ___
> 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] avfilter/vf_drawbox: use the correct macro to fill rgb plane pointers

2022-09-15 Thread Paul B Mahol
On 9/15/22, James Almer  wrote:
> Fixes ticket #9924
>
> Signed-off-by: James Almer 
> ---
>  libavfilter/vf_drawbox.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_drawbox.c b/libavfilter/vf_drawbox.c
> index 65bd039d65..64ce12 100644
> --- a/libavfilter/vf_drawbox.c
> +++ b/libavfilter/vf_drawbox.c
> @@ -162,7 +162,7 @@ static void draw_region(AVFrame *frame, DrawBoxContext
> *ctx, int left, int top,
>  row[2] = frame->data[0] + y * frame->linesize[0] + ctx->rgba_map[2];
>
>  #define ASSIGN_FOUR_CHANNELS_PACKED   \
> -ASSIGN_THREE_CHANNELS \
> +ASSIGN_THREE_CHANNELS_PACKED  \
>  row[3] = frame->data[0] + y * frame->linesize[0] + ctx->rgba_map[3];
>
>  static void draw_region_rgb_packed(AVFrame *frame, DrawBoxContext *ctx, int
> left, int top, int right, int down,
> --
> 2.37.3
>


lgtm

> ___
> 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 5/7] swresample/swresample: Fix mismatching argument names

2022-09-15 Thread Marvin Scholz



On 15 Sep 2022, at 4:12, James Almer wrote:

> On 9/14/2022 10:52 PM, Marvin Scholz wrote:
>> ---
>>   libswresample/swresample.h | 8 
>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/libswresample/swresample.h b/libswresample/swresample.h
>> index 980be65783..83821a0930 100644
>> --- a/libswresample/swresample.h
>> +++ b/libswresample/swresample.h
>> @@ -354,8 +354,8 @@ int swr_convert(struct SwrContext *s, uint8_t **out, int 
>> out_count,
>>*  in this case the output timestamps will match output 
>> sample numbers.
>>*  See ffmpeg-resampler(1) for the two modes of compensation.
>>*
>> - * @param s[in] initialized Swr context
>> - * @param pts[in]   timestamp for the next input sample, INT64_MIN if 
>> unknown
>> + * @param[in] s initialized Swr context
>> + * @param[in] pts   timestamp for the next input sample, INT64_MIN if 
>> unknown
>>* @see swr_set_compensation(), swr_drop_output(), and 
>> swr_inject_silence() are
>>*  function used internally for timestamp compensation.
>>* @return the output timestamp for the next output sample
>> @@ -636,8 +636,8 @@ int swr_convert_frame(SwrContext *swr,
>>* @see swr_close();
>>*
>>* @param swr audio resample context
>> - * @param output  output AVFrame
>> - * @param input   input AVFrame
>> + * @param output  out   AVFrame
>> + * @param input   inAVFrame
>
> @param out output AVFrame
> @param in  input AVFrame
>

Whoops, thanks. Fixed, will wait a bit in case there are other
reviews before I send a v2.

>>* @return0 on success, AVERROR on failure.
>>*/
>>   int swr_config_frame(SwrContext *swr, const AVFrame *out, const AVFrame 
>> *in);
> ___
> 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".