[FFmpeg-devel] [PATCH 3/3] vf_colorspace: Add support for smpte 431/432 (dci/display p3) primaries
Signed-off-by: Vittorio Giovara
---
I couldn't find any reference to the name of the whitepoint used for 431,
so I came up with DCI, since it looks like it is only used there.
Please CC.
Vittorio
libavfilter/vf_colorspace.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index 7e0bafa..4265aa1 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -56,6 +56,7 @@ enum Colorspace {
enum Whitepoint {
WP_D65,
WP_C,
+WP_DCI,
WP_NB,
};
@@ -268,6 +269,7 @@ static const struct TransferCharacteristics *
static const struct WhitepointCoefficients whitepoint_coefficients[WP_NB] = {
[WP_D65] = { 0.3127, 0.3290 },
[WP_C] = { 0.3100, 0.3160 },
+[WP_DCI] = { 0.3140, 0.3510 },
};
static const struct ColorPrimaries color_primaries[AVCOL_PRI_NB] = {
@@ -276,6 +278,8 @@ static const struct ColorPrimaries
color_primaries[AVCOL_PRI_NB] = {
[AVCOL_PRI_BT470BG] = { WP_D65, 0.640, 0.330, 0.290, 0.600, 0.150,
0.060,},
[AVCOL_PRI_SMPTE170M] = { WP_D65, 0.630, 0.340, 0.310, 0.595, 0.155, 0.070
},
[AVCOL_PRI_SMPTE240M] = { WP_D65, 0.630, 0.340, 0.310, 0.595, 0.155, 0.070
},
+[AVCOL_PRI_SMPTE431] = { WP_DCI, 0.680, 0.320, 0.265, 0.690, 0.150, 0.060
},
+[AVCOL_PRI_SMPTE432] = { WP_D65, 0.680, 0.320, 0.265, 0.690, 0.150, 0.060
},
[AVCOL_PRI_BT2020]= { WP_D65, 0.708, 0.292, 0.170, 0.797, 0.131, 0.046
},
};
@@ -1080,6 +1084,8 @@ static const AVOption colorspace_options[] = {
ENUM("bt470bg", AVCOL_PRI_BT470BG,"prm"),
ENUM("smpte170m",AVCOL_PRI_SMPTE170M, "prm"),
ENUM("smpte240m",AVCOL_PRI_SMPTE240M, "prm"),
+ENUM("smpte431", AVCOL_PRI_SMPTE431, "prm"),
+ENUM("smpte432", AVCOL_PRI_SMPTE432, "prm"),
ENUM("bt2020", AVCOL_PRI_BT2020, "prm"),
{ "trc","Output transfer characteristics",
--
2.10.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] vf_colorspace: Add support for iec61966-2.4 (xvYCC) transfer
Signed-off-by: Vittorio Giovara
---
As described in http://www.color.org/chardata/rgb/xvycc.xalter
Please CC.
Vittorio
libavfilter/vf_colorspace.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index 930aa95..d26f658 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -232,6 +232,7 @@ static const struct TransferCharacteristics
transfer_characteristics[AVCOL_TRC_N
[AVCOL_TRC_SMPTE170M] = { 1.099, 0.018, 0.45, 4.5 },
[AVCOL_TRC_SMPTE240M] = { 1.1115, 0.0228, 0.45, 4.0 },
[AVCOL_TRC_IEC61966_2_1] = { 1.055, 0.0031308, 1.0 / 2.4, 12.92 },
+[AVCOL_TRC_IEC61966_2_4] = { 1.099, 0.018, 0.45, 4.5 },
[AVCOL_TRC_BT2020_10] = { 1.099, 0.018, 0.45, 4.5 },
[AVCOL_TRC_BT2020_12] = { 1.0993, 0.0181, 0.45, 4.5 },
};
@@ -1078,6 +1079,8 @@ static const AVOption colorspace_options[] = {
ENUM("smpte240m",AVCOL_TRC_SMPTE240M,"trc"),
ENUM("srgb", AVCOL_TRC_IEC61966_2_1, "trc"),
ENUM("iec61966-2-1", AVCOL_TRC_IEC61966_2_1, "trc"),
+ENUM("xvycc",AVCOL_TRC_IEC61966_2_4, "trc"),
+ENUM("iec61966-2-4", AVCOL_TRC_IEC61966_2_4, "trc"),
ENUM("bt2020-10",AVCOL_TRC_BT2020_10,"trc"),
ENUM("bt2020-12",AVCOL_TRC_BT2020_12,"trc"),
--
2.10.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] vf_colorspace: Add support for ycgco color space
Signed-off-by: Vittorio Giovara
---
This is a little hackish, not sure how to represent the matrix otherwise.
Please CC.
Vittorio
libavfilter/vf_colorspace.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index d26f658..7e0bafa 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -175,6 +175,13 @@ typedef struct ColorSpaceContext {
// FIXME dithering if bitdepth goes down?
// FIXME bitexact for fate integration?
+static const double ycgco_matrix[3][3] =
+{
+{ 0.25, 0.5, 0.25 },
+{ -0.25, 0.5, -0.25 },
+{ 0.5, 0, -0.5 },
+};
+
/*
* All constants explained in e.g.
https://linuxtv.org/downloads/v4l-dvb-apis/ch02s06.html
* The older ones (bt470bg/m) are also explained in their respective ITU docs
@@ -187,6 +194,7 @@ static const struct LumaCoefficients
luma_coefficients[AVCOL_SPC_NB] = {
[AVCOL_SPC_SMPTE170M] = { 0.299, 0.587, 0.114 },
[AVCOL_SPC_BT709] = { 0.2126, 0.7152, 0.0722 },
[AVCOL_SPC_SMPTE240M] = { 0.212, 0.701, 0.087 },
+[AVCOL_SPC_YCOCG] = { 0.25, 0.5,0.25 },
[AVCOL_SPC_BT2020_NCL] = { 0.2627, 0.6780, 0.0593 },
[AVCOL_SPC_BT2020_CL] = { 0.2627, 0.6780, 0.0593 },
};
@@ -209,6 +217,12 @@ static void fill_rgb2yuv_table(const struct
LumaCoefficients *coeffs,
{
double bscale, rscale;
+// special ycgco matrix
+if (coeffs->cr == 0.25 && coeffs->cg == 0.5 && coeffs->cb == 0.25) {
+memcpy(rgb2yuv, ycgco_matrix, sizeof(double) * 9);
+return;
+}
+
rgb2yuv[0][0] = coeffs->cr;
rgb2yuv[0][1] = coeffs->cg;
rgb2yuv[0][2] = coeffs->cb;
@@ -1047,6 +1061,7 @@ static const AVOption colorspace_options[] = {
ENUM("bt470bg", AVCOL_SPC_BT470BG, "csp"),
ENUM("smpte170m", AVCOL_SPC_SMPTE170M, "csp"),
ENUM("smpte240m", AVCOL_SPC_SMPTE240M, "csp"),
+ENUM("ycgco", AVCOL_SPC_YCGCO, "csp"),
ENUM("bt2020ncl", AVCOL_SPC_BT2020_NCL, "csp"),
{ "range", "Output color range",
--
2.10.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavfi/mergeplanes: Fix >8bit formats
On 10/30/16, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes the command line provided in ticket #5916. > > Please comment, Carl Eugen Can you explain why this patch is correct way to fix bug? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavfi/mergeplanes: Fix little endian formats >8 bit.
On 10/30/16, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes ticket #5916 for (for example) yuv444p9le. > > Please comment, Carl Eugen Same as for another mergeplanes patch from you, please explain why this is correct. Are patches dependend on each other? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] news: add final report for summer of code 2016
From: "Reynaldo H. Verdejo Pinochet" Signed-off-by: Reynaldo H. Verdejo Pinochet --- src/index | 34 ++ 1 file changed, 34 insertions(+) diff --git a/src/index b/src/index index edc1243..eb3a929 100644 --- a/src/index +++ b/src/index @@ -37,6 +37,40 @@ News + October 30th, 2016, Results: Summer Of Code 2016. + +This has been a long time coming but we wanted to give a proper closure to our participation in this run of the program and it takes time. Sometimes it's just to get the final report for each project trimmed down, others, is finalizing whatever was still in progress when the program finished: final patches need to be merged, TODO lists stabilized, future plans agreed; you name it. + + +Without further ado, here's the silver-lining for each one of the projects we sought to complete during this Summer of Code season: + + FFv1 (Mentor: Michael Nierdermayer) + +Stanislav Dolganov designed and implemented experimental support for motion estimation and compensation in the lossless FFV1 codec. The design and implementation is based on the snow video codec, which uses OBMC. Stanislav's work proved that significant compression gains can be achieved with inter frame compression. FFmpeg welcomes Stanislav to continue working beyond this proof of concept and bring its advances into the official FFV1 specification within the IETF. + + Self test coverage (Mentor: Michael Niedermayer) + +Petru Rares Sincraian added several self-tests to FFmpeg and successfully went through the in-some-cases tedious process of fine tuning tests parameters to avoid known and hard to avoid problems, like checksum mismatches due to rounding errors on the myriad of platforms we support. His work has improved the code coverage of our self tests considerably. + + MPEG-4 ALS encoder implementation (Mentor: Thilo Borgmann) + +Umair Khan updated and integrated the ALS encoder to fit in the current FFmpeg codebase. He also implemented a missing feature for the ALS decoder that enables floating-point sample decoding. FFmpeg support for MPEG-4 ALS has been improved significantly by Umair's work. We welcome him to keep maintaining his improvements and hope for great contributions to come. + + Tee muxer improvements (Mentor: Marton Balint) + +Ján Sebechlebský's generic goal was to improve the tee muxer so it tolerated blocking IO and allowed transparent error recovery. During the design phase it turned out that this functionality called for a separate muxer, so Ján spent his summer working on the so-called FIFO muxer, gradually fixing issues all over the codebase. He succeeded in his task, and the FIFO muxer is now part of the main repository, alongside several other improvements he made in the process. + + TrueHD encoder (Mentor: Rostislav Pehlivanov) + +Jai Luthra's objective was to update the out-of-tree and pretty much abandoned MLP (Meridian Lossless Packing) encoder for libavcodec and improve it to enable encoding to the TrueHD format. For the qualification period the encoder was updated such that it was usable and throughout the summer, successfully improved adding support for multi-channel audio and TrueHD encoding. Jai's code has been merged into the main repository now. While a few problems remain with respect to LFE channel and 32 bit sample handling, these are in the process of being fixed such that effort can be finally put in improving the encoder's speed and efficiency. + + Motion interpolation filter (Mentor: Paul B Mahol) + +Davinder Singh investigated existing motion estimation and interpolation approaches from the available literature and previous work by our own: Michael Niedermayer, and implemented filters based on this research. These filters allow motion interpolating frame rate conversion to be applied to a video, for example, to create a slow motion effect or change the frame rate while smoothly interpolating the video along the motion vectors. There's still work to be done to call these filter 'finished', which is rather hard all things considered, but we are looking optimistic at their future. + + +And that's it. We are happy with the results of the program and immensely thankful for the opportunity of working with such an amazing set of students. We can be a tough crowd but our mentors did an amazing job at hand holding our interns through their journey. Thanks also to Google for this wonderful program and to everyone that made room in their busy lives to help making GSoC2016 a success. See you in 2017! + September 24th, 2016, SDL1 support dropped. Support for the SDL1 library has been dropped, due to it no longer being maintained (as of -- 2.9.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.
On Sun, Oct 30, 2016 at 5:13 AM, Matt Oliver wrote: > On 30 October 2016 at 03:41, Stephen Hutchinson wrote: > >> On 10/29/2016 11:22 AM, Michael Niedermayer wrote: >> >>> On Sat, Oct 29, 2016 at 06:35:19PM +1100, Matt Oliver wrote: >>> configure |5 + libavformat/avisynth.c | 14 +- 2 files changed, 6 insertions(+), 13 deletions(-) b1568f39504e5e14c924d27c8f11ba8f5816d68c 0003-avformat-avisynth.c-Use-n ew-safe-dlopen-code.patch From 633212cf1246b3fde61dd6515229e6a893005664 Mon Sep 17 00:00:00 2001 From: Matt Oliver Date: Sat, 29 Oct 2016 18:25:25 +1100 Subject: [PATCH 3/4] avformat/avisynth.c: Use new safe dlopen code. >>> >>> breaks --enable-avisynth on linux/ubuntu >>> >>> --- config.h2016-10-29 17:17:55.214014842 +0200 >>> +++ delth/config.h 2016-10-29 17:15:41.906012034 +0200 >>> @@ -1155,7 +1155,7 @@ >>> #define CONFIG_AST_DEMUXER 1 >>> #define CONFIG_AU_DEMUXER 1 >>> #define CONFIG_AVI_DEMUXER 1 >>> -#define CONFIG_AVISYNTH_DEMUXER 1 >>> +#define CONFIG_AVISYNTH_DEMUXER 0 >>> #define CONFIG_AVR_DEMUXER 1 >>> #define CONFIG_AVS_DEMUXER 1 >>> #define CONFIG_BETHSOFTVID_DEMUXER 1 >>> >>> [...] >>> >>> >> Yeah, libdl needs to be linked to on non-Windows, and the >> check for it got removed with the rest of the 'enabled avisynth' >> case in configure. Just putting dlopen under avisynth_demuxer_deps doesn't >> seem to be sufficient for that to work. > > > Looks like I missed a line, my apologies. Updated version attached. > Looking at the configure changes - having a dependency on both dlopen and LoadLibrary sounds odd. Shouldn't it be either, not both? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/utils: only call h264 decoder private function if h264 decoder is in use
> has the issue been fixed for all branches an cases or is something > missing that needs this ? > (if so this needs a null pointer check i think) This was fixed in a diffrent way in 6d9a46e884d090a68069112a3b0436aa8b563967 It forces the h264 decoder to be used, so the assumption it is in use is allways correct. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.
On 30 October 2016 at 20:21, Hendrik Leppkes wrote: > On Sun, Oct 30, 2016 at 5:13 AM, Matt Oliver wrote: > > On 30 October 2016 at 03:41, Stephen Hutchinson > wrote: > > > >> On 10/29/2016 11:22 AM, Michael Niedermayer wrote: > >> > >>> On Sat, Oct 29, 2016 at 06:35:19PM +1100, Matt Oliver wrote: > >>> > configure |5 + > libavformat/avisynth.c | 14 +- > 2 files changed, 6 insertions(+), 13 deletions(-) > b1568f39504e5e14c924d27c8f11ba8f5816d68c > 0003-avformat-avisynth.c-Use-n > ew-safe-dlopen-code.patch > From 633212cf1246b3fde61dd6515229e6a893005664 Mon Sep 17 00:00:00 > 2001 > From: Matt Oliver > Date: Sat, 29 Oct 2016 18:25:25 +1100 > Subject: [PATCH 3/4] avformat/avisynth.c: Use new safe dlopen code. > > >>> > >>> breaks --enable-avisynth on linux/ubuntu > >>> > >>> --- config.h2016-10-29 17:17:55.214014842 +0200 > >>> +++ delth/config.h 2016-10-29 17:15:41.906012034 +0200 > >>> @@ -1155,7 +1155,7 @@ > >>> #define CONFIG_AST_DEMUXER 1 > >>> #define CONFIG_AU_DEMUXER 1 > >>> #define CONFIG_AVI_DEMUXER 1 > >>> -#define CONFIG_AVISYNTH_DEMUXER 1 > >>> +#define CONFIG_AVISYNTH_DEMUXER 0 > >>> #define CONFIG_AVR_DEMUXER 1 > >>> #define CONFIG_AVS_DEMUXER 1 > >>> #define CONFIG_BETHSOFTVID_DEMUXER 1 > >>> > >>> [...] > >>> > >>> > >> Yeah, libdl needs to be linked to on non-Windows, and the > >> check for it got removed with the rest of the 'enabled avisynth' > >> case in configure. Just putting dlopen under avisynth_demuxer_deps > doesn't > >> seem to be sufficient for that to work. > > > > > > Looks like I missed a line, my apologies. Updated version attached. > > > > Looking at the configure changes - having a dependency on both dlopen > and LoadLibrary sounds odd. Shouldn't it be either, not both? > Yes, unfortunately i was testing on mingw which has both. Fixed thanks. 0003-avformat-avisynth.c-Use-new-safe-dlopen-code.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] news: add final report for summer of code 2016
On 10/30/16, reyna...@osg.samsung.com wrote: > From: "Reynaldo H. Verdejo Pinochet" > > Signed-off-by: Reynaldo H. Verdejo Pinochet > --- > src/index | 34 ++ > 1 file changed, 34 insertions(+) > No more comments from me. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] vf_colorspace: Add support for iec61966-2.4 (xvYCC) transfer
Hi, On Sun, Oct 30, 2016 at 3:07 AM, Vittorio Giovara < vittorio.giov...@gmail.com> wrote: > Signed-off-by: Vittorio Giovara > --- > As described in http://www.color.org/chardata/rgb/xvycc.xalter > Please CC. > Vittorio > > libavfilter/vf_colorspace.c | 3 +++ > 1 file changed, 3 insertions(+) OK. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] vf_colorspace: Add support for smpte 431/432 (dci/display p3) primaries
Hi,
On Sun, Oct 30, 2016 at 3:07 AM, Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:
> Signed-off-by: Vittorio Giovara
> ---
> I couldn't find any reference to the name of the whitepoint used for 431,
> so I came up with DCI, since it looks like it is only used there.
> Please CC.
> Vittorio
>
> libavfilter/vf_colorspace.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
> index 7e0bafa..4265aa1 100644
> --- a/libavfilter/vf_colorspace.c
> +++ b/libavfilter/vf_colorspace.c
> @@ -56,6 +56,7 @@ enum Colorspace {
> enum Whitepoint {
> WP_D65,
> WP_C,
> +WP_DCI,
> WP_NB,
> };
>
> @@ -268,6 +269,7 @@ static const struct TransferCharacteristics *
> static const struct WhitepointCoefficients whitepoint_coefficients[WP_NB]
> = {
> [WP_D65] = { 0.3127, 0.3290 },
> [WP_C] = { 0.3100, 0.3160 },
> +[WP_DCI] = { 0.3140, 0.3510 },
> };
Hmm... So, the wikipedia page https://en.wikipedia.org/wiki/DCI-P3 refers
to the two whitepoints here as DCI-P3 D65 and DCI-P3 Theater. Calling one
D65 and the other DCI seems confusing in that light (assuming the wikipedia
page is correct). I'd call it THEATER or DCI_P3_THEATER, to distinguish it
from DCI-P3 D65. Is that OK?
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] openssl: Allow newer TLS versions than TLSv1
On 29/10/16 22:57, Michael Niedermayer wrote: > On Sat, Oct 29, 2016 at 09:53:30AM +0100, Mark Thompson wrote: >> The use of TLSv1_*_method() disallows newer protocol versions; instead >> use SSLv23_*_method() and then explicitly disable the deprecated >> protocol versions which should not be supported. >> >> Fixes ticket #5915. >> --- >> On 28/10/16 22:15, Hendrik Leppkes wrote: >>> I should have looked further when commenting on the other patch - I guess. >>> :) >>> Looks good to me, the OpenSSL API seems to be rather confusing in this >>> regard. Maybe a comment might be useful to indicate why this is done. >> >> Hopefully this is clearer. >> >> Thanks, >> >> - Mark >> >> >> libavformat/tls_openssl.c | 7 ++- >> 1 file changed, 6 insertions(+), 1 deletion(-) > > should be ok > > thx Applied. Thanks, - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3] ffmpeg: parameters for filter thread counts
Enables specifying how many threads are available to each filtergraph.
---
v2->v3:
- Typos in docs fixed
v1->v2:
- Reworded documentation
- Removed hunk from ffmpeg_filter.c not directly applicable to patch
doc/ffmpeg.texi | 10 ++
ffmpeg.h| 3 +++
ffmpeg_filter.c | 7 +++
ffmpeg_opt.c| 4
4 files changed, 24 insertions(+)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 47c8935..fd8a0c1 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -415,6 +415,11 @@ This option is similar to @option{-filter}, the only
difference is that its
argument is the name of the file from which a filtergraph description is to be
read.
+@item -filter_threads @var{nb_threads} (@emph{global})
+Defines how many threads are used to process a filter pipeline. Each pipeline
+will produce a thread pool with this many threads available for parallel
processing.
+The default is the number of available CPUs.
+
@item -pre[:@var{stream_specifier}] @var{preset_name}
(@emph{output,per-stream})
Specify the preset for matching stream(s).
@@ -1201,6 +1206,11 @@ To generate 5 seconds of pure red video using lavfi
@code{color} source:
ffmpeg -filter_complex 'color=c=red' -t 5 out.mkv
@end example
+@item -filter_complex_threads @var{nb_threads} (@emph{global})
+Defines how many threads are used to process a filter_complex graph.
+Similar to filter_threads but used for @code{-filter_complex} graphs only.
+The default is the number of available CPUs.
+
@item -lavfi @var{filtergraph} (@emph{global})
Define a complex filtergraph, i.e. one with arbitrary number of inputs and/or
outputs. Equivalent to @option{-filter_complex}.
diff --git a/ffmpeg.h b/ffmpeg.h
index e1d4593..9a4389f 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -569,6 +569,9 @@ extern AVIOContext *progress_avio;
extern float max_error_rate;
extern char *videotoolbox_pixfmt;
+extern int filter_nbthreads;
+extern int filter_complex_nbthreads;
+
extern const AVIOInterruptCB int_cb;
extern const OptionDef options[];
diff --git a/ffmpeg_filter.c b/ffmpeg_filter.c
index 27aeca0..95b9c43 100644
--- a/ffmpeg_filter.c
+++ b/ffmpeg_filter.c
@@ -39,6 +39,9 @@
#include "libavutil/imgutils.h"
#include "libavutil/samplefmt.h"
+int filter_nbthreads = -1;
+int filter_complex_nbthreads = -1;
+
static const enum AVPixelFormat *get_compliance_unofficial_pix_fmts(enum
AVCodecID codec_id, const enum AVPixelFormat default_formats[])
{
static const enum AVPixelFormat mjpeg_formats[] =
@@ -992,6 +995,8 @@ int configure_filtergraph(FilterGraph *fg)
char args[512];
AVDictionaryEntry *e = NULL;
+fg->graph->nb_threads = filter_complex_nbthreads;
+
args[0] = 0;
while ((e = av_dict_get(ost->sws_dict, "", e,
AV_DICT_IGNORE_SUFFIX))) {
@@ -1022,6 +1027,8 @@ int configure_filtergraph(FilterGraph *fg)
e = av_dict_get(ost->encoder_opts, "threads", NULL, 0);
if (e)
av_opt_set(fg->graph, "threads", e->value, 0);
+} else {
+fg->graph->nb_threads = filter_nbthreads;
}
if ((ret = avfilter_graph_parse2(fg->graph, graph_desc, &inputs,
&outputs)) < 0)
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 4d25fff..dc94380 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -3365,12 +3365,16 @@ const OptionDef options[] = {
"set profile", "profile" },
{ "filter", HAS_ARG | OPT_STRING | OPT_SPEC | OPT_OUTPUT, { .off =
OFFSET(filters) },
"set stream filtergraph", "filter_graph" },
+{ "filter_threads", HAS_ARG | OPT_INT, {
&filter_nbthreads },
+"number of non-complex filter threads" },
{ "filter_script", HAS_ARG | OPT_STRING | OPT_SPEC | OPT_OUTPUT, { .off =
OFFSET(filter_scripts) },
"read stream filtergraph description from a file", "filename" },
{ "reinit_filter", HAS_ARG | OPT_INT | OPT_SPEC | OPT_INPUT,{ .off =
OFFSET(reinit_filters) },
"reinit filtergraph on input parameter changes", "" },
{ "filter_complex", HAS_ARG | OPT_EXPERT,{
.func_arg = opt_filter_complex },
"create a complex filtergraph", "graph_description" },
+{ "filter_complex_threads", HAS_ARG | OPT_INT, {
&filter_complex_nbthreads },
+"number of threads for -filter_complex" },
{ "lavfi", HAS_ARG | OPT_EXPERT,{
.func_arg = opt_filter_complex },
"create a complex filtergraph", "graph_description" },
{ "filter_complex_script", HAS_ARG | OPT_EXPERT, {
.func_arg = opt_filter_complex_script },
--
1.8.4.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] vf_colorspace: Add support for ycgco color space
Hi, On Sun, Oct 30, 2016 at 3:07 AM, Vittorio Giovara < vittorio.giov...@gmail.com> wrote: > Signed-off-by: Vittorio Giovara > --- > This is a little hackish, not sure how to represent the matrix otherwise. Haha :) I have to admit I hadn't put much thought into YCgCo yet. It's a little hacky but I guess it's OK... I think the primary reason some people - at some point in ancient history, certainly not today - might have cared about YCgCo is because the conversion between RGB and YCgCo is so trivial. For example, YCgCo to RGB is two butterflies (an interleaved add/sub pair), which is incredibly appealing from a performance point of view. But we're not using that property here... I'm not saying it's bad, and it's probably totally irrelevant, especially given how insignificant YCgCo is anyway, but it's worth noting. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavfi/mergeplanes: Fix >8bit formats
> Am 30.10.2016 um 00:53 schrieb Paul B Mahol : > >> On 10/30/16, Carl Eugen Hoyos wrote: >> Hi! >> >> Attached patch fixes the command line provided in ticket #5916. > > Can you explain why this patch is correct way to fix bug? I don't know if the patch is correct (that's one of the reasons I sent it here). Currently, afaict, for formats >8bit the mergeplanes filter only copies the left half of the frame from input to output, the patch tries to fix this. Do you think this should be fixed differently (or that there is no such bug)? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavfi/mergeplanes: Fix little endian formats >8 bit.
> Am 30.10.2016 um 00:55 schrieb Paul B Mahol : > >> On 10/30/16, Carl Eugen Hoyos wrote: >> Hi! >> >> Attached patch fixes ticket #5916 for (for example) yuv444p9le. > > Same as for another mergeplanes patch from you, please explain why > this is correct. I think that for little endian yuv formats >8bit but <16bit, using the mergeplanes filter currently implies an intermediate format which must have the same endianness as the input format but this is not guaranteed by the current code. Even if the issue can be worked-around differently, this patch should be applied anyway imo. > Are patches dependend on each other? The issue described here can be reproduced (seen) without applying the other patch, that's what the OP means with "left are strange" in his report on the bug tracker. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] vf_colorspace: Add support for smpte 431/432 (dci/display p3) primaries
Hi, On Sun, Oct 30, 2016 at 7:07 AM, Vittorio Giovara < vittorio.giov...@gmail.com> wrote: > Signed-off-by: Vittorio Giovara > --- > I couldn't find any reference to the name of the whitepoint used for 431, > so I came up with DCI, since it looks like it is only used there. > Please CC. > Could this patch be used to convert XYZ Digital Cinema Packages to Rec.709? I've found that converting a DCP to a YUV format in ffmpeg results in colours and contrast that look different to how the image displays in EasyDCP player or a cinema screen. IIRC, -vf colorspace doesn't accept XYZ input, so is there some intermediate step that I could take to achieve this kind of transformation, or have I just misunderstood the patch? Best, Kieran. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] news: add final report for summer of code 2016
On Sun, Oct 30, 2016 at 01:57:58 -0700, reyna...@osg.samsung.com wrote: > +Without further ado, here's the silver-lining for each one of the > projects we sought to complete during this Summer of Code season: > + > + FFv1 (Mentor: Michael Nierdermayer) ^ Niedermayer > There's still work to be done to call these filter 'finished', ^ filters > which is rather hard all things considered, but we are looking optimistic at > their future. ^ optimistically You could also wrap the raw text lines, but I'm not sure anyone cares. Kudos to everyone, BTW. Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add hds demuxer
2016-10-24 16:27 GMT+08:00 Steven Liu : > > > 2016-10-24 15:22 GMT+08:00 wm4 : > >> On Sat, 15 Oct 2016 15:52:48 +0200 >> Nicolas George wrote: >> >> > Le tridi 23 vendémiaire, an CCXXV, wm4 a écrit : >> > > XML is very complex >> > >> > This is the usual, and often only, argument raised in this kind of >> > situation. And unfortunately, I already addressed it in this very >> thread. >> > >> > XML is very complex, yes: processing instructions, entity definitions, >> DTSs >> > and schemas, namespaces, etc. >> > >> > Fortunately, we do not need that. Manifests only use the most basic XML >> > features: elements, attributes, text. Parsing that is easy. >> > >> > Regards, >> > >> >> Well, I thought the idea was already rejected by multiple people before. >> > > But i think Nicolas George's idea is useful now, for example used in hds > mkv and some format depend on simple xml format. > >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > > Hi Nicolas George, I saw ffmpeg have no HDS and DASH demuxer, and all of them's format is use xml, maybe this parser is a very useful parser, what about the basic xml :-D ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/utils: only call h264 decoder private function if h264 decoder is in use
On Sun, Oct 30, 2016 at 12:04:14PM +0100, Timo Rothenpieler wrote: > > has the issue been fixed for all branches an cases or is something > > missing that needs this ? > > (if so this needs a null pointer check i think) > > This was fixed in a diffrent way in 6d9a46e884d090a68069112a3b0436aa8b563967 > > It forces the h264 decoder to be used, so the assumption it is in use is > allways correct. My question is, does either patch need to be backported to some branch ? 6d9a46e884d090a68069112a3b0436aa8b563967 is not in 3.1 for example [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] ffmpeg: parameters for filter thread counts
On 10/30/16, DeHackEd wrote:
> Enables specifying how many threads are available to each filtergraph.
> ---
> v2->v3:
> - Typos in docs fixed
>
> v1->v2:
> - Reworded documentation
> - Removed hunk from ffmpeg_filter.c not directly applicable to patch
>
> doc/ffmpeg.texi | 10 ++
> ffmpeg.h| 3 +++
> ffmpeg_filter.c | 7 +++
> ffmpeg_opt.c| 4
> 4 files changed, 24 insertions(+)
>
> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> index 47c8935..fd8a0c1 100644
> --- a/doc/ffmpeg.texi
> +++ b/doc/ffmpeg.texi
> @@ -415,6 +415,11 @@ This option is similar to @option{-filter}, the only
> difference is that its
> argument is the name of the file from which a filtergraph description is to
> be
> read.
>
> +@item -filter_threads @var{nb_threads} (@emph{global})
> +Defines how many threads are used to process a filter pipeline. Each
> pipeline
> +will produce a thread pool with this many threads available for parallel
> processing.
> +The default is the number of available CPUs.
> +
> @item -pre[:@var{stream_specifier}] @var{preset_name}
> (@emph{output,per-stream})
> Specify the preset for matching stream(s).
>
> @@ -1201,6 +1206,11 @@ To generate 5 seconds of pure red video using lavfi
> @code{color} source:
> ffmpeg -filter_complex 'color=c=red' -t 5 out.mkv
> @end example
>
> +@item -filter_complex_threads @var{nb_threads} (@emph{global})
> +Defines how many threads are used to process a filter_complex graph.
> +Similar to filter_threads but used for @code{-filter_complex} graphs only.
> +The default is the number of available CPUs.
> +
> @item -lavfi @var{filtergraph} (@emph{global})
> Define a complex filtergraph, i.e. one with arbitrary number of inputs
> and/or
> outputs. Equivalent to @option{-filter_complex}.
> diff --git a/ffmpeg.h b/ffmpeg.h
> index e1d4593..9a4389f 100644
> --- a/ffmpeg.h
> +++ b/ffmpeg.h
> @@ -569,6 +569,9 @@ extern AVIOContext *progress_avio;
> extern float max_error_rate;
> extern char *videotoolbox_pixfmt;
>
> +extern int filter_nbthreads;
> +extern int filter_complex_nbthreads;
> +
> extern const AVIOInterruptCB int_cb;
>
> extern const OptionDef options[];
> diff --git a/ffmpeg_filter.c b/ffmpeg_filter.c
> index 27aeca0..95b9c43 100644
> --- a/ffmpeg_filter.c
> +++ b/ffmpeg_filter.c
> @@ -39,6 +39,9 @@
> #include "libavutil/imgutils.h"
> #include "libavutil/samplefmt.h"
>
> +int filter_nbthreads = -1;
> +int filter_complex_nbthreads = -1;
> +
> static const enum AVPixelFormat *get_compliance_unofficial_pix_fmts(enum
> AVCodecID codec_id, const enum AVPixelFormat default_formats[])
> {
> static const enum AVPixelFormat mjpeg_formats[] =
> @@ -992,6 +995,8 @@ int configure_filtergraph(FilterGraph *fg)
> char args[512];
> AVDictionaryEntry *e = NULL;
>
> +fg->graph->nb_threads = filter_complex_nbthreads;
> +
> args[0] = 0;
> while ((e = av_dict_get(ost->sws_dict, "", e,
> AV_DICT_IGNORE_SUFFIX))) {
> @@ -1022,6 +1027,8 @@ int configure_filtergraph(FilterGraph *fg)
> e = av_dict_get(ost->encoder_opts, "threads", NULL, 0);
> if (e)
> av_opt_set(fg->graph, "threads", e->value, 0);
> +} else {
> +fg->graph->nb_threads = filter_nbthreads;
> }
>
> if ((ret = avfilter_graph_parse2(fg->graph, graph_desc, &inputs,
> &outputs)) < 0)
> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> index 4d25fff..dc94380 100644
> --- a/ffmpeg_opt.c
> +++ b/ffmpeg_opt.c
> @@ -3365,12 +3365,16 @@ const OptionDef options[] = {
> "set profile", "profile" },
> { "filter", HAS_ARG | OPT_STRING | OPT_SPEC | OPT_OUTPUT, {
> .off = OFFSET(filters) },
> "set stream filtergraph", "filter_graph" },
> +{ "filter_threads", HAS_ARG | OPT_INT, {
> &filter_nbthreads },
> +"number of non-complex filter threads" },
> { "filter_script", HAS_ARG | OPT_STRING | OPT_SPEC | OPT_OUTPUT, {
> .off = OFFSET(filter_scripts) },
> "read stream filtergraph description from a file", "filename" },
> { "reinit_filter", HAS_ARG | OPT_INT | OPT_SPEC | OPT_INPUT,{ .off
> = OFFSET(reinit_filters) },
> "reinit filtergraph on input parameter changes", "" },
> { "filter_complex", HAS_ARG | OPT_EXPERT,{
> .func_arg = opt_filter_complex },
> "create a complex filtergraph", "graph_description" },
> +{ "filter_complex_threads", HAS_ARG | OPT_INT, {
> &filter_complex_nbthreads },
> +"number of threads for -filter_complex" },
> { "lavfi", HAS_ARG | OPT_EXPERT,{
> .func_arg = opt_filter_complex },
> "create a complex filtergraph", "graph_description" },
> { "filter_complex_script", HAS_ARG | OPT_EXPERT, {
> .func_arg = opt_filter_complex_script },
> --
> 1.8.4.1
>
> ___
> ffmpeg-devel mailing list
> f
Re: [FFmpeg-devel] [PATCH]lavfi/mergeplanes: Fix little endian formats >8 bit.
On 10/30/16, Carl Eugen Hoyos wrote: > > >> Am 30.10.2016 um 00:55 schrieb Paul B Mahol : >> >>> On 10/30/16, Carl Eugen Hoyos wrote: >>> Hi! >>> >>> Attached patch fixes ticket #5916 for (for example) yuv444p9le. >> >> Same as for another mergeplanes patch from you, please explain why >> this is correct. > > I think that for little endian yuv formats >8bit but <16bit, using the > mergeplanes filter currently implies an intermediate format which must have > the same endianness as the input format but this is not guaranteed by the > current code. > Even if the issue can be worked-around differently, this patch should be > applied anyway imo. > >> Are patches dependend on each other? > > The issue described here can be reproduced (seen) without applying the other > patch, that's what the OP means with "left are strange" in his report on the > bug tracker. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > OK, try with non 444 cases, like with 420 high bit depth and if it works apply both patches. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.
On Sun, Oct 30, 2016 at 10:31:16PM +1100, Matt Oliver wrote: > On 30 October 2016 at 20:21, Hendrik Leppkes wrote: > > > On Sun, Oct 30, 2016 at 5:13 AM, Matt Oliver wrote: > > > On 30 October 2016 at 03:41, Stephen Hutchinson > > wrote: > > > > > >> On 10/29/2016 11:22 AM, Michael Niedermayer wrote: > > >> > > >>> On Sat, Oct 29, 2016 at 06:35:19PM +1100, Matt Oliver wrote: > > >>> > > configure |5 + > > libavformat/avisynth.c | 14 +- > > 2 files changed, 6 insertions(+), 13 deletions(-) > > b1568f39504e5e14c924d27c8f11ba8f5816d68c > > 0003-avformat-avisynth.c-Use-n > > ew-safe-dlopen-code.patch > > From 633212cf1246b3fde61dd6515229e6a893005664 Mon Sep 17 00:00:00 > > 2001 > > From: Matt Oliver > > Date: Sat, 29 Oct 2016 18:25:25 +1100 > > Subject: [PATCH 3/4] avformat/avisynth.c: Use new safe dlopen code. > > > > >>> > > >>> breaks --enable-avisynth on linux/ubuntu > > >>> > > >>> --- config.h2016-10-29 17:17:55.214014842 +0200 > > >>> +++ delth/config.h 2016-10-29 17:15:41.906012034 +0200 > > >>> @@ -1155,7 +1155,7 @@ > > >>> #define CONFIG_AST_DEMUXER 1 > > >>> #define CONFIG_AU_DEMUXER 1 > > >>> #define CONFIG_AVI_DEMUXER 1 > > >>> -#define CONFIG_AVISYNTH_DEMUXER 1 > > >>> +#define CONFIG_AVISYNTH_DEMUXER 0 > > >>> #define CONFIG_AVR_DEMUXER 1 > > >>> #define CONFIG_AVS_DEMUXER 1 > > >>> #define CONFIG_BETHSOFTVID_DEMUXER 1 > > >>> > > >>> [...] > > >>> > > >>> > > >> Yeah, libdl needs to be linked to on non-Windows, and the > > >> check for it got removed with the rest of the 'enabled avisynth' > > >> case in configure. Just putting dlopen under avisynth_demuxer_deps > > doesn't > > >> seem to be sufficient for that to work. > > > > > > > > > Looks like I missed a line, my apologies. Updated version attached. > > > > > > > Looking at the configure changes - having a dependency on both dlopen > > and LoadLibrary sounds odd. Shouldn't it be either, not both? > > > > Yes, unfortunately i was testing on mingw which has both. Fixed thanks. > configure |5 ++--- > libavformat/avisynth.c | 14 +- > 2 files changed, 7 insertions(+), 12 deletions(-) > ed7ff2d7e0c984ee5253e76f54b3115386c1428d > 0003-avformat-avisynth.c-Use-new-safe-dlopen-code.patch > From 1dc1f59158cfb12d9160ee47342f5742d67ad864 Mon Sep 17 00:00:00 2001 > From: Matt Oliver > Date: Sun, 30 Oct 2016 15:13:47 +1100 > Subject: [PATCH] avformat/avisynth.c: Use new safe dlopen code. Works now thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.
On 10/30/2016 8:31 AM, Matt Oliver wrote:
> From 1dc1f59158cfb12d9160ee47342f5742d67ad864 Mon Sep 17 00:00:00 2001
> From: Matt Oliver
> Date: Sun, 30 Oct 2016 15:13:47 +1100
> Subject: [PATCH] avformat/avisynth.c: Use new safe dlopen code.
>
> ---
> configure | 5 ++---
> libavformat/avisynth.c | 14 +-
> 2 files changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/configure b/configure
> index 5993de5..9feb544 100755
> --- a/configure
> +++ b/configure
> @@ -2850,6 +2850,7 @@ asf_stream_muxer_select="asf_muxer"
> avi_demuxer_select="iso_media riffdec exif"
> avi_muxer_select="riffenc"
> avisynth_demuxer_deps="avisynth"
> +avisynth_demuxer_deps_any="dlopen LoadLibrary"
> avisynth_demuxer_select="riffdec"
With this change and the stuff removed below, avisynth (CONFIG_AVISYNTH)
will always be enabled if you configure with --enable-avisynth, and only
avisynth_demuxer will be disabled depending on the presence of dlopen and
LoadLibrary.
This is probably not intended, seeing how libavformat/Makefile checks for
CONFIG_AVISYNTH and not CONFIG_AVISYNTH_DEMUXER in order to compile the
source file, so you should make it avisynth_deps_any="dlopen LoadLibrary"
since avisynth_demuxer already depends on avisynth.
Also, consider changing libavformat/Makefile to check for the demuxer
rather than the library/feature.
> caf_demuxer_select="iso_media riffdec"
> dash_muxer_select="mp4_muxer"
> @@ -5417,6 +5418,7 @@ elif check_func dlopen -ldl && check_func dlsym -ldl;
> then
> ldl=-ldl
> fi
>
> +avisynth_demuxer_extralibs='$ldl'
> decklink_outdev_extralibs="$decklink_outdev_extralibs $ldl"
> decklink_indev_extralibs="$decklink_indev_extralibs $ldl"
> frei0r_filter_extralibs='$ldl'
> @@ -5664,9 +5666,6 @@ fi
> enabled avfoundation_indev && { check_header_objcc
> AVFoundation/AVFoundation.h || disable avfoundation_indev; }
> enabled avfoundation_indev && { check_lib2 CoreGraphics/CoreGraphics.h
> CGGetActiveDisplayList -framework CoreGraphics ||
> check_lib2
> ApplicationServices/ApplicationServices.h CGGetActiveDisplayList -framework
> ApplicationServices; }
> -enabled avisynth && { { check_lib2 "windows.h" LoadLibrary; } ||
> - { check_lib2 "dlfcn.h" dlopen -ldl; } ||
> - die "ERROR: LoadLibrary/dlopen not found for
> avisynth"; }
> enabled cuda && { check_lib cuda.h cuInit -lcuda ||
> die "ERROR: CUDA not found"; }
> enabled cuvid && { add_cflags -I$source_path;
> diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
> index 1acc44f..514cb99 100644
> --- a/libavformat/avisynth.c
> +++ b/libavformat/avisynth.c
> @@ -29,7 +29,7 @@
>
> /* Platform-specific directives for AviSynth vs AvxSynth. */
> #ifdef _WIN32
> - #include
> + #include "compat/w32dlfcn.h"
>#undef EXTERN_C
>#include "compat/avisynth/avisynth_c.h"
>#define AVISYNTH_LIB "avisynth"
> @@ -39,10 +39,6 @@
>#include "compat/avisynth/avxsynth_c.h"
>#define AVISYNTH_NAME "libavxsynth"
>#define AVISYNTH_LIB AVISYNTH_NAME SLIBSUF
> -
> - #define LoadLibrary(x) dlopen(x, RTLD_NOW | RTLD_LOCAL)
> - #define GetProcAddress dlsym
> - #define FreeLibrary dlclose
> #endif
>
> typedef struct AviSynthLibrary {
> @@ -118,13 +114,13 @@ static av_cold void avisynth_atexit_handler(void);
>
> static av_cold int avisynth_load_library(void)
> {
> -avs_library.library = LoadLibrary(AVISYNTH_LIB);
> +avs_library.library = dlopen(AVISYNTH_LIB, RTLD_NOW | RTLD_LOCAL);
> if (!avs_library.library)
> return AVERROR_UNKNOWN;
>
> #define LOAD_AVS_FUNC(name, continue_on_fail) \
> avs_library.name = \
> -(void *)GetProcAddress(avs_library.library, #name);\
> +(void *)dlsym(avs_library.library, #name); \
> if (!continue_on_fail && !avs_library.name)\
> goto fail;
>
> @@ -157,7 +153,7 @@ static av_cold int avisynth_load_library(void)
> return 0;
>
> fail:
> -FreeLibrary(avs_library.library);
> +dlclose(avs_library.library);
> return AVERROR_UNKNOWN;
> }
>
> @@ -225,7 +221,7 @@ static av_cold void avisynth_atexit_handler(void)
> avisynth_context_destroy(avs);
> avs = next;
> }
> -FreeLibrary(avs_library.library);
> +dlclose(avs_library.library);
>
> avs_atexit_called = 1;
> }
> -- 2.10.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] ffmpeg: parameters for filter thread counts
On 10/30/2016 12:09 PM, Paul B Mahol wrote:
> On 10/30/16, DeHackEd wrote:
>> Enables specifying how many threads are available to each filtergraph.
>> ---
>> v2->v3:
>> - Typos in docs fixed
>>
>> v1->v2:
>> - Reworded documentation
>> - Removed hunk from ffmpeg_filter.c not directly applicable to patch
>>
>> doc/ffmpeg.texi | 10 ++
>> ffmpeg.h| 3 +++
>> ffmpeg_filter.c | 7 +++
>> ffmpeg_opt.c| 4
>> 4 files changed, 24 insertions(+)
>>
...
>> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
>> index 4d25fff..dc94380 100644
>> --- a/ffmpeg_opt.c
>> +++ b/ffmpeg_opt.c
>> @@ -3365,12 +3365,16 @@ const OptionDef options[] = {
>> "set profile", "profile" },
>> { "filter", HAS_ARG | OPT_STRING | OPT_SPEC | OPT_OUTPUT, {
>> .off = OFFSET(filters) },
>> "set stream filtergraph", "filter_graph" },
>> +{ "filter_threads", HAS_ARG | OPT_INT, {
>> &filter_nbthreads },
>> +"number of non-complex filter threads" },
>> { "filter_script", HAS_ARG | OPT_STRING | OPT_SPEC | OPT_OUTPUT, {
>> .off = OFFSET(filter_scripts) },
>> "read stream filtergraph description from a file", "filename" },
>> { "reinit_filter", HAS_ARG | OPT_INT | OPT_SPEC | OPT_INPUT,{ .off
>> = OFFSET(reinit_filters) },
>> "reinit filtergraph on input parameter changes", "" },
>> { "filter_complex", HAS_ARG | OPT_EXPERT,{
>> .func_arg = opt_filter_complex },
>> "create a complex filtergraph", "graph_description" },
>> +{ "filter_complex_threads", HAS_ARG | OPT_INT, {
>> &filter_complex_nbthreads },
>> +"number of threads for -filter_complex" },
>> { "lavfi", HAS_ARG | OPT_EXPERT,{
>> .func_arg = opt_filter_complex },
>> "create a complex filtergraph", "graph_description" },
>> { "filter_complex_script", HAS_ARG | OPT_EXPERT, {
>> .func_arg = opt_filter_complex_script },
>> --
>> 1.8.4.1
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> How this plays out with number of threads one can set for each filter
> instance?
Each individual filter uses MIN(filter_specific_limit, filtergrpah_limit)
threads, but regardless the filtergraph will
create filtergraph_limit threads each time. This patch adds user control to the
filtergraph_limit.
My main motivation for this parameter is a system I have with 80 CPUs
(including hyperthreads). The video filtering
workload does not benefit from so many threads being created or used, and I
suffer from a significant ulimit hit and
greater difficulty debugging.
> ___
> 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
Re: [FFmpeg-devel] [PATCH v2] libavformat/tee: Add fifo support for tee
On 10/17/2016 01:13 PM, sebechlebsky...@gmail.com wrote: From: Jan Sebechlebsky Signed-off-by: Jan Sebechlebsky --- Thanks for noticing, I've fixed the patch (also some minor formatting issues I've noticed). doc/muxers.texi | 20 + libavformat/tee.c | 87 ++- 2 files changed, 106 insertions(+), 1 deletion(-) [...] Can I push this? - I am afraid I accidentally didn't send it as a reply to the Michael's review: http://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/200763.html Double-free is fixed in this version. Best regards, J. S. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] avformat/tee: Add FATE tests for tee
From: Jan Sebechlebsky
This commit also adds new diff option for fate tests allowing do compare
multiple tuples of files.
Signed-off-by: Jan Sebechlebsky
---
Changes since the last version:
- fixed out of tree build (previous version refered to SRC_PATH instead of
TARGET_PATH,
thanks to Michael for noticing that)
tests/Makefile| 1 +
tests/fate-run.sh | 7
tests/fate/tee-muxer.mak | 22 ++
tests/ref/fate/tee-muxer-h264 | 2 +
tests/ref/fate/tee-muxer-h264-audio | 30 +
tests/ref/fate/tee-muxer-h264-copy| 47 +
tests/ref/fate/tee-muxer-ignorefail | 79 +++
tests/ref/fate/tee-muxer-tstsrc | 2 +
tests/ref/fate/tee-muxer-tstsrc-audio | 49 ++
9 files changed, 239 insertions(+)
create mode 100644 tests/fate/tee-muxer.mak
create mode 100644 tests/ref/fate/tee-muxer-h264
create mode 100644 tests/ref/fate/tee-muxer-h264-audio
create mode 100644 tests/ref/fate/tee-muxer-h264-copy
create mode 100644 tests/ref/fate/tee-muxer-ignorefail
create mode 100644 tests/ref/fate/tee-muxer-tstsrc
create mode 100644 tests/ref/fate/tee-muxer-tstsrc-audio
diff --git a/tests/Makefile b/tests/Makefile
index 8e810ff..e23260f 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -164,6 +164,7 @@ include $(SRC_PATH)/tests/fate/real.mak
include $(SRC_PATH)/tests/fate/screen.mak
include $(SRC_PATH)/tests/fate/source.mak
include $(SRC_PATH)/tests/fate/subtitles.mak
+include $(SRC_PATH)/tests/fate/tee-muxer.mak
include $(SRC_PATH)/tests/fate/utvideo.mak
include $(SRC_PATH)/tests/fate/video.mak
include $(SRC_PATH)/tests/fate/voice.mak
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index c640cc5..9c90ea5 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -73,6 +73,12 @@ oneline(){
printf '%s\n' "$1" | diff -u -b - "$2"
}
+multidiff(){
+while read -r ref_file out_file; do
+diff -u -b "${base}/ref/fate/${ref_file}" "${outdir}/${out_file}" ||
return $?
+done <"$1"
+}
+
run(){
test "${V:-0}" -gt 0 && echo "$target_exec" $target_path/"$@" >&3
$target_exec $target_path/"$@"
@@ -350,6 +356,7 @@ if test -e "$ref" || test $cmp = "oneline" || test $cmp =
"grep" ; then
case $cmp in
diff) diff -u -b "$ref" "$outfile">$cmpfile ;;
rawdiff)diff -u"$ref" "$outfile">$cmpfile ;;
+mdiff) multidiff "$ref" >$cmpfile ;;
oneoff) oneoff "$ref" "$outfile">$cmpfile ;;
stddev) stddev "$ref" "$outfile">$cmpfile ;;
oneline)oneline"$ref" "$outfile">$cmpfile ;;
diff --git a/tests/fate/tee-muxer.mak b/tests/fate/tee-muxer.mak
new file mode 100644
index 000..a76cb18
--- /dev/null
+++ b/tests/fate/tee-muxer.mak
@@ -0,0 +1,22 @@
+fate-tee-muxer-h264: CMD = ffmpeg -i $(TARGET_SAMPLES)/mkv/1242-small.mkv
-vframes 11\
+ -c:v copy -c:a copy -map v:0 -map a:0 -flags
+bitexact\
+ -fflags +bitexact -fflags +bitexact -f tee\
+
"[f=framecrc]$(TARGET_PATH)/tests/data/fate/tee-muxer-h264-copy|[f=framecrc:select=1]$(TARGET_PATH)/tests/data/fate/tee-muxer-h264-audio"
+fate-tee-muxer-h264: CMP = mdiff
+FATE-SAMPLES-TEE-MUXER-$(call ALLYES, TEE_MUXER, MATROSKA_DEMUXER,
H264_DECODER) += fate-tee-muxer-h264
+
+fate-tee-muxer-ignorefail: CMD = ./ffmpeg -f lavfi -i "testsrc=s=640x480" -f
lavfi -i "sine"\
+-t 1 -map 0:v -map 1:a -c:v copy -c:a copy
-flags +bitexact -fflags +bitexact -f tee\
+
"[f=framecrc]$(TARGET_PATH)/tests/data/fate/tee-muxer-ignorefail|[f=framecrc:onfail=ignore]$(TARGET_PATH)/dev/full"
+FATE-TEE-MUXER-$(CONFIG_TEE_MUXER) += fate-tee-muxer-ignorefail
+
+fate-tee-muxer-tstsrc: CMD = ./ffmpeg -f lavfi -i "testsrc=s=640x480" -f
lavfi -i "sine"\
+ -t 1 -map 0:v -map 1:a -c:v copy -c:a copy -flags
+bitexact -fflags +bitexact -f tee\
+
"[f=framecrc]$(TARGET_PATH)/tests/data/fate/tee-muxer-tstsrc-copy|[f=framecrc:select=1]$(TARGET_PATH)/tests/data/fate/tee-muxer-tstsrc-audio"
+fate-tee-muxer-tstsrc: CMP = mdiff
+FATE-TEE-MUXER-$(CONFIG_TEE_MUXER) += fate-tee-muxer-tstsrc
+
+FATE_SAMPLES_FFMPEG += $(FATE-SAMPLES-TEE-MUXER-yes)
+FATE_FFMPEG += $(FATE-TEE-MUXER-yes)
+
+fate-tee-muxer: $(FATE-TEE-MUXER-yes) $(FATE-SAMPLES-TEE-MUXER-yes)
diff --git a/tests/ref/fate/tee-muxer-h264 b/tests/ref/fate/tee-muxer-h264
new file mode 100644
index 000..2a99a6b
--- /dev/null
+++ b/tests/ref/fate/tee-muxer-h264
@@ -0,0 +1,2 @@
+tee-muxer-h264-copy tee-muxer-h264-copy
+tee-muxer-h264-audio tee-muxer-h264-audio
\ No newline at end of file
diff --git a/tests/ref/fate/tee-muxer-h264-audio
b/tests/ref/fate/tee-muxer-h264-audio
new file mode 100644
index 000..0b42d11
--- /dev/null
++
Re: [FFmpeg-devel] [PATCH 3/3] vf_colorspace: Add support for smpte 431/432 (dci/display p3) primaries
Hi Kieran, On Sun, Oct 30, 2016 at 10:06 AM, Kieran O Leary wrote: > Hi, > > On Sun, Oct 30, 2016 at 7:07 AM, Vittorio Giovara < > vittorio.giov...@gmail.com> wrote: > > > Signed-off-by: Vittorio Giovara > > --- > > I couldn't find any reference to the name of the whitepoint used for 431, > > so I came up with DCI, since it looks like it is only used there. > > Please CC. > > > > Could this patch be used to convert XYZ Digital Cinema Packages to Rec.709? > I've found that converting a DCP to a YUV format in ffmpeg results in > colours and contrast that look different to how the image displays in > EasyDCP player or a cinema screen. IIRC, -vf colorspace doesn't accept XYZ > input, so is there some intermediate step that I could take to achieve this > kind of transformation, or have I just misunderstood the patch? Does -vf colorspace accept XYZ as input? No, not right now. It could be made to work but since raw XYZ stored in files is such a fringe feature, I didn't focus on implementing support for that. The current filter accepts any YUV colorspace, converts that to XYZ and then converts that back to any other YUV colorspace. You could conceptually skip half of that and allow XYZ input and/or output, but like I said, right now it doesn't support that yet. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mov: only read e_old if there were any old streams
This fixes a heap buffer overflow. Signed-off-by: Andreas Cadhalpun --- libavformat/mov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index 357d800..95b546e 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -3028,7 +3028,7 @@ static void mov_fix_index(MOVContext *mov, AVStream *st) // Audio decoders like AAC need need a decoder delay samples previous to the current sample, // to correctly decode this frame. Hence for audio we seek to a frame 1 sec. before the // edit_list_media_time to cover the decoder delay. -search_timestamp = FFMAX(search_timestamp - mov->time_scale, e_old[0].timestamp); +search_timestamp = FFMAX(search_timestamp - mov->time_scale, nb_old ? e_old[0].timestamp : INT64_MIN); } index = find_prev_closest_keyframe_index(st, e_old, nb_old, search_timestamp, 0); -- 2.10.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] interplayacm: check for too large b
This fixes out-of-bounds reads.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/interplayacm.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/interplayacm.c b/libavcodec/interplayacm.c
index 0fd3501..0486e00 100644
--- a/libavcodec/interplayacm.c
+++ b/libavcodec/interplayacm.c
@@ -326,6 +326,10 @@ static int t15(InterplayACMContext *s, unsigned ind,
unsigned col)
for (i = 0; i < s->rows; i++) {
/* b = (x1) + (x2 * 3) + (x3 * 9) */
b = get_bits(gb, 5);
+if (b > 26) {
+av_log(NULL, AV_LOG_ERROR, "Too large b = %d > 26\n", b);
+return AVERROR_INVALIDDATA;
+}
n1 = (mul_3x3[b] & 0x0F) - 1;
n2 = ((mul_3x3[b] >> 4) & 0x0F) - 1;
@@ -351,6 +355,10 @@ static int t27(InterplayACMContext *s, unsigned ind,
unsigned col)
for (i = 0; i < s->rows; i++) {
/* b = (x1) + (x2 * 5) + (x3 * 25) */
b = get_bits(gb, 7);
+if (b > 124) {
+av_log(NULL, AV_LOG_ERROR, "Too large b = %d > 124\n", b);
+return AVERROR_INVALIDDATA;
+}
n1 = (mul_3x5[b] & 0x0F) - 2;
n2 = ((mul_3x5[b] >> 4) & 0x0F) - 2;
@@ -375,6 +383,10 @@ static int t37(InterplayACMContext *s, unsigned ind,
unsigned col)
for (i = 0; i < s->rows; i++) {
/* b = (x1) + (x2 * 11) */
b = get_bits(gb, 7);
+if (b > 120) {
+av_log(NULL, AV_LOG_ERROR, "Too large b = %d > 120\n", b);
+return AVERROR_INVALIDDATA;
+}
n1 = (mul_2x11[b] & 0x0F) - 5;
n2 = ((mul_2x11[b] >> 4) & 0x0F) - 5;
--
2.10.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] interplayacm: increase bitstream buffer size by AV_INPUT_BUFFER_PADDING_SIZE
This fixes out-of-bounds reads by the bitstream reader. Signed-off-by: Andreas Cadhalpun --- libavcodec/interplayacm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/interplayacm.c b/libavcodec/interplayacm.c index 0486e00..f4a3446 100644 --- a/libavcodec/interplayacm.c +++ b/libavcodec/interplayacm.c @@ -72,7 +72,7 @@ static av_cold int decode_init(AVCodecContext *avctx) s->block = av_calloc(s->block_len, sizeof(int)); s->wrapbuf = av_calloc(s->wrapbuf_len, sizeof(int)); s->ampbuf = av_calloc(0x1, sizeof(int)); -s->bitstream = av_calloc(s->max_framesize, sizeof(*s->bitstream)); +s->bitstream = av_calloc(s->max_framesize + AV_INPUT_BUFFER_PADDING_SIZE / sizeof(*s->bitstream) + 1, sizeof(*s->bitstream)); if (!s->block || !s->wrapbuf || !s->ampbuf || !s->bitstream) return AVERROR(ENOMEM); -- 2.10.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] interplayacm: validate number of channels
The number of channels is used as divisor in decode_frame, so it must
not be zero to avoid SIGFPE crashes.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/interplayacm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/interplayacm.c b/libavcodec/interplayacm.c
index f4a3446..c897e72 100644
--- a/libavcodec/interplayacm.c
+++ b/libavcodec/interplayacm.c
@@ -62,6 +62,11 @@ static av_cold int decode_init(AVCodecContext *avctx)
if (avctx->extradata_size < 14)
return AVERROR_INVALIDDATA;
+if (avctx->channels <= 0) {
+av_log(avctx, AV_LOG_ERROR, "Invalid number of channels: %d\n",
avctx->channels);
+return AVERROR_INVALIDDATA;
+}
+
s->level = AV_RL16(avctx->extradata + 12) & 0xf;
s->rows = AV_RL16(avctx->extradata + 12) >> 4;
s->cols = 1 << s->level;
--
2.10.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] ffmpeg: parameters for filter thread counts
On 10/30/16, DeHackEd wrote:
> On 10/30/2016 12:09 PM, Paul B Mahol wrote:
>> On 10/30/16, DeHackEd wrote:
>>> Enables specifying how many threads are available to each filtergraph.
>>> ---
>>> v2->v3:
>>> - Typos in docs fixed
>>>
>>> v1->v2:
>>> - Reworded documentation
>>> - Removed hunk from ffmpeg_filter.c not directly applicable to patch
>>>
>>> doc/ffmpeg.texi | 10 ++
>>> ffmpeg.h| 3 +++
>>> ffmpeg_filter.c | 7 +++
>>> ffmpeg_opt.c| 4
>>> 4 files changed, 24 insertions(+)
>>>
> ...
>>> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
>>> index 4d25fff..dc94380 100644
>>> --- a/ffmpeg_opt.c
>>> +++ b/ffmpeg_opt.c
>>> @@ -3365,12 +3365,16 @@ const OptionDef options[] = {
>>> "set profile", "profile" },
>>> { "filter", HAS_ARG | OPT_STRING | OPT_SPEC | OPT_OUTPUT, {
>>> .off = OFFSET(filters) },
>>> "set stream filtergraph", "filter_graph" },
>>> +{ "filter_threads", HAS_ARG | OPT_INT, {
>>> &filter_nbthreads },
>>> +"number of non-complex filter threads" },
>>> { "filter_script", HAS_ARG | OPT_STRING | OPT_SPEC | OPT_OUTPUT, {
>>> .off = OFFSET(filter_scripts) },
>>> "read stream filtergraph description from a file", "filename" },
>>> { "reinit_filter", HAS_ARG | OPT_INT | OPT_SPEC | OPT_INPUT,{
>>> .off
>>> = OFFSET(reinit_filters) },
>>> "reinit filtergraph on input parameter changes", "" },
>>> { "filter_complex", HAS_ARG | OPT_EXPERT,{
>>> .func_arg = opt_filter_complex },
>>> "create a complex filtergraph", "graph_description" },
>>> +{ "filter_complex_threads", HAS_ARG | OPT_INT, {
>>> &filter_complex_nbthreads },
>>> +"number of threads for -filter_complex" },
>>> { "lavfi", HAS_ARG | OPT_EXPERT,{
>>> .func_arg = opt_filter_complex },
>>> "create a complex filtergraph", "graph_description" },
>>> { "filter_complex_script", HAS_ARG | OPT_EXPERT, {
>>> .func_arg = opt_filter_complex_script },
>>> --
>>> 1.8.4.1
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>
>> How this plays out with number of threads one can set for each filter
>> instance?
>
> Each individual filter uses MIN(filter_specific_limit, filtergrpah_limit)
> threads, but regardless the filtergraph will
> create filtergraph_limit threads each time. This patch adds user control to
> the filtergraph_limit.
>
> My main motivation for this parameter is a system I have with 80 CPUs
> (including hyperthreads). The video filtering
> workload does not benefit from so many threads being created or used, and I
> suffer from a significant ulimit hit and
> greater difficulty debugging.
Idea sounds fine, I will leave code review to someone else.
>
>> ___
>> 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 mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] interplayacm: validate number of channels
On 10/30/16, Andreas Cadhalpun wrote:
> The number of channels is used as divisor in decode_frame, so it must
> not be zero to avoid SIGFPE crashes.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/interplayacm.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/interplayacm.c b/libavcodec/interplayacm.c
> index f4a3446..c897e72 100644
> --- a/libavcodec/interplayacm.c
> +++ b/libavcodec/interplayacm.c
> @@ -62,6 +62,11 @@ static av_cold int decode_init(AVCodecContext *avctx)
> if (avctx->extradata_size < 14)
> return AVERROR_INVALIDDATA;
>
> +if (avctx->channels <= 0) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid number of channels: %d\n",
> avctx->channels);
> +return AVERROR_INVALIDDATA;
> +}
> +
> s->level = AV_RL16(avctx->extradata + 12) & 0xf;
> s->rows = AV_RL16(avctx->extradata + 12) >> 4;
> s->cols = 1 << s->level;
> --
> 2.10.1
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Patch is OK. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] interplayacm: check for too large b
On 10/30/16, Andreas Cadhalpun wrote:
> This fixes out-of-bounds reads.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/interplayacm.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/libavcodec/interplayacm.c b/libavcodec/interplayacm.c
> index 0fd3501..0486e00 100644
> --- a/libavcodec/interplayacm.c
> +++ b/libavcodec/interplayacm.c
> @@ -326,6 +326,10 @@ static int t15(InterplayACMContext *s, unsigned ind,
> unsigned col)
> for (i = 0; i < s->rows; i++) {
> /* b = (x1) + (x2 * 3) + (x3 * 9) */
> b = get_bits(gb, 5);
> +if (b > 26) {
> +av_log(NULL, AV_LOG_ERROR, "Too large b = %d > 26\n", b);
> +return AVERROR_INVALIDDATA;
> +}
>
> n1 = (mul_3x3[b] & 0x0F) - 1;
> n2 = ((mul_3x3[b] >> 4) & 0x0F) - 1;
> @@ -351,6 +355,10 @@ static int t27(InterplayACMContext *s, unsigned ind,
> unsigned col)
> for (i = 0; i < s->rows; i++) {
> /* b = (x1) + (x2 * 5) + (x3 * 25) */
> b = get_bits(gb, 7);
> +if (b > 124) {
> +av_log(NULL, AV_LOG_ERROR, "Too large b = %d > 124\n", b);
> +return AVERROR_INVALIDDATA;
> +}
>
> n1 = (mul_3x5[b] & 0x0F) - 2;
> n2 = ((mul_3x5[b] >> 4) & 0x0F) - 2;
> @@ -375,6 +383,10 @@ static int t37(InterplayACMContext *s, unsigned ind,
> unsigned col)
> for (i = 0; i < s->rows; i++) {
> /* b = (x1) + (x2 * 11) */
> b = get_bits(gb, 7);
> +if (b > 120) {
> +av_log(NULL, AV_LOG_ERROR, "Too large b = %d > 120\n", b);
> +return AVERROR_INVALIDDATA;
> +}
>
> n1 = (mul_2x11[b] & 0x0F) - 5;
> n2 = ((mul_2x11[b] >> 4) & 0x0F) - 5;
> --
> 2.10.1
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
probably ok.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] interplayacm: increase bitstream buffer size by AV_INPUT_BUFFER_PADDING_SIZE
On 10/30/16, Andreas Cadhalpun wrote: > This fixes out-of-bounds reads by the bitstream reader. > > Signed-off-by: Andreas Cadhalpun > --- > libavcodec/interplayacm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/interplayacm.c b/libavcodec/interplayacm.c > index 0486e00..f4a3446 100644 > --- a/libavcodec/interplayacm.c > +++ b/libavcodec/interplayacm.c > @@ -72,7 +72,7 @@ static av_cold int decode_init(AVCodecContext *avctx) > s->block = av_calloc(s->block_len, sizeof(int)); > s->wrapbuf = av_calloc(s->wrapbuf_len, sizeof(int)); > s->ampbuf = av_calloc(0x1, sizeof(int)); > -s->bitstream = av_calloc(s->max_framesize, sizeof(*s->bitstream)); > +s->bitstream = av_calloc(s->max_framesize + > AV_INPUT_BUFFER_PADDING_SIZE / sizeof(*s->bitstream) + 1, How did you came up with this fix? Little background would help. > sizeof(*s->bitstream)); > if (!s->block || !s->wrapbuf || !s->ampbuf || !s->bitstream) > return AVERROR(ENOMEM); > > -- > 2.10.1 > ___ > 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
Re: [FFmpeg-devel] [PATCH] interplayacm: increase bitstream buffer size by AV_INPUT_BUFFER_PADDING_SIZE
On 30.10.2016 22:18, Paul B Mahol wrote: > On 10/30/16, Andreas Cadhalpun wrote: >> This fixes out-of-bounds reads by the bitstream reader. >> >> Signed-off-by: Andreas Cadhalpun >> --- >> libavcodec/interplayacm.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavcodec/interplayacm.c b/libavcodec/interplayacm.c >> index 0486e00..f4a3446 100644 >> --- a/libavcodec/interplayacm.c >> +++ b/libavcodec/interplayacm.c >> @@ -72,7 +72,7 @@ static av_cold int decode_init(AVCodecContext *avctx) >> s->block = av_calloc(s->block_len, sizeof(int)); >> s->wrapbuf = av_calloc(s->wrapbuf_len, sizeof(int)); >> s->ampbuf = av_calloc(0x1, sizeof(int)); >> -s->bitstream = av_calloc(s->max_framesize, sizeof(*s->bitstream)); >> +s->bitstream = av_calloc(s->max_framesize + >> AV_INPUT_BUFFER_PADDING_SIZE / sizeof(*s->bitstream) + 1, > > How did you came up with this fix? > Little background would help. The out-of-bounds read happens in get_bits called from linear. The buffer passed to init_get_bits8 is &s->bitstream[s->bitstream_index]. The get_bits documentation says: /** * Initialize GetBitContext. * @param buffer bitstream buffer, must be AV_INPUT_BUFFER_PADDING_SIZE bytes *larger than the actual read bits because some optimized bitstream *readers read 32 or 64 bit at once and could read over the end * @param byte_size the size of the buffer in bytes * @return 0 on success, AVERROR_INVALIDDATA if the buffer_size would overflow. */ static inline int init_get_bits8(GetBitContext *s, const uint8_t *buffer, int byte_size) Increasing the buffer size fixed the problem, so the case seems quite clear. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] interplayacm: validate number of channels
On 30.10.2016 22:15, Paul B Mahol wrote:
> On 10/30/16, Andreas Cadhalpun wrote:
>> The number of channels is used as divisor in decode_frame, so it must
>> not be zero to avoid SIGFPE crashes.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavcodec/interplayacm.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/libavcodec/interplayacm.c b/libavcodec/interplayacm.c
>> index f4a3446..c897e72 100644
>> --- a/libavcodec/interplayacm.c
>> +++ b/libavcodec/interplayacm.c
>> @@ -62,6 +62,11 @@ static av_cold int decode_init(AVCodecContext *avctx)
>> if (avctx->extradata_size < 14)
>> return AVERROR_INVALIDDATA;
>>
>> +if (avctx->channels <= 0) {
>> +av_log(avctx, AV_LOG_ERROR, "Invalid number of channels: %d\n",
>> avctx->channels);
>> +return AVERROR_INVALIDDATA;
>> +}
>> +
>> s->level = AV_RL16(avctx->extradata + 12) & 0xf;
>> s->rows = AV_RL16(avctx->extradata + 12) >> 4;
>> s->cols = 1 << s->level;
>> --
>> 2.10.1
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> Patch is OK. Thanks.
Pushed.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] interplayacm: check for too large b
On 30.10.2016 22:16, Paul B Mahol wrote:
> On 10/30/16, Andreas Cadhalpun wrote:
>> This fixes out-of-bounds reads.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavcodec/interplayacm.c | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/libavcodec/interplayacm.c b/libavcodec/interplayacm.c
>> index 0fd3501..0486e00 100644
>> --- a/libavcodec/interplayacm.c
>> +++ b/libavcodec/interplayacm.c
>> @@ -326,6 +326,10 @@ static int t15(InterplayACMContext *s, unsigned ind,
>> unsigned col)
>> for (i = 0; i < s->rows; i++) {
>> /* b = (x1) + (x2 * 3) + (x3 * 9) */
>> b = get_bits(gb, 5);
>> +if (b > 26) {
>> +av_log(NULL, AV_LOG_ERROR, "Too large b = %d > 26\n", b);
>> +return AVERROR_INVALIDDATA;
>> +}
>>
>> n1 = (mul_3x3[b] & 0x0F) - 1;
>> n2 = ((mul_3x3[b] >> 4) & 0x0F) - 1;
>> @@ -351,6 +355,10 @@ static int t27(InterplayACMContext *s, unsigned ind,
>> unsigned col)
>> for (i = 0; i < s->rows; i++) {
>> /* b = (x1) + (x2 * 5) + (x3 * 25) */
>> b = get_bits(gb, 7);
>> +if (b > 124) {
>> +av_log(NULL, AV_LOG_ERROR, "Too large b = %d > 124\n", b);
>> +return AVERROR_INVALIDDATA;
>> +}
>>
>> n1 = (mul_3x5[b] & 0x0F) - 2;
>> n2 = ((mul_3x5[b] >> 4) & 0x0F) - 2;
>> @@ -375,6 +383,10 @@ static int t37(InterplayACMContext *s, unsigned ind,
>> unsigned col)
>> for (i = 0; i < s->rows; i++) {
>> /* b = (x1) + (x2 * 11) */
>> b = get_bits(gb, 7);
>> +if (b > 120) {
>> +av_log(NULL, AV_LOG_ERROR, "Too large b = %d > 120\n", b);
>> +return AVERROR_INVALIDDATA;
>> +}
>>
>> n1 = (mul_2x11[b] & 0x0F) - 5;
>> n2 = ((mul_2x11[b] >> 4) & 0x0F) - 5;
>> --
>> 2.10.1
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> probably ok.
Pushed.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer
On 27.10.2016 20:26, Michael Niedermayer wrote: On Thu, Oct 27, 2016 at 11:03:07AM -0700, Reynaldo H. Verdejo Pinochet wrote: I agree with moving the apps to a seperate repo hosted within the same infra and keeping ffserver. I will help with ffserver as my time & todo list permits I don't follow ffmpeg list for long time, so please forgive me if I said something already discussed, but the news said it is removed because of cleanups. That is reasonable, but in such case moving it to separate repo is nonsense. Also I'm not sure ffmenc/dec removal is good decision at the moment. I don't want to suggest there is ohter app than ffserver that use it, but with these removed you can forget ffserver will exists in other repo, right? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer
On 10/30/2016 8:23 PM, Lukasz Marek wrote: > On 27.10.2016 20:26, Michael Niedermayer wrote: >> On Thu, Oct 27, 2016 at 11:03:07AM -0700, Reynaldo H. Verdejo Pinochet wrote: >> I agree with moving the apps to a seperate repo hosted within >> the same infra and keeping ffserver. >> I will help with ffserver as my time & todo list permits > > I don't follow ffmpeg list for long time, so please forgive me if I said > something already discussed, but the news said it is removed because of > cleanups. That is reasonable, but in such case moving it to separate repo is > nonsense. Also I'm not sure ffmenc/dec removal is good decision at the > moment. I don't want to suggest there is ohter app than ffserver that use it, > but with these removed you can forget ffserver will exists in other repo, > right? ffmdec/enc will not be removed until the next major bump at the earliest for backwards compat reasons. At worst, when AVStream->codec is removed. And Reynaldo, who's moving ffserver to a separate repo, said he'll make it work without them in the long run. In any case, ffserver and ffm* will all be gone from the main tree sooner or later. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] news: add final report for summer of code 2016
On Sun, Oct 30, 2016 at 01:57:58AM -0700, reyna...@osg.samsung.com wrote: > From: "Reynaldo H. Verdejo Pinochet" > > Signed-off-by: Reynaldo H. Verdejo Pinochet > --- > src/index | 34 ++ > 1 file changed, 34 insertions(+) except the typos pointed out by others, and any improvments ... LGTM thanks to everyone! [...] -- 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: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] news: add final report for summer of code 2016
Thanks for the comments and corrections. Fixed the typos and pushed as: commit f06598a8e1fcccef8c38a657162db309773d1515 Author: Reynaldo H. Verdejo Pinochet Date: Sun Oct 30 01:37:26 2016 -0700 news: add final report for summer of code 2016 Bests, -- Reynaldo H. Verdejo Pinochet Open Source Group - Samsung Research America ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.
On 31 October 2016 at 05:30, James Almer wrote:
> On 10/30/2016 8:31 AM, Matt Oliver wrote:
> > From 1dc1f59158cfb12d9160ee47342f5742d67ad864 Mon Sep 17 00:00:00 2001
> > From: Matt Oliver
> > Date: Sun, 30 Oct 2016 15:13:47 +1100
> > Subject: [PATCH] avformat/avisynth.c: Use new safe dlopen code.
> >
> > ---
> > configure | 5 ++---
> > libavformat/avisynth.c | 14 +-
> > 2 files changed, 7 insertions(+), 12 deletions(-)
> >
> > diff --git a/configure b/configure
> > index 5993de5..9feb544 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2850,6 +2850,7 @@ asf_stream_muxer_select="asf_muxer"
> > avi_demuxer_select="iso_media riffdec exif"
> > avi_muxer_select="riffenc"
> > avisynth_demuxer_deps="avisynth"
> > +avisynth_demuxer_deps_any="dlopen LoadLibrary"
> > avisynth_demuxer_select="riffdec"
>
> With this change and the stuff removed below, avisynth (CONFIG_AVISYNTH)
> will always be enabled if you configure with --enable-avisynth, and only
> avisynth_demuxer will be disabled depending on the presence of dlopen and
> LoadLibrary.
> This is probably not intended, seeing how libavformat/Makefile checks for
> CONFIG_AVISYNTH and not CONFIG_AVISYNTH_DEMUXER in order to compile the
> source file, so you should make it avisynth_deps_any="dlopen LoadLibrary"
> since avisynth_demuxer already depends on avisynth.
>
> Also, consider changing libavformat/Makefile to check for the demuxer
> rather than the library/feature.
>
Changed, I also moved the avisynth stuff up to the external libraries
section of configure
>
> > caf_demuxer_select="iso_media riffdec"
> > dash_muxer_select="mp4_muxer"
> > @@ -5417,6 +5418,7 @@ elif check_func dlopen -ldl && check_func dlsym
> -ldl; then
> > ldl=-ldl
> > fi
> >
> > +avisynth_demuxer_extralibs='$ldl'
> > decklink_outdev_extralibs="$decklink_outdev_extralibs $ldl"
> > decklink_indev_extralibs="$decklink_indev_extralibs $ldl"
> > frei0r_filter_extralibs='$ldl'
> > @@ -5664,9 +5666,6 @@ fi
> > enabled avfoundation_indev && { check_header_objcc
> AVFoundation/AVFoundation.h || disable avfoundation_indev; }
> > enabled avfoundation_indev && { check_lib2 CoreGraphics/CoreGraphics.h
> CGGetActiveDisplayList -framework CoreGraphics ||
> > check_lib2
> > ApplicationServices/ApplicationServices.h
> CGGetActiveDisplayList -framework ApplicationServices; }
> > -enabled avisynth && { { check_lib2 "windows.h" LoadLibrary; }
> ||
> > - { check_lib2 "dlfcn.h" dlopen -ldl; } ||
> > - die "ERROR: LoadLibrary/dlopen not found
> for avisynth"; }
> > enabled cuda && { check_lib cuda.h cuInit -lcuda ||
> > die "ERROR: CUDA not found"; }
> > enabled cuvid && { add_cflags -I$source_path;
> > diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
> > index 1acc44f..514cb99 100644
> > --- a/libavformat/avisynth.c
> > +++ b/libavformat/avisynth.c
> > @@ -29,7 +29,7 @@
> >
> > /* Platform-specific directives for AviSynth vs AvxSynth. */
> > #ifdef _WIN32
> > - #include
> > + #include "compat/w32dlfcn.h"
> >#undef EXTERN_C
> >#include "compat/avisynth/avisynth_c.h"
> >#define AVISYNTH_LIB "avisynth"
> > @@ -39,10 +39,6 @@
> >#include "compat/avisynth/avxsynth_c.h"
> >#define AVISYNTH_NAME "libavxsynth"
> >#define AVISYNTH_LIB AVISYNTH_NAME SLIBSUF
> > -
> > - #define LoadLibrary(x) dlopen(x, RTLD_NOW | RTLD_LOCAL)
> > - #define GetProcAddress dlsym
> > - #define FreeLibrary dlclose
> > #endif
> >
> > typedef struct AviSynthLibrary {
> > @@ -118,13 +114,13 @@ static av_cold void avisynth_atexit_handler(void);
> >
> > static av_cold int avisynth_load_library(void)
> > {
> > -avs_library.library = LoadLibrary(AVISYNTH_LIB);
> > +avs_library.library = dlopen(AVISYNTH_LIB, RTLD_NOW | RTLD_LOCAL);
> > if (!avs_library.library)
> > return AVERROR_UNKNOWN;
> >
> > #define LOAD_AVS_FUNC(name, continue_on_fail) \
> > avs_library.name =
> \
> > -(void *)GetProcAddress(avs_library.library, #name);
> \
> > +(void *)dlsym(avs_library.library, #name); \
> > if (!continue_on_fail && !avs_library.name)
> \
> > goto fail;
> >
> > @@ -157,7 +153,7 @@ static av_cold int avisynth_load_library(void)
> > return 0;
> >
> > fail:
> > -FreeLibrary(avs_library.library);
> > +dlclose(avs_library.library);
> > return AVERROR_UNKNOWN;
> > }
> >
> > @@ -225,7 +221,7 @@ static av_cold void avisynth_atexit_handler(void)
> > avisynth_context_destroy(avs);
> > avs = next;
> > }
> > -FreeLibrary(avs_library.library);
> > +dlclose(avs_library.library);
> >
> > avs_atexit_called = 1;
> > }
> > -- 2.10.1.windows.1
0003-avformat-avisynth.c-Use-new-safe-dlopen-code.patch
Description: Binary data
[FFmpeg-devel] [PATCH 2/2] Add experimental demuxing support for FLAC in ISO BMFF (MP4).
Based on the draft spec at
https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt
Signed-off-by: Matthew Gregan
---
libavformat/mov.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 357d800..fc36b0e 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4684,6 +4684,46 @@ static int mov_read_saiz(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
return 0;
}
+static int mov_read_dfla(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+const size_t FLAC_STREAMINFO_SIZE = 34;
+AVStream *st;
+uint8_t type;
+size_t size;
+
+if (c->fc->nb_streams < 1)
+return 0;
+st = c->fc->streams[c->fc->nb_streams-1];
+
+if ((uint64_t)atom.size > (1<<30) || atom.size < 42)
+return AVERROR_INVALIDDATA;
+
+/* Check FlacSpecificBox version. */
+if (avio_r8(pb) != 0)
+return AVERROR_INVALIDDATA;
+
+avio_rb24(pb); /* Flags */
+
+type = avio_r8(pb);
+/* TODO: Read other METADATA_BLOCK_TYPEs if the decoder wants them. */
+if (!(type & 0x80)) {
+ av_log(c->fc, AV_LOG_WARNING, "ignoring non-STREAMINFO
FLACMetadataBlocks\n");
+}
+type = type & 0x7f;
+size = avio_rb24(pb);
+
+/* The first METADATA_BLOCK_TYPE must be STREAMINFO. */
+if (type != 0 || size != FLAC_STREAMINFO_SIZE)
+return AVERROR_INVALIDDATA;
+
+if (ff_alloc_extradata(st->codecpar, size))
+return AVERROR(ENOMEM);
+
+avio_read(pb, st->codecpar->extradata, size);
+
+return 0;
+}
+
static int cenc_filter(MOVContext *c, MOVStreamContext *sc, uint8_t *input,
int size)
{
uint32_t encrypted_bytes;
@@ -4858,6 +4898,7 @@ static const MOVParseTableEntry mov_default_parse_table[]
= {
{ MKTAG('f','r','m','a'), mov_read_frma },
{ MKTAG('s','e','n','c'), mov_read_senc },
{ MKTAG('s','a','i','z'), mov_read_saiz },
+{ MKTAG('d','f','L','a'), mov_read_dfla },
{ 0, NULL }
};
--
2.10.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] Add experimental muxing support for FLAC in ISO BMFF (MP4).
Based on the draft spec at
https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt
'-strict -2' is required to create files in this format.
Signed-off-by: Matthew Gregan
---
libavformat/isom.c | 2 ++
libavformat/movenc.c | 43 +--
2 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index ab79e22..aacbe43 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -60,6 +60,7 @@ const AVCodecTag ff_mp4_obj_type[] = {
{ AV_CODEC_ID_EAC3, 0xA6 },
{ AV_CODEC_ID_DTS , 0xA9 }, /* mp4ra.org */
{ AV_CODEC_ID_VP9 , 0xC0 }, /* nonstandard, update when there is a
standard value */
+{ AV_CODEC_ID_FLAC, 0xC1 }, /* nonstandard, update when there is a
standard value */
{ AV_CODEC_ID_TSCC2 , 0xD0 }, /* nonstandard, camtasia uses it */
{ AV_CODEC_ID_VORBIS , 0xDD }, /* nonstandard, gpac uses it */
{ AV_CODEC_ID_DVD_SUBTITLE, 0xE0 }, /* nonstandard, see
unsupported-embedded-subs-2.mp4 */
@@ -345,6 +346,7 @@ const AVCodecTag ff_codec_movaudio_tags[] = {
{ AV_CODEC_ID_WMAV2, MKTAG('W', 'M', 'A', '2') },
{ AV_CODEC_ID_EVRC,MKTAG('s', 'e', 'v', 'c') }, /* 3GPP2 */
{ AV_CODEC_ID_SMV, MKTAG('s', 's', 'm', 'v') }, /* 3GPP2 */
+{ AV_CODEC_ID_FLAC,MKTAG('f', 'L', 'a', 'C') }, /* nonstandard
*/
{ AV_CODEC_ID_NONE, 0 },
};
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 6228192..d77250e 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -654,6 +654,27 @@ static int mov_write_wfex_tag(AVFormatContext *s,
AVIOContext *pb, MOVTrack *tra
return update_size(pb, pos);
}
+static int mov_write_dfla_tag(AVIOContext *pb, MOVTrack *track)
+{
+const size_t FLAC_STREAMINFO_SIZE = 34;
+int64_t pos = avio_tell(pb);
+avio_wb32(pb, 0);
+ffio_wfourcc(pb, "dfLa");
+avio_w8(pb, 0); /* version */
+avio_wb24(pb, 0); /* flags */
+
+/* Expect the encoder to pass a METADATA_BLOCK_TYPE_STREAMINFO. */
+if (track->par->extradata_size != FLAC_STREAMINFO_SIZE)
+ return AVERROR_INVALIDDATA;
+
+/* TODO: Write other METADATA_BLOCK_TYPEs if the encoder makes them
available. */
+avio_w8(pb, 1 << 7 | 0); /* LastMetadataBlockFlag << 7 | BlockType
(STREAMINFO) */
+avio_wb24(pb, track->par->extradata_size); /* Length */
+avio_write(pb, track->par->extradata, track->par->extradata_size); /*
BlockData[Length] */
+
+return update_size(pb, pos);
+}
+
static int mov_write_chan_tag(AVFormatContext *s, AVIOContext *pb, MOVTrack
*track)
{
uint32_t layout_tag, bitmap;
@@ -963,8 +984,13 @@ static int mov_write_audio_tag(AVFormatContext *s,
AVIOContext *pb, MOVMuxContex
avio_wb16(pb, 16);
avio_wb16(pb, track->audio_vbr ? -2 : 0); /* compression ID */
} else { /* reserved for mp4/3gp */
-avio_wb16(pb, 2);
-avio_wb16(pb, 16);
+if (track->par->codec_id == AV_CODEC_ID_FLAC) {
+avio_wb16(pb, track->par->channels);
+avio_wb16(pb, av_get_bytes_per_sample(track->par->format) * 8);
+} else {
+avio_wb16(pb, 2);
+avio_wb16(pb, 16);
+}
avio_wb16(pb, 0);
}
@@ -1009,6 +1035,8 @@ static int mov_write_audio_tag(AVFormatContext *s,
AVIOContext *pb, MOVMuxContex
mov_write_extradata_tag(pb, track);
else if (track->par->codec_id == AV_CODEC_ID_WMAPRO)
mov_write_wfex_tag(s, pb, track);
+else if (track->par->codec_id == AV_CODEC_ID_FLAC)
+mov_write_dfla_tag(pb, track);
else if (track->vos_len > 0)
mov_write_glbl_tag(pb, track);
@@ -1177,6 +1205,7 @@ static int mp4_get_codec_tag(AVFormatContext *s, MOVTrack
*track)
else if (track->par->codec_id == AV_CODEC_ID_DIRAC) tag =
MKTAG('d','r','a','c');
else if (track->par->codec_id == AV_CODEC_ID_MOV_TEXT) tag =
MKTAG('t','x','3','g');
else if (track->par->codec_id == AV_CODEC_ID_VC1) tag =
MKTAG('v','c','-','1');
+else if (track->par->codec_id == AV_CODEC_ID_FLAC) tag =
MKTAG('f','L','a','C');
else if (track->par->codec_type == AVMEDIA_TYPE_VIDEO) tag =
MKTAG('m','p','4','v');
else if (track->par->codec_type == AVMEDIA_TYPE_AUDIO) tag =
MKTAG('m','p','4','a');
else if (track->par->codec_id == AV_CODEC_ID_DVD_SUBTITLE) tag =
MKTAG('m','p','4','s');
@@ -5733,6 +5762,16 @@ static int mov_init(AVFormatContext *s)
i, track->par->sample_rate);
}
}
+if (track->mode == MODE_MP4 &&
+track->par->codec_id == AV_CODEC_ID_FLAC) {
+if (s->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL) {
+av_log(s, AV_LOG_ERROR,
+ "FLAC in MP4 support is experimental, add "
+
