Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/vdpau: Enable HEVC support for working Nvidia driver versions
2019-02-03 22:09 GMT+01:00, Dominik 'Rathann' Mierzejewski : > On Sunday, 27 January 2019 at 19:48, Carl Eugen Hoyos wrote: >> 2019-01-27 19:43 GMT+01:00, Dominik 'Rathann' Mierzejewski >> : >> > On Sunday, 27 January 2019 at 19:29, Carl Eugen Hoyos wrote: >> >> 2019-01-27 19:06 GMT+01:00, Dominik 'Rathann' Mierzejewski >> >> : >> >> > Hello, >> >> > >> >> > On Wednesday, 31 October 2018 at 03:44, ManojGuptaBonda wrote: >> >> >> ffmpeg | branch: master | ManojGuptaBonda | Mon >> >> >> Oct >> >> >> 29 >> >> >> 13:57:54 2018 +0530| [4a6d5f3cadaabefe6c3548e575bb7e713997762f] | >> >> >> committer: Philip Langdale >> >> >> >> >> >> avcodec/vdpau: Enable HEVC support for working Nvidia driver >> >> >> versions >> >> >> >> >> >> The driver bugs that caused decoded HEVC content to have an >> >> >> incorrect >> >> >> memory layout have been fully fixed in the 410.xx driver release so >> >> >> we can start exposing support. >> >> >> >> >> >> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=4a6d5f3cadaabefe6c3548e575bb7e713997762f >> >> > >> >> > I have a user requesting a backport of this and >> >> > 4a976200d7853588336005a394dd31d905f5caf6 >> >> > to 4.0 branch which we use in Fedora/RPM Fusion 29: >> >> > https://bugzilla.rpmfusion.org/show_bug.cgi?id=5149 >> >> >> >> Wouldn't a user who uses an outdated version of FFmpeg >> >> typically also use an outdated Nvidia driver? >> > >> > No. Why would you say that? First, 4.0.x is not outdated from >> > where I'm sitting and second, we've updated the packaged >> > nVidia drivers in RPM Fusion for F29 to 415 already. >> >> Thank you for explaining, I misunderstood. >> >> Why are you updating Nvidia drivers but not FFmpeg? > > That would be a question to the package maintainer, not me. He's > maintaining packages for all supported nVidia driver series, not just > the latest, as far as I remember. > > As for updating FFmpeg, I consider it something akin to "libc" for all > things multimedia, so any update should be considered very carefully. I don't know anything about the development process of "libc" but there is nothing about an FFmpeg release that makes it better than the following one. >> Do you expect that (current) 4.0 has less bugs >> than the last 4.1 release? > > Not necessarily, but new features may come with new bugs, too. Of course! But there are many known bugs in FFmpeg 4.0 that are fixed in 4.1 (and some new features) so I don't see what the advantage of using 4.0. > Anyway, as James explained already, 4.1 is ABI and API > compatible, so I'll consider the update. Thanks. Given past experience, I hope you can recompile. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/vdpau: Enable HEVC support for working Nvidia driver versions
On Monday, 28 January 2019 at 04:54, James Almer wrote: > On 1/27/2019 3:43 PM, Dominik 'Rathann' Mierzejewski wrote: [...] > > If you're trying to say we can upgrade 4.0.x to 4.1.x without > > recompiling any dependent packages and you guarantee everything will > > work just like with 4.0.x, then I would be willing to entertain that > > option > > ffmpeg 4.1 is meant to be ABI compatible with 4.0, so you should be able > to replace the 4.0 libraries and anything linking to them should still > work without the need to be recompiled. > Now, "work just like with 4.0.x" is impossible to guarantee because > there were like five months of development between the two releases, and > some modules may behave slightly differently. That sounds good. I'll consider doing the upgrade. Though backporting the patches I asked in this thread would save me that work. Thanks for the reply. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/vdpau: Enable HEVC support for working Nvidia driver versions
On Sunday, 27 January 2019 at 19:57, Hendrik Leppkes wrote: > On Sun, Jan 27, 2019 at 7:43 PM Dominik 'Rathann' Mierzejewski > wrote: > > > > If you're trying to say we can upgrade 4.0.x to 4.1.x without > > recompiling any dependent packages and you guarantee everything will > > work just like with 4.0.x, then I would be willing to entertain that > > option, though we try to avoid upgrading base system components in the > > middle of a release cycle. > > Whats more base system then a driver? :) The kernel and Fedora keeps up with upstream in this regard. We don't update glibc mid-cycle, though, only between releases. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/vdpau: Enable HEVC support for working Nvidia driver versions
On Sunday, 27 January 2019 at 19:48, Carl Eugen Hoyos wrote: > 2019-01-27 19:43 GMT+01:00, Dominik 'Rathann' Mierzejewski > : > > On Sunday, 27 January 2019 at 19:29, Carl Eugen Hoyos wrote: > >> 2019-01-27 19:06 GMT+01:00, Dominik 'Rathann' Mierzejewski > >> : > >> > Hello, > >> > > >> > On Wednesday, 31 October 2018 at 03:44, ManojGuptaBonda wrote: > >> >> ffmpeg | branch: master | ManojGuptaBonda | Mon Oct > >> >> 29 > >> >> 13:57:54 2018 +0530| [4a6d5f3cadaabefe6c3548e575bb7e713997762f] | > >> >> committer: Philip Langdale > >> >> > >> >> avcodec/vdpau: Enable HEVC support for working Nvidia driver versions > >> >> > >> >> The driver bugs that caused decoded HEVC content to have an incorrect > >> >> memory layout have been fully fixed in the 410.xx driver release so > >> >> we can start exposing support. > >> >> > >> >> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=4a6d5f3cadaabefe6c3548e575bb7e713997762f > >> > > >> > I have a user requesting a backport of this and > >> > 4a976200d7853588336005a394dd31d905f5caf6 > >> > to 4.0 branch which we use in Fedora/RPM Fusion 29: > >> > https://bugzilla.rpmfusion.org/show_bug.cgi?id=5149 > >> > >> Wouldn't a user who uses an outdated version of FFmpeg > >> typically also use an outdated Nvidia driver? > > > > No. Why would you say that? First, 4.0.x is not outdated from > > where I'm sitting and second, we've updated the packaged > > nVidia drivers in RPM Fusion for F29 to 415 already. > > Thank you for explaining, I misunderstood. > > Why are you updating Nvidia drivers but not FFmpeg? That would be a question to the package maintainer, not me. He's maintaining packages for all supported nVidia driver series, not just the latest, as far as I remember. As for updating FFmpeg, I consider it something akin to "libc" for all things multimedia, so any update should be considered very carefully. > Do you expect that (current) 4.0 has less bugs > than the last 4.1 release? Not necessarily, but new features may come with new bugs, too. Anyway, as James explained already, 4.1 is ABI and API compatible, so I'll consider the update. Thanks. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2 v3] add libaribb24 ARIB STD-B24 caption decoder
* Outputs ASS lines with basic coloring and font scaling for each
given region.
* Sets the default style to the resolution of the subtitle plane
(for example, 960x540 / 36pt font for profile A).
* Has options to:
* Disable ruby text (which is coded as regions which have
half-height text in libaribb24).
Enabled by default as without positioning ruby text only
confuses as it is usually coded in the beginning of the decoded
subtitle line.
* Set the working directory, in which libaribb24 will read
configuration as well as into which it may save broadcast extra
symbols as PNG.
Unset by default.
The unconventional library check can be explained by the library's
current master branch being licensed as LGPLv3, but at the time of
writing the latest official release is still licensed under GPLv3.
Thus, one either has to wait for the following release, or enable
GPLv3.
---
Version 3 changes:
- Pre-converted subtitle region colors to BGR in local variables
to make checks work even in cases where the default colors are not
all 0xFF or 0x00-filled, and to use BGR values consistently.
- Added extra parenthesis around the active parts of the RGB_TO_BGR
macro to separate its content from the position it is used in.
Version 2 changes:
- Corrected colors by adding a macro that converts from RGB to BGR,
I had forgotten that ASS is not RGB.
Thanks to a nice person from the .jp DTV community to have
noticed this.
Changelog | 1 +
configure | 7 +
doc/decoders.texi | 25 +++
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 4 +
libavcodec/codec_desc.c | 9 +-
libavcodec/libaribb24.c | 384
libavcodec/profiles.c | 6 +
libavcodec/profiles.h | 1 +
libavcodec/version.h| 2 +-
11 files changed, 439 insertions(+), 2 deletions(-)
create mode 100644 libavcodec/libaribb24.c
diff --git a/Changelog b/Changelog
index 06cf6bf080..d5515c4911 100644
--- a/Changelog
+++ b/Changelog
@@ -17,6 +17,7 @@ version :
- maskfun filter
- hcom demuxer and decoder
- ARBC decoder
+- libaribb24 based ARIB STD-B24 caption support (profiles A and C)
version 4.1:
diff --git a/configure b/configure
index e1412352fa..cb852c6289 100755
--- a/configure
+++ b/configure
@@ -218,6 +218,7 @@ External library support:
--enable-jni enable JNI support [no]
--enable-ladspa enable LADSPA audio filtering [no]
--enable-libaom enable AV1 video encoding/decoding via libaom [no]
+ --enable-libaribb24 enable ARIB text and caption decoding via
libaribb24 [no]
--enable-libass enable libass subtitles rendering,
needed for subtitles and ass filter [no]
--enable-libbluray enable BluRay reading using libbluray [no]
@@ -1684,6 +1685,7 @@ EXTERNAL_LIBRARY_NONFREE_LIST="
EXTERNAL_LIBRARY_VERSION3_LIST="
gmp
liblensfun
+libaribb24
libopencore_amrnb
libopencore_amrwb
libvmaf
@@ -1707,6 +1709,7 @@ EXTERNAL_LIBRARY_LIST="
jni
ladspa
libaom
+libaribb24
libass
libbluray
libbs2b
@@ -3094,6 +3097,7 @@ hevc_videotoolbox_encoder_select="videotoolbox_encoder"
libaom_av1_decoder_deps="libaom"
libaom_av1_encoder_deps="libaom"
libaom_av1_encoder_select="extract_extradata_bsf"
+libaribb24_decoder_deps="libaribb24"
libcelt_decoder_deps="libcelt"
libcodec2_decoder_deps="libcodec2"
libcodec2_encoder_deps="libcodec2"
@@ -6080,6 +6084,9 @@ enabled gnutls&& require_pkg_config gnutls
gnutls gnutls/gnutls.h gn
enabled jni && { [ $target_os = "android" ] && check_headers
jni.h && enabled pthreads || die "ERROR: jni not found"; }
enabled ladspa&& require_headers "ladspa.h dlfcn.h"
enabled libaom&& require_pkg_config libaom "aom >= 1.0.0"
aom/aom_codec.h aom_codec_version
+enabled libaribb24&& { check_pkg_config libaribb24 "aribb24 > 1.0.3"
"aribb24/aribb24.h" arib_instance_new ||
+ { enabled gpl && require_pkg_config libaribb24
aribb24 "aribb24/aribb24.h" arib_instance_new; } ||
+ die "ERROR: libaribb24 requires version higher
than 1.0.3 or --enable-gpl."; }
enabled lv2 && require_pkg_config lv2 lilv-0 "lilv/lilv.h"
lilv_world_new
enabled libiec61883 && require libiec61883 libiec61883/iec61883.h
iec61883_cmp_connect -lraw1394 -lavc1394 -lrom1394 -liec61883
enabled libass&& require_pkg_config libass libass ass/ass.h
ass_library_init
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 25187e30f1..704bd60b9f 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -194,6 +194,31 @@ without this library.
@chapter Subtitles Decoders
@c man begin SUBTILES DECODERS
+@section libaribb24
+
+ARIB STD-B24 caption decoder.
+
+Implements profiles A and C of the ARIB
Re: [FFmpeg-devel] [PATCH 1/2 v2] add libaribb24 ARIB STD-B24 caption decoder
On Sun, Feb 3, 2019 at 5:34 PM Jan Ekström wrote:
>
> * Outputs ASS lines with basic coloring and font scaling for each
> given region.
> * Sets the default style to the resolution of the subtitle plane
> (for example, 960x540 / 36pt font for profile A).
> * Has options to:
> * Disable ruby text (which is coded as regions which have
> half-height text in libaribb24).
> Enabled by default as without positioning ruby text only
> confuses as it is usually coded in the beginning of the decoded
> subtitle line.
> * Set the working directory, in which libaribb24 will read
> configuration as well as into which it may save broadcast extra
> symbols as PNG.
> Unset by default.
>
> The unconventional library check can be explained by the library's
> current master branch being licensed as LGPLv3, but at the time of
> writing the latest official release is still licensed under GPLv3.
>
> Thus, one either has to wait for the following release, or enable
> GPLv3.
> ---
>
> Version 2 changes:
> - Corrected colors by adding a macro that converts from RGB to BGR,
> I had forgotten that ASS is not RGB.
> Thanks to a nice person from the .jp DTV community to have
> noticed this.
>
> Changelog | 1 +
> configure | 7 +
> doc/decoders.texi | 25 +++
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/avcodec.h| 4 +
> libavcodec/codec_desc.c | 9 +-
> libavcodec/libaribb24.c | 382
> libavcodec/profiles.c | 6 +
> libavcodec/profiles.h | 1 +
> libavcodec/version.h| 2 +-
> 11 files changed, 437 insertions(+), 2 deletions(-)
> create mode 100644 libavcodec/libaribb24.c
>
> diff --git a/Changelog b/Changelog
> index 06cf6bf080..d5515c4911 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -17,6 +17,7 @@ version :
> - maskfun filter
> - hcom demuxer and decoder
> - ARBC decoder
> +- libaribb24 based ARIB STD-B24 caption support (profiles A and C)
>
>
> version 4.1:
> diff --git a/configure b/configure
> index e1412352fa..cb852c6289 100755
> --- a/configure
> +++ b/configure
> @@ -218,6 +218,7 @@ External library support:
>--enable-jni enable JNI support [no]
>--enable-ladspa enable LADSPA audio filtering [no]
>--enable-libaom enable AV1 video encoding/decoding via libaom [no]
> + --enable-libaribb24 enable ARIB text and caption decoding via
> libaribb24 [no]
>--enable-libass enable libass subtitles rendering,
> needed for subtitles and ass filter [no]
>--enable-libbluray enable BluRay reading using libbluray [no]
> @@ -1684,6 +1685,7 @@ EXTERNAL_LIBRARY_NONFREE_LIST="
> EXTERNAL_LIBRARY_VERSION3_LIST="
> gmp
> liblensfun
> +libaribb24
> libopencore_amrnb
> libopencore_amrwb
> libvmaf
> @@ -1707,6 +1709,7 @@ EXTERNAL_LIBRARY_LIST="
> jni
> ladspa
> libaom
> +libaribb24
> libass
> libbluray
> libbs2b
> @@ -3094,6 +3097,7 @@ hevc_videotoolbox_encoder_select="videotoolbox_encoder"
> libaom_av1_decoder_deps="libaom"
> libaom_av1_encoder_deps="libaom"
> libaom_av1_encoder_select="extract_extradata_bsf"
> +libaribb24_decoder_deps="libaribb24"
> libcelt_decoder_deps="libcelt"
> libcodec2_decoder_deps="libcodec2"
> libcodec2_encoder_deps="libcodec2"
> @@ -6080,6 +6084,9 @@ enabled gnutls&& require_pkg_config gnutls
> gnutls gnutls/gnutls.h gn
> enabled jni && { [ $target_os = "android" ] && check_headers
> jni.h && enabled pthreads || die "ERROR: jni not found"; }
> enabled ladspa&& require_headers "ladspa.h dlfcn.h"
> enabled libaom&& require_pkg_config libaom "aom >= 1.0.0"
> aom/aom_codec.h aom_codec_version
> +enabled libaribb24&& { check_pkg_config libaribb24 "aribb24 > 1.0.3"
> "aribb24/aribb24.h" arib_instance_new ||
> + { enabled gpl && require_pkg_config
> libaribb24 aribb24 "aribb24/aribb24.h" arib_instance_new; } ||
> + die "ERROR: libaribb24 requires version
> higher than 1.0.3 or --enable-gpl."; }
> enabled lv2 && require_pkg_config lv2 lilv-0 "lilv/lilv.h"
> lilv_world_new
> enabled libiec61883 && require libiec61883 libiec61883/iec61883.h
> iec61883_cmp_connect -lraw1394 -lavc1394 -lrom1394 -liec61883
> enabled libass&& require_pkg_config libass libass ass/ass.h
> ass_library_init
> diff --git a/doc/decoders.texi b/doc/decoders.texi
> index 25187e30f1..704bd60b9f 100644
> --- a/doc/decoders.texi
> +++ b/doc/decoders.texi
> @@ -194,6 +194,31 @@ without this library.
> @chapter Subtitles Decoders
> @c man begin SUBTILES DECODERS
>
> +@section libaribb24
> +
> +ARIB STD-B24 caption decoder.
> +
> +Implements profiles A and C of the ARIB STD-B24 standard.
> +
> +@subsection libaribb24 Decoder Options
> +
>
Re: [FFmpeg-devel] [PATCH] avcodec/pgssubdec: Check for duplicate display segments
On Tue, Jan 29, 2019 at 01:32:17AM +0100, Michael Niedermayer wrote: > In such a duplication the previous gets overwritten and leaks > > Fixes: memleak > Fixes: > 12510/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGSSUB_fuzzer-5694439226343424 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/pgssubdec.c | 5 + > 1 file changed, 5 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC] avformat/mov: fixing sidx loading issues.
hi, i recently posted a patch to the mailing list that came from some very incorrect assumptions about the bmff spec. i've figured out what the actual issue is, and it is arguably more complex to solve, and requires some more serious changes to how sidx is loaded to fix, as such i'd like to list out the possible "solutions" in order of hackiness, and as i don't know the spec perfectly, i'd like to hear some thoughts on how each follows the spec. here we go: 1. checking offset = size and that the track id is equal to last track id. this works for both the fate test i failed early and the sample file, but breaks if the sidx atoms are out of order by track id. it also apparently doesn't take into account "non-indexed streams" that the spec seems to talk about in the description for a sidx box. 2. counting the number of sidx boxes there are and seeing if that's equal to the number of tracks * the number of moof boxes. i initially thought that there was a way to count moof boxes, but there probably isn't, and such there is no way to do this without reading the entire file. this doesn't take into account non-indexed streams, and probably breaks mpeg-ts. not a great idea. 3. the above but using the number of non-indexed streams(if there is a way to tell) works, but probably breaks mpeg-ts. probably not good. 4. just outright counting the number of sidx boxes and making the comparison the current sidx id to the number of sidx boxes. i imagine this is easy to implement for mpeg-ts, but requires some parser changes for fragmented mp4s, as we need to find the number of sidx boxes before parsing the rest of the file. this is the least hacky solution and would probably work in all cases, but it would probably require a little a bit more effort. if you have any ideas on how to do this better, feel free to scream your heart out, as i don't really entirely know what i'm doing. thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] tools/target_dec_fate.list: Extend selftests upto issue 2000
Signed-off-by: Michael Niedermayer --- tools/target_dec_fate.list | 266 + 1 file changed, 266 insertions(+) diff --git a/tools/target_dec_fate.list b/tools/target_dec_fate.list index b20137bfef..f6f131569e 100644 --- a/tools/target_dec_fate.list +++ b/tools/target_dec_fate.list @@ -125,6 +125,272 @@ 1141/clusterfuzz-testcase-6659734767665152 target_dec_amrnb_fuzzer 1213/clusterfuzz-testcase-minimized-6022987469815808 target_dec_tiff_fuzzer 1214/clusterfuzz-testcase-minimized-6130606599569408 target_dec_h264_fuzzer +1271/clusterfuzz-testcase-minimized-6095220498235392 target_dec_targa_fuzzer +1275/clusterfuzz-testcase-minimized-6718162017976320 target_dec_mdec_fuzzer +1280/clusterfuzz-testcase-minimized-6102353767825408 target_dec_svq3_fuzzer +1282/clusterfuzz-testcase-minimized-5400131681648640 target_dec_bmp_fuzzer +1283/clusterfuzz-testcase-minimized-6221126759874560 target_dec_vp3_fuzzer +1290/clusterfuzz-testcase-minimized-5815578902134784 target_dec_indeo2_fuzzer +1292/clusterfuzz-testcase-minimized-5795512143839232 target_dec_flic_fuzzer +1293/clusterfuzz-testcase-minimized-6054752074858496 target_dec_smc_fuzzer +1298/clusterfuzz-testcase-minimized-5955580877340672 target_dec_mpeg4_fuzzer +1305/clusterfuzz-testcase-minimized-5787235003662336 target_dec_amv_fuzzer +1306/clusterfuzz-testcase-minimized-6152296217968640 target_dec_msvideo1_fuzzer +1309/clusterfuzz-testcase-minimized-5754803370065920 target_dec_pcx_fuzzer +1314/clusterfuzz-testcase-minimized-4621997222920192 target_dec_png_fuzzer +1321/clusterfuzz-testcase-minimized-5875549597597696 target_dec_cinepak_fuzzer +1322/clusterfuzz-testcase-minimized-4728193644756992 target_dec_png_fuzzer +1335/clusterfuzz-testcase-minimized-5566961566089216 target_dec_cavs_fuzzer +1336/clusterfuzz-testcase-minimized-4761381930795008 target_dec_pixlet_fuzzer +1337/clusterfuzz-testcase-minimized-5212314171080704 target_dec_aac_fuzzer +1338/clusterfuzz-testcase-minimized-6485546354343936 target_dec_wnv1_fuzzer +1339/clusterfuzz-testcase-minimized-4614671485108224 target_dec_dss_sp_fuzzer +1340/clusterfuzz-testcase-minimized-4669892148068352 target_dec_adpcm_g722_fuzzer +1341/clusterfuzz-testcase-minimized-5441502618583040 target_dec_cdxl_fuzzer +1342/clusterfuzz-testcase-minimized-5490842129137664 target_dec_nellymoser_fuzzer +1344/clusterfuzz-testcase-minimized-5567131804499968 target_dec_zmbv_fuzzer +1345/clusterfuzz-testcase-minimized-6062963045695488 target_dec_dfa_fuzzer +1346/clusterfuzz-testcase-minimized-5776732600664064 target_dec_mdec_fuzzer +1348/clusterfuzz-testcase-minimized-6195673642827776 target_dec_tiertexseqvideo_fuzzer +1349/clusterfuzz-testcase-minimized-5370707196248064 target_dec_aac_fuzzer +1351/clusterfuzz-testcase-minimized-5861971645693952 target_dec_indeo4_fuzzer +1352/clusterfuzz-testcase-minimized-5757565017260032 target_dec_ac3_fixed_fuzzer +1353/clusterfuzz-testcase-minimized-5208180449607680 target_dec_snow_fuzzer +1354/clusterfuzz-testcase-minimized-5520132195483648 target_dec_sami_fuzzer +1355/clusterfuzz-testcase-minimized-6662205472768000 target_dec_mlp_fuzzer +1356/clusterfuzz-testcase-minimized-6008489086287872 target_dec_fic_fuzzer +1360/clusterfuzz-testcase-minimized-5606472043986944 target_dec_clearvideo_fuzzer
[FFmpeg-devel] [PATCH 1/2] avcodec/sbrdsp_fixed.c: remove input value limit for sbr_sum_square_c()
Fixes: 1377/clusterfuzz-testcase-minimized-5487049807233024
Fixes: assertion failure in sbr_sum_square_c()
Signed-off-by: Michael Niedermayer
---
libavcodec/sbrdsp_fixed.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/libavcodec/sbrdsp_fixed.c b/libavcodec/sbrdsp_fixed.c
index 57d98da979..91fa664c08 100644
--- a/libavcodec/sbrdsp_fixed.c
+++ b/libavcodec/sbrdsp_fixed.c
@@ -34,32 +34,36 @@
static SoftFloat sbr_sum_square_c(int (*x)[2], int n)
{
SoftFloat ret;
-uint64_t accu, round;
+uint64_t accu = 0, round;
uint64_t accu0 = 0, accu1 = 0, accu2 = 0, accu3 = 0;
int i, nz, nz0;
unsigned u;
+nz = 0;
for (i = 0; i < n; i += 2) {
-// Larger values are inavlid and could cause overflows of accu.
-av_assert2(FFABS(x[i + 0][0]) >> 30 == 0);
accu0 += (int64_t)x[i + 0][0] * x[i + 0][0];
-av_assert2(FFABS(x[i + 0][1]) >> 30 == 0);
accu1 += (int64_t)x[i + 0][1] * x[i + 0][1];
-av_assert2(FFABS(x[i + 1][0]) >> 30 == 0);
accu2 += (int64_t)x[i + 1][0] * x[i + 1][0];
-av_assert2(FFABS(x[i + 1][1]) >> 30 == 0);
accu3 += (int64_t)x[i + 1][1] * x[i + 1][1];
+if ((accu0|accu1|accu2|accu3) > UINT64_MAX -
INT32_MIN*(int64_t)INT32_MIN || i+2>=n) {
+accu0 >>= nz;
+accu1 >>= nz;
+accu2 >>= nz;
+accu3 >>= nz;
+while ((accu0|accu1|accu2|accu3) > (UINT64_MAX - accu) >> 2) {
+accu0 >>= 1;
+accu1 >>= 1;
+accu2 >>= 1;
+accu3 >>= 1;
+accu >>= 1;
+nz ++;
+}
+accu += accu0 + accu1 + accu2 + accu3;
+accu0 = accu1 = accu2 = accu3 = 0;
+}
}
-nz0 = 15;
-while ((accu0|accu1|accu2|accu3) >> 62) {
-accu0 >>= 1;
-accu1 >>= 1;
-accu2 >>= 1;
-accu3 >>= 1;
-nz0 --;
-}
-accu = accu0 + accu1 + accu2 + accu3;
+nz0 = 15 - nz;
u = accu >> 32;
if (u) {
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: request explicitly enabled components
On 3 Feb 2019, at 16:24, Marton Balint wrote: On Sun, 3 Feb 2019, Carl Eugen Hoyos wrote: 2019-01-28 2:00 GMT+01:00, Marton Balint : If we enable a component but a dependant library is disabled, then the enabled component get silently disabled. Requesting all explicitly enabled components allows configure to fail and show the missing dependencies instead of ignoring our request. For example if libdav1d is not availble ./configure --enable-decoder=libdav1d succeeds but the libdav1d decoder will not be enabled. After the patch the configure line will fail with the following message: ERROR: libdav1d_decoder requested, but not all dependencies are satisfied: libdav1d Signed-off-by: Marton Balint --- configure | 1 + 1 file changed, 1 insertion(+) diff --git a/configure b/configure index e1412352fa..1f6c6a7311 100755 --- a/configure +++ b/configure @@ -3881,6 +3881,7 @@ for opt do list=$(filter "$name" $list) [ "$list" = "" ] && warn "Option $opt did not match anything" $action $list +test $action = enable && request $list I strongly suspect that this will break regression tests. You mean fate with different configure options? I didn't find a fate instance explicity enabling a certain component. Even if some previously used configure commands error out, that is good IMHO because the user will know that a certain component won't be included in the build. What exactly does this fix? If you don't "--enable-libdav1d", you cannot get libdav1d. That is the point. If I tell configure that I want libdav1d decoder (as in --enable-decoder=libdav1d), it should either give it to me or error out. It should NOT silently disregard my request. You see the discrepancy: --enable-libdav1d error out if libdav1d is not available --enable-decoder=libdav1d does not error out if the libdav1d decoder is not available Also dependencies are often not trivial. Consider that I want the blackframe filter: ./configure --enable-filter=blackframe This succeeds yet it does not enable the filter. Why? Because the filter is GPL. How should I know why it got silently disabled if configure does not error out? I agree that when explicitly enabling something, it should be enabled or cause an error, this is what all build systems I have worked with do and definitely would be the behavior I would expect from FFmpegs configure script. Also, configure's console output shows what was enabled. That does not tell you why a component got disabled. It is also unreasonable to ask the user to always verify that everything stayed in which he explicitly enabled. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2 v2] add libaribb24 ARIB STD-B24 caption decoder
* Outputs ASS lines with basic coloring and font scaling for each
given region.
* Sets the default style to the resolution of the subtitle plane
(for example, 960x540 / 36pt font for profile A).
* Has options to:
* Disable ruby text (which is coded as regions which have
half-height text in libaribb24).
Enabled by default as without positioning ruby text only
confuses as it is usually coded in the beginning of the decoded
subtitle line.
* Set the working directory, in which libaribb24 will read
configuration as well as into which it may save broadcast extra
symbols as PNG.
Unset by default.
The unconventional library check can be explained by the library's
current master branch being licensed as LGPLv3, but at the time of
writing the latest official release is still licensed under GPLv3.
Thus, one either has to wait for the following release, or enable
GPLv3.
---
Version 2 changes:
- Corrected colors by adding a macro that converts from RGB to BGR,
I had forgotten that ASS is not RGB.
Thanks to a nice person from the .jp DTV community to have
noticed this.
Changelog | 1 +
configure | 7 +
doc/decoders.texi | 25 +++
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 4 +
libavcodec/codec_desc.c | 9 +-
libavcodec/libaribb24.c | 382
libavcodec/profiles.c | 6 +
libavcodec/profiles.h | 1 +
libavcodec/version.h| 2 +-
11 files changed, 437 insertions(+), 2 deletions(-)
create mode 100644 libavcodec/libaribb24.c
diff --git a/Changelog b/Changelog
index 06cf6bf080..d5515c4911 100644
--- a/Changelog
+++ b/Changelog
@@ -17,6 +17,7 @@ version :
- maskfun filter
- hcom demuxer and decoder
- ARBC decoder
+- libaribb24 based ARIB STD-B24 caption support (profiles A and C)
version 4.1:
diff --git a/configure b/configure
index e1412352fa..cb852c6289 100755
--- a/configure
+++ b/configure
@@ -218,6 +218,7 @@ External library support:
--enable-jni enable JNI support [no]
--enable-ladspa enable LADSPA audio filtering [no]
--enable-libaom enable AV1 video encoding/decoding via libaom [no]
+ --enable-libaribb24 enable ARIB text and caption decoding via
libaribb24 [no]
--enable-libass enable libass subtitles rendering,
needed for subtitles and ass filter [no]
--enable-libbluray enable BluRay reading using libbluray [no]
@@ -1684,6 +1685,7 @@ EXTERNAL_LIBRARY_NONFREE_LIST="
EXTERNAL_LIBRARY_VERSION3_LIST="
gmp
liblensfun
+libaribb24
libopencore_amrnb
libopencore_amrwb
libvmaf
@@ -1707,6 +1709,7 @@ EXTERNAL_LIBRARY_LIST="
jni
ladspa
libaom
+libaribb24
libass
libbluray
libbs2b
@@ -3094,6 +3097,7 @@ hevc_videotoolbox_encoder_select="videotoolbox_encoder"
libaom_av1_decoder_deps="libaom"
libaom_av1_encoder_deps="libaom"
libaom_av1_encoder_select="extract_extradata_bsf"
+libaribb24_decoder_deps="libaribb24"
libcelt_decoder_deps="libcelt"
libcodec2_decoder_deps="libcodec2"
libcodec2_encoder_deps="libcodec2"
@@ -6080,6 +6084,9 @@ enabled gnutls&& require_pkg_config gnutls
gnutls gnutls/gnutls.h gn
enabled jni && { [ $target_os = "android" ] && check_headers
jni.h && enabled pthreads || die "ERROR: jni not found"; }
enabled ladspa&& require_headers "ladspa.h dlfcn.h"
enabled libaom&& require_pkg_config libaom "aom >= 1.0.0"
aom/aom_codec.h aom_codec_version
+enabled libaribb24&& { check_pkg_config libaribb24 "aribb24 > 1.0.3"
"aribb24/aribb24.h" arib_instance_new ||
+ { enabled gpl && require_pkg_config libaribb24
aribb24 "aribb24/aribb24.h" arib_instance_new; } ||
+ die "ERROR: libaribb24 requires version higher
than 1.0.3 or --enable-gpl."; }
enabled lv2 && require_pkg_config lv2 lilv-0 "lilv/lilv.h"
lilv_world_new
enabled libiec61883 && require libiec61883 libiec61883/iec61883.h
iec61883_cmp_connect -lraw1394 -lavc1394 -lrom1394 -liec61883
enabled libass&& require_pkg_config libass libass ass/ass.h
ass_library_init
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 25187e30f1..704bd60b9f 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -194,6 +194,31 @@ without this library.
@chapter Subtitles Decoders
@c man begin SUBTILES DECODERS
+@section libaribb24
+
+ARIB STD-B24 caption decoder.
+
+Implements profiles A and C of the ARIB STD-B24 standard.
+
+@subsection libaribb24 Decoder Options
+
+@table @option
+
+@item -aribb24-base-path @var{path}
+Sets the base path for the libaribb24 library. This is utilized for reading of
+configuration files (for custom unicode conversions), and for dumping of
+non-text symbols as images under that location.
+
+Unset by default.
+
+@item
Re: [FFmpeg-devel] [PATCH] configure: request explicitly enabled components
On Sun, 3 Feb 2019, Carl Eugen Hoyos wrote: 2019-01-28 2:00 GMT+01:00, Marton Balint : If we enable a component but a dependant library is disabled, then the enabled component get silently disabled. Requesting all explicitly enabled components allows configure to fail and show the missing dependencies instead of ignoring our request. For example if libdav1d is not availble ./configure --enable-decoder=libdav1d succeeds but the libdav1d decoder will not be enabled. After the patch the configure line will fail with the following message: ERROR: libdav1d_decoder requested, but not all dependencies are satisfied: libdav1d Signed-off-by: Marton Balint --- configure | 1 + 1 file changed, 1 insertion(+) diff --git a/configure b/configure index e1412352fa..1f6c6a7311 100755 --- a/configure +++ b/configure @@ -3881,6 +3881,7 @@ for opt do list=$(filter "$name" $list) [ "$list" = "" ] && warn "Option $opt did not match anything" $action $list +test $action = enable && request $list I strongly suspect that this will break regression tests. You mean fate with different configure options? I didn't find a fate instance explicity enabling a certain component. Even if some previously used configure commands error out, that is good IMHO because the user will know that a certain component won't be included in the build. What exactly does this fix? If you don't "--enable-libdav1d", you cannot get libdav1d. That is the point. If I tell configure that I want libdav1d decoder (as in --enable-decoder=libdav1d), it should either give it to me or error out. It should NOT silently disregard my request. You see the discrepancy: --enable-libdav1d error out if libdav1d is not available --enable-decoder=libdav1d does not error out if the libdav1d decoder is not available Also dependencies are often not trivial. Consider that I want the blackframe filter: ./configure --enable-filter=blackframe This succeeds yet it does not enable the filter. Why? Because the filter is GPL. How should I know why it got silently disabled if configure does not error out? Also, configure's console output shows what was enabled. That does not tell you why a component got disabled. It is also unreasonable to ask the user to always verify that everything stayed in which he explicitly enabled. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
Binary searching would hang if the fragment items do NOT have timestamp for the
specified stream.
For example, a fmp4 consists of separated 'moof' boxes for each track, and
separated 'sidx' for each segment, but no 'mfra' box.
Then every fragment item only have the timestamp for one of its tracks.
Signed-off-by: Charles Liu
---
libavformat/mov.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9b9739f788..35cb619e9f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1266,7 +1266,7 @@ static int64_t get_frag_time(MOVFragmentIndex *frag_index,
static int search_frag_timestamp(MOVFragmentIndex *frag_index,
AVStream *st, int64_t timestamp)
{
-int a, b, m;
+int a, b, m, m0;
int64_t frag_time;
int id = -1;
@@ -1282,15 +1282,18 @@ static int search_frag_timestamp(MOVFragmentIndex
*frag_index,
b = frag_index->nb_items;
while (b - a > 1) {
-m = (a + b) >> 1;
-frag_time = get_frag_time(frag_index, m, id);
-if (frag_time != AV_NOPTS_VALUE) {
-if (frag_time >= timestamp)
-b = m;
-if (frag_time <= timestamp)
-a = m;
-}
+m0 = m = (a + b) >> 1;
+
+while (m < b &&
+ (frag_time = get_frag_time(frag_index, m, id)) ==
AV_NOPTS_VALUE)
+m++;
+
+if (m < b && frag_time <= timestamp)
+a = m;
+else
+b = m0;
}
+
return a;
}
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2 v2] lavf/mpegts: add reading of ARIB data coding descriptor
On Sun, Feb 3, 2019 at 3:33 PM Jan Ekström wrote:
>
> On Sun, Feb 3, 2019 at 3:12 PM Carl Eugen Hoyos wrote:
> >
> > 2019-02-03 1:39 GMT+01:00, Jan Ekström :
> > > This enables us to read the data coding type utilized for
> > > a specific private data stream, of which we currently are
> > > interested in ARIB caption streams.
> > >
> > > The component tag limitations are according to ARIB TR-B14,
> > > and the component IDs are defined in ARIB STD-B10.
> > > ---
> > > libavformat/mpegts.c | 44 +++
> > > libavformat/version.h | 2 +-
> > > 2 files changed, 45 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> > > index 300db110d4..f9dc04eb52 100644
> > > --- a/libavformat/mpegts.c
> > > +++ b/libavformat/mpegts.c
> > > @@ -2013,6 +2013,50 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc,
> > > AVStream *st, int stream_type
> > > }
> > > }
> > > break;
> > > +case 0xfd: /* ARIB data coding type descriptor */
> > > +// STD-B24, fascicle 3, chapter 4 defines private_stream_1
> > > +// for captions
> > > +if (stream_type == STREAM_TYPE_PRIVATE_DATA) {
> > > +// This structure is defined in STD-B10, part 1, listing 5.4
> > > and
> > > +// part 2, 6.2.20).
> > > +// Listing of data_component_ids is in STD-B10, part 2, Annex
> > > J.
> > > +// Component tag limits are documented in TR-B14, fascicle 2,
> > > +// Vol. 3, Section 2, 4.2.8.1
> > > +int actual_component_tag = st->stream_identifier - 1;
> > > +int picked_profile = FF_PROFILE_UNKNOWN;
> > > +int data_component_id = get16(pp, desc_end);
> >
> > > +if (data_component_id < 0)
> > > +return AVERROR_INVALIDDATA;
> >
> > What is the effect of this return if it happens?
> > Why isn't this just a "break" like below?
> >
>
> I think this might have been a half-automatic thing on my behalf after
> seeing that get16 does indeed return an error value if it can't read
> that amount of data.
>
> Although, it seems like there is no concise way of handling errors
> even in this function (`ff_parse_mpeg2_descriptor`):
> 1. 0x1E breaks.
> 2. 0x56, 0x59 set AVERROR_INVALIDDATA if the descriptor is not long
> enough (pointer check instead of getXX though).
> 3. 0x26 does an exact equality check on a specific value and ignores
> result otherwise.
> 4. 0x7f does a getXX and then returns AVERROR_INVALIDDATA if it fails
> (this is getting similar to what I did).
>
> Personally I don't have heavy feelings about how I exit this function,
> but I feel like if there's not enough data and we've gotten as far as
> we've got, returning "invalid data" is not incorrect (and has a
> precedent).
>
Also sorry, I just noticed the two different types of exit. I guess I
did just a break there since we seem to still have a valid structure,
but we're just not interested in that specific coding type.
(a list of them can be seen in the specs I noted).
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2 v2] lavf/mpegts: add reading of ARIB data coding descriptor
On Sun, Feb 3, 2019 at 3:12 PM Carl Eugen Hoyos wrote:
>
> 2019-02-03 1:39 GMT+01:00, Jan Ekström :
> > This enables us to read the data coding type utilized for
> > a specific private data stream, of which we currently are
> > interested in ARIB caption streams.
> >
> > The component tag limitations are according to ARIB TR-B14,
> > and the component IDs are defined in ARIB STD-B10.
> > ---
> > libavformat/mpegts.c | 44 +++
> > libavformat/version.h | 2 +-
> > 2 files changed, 45 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> > index 300db110d4..f9dc04eb52 100644
> > --- a/libavformat/mpegts.c
> > +++ b/libavformat/mpegts.c
> > @@ -2013,6 +2013,50 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc,
> > AVStream *st, int stream_type
> > }
> > }
> > break;
> > +case 0xfd: /* ARIB data coding type descriptor */
> > +// STD-B24, fascicle 3, chapter 4 defines private_stream_1
> > +// for captions
> > +if (stream_type == STREAM_TYPE_PRIVATE_DATA) {
> > +// This structure is defined in STD-B10, part 1, listing 5.4
> > and
> > +// part 2, 6.2.20).
> > +// Listing of data_component_ids is in STD-B10, part 2, Annex
> > J.
> > +// Component tag limits are documented in TR-B14, fascicle 2,
> > +// Vol. 3, Section 2, 4.2.8.1
> > +int actual_component_tag = st->stream_identifier - 1;
> > +int picked_profile = FF_PROFILE_UNKNOWN;
> > +int data_component_id = get16(pp, desc_end);
>
> > +if (data_component_id < 0)
> > +return AVERROR_INVALIDDATA;
>
> What is the effect of this return if it happens?
> Why isn't this just a "break" like below?
>
I think this might have been a half-automatic thing on my behalf after
seeing that get16 does indeed return an error value if it can't read
that amount of data.
Although, it seems like there is no concise way of handling errors
even in this function (`ff_parse_mpeg2_descriptor`):
1. 0x1E breaks.
2. 0x56, 0x59 set AVERROR_INVALIDDATA if the descriptor is not long
enough (pointer check instead of getXX though).
3. 0x26 does an exact equality check on a specific value and ignores
result otherwise.
4. 0x7f does a getXX and then returns AVERROR_INVALIDDATA if it fails
(this is getting similar to what I did).
Personally I don't have heavy feelings about how I exit this function,
but I feel like if there's not enough data and we've gotten as far as
we've got, returning "invalid data" is not incorrect (and has a
precedent).
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2 v2] lavf/mpegts: add reading of ARIB data coding descriptor
2019-02-03 1:39 GMT+01:00, Jan Ekström :
> This enables us to read the data coding type utilized for
> a specific private data stream, of which we currently are
> interested in ARIB caption streams.
>
> The component tag limitations are according to ARIB TR-B14,
> and the component IDs are defined in ARIB STD-B10.
> ---
> libavformat/mpegts.c | 44 +++
> libavformat/version.h | 2 +-
> 2 files changed, 45 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index 300db110d4..f9dc04eb52 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -2013,6 +2013,50 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc,
> AVStream *st, int stream_type
> }
> }
> break;
> +case 0xfd: /* ARIB data coding type descriptor */
> +// STD-B24, fascicle 3, chapter 4 defines private_stream_1
> +// for captions
> +if (stream_type == STREAM_TYPE_PRIVATE_DATA) {
> +// This structure is defined in STD-B10, part 1, listing 5.4
> and
> +// part 2, 6.2.20).
> +// Listing of data_component_ids is in STD-B10, part 2, Annex
> J.
> +// Component tag limits are documented in TR-B14, fascicle 2,
> +// Vol. 3, Section 2, 4.2.8.1
> +int actual_component_tag = st->stream_identifier - 1;
> +int picked_profile = FF_PROFILE_UNKNOWN;
> +int data_component_id = get16(pp, desc_end);
> +if (data_component_id < 0)
> +return AVERROR_INVALIDDATA;
What is the effect of this return if it happens?
Why isn't this just a "break" like below?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: request explicitly enabled components
2019-01-28 2:00 GMT+01:00, Marton Balint : > If we enable a component but a dependant library is disabled, then the > enabled > component get silently disabled. Requesting all explicitly enabled > components > allows configure to fail and show the missing dependencies instead of > ignoring > our request. > > For example if libdav1d is not availble ./configure > --enable-decoder=libdav1d > succeeds but the libdav1d decoder will not be enabled. After the patch the > configure line will fail with the following message: > ERROR: libdav1d_decoder requested, but not all dependencies are satisfied: > libdav1d > > Signed-off-by: Marton Balint > --- > configure | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configure b/configure > index e1412352fa..1f6c6a7311 100755 > --- a/configure > +++ b/configure > @@ -3881,6 +3881,7 @@ for opt do > list=$(filter "$name" $list) > [ "$list" = "" ] && warn "Option $opt did not match anything" > $action $list > +test $action = enable && request $list I strongly suspect that this will break regression tests. What exactly does this fix? If you don't "--enable-libdav1d", you cannot get libdav1d. Also, configure's console output shows what was enabled. I am not happy with this patch, sorry, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] configure: request explicitly enabled components
On Mon, 28 Jan 2019, Marton Balint wrote:
If we enable a component but a dependant library is disabled, then the enabled
component get silently disabled. Requesting all explicitly enabled components
allows configure to fail and show the missing dependencies instead of ignoring
our request.
For example if libdav1d is not availble ./configure --enable-decoder=libdav1d
succeeds but the libdav1d decoder will not be enabled. After the patch the
configure line will fail with the following message:
ERROR: libdav1d_decoder requested, but not all dependencies are satisfied:
libdav1d
Signed-off-by: Marton Balint
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index e1412352fa..afe64bf98a 100755
--- a/configure
+++ b/configure
@@ -3880,6 +3880,7 @@ for opt do
name=$(echo "${optval}" | sed "s/,/_${thing}|/g")_${thing}
list=$(filter "$name" $list)
[ "$list" = "" ] && warn "Option $opt did not match anything"
+test $action = enable && request $list
$action $list
;;
--enable-yasm|--disable-yasm)
--
Ping.
Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
