Re: [FFmpeg-devel] [Question] Technical reason why FFmpeg sets a mstack-alignment value on compile time?
Am 12.11.22 um 23:09 schrieb Ronald S. Bultje: Hi, On Sat, Nov 12, 2022 at 1:57 PM Nomis101 wrote: Hi.If building FFmpeg, configure does set a value for mstack-alignment, for example on macOS -mstack-alignment=16. On HandBrake we found there is an issue with current Clang in Xcode about conflicting 'override-stack-alignment' values if we build with ThinLTO. "ld: linking module flags 'override-stack-alignment': IDs have conflicting values" I found out why this is. x264 does set -mstack-alignment=64 in configure, FFmpeg does set -mstack-alignment=16 and this seems to be a conflict when linking. If I modify both configure files and remove the mstack-alignment part, then the build does finish with no error. And here comes my questions. I was wondering, about the technical reason why FFmpeg does set mstack-alignment? And if it would be safe to disable it in case FFmpeg is compiled with ThinLTO (for HandBrake)? It can safely be set to the higher of the two values, it has the same meaning. Alignment of 64 implies alignment of 16. Thanks. I found out, that its enough to disable the mstack-alignment part for x264 in case of ThinLTO. This will also fix the error. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ 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] [Question] Technical reason why FFmpeg sets a mstack-alignment value on compile time?
Hi.If building FFmpeg, configure does set a value for mstack-alignment, for example on macOS -mstack-alignment=16. On HandBrake we found there is an issue with current Clang in Xcode about conflicting 'override-stack-alignment' values if we build with ThinLTO. "ld: linking module flags 'override-stack-alignment': IDs have conflicting values" I found out why this is. x264 does set -mstack-alignment=64 in configure, FFmpeg does set -mstack-alignment=16 and this seems to be a conflict when linking. If I modify both configure files and remove the mstack-alignment part, then the build does finish with no error. And here comes my questions. I was wondering, about the technical reason why FFmpeg does set mstack-alignment? And if it would be safe to disable it in case FFmpeg is compiled with ThinLTO (for HandBrake)? Thanks and Regards ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: Remove experimental status of TrueHD-in-MP4 muxing (mlpa)
Am 11.11.22 um 14:48 schrieb Nomis101: Am 11.11.22 um 14:05 schrieb Jan Ekström: On Wed, Nov 9, 2022 at 9:15 PM Nomis101 wrote: Am 06.11.22 um 21:57 schrieb Carl Eugen Hoyos: Am Sa., 5. Nov. 2022 um 22:31 Uhr schrieb Nomis101 : Support for mlpa muxing was added back in 2019: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619 But it was hidden back then behind FF_COMPLIANCE_EXPERIMENTAL, because it was new and there was no support from other applications. In the meantime there is support in MediaInfo: MediaArea/MediaInfoLib#1258 For VLC: videolan/vlc@9c49f40 Since version 7.3.4 for Infuse: https://community.firecore.com/t/dolby-mlp-mlpa-codec-support/26100/31 And mpv does support this as well. If there was ever a good reason to make this feature experimental, I don't think these applications change the situation. The reason to make this experimental was, because there was no implementation from others at this time. http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248435.html Now, there is implementation from others. How many implementation from others will be needed to change the situation? I think the main thing was to have the feature verified by non-FFmpeg things. Basically, if you wrote out a TrueHD file and actual 3rd party implementations that didn't just utilize FFmpeg for reading would happily read it, then the flag should be removed. If the VLC commit did not specifically say "we did it like this to enable support for files that FFmpeg generated" but rather that they followed the spec, then that's one alternative implementation indeed. And if MediaInfo or that Infuse thing also added support for the exact same mapping and that neither specifically utilized FFmpeg internally, then those also apply. Finally, I think the D company has a git repo for "dlb_mp4base", you could check if that supports this mapping. Best regards, Jan OK, thanks Jan for the detailed explanation. I will check D company. Infuse has implemented it independently of FFmpeg. VLC and Mediainfo I do not know. The specs were mentioned in the bug, but also FFmpeg. But both would not implement anything if there was no specification for it. There is also support in "dlb_mp4base": https://github.com/DolbyLaboratories/dlb_mp4base/blob/8da6d4a8fc095a88349fbdac33e7e68fb3b93649/src/mp4_muxer.c#L149 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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/movenc: Remove experimental status of TrueHD-in-MP4 muxing (mlpa)
Am 11.11.22 um 14:05 schrieb Jan Ekström: On Wed, Nov 9, 2022 at 9:15 PM Nomis101 wrote: Am 06.11.22 um 21:57 schrieb Carl Eugen Hoyos: Am Sa., 5. Nov. 2022 um 22:31 Uhr schrieb Nomis101 : Support for mlpa muxing was added back in 2019: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619 But it was hidden back then behind FF_COMPLIANCE_EXPERIMENTAL, because it was new and there was no support from other applications. In the meantime there is support in MediaInfo: MediaArea/MediaInfoLib#1258 For VLC: videolan/vlc@9c49f40 Since version 7.3.4 for Infuse: https://community.firecore.com/t/dolby-mlp-mlpa-codec-support/26100/31 And mpv does support this as well. If there was ever a good reason to make this feature experimental, I don't think these applications change the situation. The reason to make this experimental was, because there was no implementation from others at this time. http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248435.html Now, there is implementation from others. How many implementation from others will be needed to change the situation? I think the main thing was to have the feature verified by non-FFmpeg things. Basically, if you wrote out a TrueHD file and actual 3rd party implementations that didn't just utilize FFmpeg for reading would happily read it, then the flag should be removed. If the VLC commit did not specifically say "we did it like this to enable support for files that FFmpeg generated" but rather that they followed the spec, then that's one alternative implementation indeed. And if MediaInfo or that Infuse thing also added support for the exact same mapping and that neither specifically utilized FFmpeg internally, then those also apply. Finally, I think the D company has a git repo for "dlb_mp4base", you could check if that supports this mapping. Best regards, Jan OK, thanks Jan for the detailed explanation. I will check D company. Infuse has implemented it independently of FFmpeg. VLC and Mediainfo I do not know. The specs were mentioned in the bug, but also FFmpeg. But both would not implement anything if there was no specification for it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: Remove experimental status of TrueHD-in-MP4 muxing (mlpa)
Am 06.11.22 um 21:57 schrieb Carl Eugen Hoyos: Am Sa., 5. Nov. 2022 um 22:31 Uhr schrieb Nomis101 : Support for mlpa muxing was added back in 2019: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619 But it was hidden back then behind FF_COMPLIANCE_EXPERIMENTAL, because it was new and there was no support from other applications. In the meantime there is support in MediaInfo: MediaArea/MediaInfoLib#1258 For VLC: videolan/vlc@9c49f40 Since version 7.3.4 for Infuse: https://community.firecore.com/t/dolby-mlp-mlpa-codec-support/26100/31 And mpv does support this as well. If there was ever a good reason to make this feature experimental, I don't think these applications change the situation. The reason to make this experimental was, because there was no implementation from others at this time. http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248435.html Now, there is implementation from others. How many implementation from others will be needed to change the situation? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ 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/movenc: Remove experimental status of TrueHD-in-MP4 muxing (mlpa)
Am 05.11.22 um 21:31 schrieb Nomis101:
Support for mlpa muxing was added back in 2019:
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619
But it was hidden back then behind FF_COMPLIANCE_EXPERIMENTAL, because it was new and there was no
support from other applications.
In the meantime there is support in MediaInfo: MediaArea/MediaInfoLib#1258
For VLC: videolan/vlc@9c49f40
Since version 7.3.4 for Infuse:
https://community.firecore.com/t/dolby-mlp-mlpa-codec-support/26100/31
And mpv does support this as well.
So, there is no need anymore to hide this behind FF_COMPLIANCE_EXPERIMENTAL. Also, it should be the
user's responsibility to choose this only if the user's software/hardware supports it.
Therefore, this patch removes the experimental status of TrueHD-in-MP4 muxing.
Signed-off-by: Nomis101
---
libavformat/movenc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 754f95912a..50f1831860 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -7157,7 +7157,6 @@ static int mov_init(AVFormatContext *s)
}
}
if (track->par->codec_id == AV_CODEC_ID_FLAC ||
- track->par->codec_id == AV_CODEC_ID_TRUEHD ||
track->par->codec_id == AV_CODEC_ID_OPUS) {
if (track->mode != MODE_MP4) {
av_log(s, AV_LOG_ERROR, "%s only supported in MP4.\n",
avcodec_get_name(track->par->codec_id));
Hi all. Patchwork does say something about "Failed to apply patch". Is this somehing I should worry
about? And if yes, how to fix it? It has been properly generated using git format-patch.
___
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] avformat/movenc: Remove experimental status of TrueHD-in-MP4 muxing (mlpa)
Support for mlpa muxing was added back in 2019:
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619
But it was hidden back then behind FF_COMPLIANCE_EXPERIMENTAL, because it was new and there was no
support from other applications.
In the meantime there is support in MediaInfo: MediaArea/MediaInfoLib#1258
For VLC: videolan/vlc@9c49f40
Since version 7.3.4 for Infuse:
https://community.firecore.com/t/dolby-mlp-mlpa-codec-support/26100/31
And mpv does support this as well.
So, there is no need anymore to hide this behind FF_COMPLIANCE_EXPERIMENTAL. Also, it should be the
user's responsibility to choose this only if the user's software/hardware supports it.
Therefore, this patch removes the experimental status of TrueHD-in-MP4 muxing.
Signed-off-by: Nomis101
---
libavformat/movenc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 754f95912a..50f1831860 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -7157,7 +7157,6 @@ static int mov_init(AVFormatContext *s)
}
}
if (track->par->codec_id == AV_CODEC_ID_FLAC ||
-track->par->codec_id == AV_CODEC_ID_TRUEHD ||
track->par->codec_id == AV_CODEC_ID_OPUS) {
if (track->mode != MODE_MP4) {
av_log(s, AV_LOG_ERROR, "%s only supported in MP4.\n",
avcodec_get_name(track->par->codec_id));
--
2.37.1 (Apple Git-137.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] Compilation error with --enable-libmysofa
I'm getting a compilation error if I build FFmpeg with --enable-libmysofa. This has worked nicely some weeks ago. This is on macOS 12.1. I have libmysofa-1.2.1 installed. FFmpeg is latest master. If I remove --enable-libmysofa, it builds without issue. /...// //POD doc/ffmpeg-scaler.pod// //POD doc/ffmpeg-resampler.pod// //POD doc/ffmpeg-codecs.pod// //POD doc/ffmpeg-bitstream-filters.pod// //POD doc/ffmpeg-formats.pod// //POD doc/ffmpeg-protocols.pod// //POD doc/ffmpeg-devices.pod// //POD doc/libavutil.pod// //POD doc/libswscale.pod// //POD doc/ffmpeg-filters.pod// //ld: archive has no table of contents file 'libswscale/libswscale.a' for architecture x86_64// //clang: error: linker command failed with exit code 1 (use -v to see invocation)// //make: *** [tools/sofa2wavs] Error 1// //make: *** Waiting for unfinished jobs// //STRIP libavcodec/x86/vp9itxfm.o// //rm libavfilter/metal/vf_yadif_videotoolbox.metal.air libavfilter/metal/vf_yadif_videotoolbox.metallib libavfilter/metal/vf_yadif_videotoolbox.metallib.c/ ___ 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] [Question] Are there any legal or patenting issues concerning the AC-4 patches?
Am 31.05.21 um 20:54 schrieb Lynne: > May 31, 2021, 19:59 by nomis...@web.de: > >> Hi everyone. Back in March 2020 a set of patches for AC-4 support into >> FFmpeg was posted on this >> list. As these patches are not integrated in FFmpeg the HandBrake team was >> considering if we should >> add them to the internal FFmpeg patches for HandBrake. We are aware, that >> this patches are WIP and >> that there are maybe still some technical weak points. >> But, we would like to clarify if there are any legal or patenting issues >> with this patches? Would >> this patches be compatible with the GPLv2 license of HandBrake? We don't >> want to come into any kind >> of cease and desist situation. >> > > No, it's just that the decoder still has some issues with one of its QMF > synthesis > filters, and the developer seems busy right now to fix it. The spec is very > long, very obtuse, and very annoying. > The decoder will be lgpl like the rest of our code. We really can't care less > about patents (we don't read them either, they're all useless), and C > aren't really worth the paper they're printed on in Europe, so we've been left > alone, hopefully for the future too. > ___ Thank you very much for your detailed answer, that was very helpful. ___ 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] [Question] Are there any legal or patenting issues concerning the AC-4 patches?
Hi everyone. Back in March 2020 a set of patches for AC-4 support into FFmpeg was posted on this list. As these patches are not integrated in FFmpeg the HandBrake team was considering if we should add them to the internal FFmpeg patches for HandBrake. We are aware, that this patches are WIP and that there are maybe still some technical weak points. But, we would like to clarify if there are any legal or patenting issues with this patches? Would this patches be compatible with the GPLv2 license of HandBrake? We don't want to come into any kind of cease and desist situation. https://github.com/HandBrake/HandBrake/issues/3594#issuecomment-849891899 Thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Constant quality for videotoolboxenc on M1
Hi, back in January it was asked if it would be possible to add constant quality encoding for videotoolbox on macOS to FFmpeg. Later, somebody provided a patch. http://ffmpeg.org/pipermail/ffmpeg-devel/2021-January/274989.html Would it be possible for somebody to take a look into this? Not only would it be a great addition to videotoolbox video encoding, it would also help to reduce the amount of patches from the internal FFmpeg patchset of HandBrake (the one for b-frames and the one for constant quality). Thank you very much. ___ 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] [PATCH] avcodec: Fix h264_videotoolbox writing b-frames (fix ticket #8353)
Am 21.03.20 um 15:58 schrieb Rick Kern: > On Wed, Mar 18, 2020 at 12:32 PM Nomis101 wrote: > >> Am 29.02.20 um 02:39 schrieb Nomis101: >>> From: Damiano Galassi >>> >>> Signed-off-by: Nomis101 >>> --- >>> libavcodec/videotoolboxenc.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c >>> index cc08cf6a50..32d893e485 100644 >>> --- a/libavcodec/videotoolboxenc.c >>> +++ b/libavcodec/videotoolboxenc.c >>> @@ -1355,6 +1355,7 @@ static int vtenc_configure_encoder(AVCodecContext >> *avctx) >>> vtctx->get_param_set_func = >> compat_keys.CMVideoFormatDescriptionGetHEVCParameterSetAtIndex; >>> if (!vtctx->get_param_set_func) return AVERROR(EINVAL); >>> if (!get_vt_hevc_profile_level(avctx, _level)) return >> AVERROR(EINVAL); >>> +vtctx->has_b_frames = avctx->max_b_frames > 0; >> > This is in the HEVC block. The H.264 encoder will output B-frames if the > hardware supports it and the -bf parameter is used with a value of 1 or > more. Oh yes, the patch was that old, that I have actually mixed this up. It was for HEVC. I found the original bug: https://github.com/HandBrake/HandBrake/pull/1522 I could change the subject and the commit message accordingly, if thats fine? > >> } >>> >>> enc_info = CFDictionaryCreateMutable( >>> -- >>> 2.21.1 (Apple Git-122.3) >>> >> >> >> What do I need to do to get this reviewed? Its just a one-liner. >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel 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] [PATCH] avcodec: Fix h264_videotoolbox writing b-frames (fix ticket #8353)
Am 29.02.20 um 02:39 schrieb Nomis101: > From: Damiano Galassi > > Signed-off-by: Nomis101 > --- > libavcodec/videotoolboxenc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c > index cc08cf6a50..32d893e485 100644 > --- a/libavcodec/videotoolboxenc.c > +++ b/libavcodec/videotoolboxenc.c > @@ -1355,6 +1355,7 @@ static int vtenc_configure_encoder(AVCodecContext > *avctx) > vtctx->get_param_set_func = > compat_keys.CMVideoFormatDescriptionGetHEVCParameterSetAtIndex; > if (!vtctx->get_param_set_func) return AVERROR(EINVAL); > if (!get_vt_hevc_profile_level(avctx, _level)) return > AVERROR(EINVAL); > +vtctx->has_b_frames = avctx->max_b_frames > 0; > } > > enc_info = CFDictionaryCreateMutable( > -- > 2.21.1 (Apple Git-122.3) > What do I need to do to get this reviewed? Its just a one-liner. ___ 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] [PATCH] avcodec: Fix h264_videotoolbox writing b-frames (fix ticket #8353)
From: Damiano Galassi Signed-off-by: Nomis101 --- libavcodec/videotoolboxenc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c index cc08cf6a50..32d893e485 100644 --- a/libavcodec/videotoolboxenc.c +++ b/libavcodec/videotoolboxenc.c @@ -1355,6 +1355,7 @@ static int vtenc_configure_encoder(AVCodecContext *avctx) vtctx->get_param_set_func = compat_keys.CMVideoFormatDescriptionGetHEVCParameterSetAtIndex; if (!vtctx->get_param_set_func) return AVERROR(EINVAL); if (!get_vt_hevc_profile_level(avctx, _level)) return AVERROR(EINVAL); +vtctx->has_b_frames = avctx->max_b_frames > 0; } enc_info = CFDictionaryCreateMutable( -- 2.21.1 (Apple Git-122.3) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] [PATCH] avcodec: Fix h264_videotoolbox writing b-frames (fix ticket #8353)
Am 28.02.20 um 19:19 schrieb Carl Eugen Hoyos: > Am Fr., 28. Feb. 2020 um 19:08 Uhr schrieb Nomis101 : >> >> Am 27.02.20 um 19:13 schrieb Nomis101: >>> Signed-off-by: Nomis101 >>> --- >>> libavcodec/videotoolboxenc.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c >>> index cc08cf6a50..32d893e485 100644 >>> --- a/libavcodec/videotoolboxenc.c >>> +++ b/libavcodec/videotoolboxenc.c >>> @@ -1355,6 +1355,7 @@ static int vtenc_configure_encoder(AVCodecContext >>> *avctx) >>> vtctx->get_param_set_func = >>> compat_keys.CMVideoFormatDescriptionGetHEVCParameterSetAtIndex; >>> if (!vtctx->get_param_set_func) return AVERROR(EINVAL); >>> if (!get_vt_hevc_profile_level(avctx, _level)) return >>> AVERROR(EINVAL); >>> +vtctx->has_b_frames = avctx->max_b_frames > 0; >>> } >>> >>> enc_info = CFDictionaryCreateMutable( >>> -- >>> 2.21.1 (Apple Git-122.3) >>> >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". >>> >> >> >> Just to clarify, what this patch does. It will fix >> trac.ffmpeg.org/ticket/8353 "h264_videotoolbox is not writing b-frames". > >> The fix is adopted from HandBrake's FFmpeg patch set: >> https://github.com/HandBrake/HandBrake/blob/master/contrib/ffmpeg/A04-videotoolbox.patch > > Then please fix the attribution. OK, will do. But, where in send-email can I change the attribution? > And ask Bradley why he didn't send the patch here... The patch for HandBrake comes from galad87. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ 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] [PATCH] avcodec: Fix h264_videotoolbox writing b-frames (fix ticket #8353)
Am 27.02.20 um 19:13 schrieb Nomis101: > Signed-off-by: Nomis101 > --- > libavcodec/videotoolboxenc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c > index cc08cf6a50..32d893e485 100644 > --- a/libavcodec/videotoolboxenc.c > +++ b/libavcodec/videotoolboxenc.c > @@ -1355,6 +1355,7 @@ static int vtenc_configure_encoder(AVCodecContext > *avctx) > vtctx->get_param_set_func = > compat_keys.CMVideoFormatDescriptionGetHEVCParameterSetAtIndex; > if (!vtctx->get_param_set_func) return AVERROR(EINVAL); > if (!get_vt_hevc_profile_level(avctx, _level)) return > AVERROR(EINVAL); > +vtctx->has_b_frames = avctx->max_b_frames > 0; > } > > enc_info = CFDictionaryCreateMutable( > -- > 2.21.1 (Apple Git-122.3) > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > Just to clarify, what this patch does. It will fix trac.ffmpeg.org/ticket/8353 "h264_videotoolbox is not writing b-frames". The fix is adopted from HandBrake's FFmpeg patch set: https://github.com/HandBrake/HandBrake/blob/master/contrib/ffmpeg/A04-videotoolbox.patch ___ 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] [PATCH] avcodec: Fix h264_videotoolbox writing b-frames (fix ticket #8353)
Signed-off-by: Nomis101 --- libavcodec/videotoolboxenc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c index cc08cf6a50..32d893e485 100644 --- a/libavcodec/videotoolboxenc.c +++ b/libavcodec/videotoolboxenc.c @@ -1355,6 +1355,7 @@ static int vtenc_configure_encoder(AVCodecContext *avctx) vtctx->get_param_set_func = compat_keys.CMVideoFormatDescriptionGetHEVCParameterSetAtIndex; if (!vtctx->get_param_set_func) return AVERROR(EINVAL); if (!get_vt_hevc_profile_level(avctx, _level)) return AVERROR(EINVAL); +vtctx->has_b_frames = avctx->max_b_frames > 0; } enc_info = CFDictionaryCreateMutable( -- 2.21.1 (Apple Git-122.3) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] [PATCH] avcodec: Add more kCVImageBufferColorPrimaries to videotoolboxenc
Am 17.11.19 um 01:05 schrieb Richard Kern: > >> On Nov 16, 2019, at 7:03 PM, Nomis101 wrote: >> >> Thanks for reviewing. Would be nice, if somebody could push to master then. >> I can't. >> >> > I’ll test it out tomorrow and push. Cool, thank you very much. :-) > >>> Am 15.11.19 um 15:58 schrieb Limin Wang: >>>> On Sun, Nov 03, 2019 at 01:20:38AM +0100, Nomis101 wrote: >>>> --- >>>> libavcodec/videotoolboxenc.c | 8 >>>> 1 file changed, 8 insertions(+) >>>> >>>> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c >>>> index 40a7f643e0..cc08cf6a50 100644 >>>> --- a/libavcodec/videotoolboxenc.c >>>> +++ b/libavcodec/videotoolboxenc.c >>>> @@ -894,6 +894,14 @@ static int get_cv_color_primaries(AVCodecContext >>>> *avctx, >>>> *primaries = NULL; >>>> break; >>>> >>>> +case AVCOL_PRI_BT470BG: >>>> +*primaries = kCVImageBufferColorPrimaries_EBU_3213; >>>> +break; >>>> + >>>> +case AVCOL_PRI_SMPTE170M: >>>> +*primaries = kCVImageBufferColorPrimaries_SMPTE_C; >>>> +break; >>>> + >>> lgtm >>> >>>> case AVCOL_PRI_BT709: >>>> *primaries = kCVImageBufferColorPrimaries_ITU_R_709_2; >>>> break; >>>> -- >>>> 2.21.0 (Apple Git-122) >>>> >>>> ___ >>>> ffmpeg-devel mailing list >>>> ffmpeg-devel@ffmpeg.org >>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>>> >>>> To unsubscribe, visit link above, or email >>>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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] [PATCH] avcodec: Add more kCVImageBufferColorPrimaries to videotoolboxenc
Thanks for reviewing. Would be nice, if somebody could push to master then. I can't. Am 15.11.19 um 15:58 schrieb Limin Wang: > On Sun, Nov 03, 2019 at 01:20:38AM +0100, Nomis101 wrote: >> --- >> libavcodec/videotoolboxenc.c | 8 >> 1 file changed, 8 insertions(+) >> >> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c >> index 40a7f643e0..cc08cf6a50 100644 >> --- a/libavcodec/videotoolboxenc.c >> +++ b/libavcodec/videotoolboxenc.c >> @@ -894,6 +894,14 @@ static int get_cv_color_primaries(AVCodecContext *avctx, >> *primaries = NULL; >> break; >> >> +case AVCOL_PRI_BT470BG: >> +*primaries = kCVImageBufferColorPrimaries_EBU_3213; >> +break; >> + >> +case AVCOL_PRI_SMPTE170M: >> +*primaries = kCVImageBufferColorPrimaries_SMPTE_C; >> +break; >> + > lgtm > >> case AVCOL_PRI_BT709: >> *primaries = kCVImageBufferColorPrimaries_ITU_R_709_2; >> break; >> -- >> 2.21.0 (Apple Git-122) >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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] [PATCH] avcodec: Add more kCVImageBufferColorPrimaries to videotoolboxenc
Videotoolbox currently only supports the color primaries gamut ITU R 709 and 2020. This patch adds support for EBU 3213 (PAL video) and SMPTE C (standard definition video). That is importand for video convertion applications, based on FFmpeg. Would be nice to get this reviewed. Am 03.11.19 um 01:20 schrieb Nomis101: > --- > libavcodec/videotoolboxenc.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c > index 40a7f643e0..cc08cf6a50 100644 > --- a/libavcodec/videotoolboxenc.c > +++ b/libavcodec/videotoolboxenc.c > @@ -894,6 +894,14 @@ static int get_cv_color_primaries(AVCodecContext *avctx, > *primaries = NULL; > break; > > +case AVCOL_PRI_BT470BG: > +*primaries = kCVImageBufferColorPrimaries_EBU_3213; > +break; > + > +case AVCOL_PRI_SMPTE170M: > +*primaries = kCVImageBufferColorPrimaries_SMPTE_C; > +break; > + > case AVCOL_PRI_BT709: > *primaries = kCVImageBufferColorPrimaries_ITU_R_709_2; > break; > -- > 2.21.0 (Apple Git-122) > ___ 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] [PATCH] avcodec: Add more kCVImageBufferColorPrimaries to videotoolboxenc
--- libavcodec/videotoolboxenc.c | 8 1 file changed, 8 insertions(+) diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c index 40a7f643e0..cc08cf6a50 100644 --- a/libavcodec/videotoolboxenc.c +++ b/libavcodec/videotoolboxenc.c @@ -894,6 +894,14 @@ static int get_cv_color_primaries(AVCodecContext *avctx, *primaries = NULL; break; +case AVCOL_PRI_BT470BG: +*primaries = kCVImageBufferColorPrimaries_EBU_3213; +break; + +case AVCOL_PRI_SMPTE170M: +*primaries = kCVImageBufferColorPrimaries_SMPTE_C; +break; + case AVCOL_PRI_BT709: *primaries = kCVImageBufferColorPrimaries_ITU_R_709_2; break; -- 2.21.0 (Apple Git-122) ___ 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: Add smpte2084 transfer function to videotoolboxenc
Am 12.06.19 um 10:01 schrieb Michael Niedermayer: > On Wed, Jun 12, 2019 at 09:44:26AM +0200, Nomis101 wrote: >> This patch will add support of the smpte2084 transfer function to >> videotoolboxenc. kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ is >> available on macOS 10.13 and up. >> This is on the bug tracker at https://trac.ffmpeg.org/ticket/7953 >> >> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c >> index 3665581283..e786ebe3a7 100644 >> --- a/libavcodec/videotoolboxenc.c >> +++ b/libavcodec/videotoolboxenc.c >> @@ -909,6 +909,12 @@ static int get_cv_transfer_function(AVCodecContext >> *avctx, >> case AVCOL_TRC_SMPTE240M: >> *transfer_fnc = kCVImageBufferTransferFunction_SMPTE_240M_1995; >> break; >> + >> +#if __MAC_OS_X_VERSION_MIN_REQUIRED >= 101300 >> +case AVCOL_TRC_SMPTE2084: >> +*transfer_fnc = kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ; >> +break; >> +#endif >> >> case AVCOL_TRC_GAMMA22: >> gamma = 2.2; > > git does not like this patch > > Applying: avcodec: Add smpte2084 transfer function to videotoolboxenc > Using index info to reconstruct a base tree... > error: patch failed: libavcodec/videotoolboxenc.c:909 > error: libavcodec/videotoolboxenc.c: patch does not apply > error: Did you hand edit your patch? > It does not apply to blobs recorded in its index. > > > [..] > > > > ___ > 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". > Sorry, I removed some whitespace afterwards. My bad. I attached a new untouched patch created only by git format-patch. Hope this applies. From a973fa96e4f8f54351e14019acf6b1f7b5b3ff00 Mon Sep 17 00:00:00 2001 From: Nomis101 Date: Wed, 12 Jun 2019 10:32:47 +0200 Subject: [PATCH] [PATCH] avcodec: Add smpte2084 transfer function to videotoolboxenc --- libavcodec/videotoolboxenc.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c index 3665581283..f2cb24a012 100644 --- a/libavcodec/videotoolboxenc.c +++ b/libavcodec/videotoolboxenc.c @@ -910,6 +910,12 @@ static int get_cv_transfer_function(AVCodecContext *avctx, *transfer_fnc = kCVImageBufferTransferFunction_SMPTE_240M_1995; break; +#if __MAC_OS_X_VERSION_MIN_REQUIRED >= 101300 +case AVCOL_TRC_SMPTE2084: +*transfer_fnc = kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ; +break; +#endif + case AVCOL_TRC_GAMMA22: gamma = 2.2; *transfer_fnc = kCVImageBufferTransferFunction_UseGamma; -- 2.20.1 (Apple Git-117) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec: Add smpte2084 transfer function to videotoolboxenc
This patch will add support of the smpte2084 transfer function to videotoolboxenc. kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ is available on macOS 10.13 and up. This is on the bug tracker at https://trac.ffmpeg.org/ticket/7953 diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c index 3665581283..e786ebe3a7 100644 --- a/libavcodec/videotoolboxenc.c +++ b/libavcodec/videotoolboxenc.c @@ -909,6 +909,12 @@ static int get_cv_transfer_function(AVCodecContext *avctx, case AVCOL_TRC_SMPTE240M: *transfer_fnc = kCVImageBufferTransferFunction_SMPTE_240M_1995; break; + +#if __MAC_OS_X_VERSION_MIN_REQUIRED >= 101300 +case AVCOL_TRC_SMPTE2084: +*transfer_fnc = kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ; +break; +#endif case AVCOL_TRC_GAMMA22: gamma = 2.2; patch.bin Description: application/macbinary ___ 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] Is this a regression or not?
Am 28.05.19 um 21:33 schrieb Marton Balint: > > > On Tue, 28 May 2019, Nomis101 wrote: > >> I regularly build HandBrake against the latest FFmpeg master to check if all >> works as expected or something is broken and I need to open a bug. With the >> latest master I found some issues, but I'm >> unsure if this is a regression or not. >> After commit f9271d0158122c9e043b7d83f691884b65ec1ba5 HB doesn't recognize >> the audio stream anymore, so the encoded file has no audio stream at all. Is >> this >> 1. A regression and I should report this to the FFmpeg bug tracker >> or is it >> 2. A change in the way how streams are handled and all FFmpeg-depended >> applications will need to modify their code accordingly? > > From this description I don't know. Open a ticket in trac.ffmpeg.org and > post the command line handbrake generates and the ffmpeg command output. > > Thanks, > Marton > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > Thanks. I did report it to trac.ffmpeg.org now as #7928. It turned out, it was not the commit from my initital post. So, sorry for blaming the wrong commit. ___ 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] Is this a regression or not?
I regularly build HandBrake against the latest FFmpeg master to check if all works as expected or something is broken and I need to open a bug. With the latest master I found some issues, but I'm unsure if this is a regression or not. After commit f9271d0158122c9e043b7d83f691884b65ec1ba5 HB doesn't recognize the audio stream anymore, so the encoded file has no audio stream at all. Is this 1. A regression and I should report this to the FFmpeg bug tracker or is it 2. A change in the way how streams are handled and all FFmpeg-depended applications will need to modify their code accordingly? Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
