Re: [FFmpeg-devel] [PATCH v2] avcodec/libsvtav1: add support for setting chroma sample location
On 4/25/2022 6:59 PM, Jan Ekström wrote:
Support for configuring this was added with version 1.0.0.
---
libavcodec/libsvtav1.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 2e3d96ce37..49c396387f 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -205,6 +205,33 @@ static int config_enc_params(EbSvtAv1EncConfiguration
*param,
else
param->color_range = !!(desc->flags & AV_PIX_FMT_FLAG_RGB);
+#if SVT_AV1_CHECK_VERSION(1, 0, 0)
+if (avctx->chroma_sample_location != AVCHROMA_LOC_UNSPECIFIED) {
+const char *name =
+av_chroma_location_name(avctx->chroma_sample_location);
+
+switch (avctx->chroma_sample_location) {
+case AVCHROMA_LOC_LEFT:
+param->chroma_sample_position = EB_CSP_VERTICAL;
+break;
+case AVCHROMA_LOC_TOPLEFT:
+param->chroma_sample_position = EB_CSP_COLOCATED;
+break;
+default:
+if (!name)
+break;
+
+av_log(avctx, AV_LOG_WARNING,
+ "Specified chroma sample location %s is unsupported "
+ "on the AV1 bit stream level. Usage of a container that "
+ "allows passing this information - such as Matroska - "
+ "is recommended.\n",
+ name);
+break;
+}
+}
+#endif
+
if (avctx->profile != FF_PROFILE_UNKNOWN)
param->profile = avctx->profile;
Should be ok.
___
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] avcodec/libsvtav1: pass pict_type to library
On 4/25/2022 7:54 PM, Christopher Degawa wrote:
match the behavior of SvtAv1EncApp to ensure pic_type is always set
before passing it to the library.
The other options for pic_type aren't currently used inside the library,
so they aren't introduced in this patch.
Signed-off-by: Christopher Degawa
---
libavcodec/libsvtav1.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 2e3d96ce37..088b9bab02 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -404,6 +404,16 @@ static int eb_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
headerPtr->p_app_private = NULL;
headerPtr->pts = frame->pts;
+switch (frame->pict_type) {
+case AV_PICTURE_TYPE_I:
+headerPtr->pic_type = EB_AV1_KEY_PICTURE;
+break;
+default:
+// Actually means auto, or default.
+headerPtr->pic_type = EB_AV1_INVALID_PICTURE;
+break;
+}
+
svt_av1_enc_send_picture(svt_enc->svt_handle, headerPtr);
return 0;
Should be ok.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avcodec/libsvtav1: pass pict_type to library
match the behavior of SvtAv1EncApp to ensure pic_type is always set
before passing it to the library.
The other options for pic_type aren't currently used inside the library,
so they aren't introduced in this patch.
Signed-off-by: Christopher Degawa
---
libavcodec/libsvtav1.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 2e3d96ce37..088b9bab02 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -404,6 +404,16 @@ static int eb_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
headerPtr->p_app_private = NULL;
headerPtr->pts = frame->pts;
+switch (frame->pict_type) {
+case AV_PICTURE_TYPE_I:
+headerPtr->pic_type = EB_AV1_KEY_PICTURE;
+break;
+default:
+// Actually means auto, or default.
+headerPtr->pic_type = EB_AV1_INVALID_PICTURE;
+break;
+}
+
svt_av1_enc_send_picture(svt_enc->svt_handle, headerPtr);
return 0;
--
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] [PATCH] avcodec/libsvtav1: pass pict_type to library
On 4/25/2022 7:37 PM, Christopher Degawa wrote:
match the behavior of SvtAv1EncApp to ensure pic_type is always set
before passing it to the library.
The other options for pic_type aren't currently used inside the library,
so they aren't introduced in this patch.
Signed-off-by: Christopher Degawa
---
libavcodec/libsvtav1.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 2e3d96ce37..eafb762a7d 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -404,6 +404,11 @@ static int eb_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
headerPtr->p_app_private = NULL;
headerPtr->pts = frame->pts;
+switch (frame->pict_type) {
+case AV_PICTURE_TYPE_I: headerPtr->pic_type = EB_AV1_KEY_PICTURE; break;
+default: headerPtr->pic_type = EB_AV1_INVALID_PICTURE; break; // Actually
means auto, or default.
+}
Please align these vertically if you're not using separate lines.
+
svt_av1_enc_send_picture(svt_enc->svt_handle, headerPtr);
return 0;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/rtsp: pkt_size option is not honored in rtsp
Yes, only impact using TCP as the transport. From: ffmpeg-devel on behalf of Tristan Matthews Sent: Tuesday, April 19, 2022 7:03 AM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH] libavformat/rtsp: pkt_size option is not honored in rtsp On Wed, Apr 6, 2022 at 10:04 AM Zhao Zhili wrote: > > > 在 2022年4月6日，下午9:49，Yubo Xie 写道： > > > > Yes, I've removed it already. > > Sorry I missed that. LGTM. > Nice catch, I guess this bug only impacted using TCP as the media-transport? I'm guessing I only tested UDP at the time. Best, Tristan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpeg-develdata=05%7C01%7C%7C67d43f7f7013450b099d08da220d704a%7C84df9e7fe9f640afb435%7C1%7C0%7C637859738357962087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=SlNeWN0R58SKEfBvkqphfltqo9xEFvIft4glZHmuomk%3Dreserved=0 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/libsvtav1: pass pict_type to library
match the behavior of SvtAv1EncApp to ensure pic_type is always set
before passing it to the library.
The other options for pic_type aren't currently used inside the library,
so they aren't introduced in this patch.
Signed-off-by: Christopher Degawa
---
libavcodec/libsvtav1.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 2e3d96ce37..eafb762a7d 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -404,6 +404,11 @@ static int eb_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
headerPtr->p_app_private = NULL;
headerPtr->pts = frame->pts;
+switch (frame->pict_type) {
+case AV_PICTURE_TYPE_I: headerPtr->pic_type = EB_AV1_KEY_PICTURE; break;
+default: headerPtr->pic_type = EB_AV1_INVALID_PICTURE; break; // Actually
means auto, or default.
+}
+
svt_av1_enc_send_picture(svt_enc->svt_handle, headerPtr);
return 0;
--
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 v2] avcodec/libsvtav1: add support for setting chroma sample location
Support for configuring this was added with version 1.0.0.
---
libavcodec/libsvtav1.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 2e3d96ce37..49c396387f 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -205,6 +205,33 @@ static int config_enc_params(EbSvtAv1EncConfiguration
*param,
else
param->color_range = !!(desc->flags & AV_PIX_FMT_FLAG_RGB);
+#if SVT_AV1_CHECK_VERSION(1, 0, 0)
+if (avctx->chroma_sample_location != AVCHROMA_LOC_UNSPECIFIED) {
+const char *name =
+av_chroma_location_name(avctx->chroma_sample_location);
+
+switch (avctx->chroma_sample_location) {
+case AVCHROMA_LOC_LEFT:
+param->chroma_sample_position = EB_CSP_VERTICAL;
+break;
+case AVCHROMA_LOC_TOPLEFT:
+param->chroma_sample_position = EB_CSP_COLOCATED;
+break;
+default:
+if (!name)
+break;
+
+av_log(avctx, AV_LOG_WARNING,
+ "Specified chroma sample location %s is unsupported "
+ "on the AV1 bit stream level. Usage of a container that "
+ "allows passing this information - such as Matroska - "
+ "is recommended.\n",
+ name);
+break;
+}
+}
+#endif
+
if (avctx->profile != FF_PROFILE_UNKNOWN)
param->profile = avctx->profile;
--
2.36.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavf/tls_mbedtls: add support for mbedtls version 3
On Sun, Apr 24, 2022 at 2:33 AM Timo Rothenpieler wrote:
>
> - certs.h is gone. Only contains test data, and was not used at all.
> - config.h is renamed. Was seemingly not used, so can be removed.
> - MBEDTLS_ERR_SSL_NO_USABLE_CIPHERSUITE is gone, instead
> MBEDTLS_ERR_SSL_HANDSHAKE_FAILURE will be thrown.
> - mbedtls_pk_parse_keyfile now needs to be passed a properly seeded
> RNG. Hence, move the call to after RNG seeding.
>
> Signed-off-by: Timo Rothenpieler
> ---
> libavformat/tls_mbedtls.c | 34 ++
> 1 file changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/libavformat/tls_mbedtls.c b/libavformat/tls_mbedtls.c
> index 5754d0d018..8503523b6d 100644
> --- a/libavformat/tls_mbedtls.c
> +++ b/libavformat/tls_mbedtls.c
> @@ -19,8 +19,7 @@
> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> */
>
> -#include
> -#include
> +#include
> #include
> #include
> #include
> @@ -130,9 +129,15 @@ static void handle_pk_parse_error(URLContext *h, int ret)
> static void handle_handshake_error(URLContext *h, int ret)
> {
> switch (ret) {
> +#if MBEDTLS_VERSION_MAJOR < 3
> case MBEDTLS_ERR_SSL_NO_USABLE_CIPHERSUITE:
> av_log(h, AV_LOG_ERROR, "None of the common ciphersuites is usable.
> Was the local certificate correctly set?\n");
> break;
> +#else
> +case MBEDTLS_ERR_SSL_HANDSHAKE_FAILURE:
> +av_log(h, AV_LOG_ERROR, "TLS handshake failed.\n");
> +break;
> +#endif
> case MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE:
> av_log(h, AV_LOG_ERROR, "A fatal alert message was received from the
> peer, has the peer a correct certificate?\n");
> break;
> @@ -195,16 +200,6 @@ static int tls_open(URLContext *h, const char *uri, int
> flags, AVDictionary **op
> }
> }
>
> -// load key file
> -if (shr->key_file) {
> -if ((ret = mbedtls_pk_parse_keyfile(_ctx->priv_key,
> -shr->key_file,
> -tls_ctx->priv_key_pw)) != 0) {
> -handle_pk_parse_error(h, ret);
> -goto fail;
> -}
> -}
> -
> // seed the random number generator
> if ((ret = mbedtls_ctr_drbg_seed(_ctx->ctr_drbg_context,
> mbedtls_entropy_func,
> @@ -214,6 +209,21 @@ static int tls_open(URLContext *h, const char *uri, int
> flags, AVDictionary **op
> goto fail;
> }
>
> +// load key file
> +if (shr->key_file) {
> +if ((ret = mbedtls_pk_parse_keyfile(_ctx->priv_key,
> +shr->key_file,
> +tls_ctx->priv_key_pw
> +#if MBEDTLS_VERSION_MAJOR >= 3
> +, mbedtls_ctr_drbg_random,
> +_ctx->ctr_drbg_context
> +#endif
> +)) != 0) {
> +handle_pk_parse_error(h, ret);
> +goto fail;
> +}
> +}
> +
Seems correct enough as the RNG is then utilized in the TLS
configuration as well.
As long as the mbedtls API documentation notes that it is OK to
utilize the same RNG for both this as well as the TLS configuration
itself, this seems fine.
Jan
___
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/libsvtav1: add support for setting chroma sample location
On 4/25/2022 6:02 PM, Jan Ekström wrote:
Support for configuring this was added with version 1.0.0.
---
libavcodec/libsvtav1.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 2e3d96ce37..a670dab822 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -205,6 +205,28 @@ static int config_enc_params(EbSvtAv1EncConfiguration
*param,
else
param->color_range = !!(desc->flags & AV_PIX_FMT_FLAG_RGB);
+#if SVT_AV1_CHECK_VERSION(1, 0, 0)
+if (avctx->chroma_sample_location != AVCHROMA_LOC_UNSPECIFIED) {
+switch (avctx->chroma_sample_location) {
+case AVCHROMA_LOC_LEFT:
+param->chroma_sample_position = EB_CSP_VERTICAL;
+break;
+case AVCHROMA_LOC_TOPLEFT:
+param->chroma_sample_position = EB_CSP_COLOCATED;
+break;
+default:
+av_log(avctx, AV_LOG_INFO,
+ "Specified chroma sample location %s (%d) is unsupported "
+ "on the AV1 bit stream level. Usage of a container that "
+ "allows passing this information - such as Matroska - "
+ "is recommended.\n",
+ av_chroma_location_name(avctx->chroma_sample_location),
This can return NULL on invalid AVChromaLocation values, so better check
for that and print a different log message.
+ avctx->chroma_sample_location);
+break;
+}
+}
+#endif
+
if (avctx->profile != FF_PROFILE_UNKNOWN)
param->profile = avctx->profile;
___
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/libsvtav1: add support for setting chroma sample location
Support for configuring this was added with version 1.0.0.
---
libavcodec/libsvtav1.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 2e3d96ce37..a670dab822 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -205,6 +205,28 @@ static int config_enc_params(EbSvtAv1EncConfiguration
*param,
else
param->color_range = !!(desc->flags & AV_PIX_FMT_FLAG_RGB);
+#if SVT_AV1_CHECK_VERSION(1, 0, 0)
+if (avctx->chroma_sample_location != AVCHROMA_LOC_UNSPECIFIED) {
+switch (avctx->chroma_sample_location) {
+case AVCHROMA_LOC_LEFT:
+param->chroma_sample_position = EB_CSP_VERTICAL;
+break;
+case AVCHROMA_LOC_TOPLEFT:
+param->chroma_sample_position = EB_CSP_COLOCATED;
+break;
+default:
+av_log(avctx, AV_LOG_INFO,
+ "Specified chroma sample location %s (%d) is unsupported "
+ "on the AV1 bit stream level. Usage of a container that "
+ "allows passing this information - such as Matroska - "
+ "is recommended.\n",
+ av_chroma_location_name(avctx->chroma_sample_location),
+ avctx->chroma_sample_location);
+break;
+}
+}
+#endif
+
if (avctx->profile != FF_PROFILE_UNKNOWN)
param->profile = avctx->profile;
--
2.36.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi
Thus far I've avoided jumping into this because I genuinely do not care about Windows' code page shenanigans or what-all, but because this seems to be zeroing in on one thing in particular... On 4/25/22 5:03 AM, nil-admir...@mailo.com wrote: If you were to look at the code, you would've seen that charset conversion was already there. AviSynth is not Unicode-aware, it expects ANSI strings. Inline charset conversion was replaced by a library call, which, again, was already there, only slightly extended. > Which is necessary for compatibility with AviSynth, It has nothing to do with compatibility with AviSynth, because AviSynth just uses the code page the system is set on. What 'it's not Unicode-aware' means is that it doesn't jump into convoluted conversions to UTF-16, because that's what Windows meant by 'Unicode' for 20+ years, and nobody from either classic AviSynth or Plus wanted to do that, because it's an absolute mess and now that Plus is cross-platform, utterly pointless on every other OS, because they all use UTF-8 and have for at least 15 years, if not [much] longer. Some third-party applications that utilize AviSynth have decided they want to bend over backwards to make sure their users don't have to freak themselves out by telling Windows to use UTF-8 as the system code page, so they'll do an end-run around it and use these sorts of manifests to force the program's locale to UTF-8, AppLocale style. But that's not a compatibility issue with AviSynth. As soon as Microsoft actually makes UTF-8 the default code page going forward, that issue will poof out of existence, as if by magic. It already does if you toggle it on in the system settings. Nothing special was required regarding locale support when Linux, macOS, BSD, and Haiku support landed. All of those use UTF-8 and AviSynth+ works with it transparently. And it works with UTF-8 on Windows transparently if you've gone into the Region Settings and actually enabled it. Even AviSynth 2.6 is cool with it, as this screenshot from *two years ago* illustrates: https://i.imgur.com/1p5osrE.jpg ___ 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] libavcodec/videotoolboxenc.c: add option to hevc encoder to prioritize speed.
> Am 25.04.2022 um 21:14 schrieb Rick Kern :
>
>>
>>{ "a53cc", "Use A53 Closed Captions (if available)", OFFSET(a53_cc),
>> AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, VE },
>> +{ "prio_speed", "prioritize encoding speed", OFFSET(prio_speed),
>> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
>>
> It might be simpler to make the default value of prio_speed -1, and set
> this property on the encoder session only when it's non-negative. Then we
> won't need to worry about the default value changing for different codecs
> or different OS versions. It could also be moved into COMMON_OPTIONS in
> this case.
oh yes, that’s way better. I didn’t think of that in the first place. Thanks
for the hint.
Here’s the modified patch
Simone
0001-add-options-to-h264-hevc-and-prores-encoders-to-prio.patch
Description: Binary data
___
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 00/21] avdevice (mostly dshow) enhancements
Ping for the series, especially the first commit in the series which should spark some discussion. Thanks! Dee On Wed, Mar 30, 2022 at 2:18 PM Diederick Niehorster wrote: > > This patch series implements a series of features, mostly enhancing the > dshow avdevice, but also adding new functionality to avformat. > This whole patchset enabled users of the FFmpeg API to fully > query and control a dshow device, making FFmpeg a nice backend for any > program that needs access to, e.g., a webcam. > > Different from v3 and v4, part of the patches has now been accepted, so > only remaining features are in this set. Importantly, as per discussion > on the list ( > https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281513.html, see > especially https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281586.html), > to resolve the the unholy ABI-relationship between libavdevice and > libavformat and allow easier working on the part of the avdevice API > that lives in avformat, avdevice is now locked to a specific major and minor > version of avformat. This is documented in libavdevice/avdevice.h. > > Regarding new functionality added to avformat: > Querying the capabilities of a dshow device is also possible on a > device that is already opened. I expect/guess however that it may not be > possible to achieve that for all of the avdevices, so in principle it is > important that this patchset adds the ability to create an allocated but > unopened AVFormatContext+AVInputFormat with the new function > avformat_alloc_input_context(). This is tested in the new > device_get_capabilities example. > > Diederick Niehorster (21): > avdevice: lock to minor version of avformat > avformat: add control_message function to AVInputFormat > avdevice/dshow: implement control_message interface > avdevice: add control message requesting to show config dialog > avdevice/dshow: accept show config dialog control message > avdevice/dshow: add config dialog command for crossbar and tv tuner > avdevice/avdevice: Revert "Deprecate AVDevice Capabilities API" > avdevice/avdevice: clean up avdevice_capabilities_create > avdevice: capabilities API details no longer public > avutil/opt: document AVOptionRange min_value > max_value > avdevice: Add internal helpers for querying device capabilities > avdevice: change device capabilities option type > avdevice: improve capabilities' option API > avdevice/dshow: move audio format helpers > avdevice/dshow: when closing, set context fields back to zero > avdevice/dshow: implement capabilities API > avdevice/dshow: cosmetics > avformat: add avformat_alloc_input_context() > doc/examples: adding device_get_capabilities example > Makefile/examples: cosmetics > avdevice/dshow: capabilities query also works on opened device > > configure | 2 + > doc/examples/.gitignore| 1 + > doc/examples/Makefile | 47 +- > doc/examples/Makefile.example | 1 + > doc/examples/device_get_capabilities.c | 243 ++ > doc/indevs.texi| 34 ++ > libavdevice/avdevice.c | 177 ++- > libavdevice/avdevice.h | 111 ++--- > libavdevice/dshow.c| 641 +++-- > libavdevice/dshow_capture.h| 14 + > libavdevice/dshow_crossbar.c | 91 ++-- > libavdevice/internal.h | 66 +++ > libavdevice/utils.c| 48 ++ > libavdevice/version.h | 15 +- > libavdevice/version_major.h| 2 +- > libavformat/avformat.h | 59 ++- > libavformat/demux.c| 74 ++- > libavformat/utils.c| 5 + > libavformat/version.h | 14 +- > libavutil/avutil.h | 3 + > libavutil/macros.h | 3 + > libavutil/opt.c| 2 +- > libavutil/opt.h| 5 + > 23 files changed, 1462 insertions(+), 196 deletions(-) > create mode 100644 doc/examples/device_get_capabilities.c > > -- > 2.28.0.windows.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] FFmpeg 5.0 LTS vs 5.1 LTS
On Mon, 25 Apr 2022, at 20:40, Michael Niedermayer wrote: > On Mon, Apr 25, 2022 at 08:04:25PM +0200, Jean-Baptiste Kempf wrote: >> On Mon, 25 Apr 2022, at 19:19, Michael Niedermayer wrote: >> > On Mon, Apr 25, 2022 at 01:51:26PM +0200, Jean-Baptiste Kempf wrote: >> >> On Sat, 23 Apr 2022, at 18:36, Michael Niedermayer wrote: >> >> > Do people prefer that 5.0 becomes LTS or the next (5.1) ? >> >> > Or something else ? >> >> >> >> My understanding of the consensus was; >> >> - 5.0 in Dec/Jan >> >> - 5.1 in Jul with API additions, but no ABI/behavior breakage >> > >> > yes >> >> OK. >> >> >> - 6.0 in Dec 22 with ABI/API/behavior breakage and while 5.1 becomes LTS >> > >> > we could give 5.1 an LTS "tag" when its released already >> >> I would mention it, tbh. >> >> > also thers the possibility that by december we have nothing that really >> > benefits from a ABI/API/behavior breakage. >> > If that happens people might prefer 5.2 over 6.0 i dont know. >> >> I think it would be clearer to accustom people that we have one big >> potential change every year, at the same date. > > thats not a bad idea. Still bumping the sonames of the libs when there is > no reason is not really nice. I dont know if we will have a reason in december A major number does not mean major soname bump if not needed. This is release numbers. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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] FFmpeg 5.0 LTS vs 5.1 LTS
> -Original Message- > From: ffmpeg-devel On Behalf Of > Michael Niedermayer > Sent: Monday, April 25, 2022 8:40 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] FFmpeg 5.0 LTS vs 5.1 LTS > > On Mon, Apr 25, 2022 at 08:04:25PM +0200, Jean-Baptiste Kempf wrote: > > On Mon, 25 Apr 2022, at 19:19, Michael Niedermayer wrote: > > > On Mon, Apr 25, 2022 at 01:51:26PM +0200, Jean-Baptiste Kempf > wrote: > > >> On Sat, 23 Apr 2022, at 18:36, Michael Niedermayer wrote: > > >> > Do people prefer that 5.0 becomes LTS or the next (5.1) ? > > >> > Or something else ? > > >> > > >> My understanding of the consensus was; > > >> - 5.0 in Dec/Jan > > >> - 5.1 in Jul with API additions, but no ABI/behavior breakage > > > > > > yes > > > > OK. > > > > >> - 6.0 in Dec 22 with ABI/API/behavior breakage and while 5.1 > becomes LTS > > > > > > we could give 5.1 an LTS "tag" when its released already > > > > I would mention it, tbh. > > > > > also thers the possibility that by december we have nothing that > really > > > benefits from a ABI/API/behavior breakage. > > > If that happens people might prefer 5.2 over 6.0 i dont know. > > > > I think it would be clearer to accustom people that we have one big > potential change every year, at the same date. > > thats not a bad idea. Still bumping the sonames of the libs when there > is > no reason is not really nice. I dont know if we will have a reason in > december I think, the most valid reason to increase a version number is the publishing of a release :-) Totally crazy concept: ffmpeg 6.0 libavutil.so.6.0.100 libavcodec.so.6.0.100 libavfilter.so.6.0.100 libavformat.so.6.0.100 ... ffmpeg 6.1 libavutil.so.6.1.100 libavcodec.so.6.1.100 libavfilter.so.6.1.100 libavformat.so.6.1.100 ... Best, softworkz (yes, I mean no cross-version compatibility) ___ 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] libavcodec/videotoolboxenc.c: add option to hevc encoder to prioritize speed.
On Sat, Apr 23, 2022 at 8:31 AM Simone Karin Lehmann
wrote:
>
>
> > Am 22.04.2022 um 18:52 schrieb Thilo Borgmann :
> >
> >
>
> > For that version I get:
> >
> > libavcodec/videotoolboxenc.c:1153:39: error: use of undeclared
> identifier 'kVTCompressionPropertyKey_PrioritizeEncodingSpeedOverQuality'
> >
> kVTCompressionPropertyKey_PrioritizeEncodingSpeedOverQuality,
> > ^
> >
> > Should require some OSX version dependency via #if'ery somewhere sane.
> Like
> > #if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
> >
> > or similar.
>
> If I understand the code correctly, it seems to me to be bettter to add
> kVTCompressionPropertyKey_PrioritizeEncodingSpeedOverQuality to the
> compat_keys struct.
>
> And digging through the SDK headers I’ve found that this property is
> available for h264 and ProRes encoders too. But since the SDK states that
> this property defaults to FALSE for h264 and hevc and to TRUE for ProRes I
> didn’t add it to the COMMON_OPTIONS but to each encoder options, because I
> didn’t want to make a regression to the ProRes or enabling it by default
> for h264 and hevc. Hope that’s ok.
>
> Here’s the resulting patch
>
> Regards
> Simone
>
>
> Signed-off-by: Simone Karin Lehmann sim...@lisanet.de>>
> ---
> libavcodec/videotoolboxenc.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> index 270496b7a7..462d2a8fb6 100644
> --- a/libavcodec/videotoolboxenc.c
> +++ b/libavcodec/videotoolboxenc.c
> @@ -100,6 +100,7 @@ static struct{
>
> CFStringRef kVTCompressionPropertyKey_RealTime;
> CFStringRef kVTCompressionPropertyKey_TargetQualityForAlpha;
> +CFStringRef
> kVTCompressionPropertyKey_PrioritizeEncodingSpeedOverQuality;
>
> CFStringRef
> kVTVideoEncoderSpecification_EnableHardwareAcceleratedVideoEncoder;
> CFStringRef
> kVTVideoEncoderSpecification_RequireHardwareAcceleratedVideoEncoder;
> @@ -161,6 +162,8 @@ static void loadVTEncSymbols(){
> GET_SYM(kVTCompressionPropertyKey_RealTime, "RealTime");
> GET_SYM(kVTCompressionPropertyKey_TargetQualityForAlpha,
> "TargetQualityForAlpha");
> +GET_SYM(kVTCompressionPropertyKey_PrioritizeEncodingSpeedOverQuality,
> +"PrioritizeEncodingSpeedOverQuality");
>
>
> GET_SYM(kVTVideoEncoderSpecification_EnableHardwareAcceleratedVideoEncoder,
> "EnableHardwareAcceleratedVideoEncoder");
> @@ -237,6 +240,7 @@ typedef struct VTEncContext {
> int allow_sw;
> int require_sw;
> double alpha_quality;
> +int prio_speed;
>
> bool flushing;
> int has_b_frames;
> @@ -1146,6 +1150,16 @@ static int vtenc_create_encoder(AVCodecContext
> *avctx,
> return AVERROR_EXTERNAL;
> }
>
> +// prioritize speed over quality
> +if (vtctx->prio_speed) {
+status = VTSessionSetProperty(vtctx->session,
> +
> compat_keys.kVTCompressionPropertyKey_PrioritizeEncodingSpeedOverQuality,
> + kCFBooleanTrue);
> +if (status) {
> +av_log(avctx, AV_LOG_WARNING,
> "PrioritizeEncodingSpeedOverQuality property is not supported on this
> device. Ignoring.\n");
> +}
> +}
> +
> if ((vtctx->codec_id == AV_CODEC_ID_H264 || vtctx->codec_id ==
> AV_CODEC_ID_HEVC)
> && max_rate > 0) {
> bytes_per_second_value = max_rate >> 3;
> @@ -2711,6 +2725,7 @@ static const AVOption h264_options[] = {
> { "ac","CABAC entropy coding", 0, AV_OPT_TYPE_CONST, { .i64 =
> VT_CABAC }, INT_MIN, INT_MAX, VE, "coder" },
>
> { "a53cc", "Use A53 Closed Captions (if available)", OFFSET(a53_cc),
> AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, VE },
> +{ "prio_speed", "prioritize encoding speed", OFFSET(prio_speed),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
>
It might be simpler to make the default value of prio_speed -1, and set
this property on the encoder session only when it's non-negative. Then we
won't need to worry about the default value changing for different codecs
or different OS versions. It could also be moved into COMMON_OPTIONS in
this case.
>
> COMMON_OPTIONS
> { NULL },
> @@ -2745,6 +2760,7 @@ static const AVOption hevc_options[] = {
> { "main10", "Main10 Profile", 0, AV_OPT_TYPE_CONST, { .i64 =
> HEVC_PROF_MAIN10 }, INT_MIN, INT_MAX, VE, "profile" },
>
> { "alpha_quality", "Compression quality for the alpha channel",
> OFFSET(alpha_quality), AV_OPT_TYPE_DOUBLE, { .dbl = 0.0 }, 0.0, 1.0, VE },
> +{ "prio_speed", "prioritize encoding speed", OFFSET(prio_speed),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
>
> COMMON_OPTIONS
> { NULL },
> @@ -2785,6 +2801,8 @@ static const AVOption prores_options[] = {
> { "", "ProRes ", 0,
> AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_PRORES_ },INT_MIN,
> INT_MAX, VE, "profile" },
> { "xq", "ProRes XQ",
Re: [FFmpeg-devel] [PATCH 2/2] lavfi: Add blurriness filter
Am 25.04.22 um 00:08 schrieb Thilo Borgmann: Am 25.04.22 um 00:03 schrieb Thilo Borgmann: Am 24.04.22 um 19:28 schrieb Thilo Borgmann: Am 23.04.22 um 15:32 schrieb Thilo Borgmann: Hi, v3 updated to current HEAD. Named blurdetect filter now. Minor fixes on allocation and removed -f option. Please make this per plane filtering, with default to measure only first plane. done in v4. (Will add Changelog, version.h and fate test once the filter itself looks ok) Ping. v5 according to IRC comments. v6 (1/2 and 2/2) according to IRC comments. LGTM'd there, applying soon. Added Changelog, version.h, FATE. v7: removed useless debug garbage. Still applying soon. v8: and now even with adapted FATE. Pushed, thanks! -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 5.0 LTS vs 5.1 LTS
On Mon, Apr 25, 2022 at 08:04:25PM +0200, Jean-Baptiste Kempf wrote: > On Mon, 25 Apr 2022, at 19:19, Michael Niedermayer wrote: > > On Mon, Apr 25, 2022 at 01:51:26PM +0200, Jean-Baptiste Kempf wrote: > >> On Sat, 23 Apr 2022, at 18:36, Michael Niedermayer wrote: > >> > Do people prefer that 5.0 becomes LTS or the next (5.1) ? > >> > Or something else ? > >> > >> My understanding of the consensus was; > >> - 5.0 in Dec/Jan > >> - 5.1 in Jul with API additions, but no ABI/behavior breakage > > > > yes > > OK. > > >> - 6.0 in Dec 22 with ABI/API/behavior breakage and while 5.1 becomes LTS > > > > we could give 5.1 an LTS "tag" when its released already > > I would mention it, tbh. > > > also thers the possibility that by december we have nothing that really > > benefits from a ABI/API/behavior breakage. > > If that happens people might prefer 5.2 over 6.0 i dont know. > > I think it would be clearer to accustom people that we have one big potential > change every year, at the same date. thats not a bad idea. Still bumping the sonames of the libs when there is no reason is not really nice. I dont know if we will have a reason in december 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] FFmpeg 5.0 LTS vs 5.1 LTS
On 4/25/2022 2:19 PM, Michael Niedermayer wrote: On Mon, Apr 25, 2022 at 01:51:26PM +0200, Jean-Baptiste Kempf wrote: On Sat, 23 Apr 2022, at 18:36, Michael Niedermayer wrote: Do people prefer that 5.0 becomes LTS or the next (5.1) ? Or something else ? My understanding of the consensus was; - 5.0 in Dec/Jan - 5.1 in Jul with API additions, but no ABI/behavior breakage yes - 6.0 in Dec 22 with ABI/API/behavior breakage and while 5.1 becomes LTS we could give 5.1 an LTS "tag" when its released already also thers the possibility that by december we have nothing that really benefits from a ABI/API/behavior breakage. If that happens people might prefer 5.2 over 6.0 i dont know. An ABI bump doesn't need to be justified by the need to break something for the sake of an addition, like new fields to structs with ABI-tied size (of which there are not many, for that matter). It could simply be done in an scheduled manner to get rid of deprecated stuff that's old enough to be dropped, giving the project some predictability, and keeping the tree clean-ish. thx [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ 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] FFmpeg 5.0 LTS vs 5.1 LTS
On Mon, 25 Apr 2022, at 19:19, Michael Niedermayer wrote: > On Mon, Apr 25, 2022 at 01:51:26PM +0200, Jean-Baptiste Kempf wrote: >> On Sat, 23 Apr 2022, at 18:36, Michael Niedermayer wrote: >> > Do people prefer that 5.0 becomes LTS or the next (5.1) ? >> > Or something else ? >> >> My understanding of the consensus was; >> - 5.0 in Dec/Jan >> - 5.1 in Jul with API additions, but no ABI/behavior breakage > > yes OK. >> - 6.0 in Dec 22 with ABI/API/behavior breakage and while 5.1 becomes LTS > > we could give 5.1 an LTS "tag" when its released already I would mention it, tbh. > also thers the possibility that by december we have nothing that really > benefits from a ABI/API/behavior breakage. > If that happens people might prefer 5.2 over 6.0 i dont know. I think it would be clearer to accustom people that we have one big potential change every year, at the same date. jb -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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] FFmpeg 5.0 LTS vs 5.1 LTS
On Mon, Apr 25, 2022 at 01:51:26PM +0200, Jean-Baptiste Kempf wrote: > On Sat, 23 Apr 2022, at 18:36, Michael Niedermayer wrote: > > Do people prefer that 5.0 becomes LTS or the next (5.1) ? > > Or something else ? > > My understanding of the consensus was; > - 5.0 in Dec/Jan > - 5.1 in Jul with API additions, but no ABI/behavior breakage yes > - 6.0 in Dec 22 with ABI/API/behavior breakage and while 5.1 becomes LTS we could give 5.1 an LTS "tag" when its released already also thers the possibility that by december we have nothing that really benefits from a ABI/API/behavior breakage. If that happens people might prefer 5.2 over 6.0 i dont know. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri 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 v2] avformat/mpegts: set data broadcast streams as such
On Mon, Apr 25, 2022 at 3:19 PM Jan Ekström wrote: > > On Mon, Apr 25, 2022 at 2:33 PM Jan Ekström wrote: > > > > On Mon, Apr 25, 2022 at 1:36 PM Jan Ekström wrote: > > > > > > On Tue, Apr 19, 2022 at 11:06 PM Marton Balint wrote: > > > > > > > > > > > > > > > > On Tue, 19 Apr 2022, Jan Ekström wrote: > > > > > > > > > On Tue, Apr 19, 2022 at 1:13 PM Jan Ekström wrote: > > > > >> > > > > >> On Tue, Apr 19, 2022 at 3:00 AM Marton Balint wrote: > > > > >> > > > > > >> > > > > > >> > > > > > >> > On Thu, 14 Apr 2022, Jan Ekström wrote: > > > > >> > > > > > >> > > On Mon, Apr 11, 2022 at 1:50 PM Jan Ekström > > > > >> > > wrote: > > > > >> > >> > > > > >> > >> From: Jan Ekström > > > > >> > >> > > > > >> > >> Additionally, they should not be probed, as this is essentially > > > > >> > >> various types of binary data. > > > > >> > >> > > > > >> > >> Signed-off-by: Jan Ekström > > > > >> > >> --- > > > > >> > > > > > > >> > > Ping. > > > > >> > > > > > > >> > > Basically this checks if we have an unknown stream with a private > > > > >> > > stream type still at the end of the per-stream loop in PMT > > > > >> > > parsing, > > > > >> > > and then cancels the stop of parsing that usually occurs as a > > > > >> > > PMT is > > > > >> > > hit. Instead the logic will continue parsing further. When an > > > > >> > > SDT is > > > > >> > > then found and a PMT for that program has already been received, > > > > >> > > it > > > > >> > > will then stop header reading at that point. > > > > >> > > > > > >> > But why does it matter when the initial parsing is stopped? I mean > > > > >> > it > > > > >> > stops at the first PMT right now, nobody expects it to find all the > > > > >> > programs and all the streams or all the stream codecs/parameters. > > > > >> > > > > > >> > I am saying, that ideally, the ts->stop_parse magic should not be > > > > >> > needed > > > > >> > to be changed to fix your issue and when an SDT is detected with > > > > >> > the > > > > >> > broadcast descriptor that should stop any existing data stream > > > > >> > parsing. Do > > > > >> > you know why it does not work like that? > > > > >> > > > > > >> > > > > >> If the codec is unknown after header parsing, the general parsing > > > > >> logic is utilized to probe which codec is possibly in that unknown > > > > >> stream, and thus more data is read from that stream, which can cause > > > > >> further delays. > > > > >> > > > > >> If the codec is known as data, it leads to no such result. > > > > >> > > > > >> Basically, the idea is to figure out whether a stream is a data > > > > >> stream > > > > >> or not during header parsing, if possible. > > > > >> > > > > > > > > > > Just double-checked and the difference is whether > > > > > max_stream_analyze_duration gets utilized in > > > > > libavformat/demux.c::avformat_find_stream_info . > > > > > > > > > > If a stream is marked as unknown, it will get checked for longer. If > > > > > it is marked as a known "codec" it gets through quicker. > > > > > > > > The part of the patch which parses the SDT and sets the codec is fine. > > > > But the fact that you have to set the codec during mpegts_read_header > > > > to make it stop parsing definitely looks like some bug in some code > > > > somewhere. It should be enough to set the codec sometime later in > > > > mpegts_read_packet() (which is called during > > > > avformat_find_stream_info()) > > > > > > > > Or to make it even more strange: comment out handle_packets() in > > > > mpegts_read_header. And it will work just fine. So if nothing is parsed > > > > in mpegts_read_header then it works. If something is parsed, then it > > > > does > > > > not. Kind of unexpected... > > > > > > > > Regards, > > > > Marton > > > > > > Hi, > > > > > > So I poked at this again and did the changes you requested. The result > > > is that if the "continue parsing until SDT if you have these sorts of > > > streams in-band" logic is removed, it leads to the FATE test ending up > > > with the result of "codec_name=unknown". Which makes the test rather > > > useless as it doesn't actually show that the stream is noted as a data > > > stream. Additionally, I thought the logic made sense since as much as > > > I dislike having information outside of PMT being utilized for PMT > > > purposes, that is effectively what this SDT descriptor is utilized > > > for. Given I specifically limited this logic to unknown streams within > > > a specific stream identifier range, the effect of this change would > > > have been far-from-global as well. > > > > > > I have a hunch that information is copied from the lavf-internal codec > > > context to codecpar at one point, and then no further synchronization > > > is attempted. > > > > So, when checking the following diff: > > > > diff --git a/libavformat/demux.c b/libavformat/demux.c > > index ad7b5dbf83..6e483acb10 100644 > > --- a/libavformat/demux.c > > +++ b/libavformat/demux.c > > @@ -2909,6 +2909,11 @@ int
Re: [FFmpeg-devel] [PATCH 2/2] avfilter: add colorchart video filter
It's missing in the table of contents of the documentation. ___ 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 v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi
> -Original Message- > From: ffmpeg-devel On Behalf Of > Martin Storsjö > Sent: Monday, April 25, 2022 3:02 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v11 1/6] > libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and > utf8toansi > > On Mon, 25 Apr 2022, Hendrik Leppkes wrote: > > > On Mon, Apr 25, 2022 at 1:12 PM Soft Works > wrote: > >> > >> From my point of view: > >> ffmpeg is already working pretty well in handling long file paths > (also with > >> Unicode characters) when pre-fixing paths with \\?\, and this is > working > >> on all Windows versions without all the caveats, requirements and > conditions > >> that I mentioned. > > > > "We have already worked around this problem in our deployment, > > therefore there is no need to try to improve it" is surely not a > very > > strong argument. > > > > Will your work-around continue to work? Yes. > > Will the changes actually impact anyone negatively? No known case is > > documented, here or otherwise. > > Will this change objectively improve the operation of ffmpeg on > > Windows? Maybe not for everyone (yet), but certainly it'll allow it > to > > do so in controlled environments. > > > > I'm not seeing a good argument here to generally block the patch on, > > as this entire thread boils down to .. what? Fear of change? > > Unless you can demonstrate an actual problem resulting from applying > > this patch, this line of arguments seems not very productive. > > +1, I agree here. > > Asking users to manually use \\?\ paths isn't something we should > recommend as solution. > > Internally prepending \\?\ when necessary could work (and would also > be a > possible fix, which at least would fix everything that goes through > avio), > but that's clearly much more risky than just adding a mostly-noop > manifest. (And that only works for absolute paths; it requires some > path > munging logic to be able to do that.) I wouldn't mind going that way > too, > but the current patchset seems risk free to me. > > FWIW, LLVM does something like that [1] - before opening files, it > checks > if a path seems to be too long, and if it is, it converts it into an > absolute path and adds such a prefix. But that's clearly more risky > and > more nontrivial than this patchset. I see it the other way round. This patchset does not provide reliable behavior. This way, you won't be able to use long paths with ffmpeg within the next 5-8 years at minimum, because even in the latest versions of Windows 11, this is not enabled by default in the operating system. What is the value of adding a capability where it will be a lottery game whether it will work or not on each system? Best regards, softworkz ___ 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 v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi
> -Original Message- > From: ffmpeg-devel On Behalf Of > Hendrik Leppkes > Sent: Monday, April 25, 2022 2:52 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v11 1/6] > libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and > utf8toansi > > On Mon, Apr 25, 2022 at 1:12 PM Soft Works > wrote: > > > > From my point of view: > > ffmpeg is already working pretty well in handling long file paths > (also with > > Unicode characters) when pre-fixing paths with \\?\, and this is > working > > on all Windows versions without all the caveats, requirements and > conditions > > that I mentioned. > > "We have already worked around this problem in our deployment, > therefore there is no need to try to improve it" is surely not a very > strong argument. > > Will your work-around continue to work? Yes. > Will the changes actually impact anyone negatively? No known case is > documented, here or otherwise. You may want to read this: https://docs.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page > Will this change objectively improve the operation of ffmpeg on > Windows? Maybe not for everyone (yet), but certainly it'll allow it to > do so in controlled environments. > > I'm not seeing a good argument here to generally block the patch on, > as this entire thread boils down to .. what? Fear of change? Pardon? Seems you missed my point (probably you haven't followed the full conversation). What I'm saying is that prepending the long path prefix is the better way for supporting long paths and I mentioned our experience with it only to confirm that it's working well. The .NET/corefx runtime uses the prefix method internally, rclone is using it, the Java runtime is using it, just to name a few examples. Best regards, softworkz ___ 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 v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi
On Mon, 25 Apr 2022, Hendrik Leppkes wrote: On Mon, Apr 25, 2022 at 1:12 PM Soft Works wrote: From my point of view: ffmpeg is already working pretty well in handling long file paths (also with Unicode characters) when pre-fixing paths with \\?\, and this is working on all Windows versions without all the caveats, requirements and conditions that I mentioned. "We have already worked around this problem in our deployment, therefore there is no need to try to improve it" is surely not a very strong argument. Will your work-around continue to work? Yes. Will the changes actually impact anyone negatively? No known case is documented, here or otherwise. Will this change objectively improve the operation of ffmpeg on Windows? Maybe not for everyone (yet), but certainly it'll allow it to do so in controlled environments. I'm not seeing a good argument here to generally block the patch on, as this entire thread boils down to .. what? Fear of change? Unless you can demonstrate an actual problem resulting from applying this patch, this line of arguments seems not very productive. +1, I agree here. Asking users to manually use \\?\ paths isn't something we should recommend as solution. Internally prepending \\?\ when necessary could work (and would also be a possible fix, which at least would fix everything that goes through avio), but that's clearly much more risky than just adding a mostly-noop manifest. (And that only works for absolute paths; it requires some path munging logic to be able to do that.) I wouldn't mind going that way too, but the current patchset seems risk free to me. FWIW, LLVM does something like that [1] - before opening files, it checks if a path seems to be too long, and if it is, it converts it into an absolute path and adds such a prefix. But that's clearly more risky and more nontrivial than this patchset. [1] https://github.com/llvm/llvm-project/blob/llvmorg-14.0.0/llvm/lib/Support/Windows/Path.inc#L98-L124 // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi
On Mon, Apr 25, 2022 at 1:12 PM Soft Works wrote: > > From my point of view: > ffmpeg is already working pretty well in handling long file paths (also with > Unicode characters) when pre-fixing paths with \\?\, and this is working > on all Windows versions without all the caveats, requirements and conditions > that I mentioned. "We have already worked around this problem in our deployment, therefore there is no need to try to improve it" is surely not a very strong argument. Will your work-around continue to work? Yes. Will the changes actually impact anyone negatively? No known case is documented, here or otherwise. Will this change objectively improve the operation of ffmpeg on Windows? Maybe not for everyone (yet), but certainly it'll allow it to do so in controlled environments. I'm not seeing a good argument here to generally block the patch on, as this entire thread boils down to .. what? Fear of change? Unless you can demonstrate an actual problem resulting from applying this patch, this line of arguments seems not very productive. - Hendrik ___ 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] avformat/mpegts: set data broadcast streams as such
On Mon, Apr 25, 2022 at 2:33 PM Jan Ekström wrote: > > On Mon, Apr 25, 2022 at 1:36 PM Jan Ekström wrote: > > > > On Tue, Apr 19, 2022 at 11:06 PM Marton Balint wrote: > > > > > > > > > > > > On Tue, 19 Apr 2022, Jan Ekström wrote: > > > > > > > On Tue, Apr 19, 2022 at 1:13 PM Jan Ekström wrote: > > > >> > > > >> On Tue, Apr 19, 2022 at 3:00 AM Marton Balint wrote: > > > >> > > > > >> > > > > >> > > > > >> > On Thu, 14 Apr 2022, Jan Ekström wrote: > > > >> > > > > >> > > On Mon, Apr 11, 2022 at 1:50 PM Jan Ekström > > > >> > > wrote: > > > >> > >> > > > >> > >> From: Jan Ekström > > > >> > >> > > > >> > >> Additionally, they should not be probed, as this is essentially > > > >> > >> various types of binary data. > > > >> > >> > > > >> > >> Signed-off-by: Jan Ekström > > > >> > >> --- > > > >> > > > > > >> > > Ping. > > > >> > > > > > >> > > Basically this checks if we have an unknown stream with a private > > > >> > > stream type still at the end of the per-stream loop in PMT parsing, > > > >> > > and then cancels the stop of parsing that usually occurs as a PMT > > > >> > > is > > > >> > > hit. Instead the logic will continue parsing further. When an SDT > > > >> > > is > > > >> > > then found and a PMT for that program has already been received, it > > > >> > > will then stop header reading at that point. > > > >> > > > > >> > But why does it matter when the initial parsing is stopped? I mean it > > > >> > stops at the first PMT right now, nobody expects it to find all the > > > >> > programs and all the streams or all the stream codecs/parameters. > > > >> > > > > >> > I am saying, that ideally, the ts->stop_parse magic should not be > > > >> > needed > > > >> > to be changed to fix your issue and when an SDT is detected with the > > > >> > broadcast descriptor that should stop any existing data stream > > > >> > parsing. Do > > > >> > you know why it does not work like that? > > > >> > > > > >> > > > >> If the codec is unknown after header parsing, the general parsing > > > >> logic is utilized to probe which codec is possibly in that unknown > > > >> stream, and thus more data is read from that stream, which can cause > > > >> further delays. > > > >> > > > >> If the codec is known as data, it leads to no such result. > > > >> > > > >> Basically, the idea is to figure out whether a stream is a data stream > > > >> or not during header parsing, if possible. > > > >> > > > > > > > > Just double-checked and the difference is whether > > > > max_stream_analyze_duration gets utilized in > > > > libavformat/demux.c::avformat_find_stream_info . > > > > > > > > If a stream is marked as unknown, it will get checked for longer. If > > > > it is marked as a known "codec" it gets through quicker. > > > > > > The part of the patch which parses the SDT and sets the codec is fine. > > > But the fact that you have to set the codec during mpegts_read_header > > > to make it stop parsing definitely looks like some bug in some code > > > somewhere. It should be enough to set the codec sometime later in > > > mpegts_read_packet() (which is called during avformat_find_stream_info()) > > > > > > Or to make it even more strange: comment out handle_packets() in > > > mpegts_read_header. And it will work just fine. So if nothing is parsed > > > in mpegts_read_header then it works. If something is parsed, then it does > > > not. Kind of unexpected... > > > > > > Regards, > > > Marton > > > > Hi, > > > > So I poked at this again and did the changes you requested. The result > > is that if the "continue parsing until SDT if you have these sorts of > > streams in-band" logic is removed, it leads to the FATE test ending up > > with the result of "codec_name=unknown". Which makes the test rather > > useless as it doesn't actually show that the stream is noted as a data > > stream. Additionally, I thought the logic made sense since as much as > > I dislike having information outside of PMT being utilized for PMT > > purposes, that is effectively what this SDT descriptor is utilized > > for. Given I specifically limited this logic to unknown streams within > > a specific stream identifier range, the effect of this change would > > have been far-from-global as well. > > > > I have a hunch that information is copied from the lavf-internal codec > > context to codecpar at one point, and then no further synchronization > > is attempted. > > So, when checking the following diff: > > diff --git a/libavformat/demux.c b/libavformat/demux.c > index ad7b5dbf83..6e483acb10 100644 > --- a/libavformat/demux.c > +++ b/libavformat/demux.c > @@ -2909,6 +2909,11 @@ int avformat_find_stream_info(AVFormatContext > *ic, AVDictionary **options) > FFStream *const sti = ffstream(st); > const char *errmsg; > > +av_log(ic, AV_LOG_VERBOSE, > + "stream %u (%sinitialized), codec context codec: %s, > codecpar codec: %s\n", > + i, sti->avctx_inited ? "" : "not ", > +
Re: [FFmpeg-devel] FFmpeg 5.0 LTS vs 5.1 LTS
On Sat, 23 Apr 2022, at 18:36, Michael Niedermayer wrote: > Do people prefer that 5.0 becomes LTS or the next (5.1) ? > Or something else ? My understanding of the consensus was; - 5.0 in Dec/Jan - 5.1 in Jul with API additions, but no ABI/behavior breakage - 6.0 in Dec 22 with ABI/API/behavior breakage and while 5.1 becomes LTS - 6.1 in Jul 23... -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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] avformat/mpegts: set data broadcast streams as such
On Mon, Apr 25, 2022 at 1:36 PM Jan Ekström wrote:
>
> On Tue, Apr 19, 2022 at 11:06 PM Marton Balint wrote:
> >
> >
> >
> > On Tue, 19 Apr 2022, Jan Ekström wrote:
> >
> > > On Tue, Apr 19, 2022 at 1:13 PM Jan Ekström wrote:
> > >>
> > >> On Tue, Apr 19, 2022 at 3:00 AM Marton Balint wrote:
> > >> >
> > >> >
> > >> >
> > >> > On Thu, 14 Apr 2022, Jan Ekström wrote:
> > >> >
> > >> > > On Mon, Apr 11, 2022 at 1:50 PM Jan Ekström wrote:
> > >> > >>
> > >> > >> From: Jan Ekström
> > >> > >>
> > >> > >> Additionally, they should not be probed, as this is essentially
> > >> > >> various types of binary data.
> > >> > >>
> > >> > >> Signed-off-by: Jan Ekström
> > >> > >> ---
> > >> > >
> > >> > > Ping.
> > >> > >
> > >> > > Basically this checks if we have an unknown stream with a private
> > >> > > stream type still at the end of the per-stream loop in PMT parsing,
> > >> > > and then cancels the stop of parsing that usually occurs as a PMT is
> > >> > > hit. Instead the logic will continue parsing further. When an SDT is
> > >> > > then found and a PMT for that program has already been received, it
> > >> > > will then stop header reading at that point.
> > >> >
> > >> > But why does it matter when the initial parsing is stopped? I mean it
> > >> > stops at the first PMT right now, nobody expects it to find all the
> > >> > programs and all the streams or all the stream codecs/parameters.
> > >> >
> > >> > I am saying, that ideally, the ts->stop_parse magic should not be
> > >> > needed
> > >> > to be changed to fix your issue and when an SDT is detected with the
> > >> > broadcast descriptor that should stop any existing data stream
> > >> > parsing. Do
> > >> > you know why it does not work like that?
> > >> >
> > >>
> > >> If the codec is unknown after header parsing, the general parsing
> > >> logic is utilized to probe which codec is possibly in that unknown
> > >> stream, and thus more data is read from that stream, which can cause
> > >> further delays.
> > >>
> > >> If the codec is known as data, it leads to no such result.
> > >>
> > >> Basically, the idea is to figure out whether a stream is a data stream
> > >> or not during header parsing, if possible.
> > >>
> > >
> > > Just double-checked and the difference is whether
> > > max_stream_analyze_duration gets utilized in
> > > libavformat/demux.c::avformat_find_stream_info .
> > >
> > > If a stream is marked as unknown, it will get checked for longer. If
> > > it is marked as a known "codec" it gets through quicker.
> >
> > The part of the patch which parses the SDT and sets the codec is fine.
> > But the fact that you have to set the codec during mpegts_read_header
> > to make it stop parsing definitely looks like some bug in some code
> > somewhere. It should be enough to set the codec sometime later in
> > mpegts_read_packet() (which is called during avformat_find_stream_info())
> >
> > Or to make it even more strange: comment out handle_packets() in
> > mpegts_read_header. And it will work just fine. So if nothing is parsed
> > in mpegts_read_header then it works. If something is parsed, then it does
> > not. Kind of unexpected...
> >
> > Regards,
> > Marton
>
> Hi,
>
> So I poked at this again and did the changes you requested. The result
> is that if the "continue parsing until SDT if you have these sorts of
> streams in-band" logic is removed, it leads to the FATE test ending up
> with the result of "codec_name=unknown". Which makes the test rather
> useless as it doesn't actually show that the stream is noted as a data
> stream. Additionally, I thought the logic made sense since as much as
> I dislike having information outside of PMT being utilized for PMT
> purposes, that is effectively what this SDT descriptor is utilized
> for. Given I specifically limited this logic to unknown streams within
> a specific stream identifier range, the effect of this change would
> have been far-from-global as well.
>
> I have a hunch that information is copied from the lavf-internal codec
> context to codecpar at one point, and then no further synchronization
> is attempted.
So, when checking the following diff:
diff --git a/libavformat/demux.c b/libavformat/demux.c
index ad7b5dbf83..6e483acb10 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -2909,6 +2909,11 @@ int avformat_find_stream_info(AVFormatContext
*ic, AVDictionary **options)
FFStream *const sti = ffstream(st);
const char *errmsg;
+av_log(ic, AV_LOG_VERBOSE,
+ "stream %u (%sinitialized), codec context codec: %s,
codecpar codec: %s\n",
+ i, sti->avctx_inited ? "" : "not ",
+ avcodec_get_name(sti->avctx->codec_id),
avcodec_get_name(st->codecpar->codec_id));
+
/* if no packet was ever seen, update context now for
has_codec_parameters */
if (!sti->avctx_inited) {
if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
..the result was that:
- codec context was already noted
Re: [FFmpeg-devel] [PATCH v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi
> -Original Message- > From: ffmpeg-devel On Behalf Of nil- > admir...@mailo.com > Sent: Monday, April 25, 2022 11:52 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v11 1/6] > libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and > utf8toansi > > > Again, you have deleted my asking for an example scenario > > and which library would need to be loaded from a long path. > > Because I don't think that an example would be relevant. A code change for which no use case exists and does not provide any benefit is not relevant. That's my point. > > For the longpaths attribute, you could surely argue that it's "just" > > that you don't know whether it will work or not. > > But forcing a different code page for a process _IS_ a fundamental > > alteration. > > Which is necessary for compatibility with AviSynth, and commit message > says exactly that: https://ffmpeg.org/pipermail/ffmpeg-devel/2022- > April/295572.html. Yes, I understand. You want to make a fundamental change to ffmpeg because of AviSynth. > > I'm restoring the line of your own question which you have deleted: > > > > > > Is it a big deal to change a registry and reboot? > > My response to that was: > > ... > > Really? I answer your question and then you delete your question > > and ask what my answer would have to do with the patchset? > > Sorry, I should've directly asked what: > > > 3. A registry key or group policy needs to be set on Windows to > enable this > > ´ (in both cases, administrative permission/UAC is required to set > it) > > 4. Even when registry key or group policy is set, it might still be > pending > >a reboot > > has to do with this patchset, instead of asking a rhetorical question > of whether > it's a big deal or not. Imagine, you are creating a software (no matter whether you're big or small, open or closed source, targeting business or home users, using a custom or public built ffmpeg) and you bundle ffmpeg.exe with your software like many are doing. Now, re-read my comments, maybe it will make more sense to you. If not - I'm in no way authoritative for ffmpeg, others may have different opinions. From my point of view: ffmpeg is already working pretty well in handling long file paths (also with Unicode characters) when pre-fixing paths with \\?\, and this is working on all Windows versions without all the caveats, requirements and conditions that I mentioned. Best regards, softworkz ___ 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] avformat/mpegts: set data broadcast streams as such
On Tue, Apr 19, 2022 at 11:06 PM Marton Balint wrote: > > > > On Tue, 19 Apr 2022, Jan Ekström wrote: > > > On Tue, Apr 19, 2022 at 1:13 PM Jan Ekström wrote: > >> > >> On Tue, Apr 19, 2022 at 3:00 AM Marton Balint wrote: > >> > > >> > > >> > > >> > On Thu, 14 Apr 2022, Jan Ekström wrote: > >> > > >> > > On Mon, Apr 11, 2022 at 1:50 PM Jan Ekström wrote: > >> > >> > >> > >> From: Jan Ekström > >> > >> > >> > >> Additionally, they should not be probed, as this is essentially > >> > >> various types of binary data. > >> > >> > >> > >> Signed-off-by: Jan Ekström > >> > >> --- > >> > > > >> > > Ping. > >> > > > >> > > Basically this checks if we have an unknown stream with a private > >> > > stream type still at the end of the per-stream loop in PMT parsing, > >> > > and then cancels the stop of parsing that usually occurs as a PMT is > >> > > hit. Instead the logic will continue parsing further. When an SDT is > >> > > then found and a PMT for that program has already been received, it > >> > > will then stop header reading at that point. > >> > > >> > But why does it matter when the initial parsing is stopped? I mean it > >> > stops at the first PMT right now, nobody expects it to find all the > >> > programs and all the streams or all the stream codecs/parameters. > >> > > >> > I am saying, that ideally, the ts->stop_parse magic should not be needed > >> > to be changed to fix your issue and when an SDT is detected with the > >> > broadcast descriptor that should stop any existing data stream parsing. > >> > Do > >> > you know why it does not work like that? > >> > > >> > >> If the codec is unknown after header parsing, the general parsing > >> logic is utilized to probe which codec is possibly in that unknown > >> stream, and thus more data is read from that stream, which can cause > >> further delays. > >> > >> If the codec is known as data, it leads to no such result. > >> > >> Basically, the idea is to figure out whether a stream is a data stream > >> or not during header parsing, if possible. > >> > > > > Just double-checked and the difference is whether > > max_stream_analyze_duration gets utilized in > > libavformat/demux.c::avformat_find_stream_info . > > > > If a stream is marked as unknown, it will get checked for longer. If > > it is marked as a known "codec" it gets through quicker. > > The part of the patch which parses the SDT and sets the codec is fine. > But the fact that you have to set the codec during mpegts_read_header > to make it stop parsing definitely looks like some bug in some code > somewhere. It should be enough to set the codec sometime later in > mpegts_read_packet() (which is called during avformat_find_stream_info()) > > Or to make it even more strange: comment out handle_packets() in > mpegts_read_header. And it will work just fine. So if nothing is parsed > in mpegts_read_header then it works. If something is parsed, then it does > not. Kind of unexpected... > > Regards, > Marton Hi, So I poked at this again and did the changes you requested. The result is that if the "continue parsing until SDT if you have these sorts of streams in-band" logic is removed, it leads to the FATE test ending up with the result of "codec_name=unknown". Which makes the test rather useless as it doesn't actually show that the stream is noted as a data stream. Additionally, I thought the logic made sense since as much as I dislike having information outside of PMT being utilized for PMT purposes, that is effectively what this SDT descriptor is utilized for. Given I specifically limited this logic to unknown streams within a specific stream identifier range, the effect of this change would have been far-from-global as well. I have a hunch that information is copied from the lavf-internal codec context to codecpar at one point, and then no further synchronization is attempted. As for the results being different without any packets being actually demuxed, codec_info_nb_frames is possibly a variable which has some relevance to it, although most checks against it seem to be of the > 1 type, instead of > 0. Jan ___ 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] avutil/hwcontext_videotoolbox: create real buffer pool
> On Mar 31, 2022, at 2:48 PM, zhilizhao(赵志立) wrote: > > Ping for patch 1/2. rcombs has reviewed the patch on IRC. I decided to > drop patch 2/2. > > >> 11:05 rcombs: quink_: seems reasonable to me >> 11:06 quink_: rcombs: thanks : ) >> 11:06 rcombs: not entirely sure what the deal with the second commit is but >> ¯\_(ツ)_/¯ it's harmless so w/e > > >> On Mar 10, 2022, at 12:37 PM, Zhao Zhili wrote: >> >> vt_get_buffer shouldn't do buffer pool's job. >> --- >> libavutil/hwcontext_videotoolbox.c | 71 ++ >> 1 file changed, 34 insertions(+), 37 deletions(-) >> >> diff --git a/libavutil/hwcontext_videotoolbox.c >> b/libavutil/hwcontext_videotoolbox.c >> index 026127d412..e442a95007 100644 >> --- a/libavutil/hwcontext_videotoolbox.c >> +++ b/libavutil/hwcontext_videotoolbox.c No functional change. Will apply this week unless there are objections. ___ 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/mov: Add avif to list of supported extensions
Pushed as f2724d2b6958a4e62afa10157f2b19566239e12d
On 2022-04-25 12:09 am, Vignesh Venkatasubramanian wrote:
AVIF still and animations are now supported by the MOV parser.
Add the "avif" extension to the list of supported extensions to
AVInputFormat.
Signed-off-by: Vignesh Venkatasubramanian
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 3e83e54a77..26aeeaea0c 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -9036,7 +9036,7 @@ const AVInputFormat ff_mov_demuxer = {
.long_name = NULL_IF_CONFIG_SMALL("QuickTime / MOV"),
.priv_class = _class,
.priv_data_size = sizeof(MOVContext),
-.extensions = "mov,mp4,m4a,3gp,3g2,mj2,psp,m4b,ism,ismv,isma,f4v",
+.extensions = "mov,mp4,m4a,3gp,3g2,mj2,psp,m4b,ism,ismv,isma,f4v,avif",
.flags_internal = FF_FMT_INIT_CLEANUP,
.read_probe = mov_probe,
.read_header= mov_read_header,
___
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/mov: fix missing extra data updating
> On Mar 30, 2022, at 2:04 AM, Zhao Zhili wrote:
>
> The stsc_index is checked and updated for the next sample. If the
> next sample needs to update stsd_index and stsc_index, then only
> stsc_index is updated, which leads to a missing
> AV_PKT_DATA_NEW_EXTRADATA. For example, the sample in the second
> chunk needs to update both.
>
> entry[0]
>first_chunk = 1
>samples_per_chunk = 3
>sample_description_index = 1
> entry[1]
>first_chunk = 2
>samples_per_chunk = 1
>sample_description_index = 2
> entry[2]
>first_chunk = 3
>samples_per_chunk = 8
>sample_description_index = 2
>
> The fix is simple: first check and update stsd_index for current
> sample, then check and update stsc_index for the next.
> ---
> libavformat/mov.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 6c847de164..c9d4f2ef43 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -8591,20 +8591,20 @@ static int mov_read_packet(AVFormatContext *s,
> AVPacket *pkt)
>
> /* Multiple stsd handling. */
> if (sc->stsc_data) {
> -/* Keep track of the stsc index for the given sample, then check
> -* if the stsd index is different from the last used one. */
> +if (sc->stsc_data[sc->stsc_index].id > 0 &&
> +sc->stsc_data[sc->stsc_index].id - 1 < sc->stsd_count &&
> +sc->stsc_data[sc->stsc_index].id - 1 != sc->last_stsd_index) {
> +ret = mov_change_extradata(sc, pkt);
> +if (ret < 0)
> +return ret;
> +}
> +
> +/* Update the stsc index for the next sample */
> sc->stsc_sample++;
> if (mov_stsc_index_valid(sc->stsc_index, sc->stsc_count) &&
> mov_get_stsc_samples(sc, sc->stsc_index) == sc->stsc_sample) {
> sc->stsc_index++;
> sc->stsc_sample = 0;
> -/* Do not check indexes after a switch. */
> -} else if (sc->stsc_data[sc->stsc_index].id > 0 &&
> - sc->stsc_data[sc->stsc_index].id - 1 < sc->stsd_count &&
> - sc->stsc_data[sc->stsc_index].id - 1 !=
> sc->last_stsd_index) {
> -ret = mov_change_extradata(sc, pkt);
> -if (ret < 0)
> -return ret;
> }
> }
>
Multi sample entry is a less used feature. Since we have it, better keep it
work. This patch fixed a corner case.
Will apply this week unless there are objections.
___
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 v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi
> Again, you have deleted my asking for an example scenario > and which library would need to be loaded from a long path. Because I don't think that an example would be relevant. Generic library function must be able to load a library, no matter the location. You're talking as if MAX_PATH limited library loader is self-evidently superior, and it is the loader that has no such limitation that has to justify its existence. As far as I'm concerned it just the other way around. > For the longpaths attribute, you could surely argue that it's "just" > that you don't know whether it will work or not. > But forcing a different code page for a process _IS_ a fundamental > alteration. Which is necessary for compatibility with AviSynth, and commit message says exactly that: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295572.html. > I'm restoring the line of your own question which you have deleted: > > > > > Is it a big deal to change a registry and reboot? > My response to that was: > ... > Really? I answer your question and then you delete your question > and ask what my answer would have to do with the patchset? Sorry, I should've directly asked what: > 3. A registry key or group policy needs to be set on Windows to enable this > ´ (in both cases, administrative permission/UAC is required to set it) > 4. Even when registry key or group policy is set, it might still be pending >a reboot has to do with this patchset, instead of asking a rhetorical question of whether it's a big deal or not. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] avutil/hwcontext_qsv: fix D3D11VA<->qsv hwmap errors
On Fri, 2022-04-01 at 17:24 +0800, Tong Wu wrote:
> For hwmap between qsv and d3d11va, The mfxHDLPair information should be
> put into texture_infos when deriving from qsv context. Moreover, when
> uploading from rawvideo, the ways that the textures are created are
> different, bindflag assertions are needed to make sure the right
> textures are derived during the process. Now after this fix,
> d3d_dec->qsv_vpp->qsv_enc, d3d_dec->qsv_vpp->qsv_download->yuv,
> yuv->d3d_upload->qsv_vpp->qsv->download->yuv,
> qsv_dec->qsv_vpp->d3d_download->yuv can all work properly.
>
> For d3d_dec->qsv_vpp->qsv_enc, one sample command line:
> ffmpeg.exe -hwaccel qsv -c:v h264_qsv -i input.264
> -vf
> "hwmap=derive_device=d3d11va,format=d3d11,hwmap=derive_device=qsv,format=qsv"
> -c:v h264_qsv -y ./output.264
The default child_device_type is dxva2 for option --enable-libmfx, I don't think
it makes sense to derive a QSV device based on dxva2 child device to a
d3d11vadevice.
But even if initializing qsv device with d3d11va child device, the command below
still doesn't work
$ ffmpeg.exe -y -hwaccel qsv -init_hw_device
qsv=qsv:hw,child_device=0,child_device_type=d3d11va -c:v h264_qsv -i input.h264
-vf "hwmap=derive_device=d3d11va,format=d3d11,hwdownload,format=nv12" -f null -
You may try https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=5304
Thanks
Haihao
>
> Signed-off-by: Tong Wu
> ---
> libavutil/hwcontext_qsv.c | 48 ---
> 1 file changed, 40 insertions(+), 8 deletions(-)
>
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index 95f8071abe..e6a7ac3ef0 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -806,12 +806,23 @@ static int qsv_frames_derive_from(AVHWFramesContext
> *dst_ctx,
> #if CONFIG_D3D11VA
> case AV_HWDEVICE_TYPE_D3D11VA:
> {
> +dst_ctx->initial_pool_size = src_ctx->initial_pool_size;
> AVD3D11VAFramesContext *dst_hwctx = dst_ctx->hwctx;
> -mfxHDLPair *pair = (mfxHDLPair*)src_hwctx-
> >surfaces[i].Data.MemId;
> -dst_hwctx->texture = (ID3D11Texture2D*)pair->first;
> +dst_hwctx->texture_infos = av_calloc(src_hwctx->nb_surfaces,
> + sizeof(*dst_hwctx-
> >texture_infos));
> if (src_hwctx->frame_type & MFX_MEMTYPE_SHARED_RESOURCE)
> dst_hwctx->MiscFlags = D3D11_RESOURCE_MISC_SHARED;
> dst_hwctx->BindFlags = qsv_get_d3d11va_bind_flags(src_hwctx-
> >frame_type);
> +for (i = 0; i < src_hwctx->nb_surfaces; i++) {
> +mfxHDLPair* pair = (mfxHDLPair*)src_hwctx-
> >surfaces[i].Data.MemId;
> +dst_hwctx->texture_infos[i].texture = (ID3D11Texture2D*)pair-
> >first;
> +if (dst_hwctx->BindFlags & D3D11_BIND_RENDER_TARGET) {
> +dst_hwctx->texture_infos[i].index = 0;
> +}
> +else {
> +dst_hwctx->texture_infos[i].index = (intptr_t)pair-
> >second;
> +}
> +}
> }
> break;
> #endif
> @@ -900,9 +911,16 @@ static int qsv_map_from(AVHWFramesContext *ctx,
> dst->height = src->height;
>
> if (child_frames_ctx->device_ctx->type == AV_HWDEVICE_TYPE_D3D11VA) {
> +#if CONFIG_D3D11VA
> +AVD3D11VAFramesContext* child_frames_hwctx = child_frames_ctx-
> >hwctx;
> mfxHDLPair *pair = (mfxHDLPair*)surf->Data.MemId;
> dst->data[0] = pair->first;
> -dst->data[1] = pair->second;
> +if (child_frames_hwctx->BindFlags & D3D11_BIND_RENDER_TARGET) {
> +dst->data[1] = 0;
> +} else {
> +dst->data[1] = pair->second;
> +}
> +#endif
> } else {
> dst->data[3] = child_data;
> }
> @@ -930,9 +948,16 @@ static int qsv_map_from(AVHWFramesContext *ctx,
> dummy->height= src->height;
>
> if (child_frames_ctx->device_ctx->type == AV_HWDEVICE_TYPE_D3D11VA) {
> +#if CONFIG_D3D11VA
> +AVD3D11VAFramesContext* child_frames_hwctx = child_frames_ctx->hwctx;
> mfxHDLPair *pair = (mfxHDLPair*)surf->Data.MemId;
> dummy->data[0] = pair->first;
> -dummy->data[1] = pair->second;
> +if (child_frames_hwctx->BindFlags & D3D11_BIND_RENDER_TARGET) {
> +dst->data[1] = 0;
> +} else {
> +dst->data[1] = pair->second;
> +}
> +#endif
> } else {
> dummy->data[3] = child_data;
> }
> @@ -1287,6 +1312,10 @@ static int qsv_frames_derive_to(AVHWFramesContext
> *dst_ctx,
> return AVERROR(ENOSYS);
> }
>
> +s->child_frames_ref = av_buffer_ref(dst_ctx->internal->source_frames);
> +if (!s->child_frames_ref) {
> +return AVERROR(ENOMEM);
> +}
> dst_hwctx->surfaces = s->surfaces_internal;
>
> return 0;
> @@ -1314,10 +1343,13 @@
Re: [FFmpeg-devel] [PATCH v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi
> -Original Message- > From: ffmpeg-devel On Behalf Of nil- > admir...@mailo.com > Sent: Monday, April 25, 2022 11:04 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v11 1/6] > libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and > utf8toansi > > > You normally don't load libraries from such longs paths. > > And? 80% of FFmpeg functionality is normally not used. Again, you have deleted my asking for an example scenario and which library would need to be loaded from a long path. > > But file IO is a fundamental feature where a common and predictable > > behavior is crucial. > > You're talking as if the manifest change somehow broke or > fundamentally altered > file IO, which it clearly did not. For the longpaths attribute, you could surely argue that it's "just" that you don't know whether it will work or not. But forcing a different code page for a process _IS_ a fundamental alteration. I'm restoring the line of your own question which you have deleted: > > > > Is it a big deal to change a registry and reboot? My response to that was: > > Yes it is. Especially when you don't know that it's needed or > whether > > it's needed or when it is needed. > > Also it requires administrative permissions which not everybody has. > > Further it's a serious change to OS behavior and you cannot expect > that > > all users are educated enough for being able to make this decision > > and be confident that it won't have any unexpected side effects. > > What does all of that have to do with these patches? Really? I answer your question and then you delete your question and ask what my answer would have to do with the patchset? sw ___ 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] FFmpeg 5.0 LTS vs 5.1 LTS
> -Original Message- > From: ffmpeg-devel On Behalf Of Paul > B Mahol > Sent: Monday, April 25, 2022 10:01 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] FFmpeg 5.0 LTS vs 5.1 LTS > > On Mon, Apr 25, 2022 at 12:48 AM Soft Works > wrote: > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Michael Niedermayer > > > Sent: Saturday, April 23, 2022 6:36 PM > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: [FFmpeg-devel] FFmpeg 5.0 LTS vs 5.1 LTS > > > > > > Hi all > > > > > > Do people prefer that 5.0 becomes LTS or the next (5.1) ? > > > Or something else ? > > > > @Anton - I'm wondering how your multi-threading transformations > > to ffmpeg.c would align with the release schedule? > > > > I think an LTS release should be either before or after the > > series of changes you are planning. It would be unfortunate > > when 5.1 would be somewhere in the middle of those changes > > and become LTS. > > (as you said it could take a year in the worst case) > > > > > I'm still expecting info that you said to provide. That "information" is about explaining why I said that it's difficult to debug filtering in ffmpeg. I haven't forgot about and I'll get to it shortly. As I mentioned before, I'm concerned about the transitioning process but not opposed to the end result. My suggestion was to retain the current code flow as an option, but nobody else found it useful - that's ok, I have no intentions to insist. Besides that, from my personal pov: the faster it can be driven to completion, the better, so there's just a "before-state" (the current state) and a "completion state" to care about. Having a release in-between would create an additional state to deal with, and that's what I would find unfortunate. softworkz ___ 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 v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi
> You normally don't load libraries from such longs paths. And? 80% of FFmpeg functionality is normally not used. > But file IO is a fundamental feature where a common and predictable > behavior is crucial. You're talking as if the manifest change somehow broke or fundamentally altered file IO, which it clearly did not. > That's true, but the file IO in ffmpeg does not use MAX_PATH buffers, > so it's only about those few specific cases: I'm glad it doesn't use MAX_PATH everywhere. Takes only 6 pathes to fix, not a thousand. > Patch 2/6: Removing the fixed-size buffer is surely a good change, > but can't you just completely remove the charset > conversion and use the same file IO patterns that ffmpeg > is using everywhere else? If you were to look at the code, you would've seen that charset conversion was already there. AviSynth is not Unicode-aware, it expects ANSI strings. Inline charset conversion was replaced by a library call, which, again, was already there, only slightly extended. > Patch 4/6: Seems to be pointless because you cannot run ffmpeg.exe from > a long path anyway. Neither with cmd nor with powershell. > Even if you could, it would be a pretty exotic use case. This current limitation may disappear in a future version of Windows, the same way path limit disappeared. > And the servers? Servers have the same lifecycle as client versions do. > And all those which are still using older versions? For them manifest change is a no-op. > Yes it is. Especially when you don't know that it's needed or whether > it's needed or when it is needed. > Also it requires administrative permissions which not everybody has. > Further it's a serious change to OS behavior and you cannot expect that > all users are educated enough for being able to make this decision > and be confident that it won't have any unexpected side effects. What does all of that have to do with these patches? > That's what I tried to explain. "Any other patch" makes a change > after which you know that the change has been made. > > But adding those attributes will impose changes that will be effective > under certain conditions only and about which neither the user nor the > application "knows" whether they are effective or not. Before these patches FFmpeg cannot handle long paths. After these patches, it can. They are certainly not invisible. > No. There's are common file APIs where such change could be made. During the review of these patches it was found that parts FFmpeg use av_fopen_utf8, while others use plain fopen. There is no common file API. > PS: Your line breaks were all doubled. Please check before replying. Were normal in email client. I don't know how they got garbled. My previous messages didn't have such a problem. ___ 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] arm64: Fix wrong BTI landing pad
This patch fixes a wrong type of BTI landing pad when branching to functions instantiated via the fft*_neon macro. Although the previously employed paciasp instruction serves as a landing pad, for the ways that this function is invoked it is the wrong type, resulting in an unexpected termination of the running process. Signed-off-by: André Kempe --- libavcodec/aarch64/fft_neon.S | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/aarch64/fft_neon.S b/libavcodec/aarch64/fft_neon.S index dd5f55eb87..9ff3f9c526 100644 --- a/libavcodec/aarch64/fft_neon.S +++ b/libavcodec/aarch64/fft_neon.S @@ -340,6 +340,7 @@ endfunc .macro def_fft n, n2, n4 function fft\n\()_neon, align=6 +AARCH64_VALID_JUMP_TARGET AARCH64_SIGN_LINK_REGISTER sub sp, sp, #16 stp x28, x30, [sp] -- 2.25.1 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ 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] FFmpeg 5.0 LTS vs 5.1 LTS
On Mon, Apr 25, 2022 at 12:48 AM Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Michael Niedermayer > > Sent: Saturday, April 23, 2022 6:36 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: [FFmpeg-devel] FFmpeg 5.0 LTS vs 5.1 LTS > > > > Hi all > > > > Do people prefer that 5.0 becomes LTS or the next (5.1) ? > > Or something else ? > > @Anton - I'm wondering how your multi-threading transformations > to ffmpeg.c would align with the release schedule? > > I think an LTS release should be either before or after the > series of changes you are planning. It would be unfortunate > when 5.1 would be somewhere in the middle of those changes > and become LTS. > (as you said it could take a year in the worst case) > > I'm still expecting info that you said to provide. > Thanks, > softworkz > ___ > 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] 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".
