[FFmpeg-devel] Audiotoolbox fix missing decoder out properties
This is a repost of the patch by Chris Snowhill who originally sent this patch on 31 December - which didn't receive any replies. As you can see on https://trac.ffmpeg.org/ticket/9564 the patch is needed and works perfectly. I have rebased it and recompiled it. Original commit description: Monterey needs mBytesPerFrame and mBytesPerPacket to be set, and I'm surprised this didn't break any previous system versions. Fixes bug #9564: Cannot decode xHE-AAC with audiotoolbox (aac_at) on Mac OS Monterey. Fixes likely bug that none of the AudioToolbox decoders work on Monterey. --- libavcodec/audiotoolboxdec.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c index b8d0e868f7..daccf4abf8 100644 --- a/libavcodec/audiotoolboxdec.c +++ b/libavcodec/audiotoolboxdec.c @@ -375,6 +375,11 @@ static av_cold int ffat_create_decoder(AVCodecContext *avctx, avctx->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC; avctx->ch_layout.nb_channels = out_format.mChannelsPerFrame = in_format.mChannelsPerFrame; +out_format.mBytesPerFrame = +out_format.mChannelsPerFrame * (out_format.mBitsPerChannel / 8); +out_format.mBytesPerPacket = +out_format.mBytesPerFrame * out_format.mFramesPerPacket; + if (avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_QT) in_format.mFramesPerPacket = 64; -- 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] avcodec/audiotoolboxdec: fix missing decoder out properties
Resubmit: fix title. This is a repost of the patch by Chris Snowhill who originally sent this patch on 31 December - which didn't receive any replies. As you can see on https://trac.ffmpeg.org/ticket/9564 the patch is needed and works perfectly. I have rebased it and recompiled it. Original commit description: Monterey needs mBytesPerFrame and mBytesPerPacket to be set, and I'm surprised this didn't break any previous system versions. Fixes bug #9564: Cannot decode xHE-AAC with audiotoolbox (aac_at) on Mac OS Monterey. Fixes likely bug that none of the AudioToolbox decoders work on Monterey. --- libavcodec/audiotoolboxdec.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c index b8d0e868f7..daccf4abf8 100644 --- a/libavcodec/audiotoolboxdec.c +++ b/libavcodec/audiotoolboxdec.c @@ -375,6 +375,11 @@ static av_cold int ffat_create_decoder(AVCodecContext *avctx, avctx->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC; avctx->ch_layout.nb_channels = out_format.mChannelsPerFrame = in_format.mChannelsPerFrame; +out_format.mBytesPerFrame = +out_format.mChannelsPerFrame * (out_format.mBitsPerChannel / 8); +out_format.mBytesPerPacket = +out_format.mBytesPerFrame * out_format.mFramesPerPacket; + if (avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_QT) in_format.mFramesPerPacket = 64; -- 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] ping, ping, just 5 lines
The patch "avcodec/audiotoolboxdec: fix missing decoder out properties" hasn't been reviewed. Could anyone with some time, please, review this patch? Audiotoolbox decoder on macOS desperately needs this to be useful. ___ 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] 2nd ping
It would be great if anyone who reads this could review this small patch (original: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295351.html): This is a repost of the patch by Chris Snowhill who originally sent this patch on 31 December - which didn't receive any replies. As you can see on https://trac.ffmpeg.org/ticket/9564 the patch is needed and works perfectly. I have rebased it and recompiled it. Original commit description: Monterey needs mBytesPerFrame and mBytesPerPacket to be set, and I'm surprised this didn't break any previous system versions. Fixes bug #9564: Cannot decode xHE-AAC with audiotoolbox (aac_at) on Mac OS Monterey. Fixes likely bug that none of the AudioToolbox decoders work on Monterey. --- libavcodec/audiotoolboxdec.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c index b8d0e868f7..daccf4abf8 100644 --- a/libavcodec/audiotoolboxdec.c +++ b/libavcodec/audiotoolboxdec.c @@ -375,6 +375,11 @@ static av_cold int ffat_create_decoder(AVCodecContext *avctx, avctx->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC; avctx->ch_layout.nb_channels = out_format.mChannelsPerFrame = in_format.mChannelsPerFrame; +out_format.mBytesPerFrame = +out_format.mChannelsPerFrame * (out_format.mBitsPerChannel / 8); +out_format.mBytesPerPacket = +out_format.mBytesPerFrame * out_format.mFramesPerPacket; + if (avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_QT) in_format.mFramesPerPacket = 64; -- 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".
Re: [FFmpeg-devel] 2nd ping
Nicely applied, many thanks!
Sent: Sunday, April 24, 2022 at 11:04 PM
From: "James Almer"
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] avdevice/dshow: reuse unused variables.
On 4/19/2022 5:13 AM, Diederick Niehorster wrote:
> Fix for f125c504d8fece6420bb97767f9e72414c26312a, requested_sample_rate
> and such should be used.
>
> Signed-off-by: Diederick Niehorster
> ---
> libavdevice/dshow.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
> index 1e69620880..5946a72cc2 100644
> --- a/libavdevice/dshow.c
> +++ b/libavdevice/dshow.c
> @@ -1003,9 +1003,9 @@ dshow_cycle_formats(AVFormatContext *avctx, enum
> dshowDeviceType devtype,
> continue;
> }
> if (
> - (ctx->sample_rate && ctx->sample_rate != fx->nSamplesPerSec) ||
> - (ctx->sample_size && ctx->sample_size != fx->wBitsPerSample) ||
> - (ctx->channels && ctx->channels != fx->nChannels )
> + (requested_sample_rate && requested_sample_rate != fx->nSamplesPerSec) ||
> + (requested_sample_size && requested_sample_size != fx->wBitsPerSample) ||
> + (requested_channels && requested_channels != fx->nChannels )
> ) {
> goto next;
> }
Will apply.
___
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] Guidance needed for a semi-breaking change
Hi, It's my first time writing an (original) patch for ffmpeg, so I would like your help. I’m planning to propose a diff to an encoder param for aac_at, which is, as currently listed by "ffmpeg -h encoder=aac_at”: -aac_at_qualityE...A.. quality vs speed control (from 0 to 2) (default 0) Currently, 0 uses HIGH, and 1, 2 use MID, LOW quality encodings. I’d like to change this param so that all 5 levels listed by Apple (MAX, HIGH, MID, LOW, MIN) can be used. Do I change it to: -aac_at_qualityE...A.. quality vs speed control (from 0 to 4) (default 0) and migrate everyone to a higher-quality encoding preset or -aac_at_qualityE...A.. quality vs speed control (from -1 to 3) (default -1) so that previous levels are kept as they are, adding only MAX and MIN, which were previously out of range. I’d like to know: Which of these aligns better with FFMPEG’s policies? Many thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Guidance needed for a semi-breaking change
I wasn't considering a breaking change, those using -aac_at_quality 0 or -aac_at_quality 2 would continue to use those. However, would moving -aac_at_quality 0 from HIGH (currently highest used by FFMPEG) to MAX be welcome? I'd assume that those using -aac_at_quality 0 do so to use the highest quality option available. If not, extending the range (0,2) to (-1,3) without moving any previous options would work. From what I understand negative numbers are OK in ffmpeg since `-q:a -1` produces higher quality than `-q:a 0` for me. How about this? Thanks again Sent: Wednesday, April 27, 2022 at 1:49 PM From: "Timo Rothenpieler" To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] Guidance needed for a semi-breaking change You need to keep API and ABI compatibility, cause otherwise it's a breaking change which can only happen at a major bump. Any and all existing applications and commandline need to keep working as they do right now. What you could do is convert the option into a OPT_TYPE_CONST one, and offer the new values as actual textual option, and set up the numerical values so that they align with what's currently offered. ___ 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] Guidance needed for a semi-breaking change
The default for AAC_AT is to produce highest quality audio, which I'll keep undoubtedly in the same direction. However, the question is this: Should the one who explicitly set `-aac_at_quality 0` (highest quality available) be moved from HIGH to MAX, HOWEVER causing the side effect of moving everyone up in the quality-speed tradeoff by one, (or we can eliminate HIGH and just replace it with MAX which has no tradeoffs AFAIK) OR add `-1`, so that only those who entered no `aac_at_quality` be moved to -1, and keeping explicit people having set `-aac_at_quality 0` at HIGH for them, although they might have meant MAX when they started using it? (i.e. no regression nor improvement for them) --- Sent: Wednesday, April 27, 2022 at 2:18 PM From: "Nicolas George" To: "FFmpeg development discussions and patches" Subject: Re: [FFmpeg-devel] Guidance needed for a semi-breaking change Timo Rothenpieler (12022-04-27): > Any existing commandline should produce the exact same output after the > change. I do not agree. Small changes in default behavior are acceptable, since the user did not specify what they want. (I would argue that changes that fix a bug and changes that are unambiguously and exclusively an improvement are acceptable.) Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ 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] Guidance needed for a semi-breaking change
Would you then approve changing current 0 from HIGH to MAX? Alternatively -1 can be added until a major bump, while keeping 0 as default. Either would be nondestructive. And do you have an example/doc text about adding version guards to an arg? I hope there's a general preprocessor variable for FFMPEGv6 Sent: Wednesday, April 27, 2022 at 4:18 PM From: "Timo Rothenpieler" To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] Guidance needed for a semi-breaking change On 27.04.2022 16:07, MCC CS wrote: > The default for AAC_AT is to produce highest quality audio, which I'll keep > undoubtedly > in the same direction. However, the question is this: > > Should the one who explicitly set `-aac_at_quality 0` (highest quality > available) be moved from HIGH to MAX, > HOWEVER causing the side effect of moving everyone up in the quality-speed > tradeoff by one, > > (or we can eliminate HIGH and just replace it with MAX which has no tradeoffs > AFAIK) > > OR add `-1`, so that only those who entered no `aac_at_quality` be moved to > -1, > and keeping explicit people having set `-aac_at_quality 0` at HIGH for them, > although they might have meant MAX when they started using it? > (i.e. no regression nor improvement for them) The strictly correct approach here would be to add version guards, and switch to the new behaviour next major bump. I do agree though that that seems a bit over the top for this, and specially if there is a higher quality than what ffmpeg currently offers, I could definitely see keeping 0 as "highest possible quality". ___ 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".
