Re: [FFmpeg-devel] [PATCH v8 2/2] doc: Add libsvt_hevc encoder docs
The changes in my review don't look to have been made.
http://www.ffmpeg.org/pipermail/ffmpeg-devel/2019-March/240931.html
Gyan
On 20-03-2019 01:14 PM, Jing Sun wrote:
Add docs for libsvt_hevc encoder in encoders.texi and general.texi
Signed-off-by: Jun Zhao
Signed-off-by: Zhengxu Huang
Signed-off-by: Hassene Tmar
Signed-off-by: Jing Sun
---
doc/encoders.texi | 145 ++
doc/general.texi | 8 +++
2 files changed, 153 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 29625ba..0b30776 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1569,6 +1569,151 @@ Set maximum NAL size in bytes.
Allow skipping frames to hit the target bitrate if set to 1.
@end table
+@section libsvt_hevc
+
+Scalable Video Technology for HEVC encoder (SVT-HEVC encoder) wrapper.
+
+This encoder requires the presence of the headers and
+library during configuration. You need to explicitly configure the
+build with @code{--enable-libsvthevc}. The library is detected using
+@command{pkg-config}.
+
+For more information about the library see
+@url{https://github.com/intel/SVT-HEVC.git}.
+
+@subsection Options
+
+The following FFmpeg global options affect the configurations of the
+libsvt_hevc encoder.
+
+@table @option
+@item b (@emph{bitrate})
+Set the bitrate (as a number of bits per second). Default is 7M.
+
+@item g / @option{gop_size}
+Set the GOP size. Default is -2 (unspecified).
+
+@item flags +cgop
+Enable closed GOP.
+
+@item qmin (@emph{min-q})
+Defaults 10
+
+@item qmax (@emph{max-q})
+Defaults 48
+
+Set minimum/maximum quantisation values. Valid range is from 0 to 51
+(Only used when bit rate control mode @option{rc} is set to 1(vbr) mode.
+Has to be qmax > = qmin).
+
+@item profile (@emph{profile})
+Set profile restrictions. Can assume one of the following possible values:
+
+Default is 2 (main10).
+
+@table @samp
+@item main
+main profile
+@item main10
+main10 profile
+@end table
+
+@item level
+
+@option{profile} sets the value of @emph{profile}.
+@option{level} sets the value of @emph{level}.
+
+The encoder also has its own specific options:
+
+@table @option
+@item vui
+Enables or disables the vui structure in the HEVC elementary
+bitstream. 0 = Off, 1 = On. Default is 0 (Off).
+
+@item aud (@emph{aud})
+Enable use of access unit delimiters when set to 1. Default is 0 (Off).
+
+@item hielevel
+Set hierarchical levels. Can assume one of the following possible values:
+
+Default is 3 (4level).
+
+@table @samp
+@item flat
+none hierarchy level
+@item 2level
+2-level hierarchy
+@item 3level
+3-level hierarchy
+@item 4level
+4-level hierarchy
+@end table
+
+@item la_depth
+Set look-ahead depth, depending on bit rate control mode @option{rc}, when
+bit rate control mode is set to vbr it's best to set this parameter to be
+equal to the intra period value (such is the default set by the encoder),
+when cqp is chosen, then a look ahead is recommended. The range is from
@var{0-256}.
+
+@item preset
+A preset defining the quality vs density tradeoff point that the
+encoding is to be performed at.(e.g. 0 is the highest quality mode,
+12 is the highest density mode). The range is from @var{0-12}. Default is 9.
+
+@item tier
+Set @emph{general_tier_flag}. This may affect the level chosen for the stream
+if it is not explicitly specified. Can assume one of the following possible
values:
+
+Default is 1 (main).
+
+@table @samp
+@item main
+main tier
+@item high
+high tier
+@end table
+
+@item rc
+Set bit rate control mode. Can assume one of the following possible values:
+
+Default is 0 (cqp).
+
+@table @samp
+@item cqp
+Constant QP (CQP) mode
+@item vbr
+Variable Bit Rate (VBR) mode
+@end table
+
+@item qp
+Initial quantization parameter for the intra pictures used when
+@option{rc} is cqp mode. The range is from @var{0-51}. Default is 32.
+
+@item sc_detection
+Enables or disables the scene change detection algorithm. Default is 0
(disable).
+
+@item tune
+Set quality tuning mode. Can assume one of the following possible values:
+
+Default is 1 (oq).
+
+@table @samp
+@item sq
+Visually optimized mode
+@item oq
+PSNR / SSIM optimized mode
+@item vmaf
+VMAF optimized mode
+@end table
+
+@item bl_mode
+Enables or disables Random Access Prediction. Default is 0 (disable).
+@end table
+
+@item hdr
+High dynamic range input. Default is 0 (disable).
+@end table
+
@section libtheora
libtheora Theora encoder wrapper.
diff --git a/doc/general.texi b/doc/general.texi
index fe94c40..f90e188 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -234,6 +234,14 @@ FFmpeg can use the OpenJPEG libraries for
decoding/encoding J2K videos. Go to
instructions. To enable using OpenJPEG in FFmpeg, pass
@code{--enable-libopenjpeg} to
@file{./configure}.
+@section Scalable Video Technology for HEVC
+
+FFmpeg can make use of the SVT-HEVC library for HEVC encoding.
+
+Go to @url{https://github.com/intel/SVT-HEVC.git} and follow the
Re: [FFmpeg-devel] [PATCH 2/2] swscale/ppc: Add av_unused to template vars only used in one includer
On Mon, 18 Mar 2019 13:56:52 +0200 Lauri Kasanen wrote: > Signed-off-by: Lauri Kasanen > --- > libswscale/ppc/swscale_ppc_template.c | 21 +++-- > 1 file changed, 11 insertions(+), 10 deletions(-) Applying these two. - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 1/1] lavc/h264_levels: add MaxMBPS checking and update fate test.
2019-03-08 7:39 GMT+01:00, Decai Lin :
> 1. add MaxMBPS checking for level idc setting to align with AVC spec
>AnnexA table A-1/A-6 level limits.
> 2. update h264 level fate test.
>
> Signed-off-by: Decai Lin
> ---
> libavcodec/h264_levels.c | 6 +
> libavcodec/h264_levels.h | 1 +
> libavcodec/h264_metadata_bsf.c | 10 +++-
> libavcodec/tests/h264_levels.c | 58
> +++---
> libavcodec/vaapi_encode_h264.c | 7 +
> 5 files changed, 78 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/h264_levels.c b/libavcodec/h264_levels.c
> index 7a55116..7fdb61d 100644
> --- a/libavcodec/h264_levels.c
> +++ b/libavcodec/h264_levels.c
> @@ -89,6 +89,7 @@ const H264LevelDescriptor *ff_h264_get_level(int
> level_idc,
>
> const H264LevelDescriptor *ff_h264_guess_level(int profile_idc,
> int64_t bitrate,
> + int framerate,
> int width, int height,
> int max_dec_frame_buffering)
> {
> @@ -116,6 +117,11 @@ const H264LevelDescriptor *ff_h264_guess_level(int
> profile_idc,
> continue;
>
> if (width_mbs && height_mbs) {
> +if (framerate > level->max_mbps / (width_mbs * height_mbs))
> +continue;
> +}
> +
> +if (width_mbs && height_mbs) {
This looks very strange:
Do I miss something or can these blocks be merged /
the last two inserts be removed?
[...]
> @@ -244,7 +245,14 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
> height = 16 * (sps->pic_height_in_map_units_minus1 + 1) *
> (2 - sps->frame_mbs_only_flag);
>
> -desc = ff_h264_guess_level(sps->profile_idc, bit_rate,
> +if (sps->vui.timing_info_present_flag) {
> +framerate = sps->vui.time_scale /
> sps->vui.num_units_in_tick;
> +}
> +else {
Please merge these lines.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/flvdec: added support for KUX container
2019-03-19 18:11 GMT+01:00, swarajhota...@gmail.com : > From: Swaraj Hota > > Fixes ticket #4519. > --- > This is my qualification task for GSoC 2019. > Please suggest any more changes if required. There is a zipped section in the files starting at 0xe4, the password is "meta". Is there anything in this metadata block that may be useful for a player? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 1/1] lavc/h264_levels: add MaxMBPS checking and update fate test.
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Carl Eugen Hoyos
> Sent: 2019年3月20日 16:33
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/1] lavc/h264_levels: add MaxMBPS
> checking and update fate test.
>
> 2019-03-08 7:39 GMT+01:00, Decai Lin :
> > 1. add MaxMBPS checking for level idc setting to align with AVC spec
> >AnnexA table A-1/A-6 level limits.
> > 2. update h264 level fate test.
> >
> > Signed-off-by: Decai Lin
> > ---
> > libavcodec/h264_levels.c | 6 +
> > libavcodec/h264_levels.h | 1 +
> > libavcodec/h264_metadata_bsf.c | 10 +++-
> > libavcodec/tests/h264_levels.c | 58
> > +++---
> > libavcodec/vaapi_encode_h264.c | 7 +
> > 5 files changed, 78 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/h264_levels.c b/libavcodec/h264_levels.c index
> > 7a55116..7fdb61d 100644
> > --- a/libavcodec/h264_levels.c
> > +++ b/libavcodec/h264_levels.c
> > @@ -89,6 +89,7 @@ const H264LevelDescriptor *ff_h264_get_level(int
> > level_idc,
> >
> > const H264LevelDescriptor *ff_h264_guess_level(int profile_idc,
> > int64_t bitrate,
> > + int framerate,
> > int width, int
> height,
> > int
> > max_dec_frame_buffering) { @@ -116,6 +117,11 @@ const
> > H264LevelDescriptor *ff_h264_guess_level(int profile_idc,
> > continue;
> >
> > if (width_mbs && height_mbs) {
> > +if (framerate > level->max_mbps / (width_mbs *
> height_mbs))
> > +continue;
> > +}
> > +
> > +if (width_mbs && height_mbs) {
>
> This looks very strange:
> Do I miss something or can these blocks be merged / the last two inserts be
> removed?
OK, will merge them in one block.
> [...]
>
> > @@ -244,7 +245,14 @@ static int
> h264_metadata_update_sps(AVBSFContext *bsf,
> > height = 16 * (sps->pic_height_in_map_units_minus1 + 1)
> *
> > (2 - sps->frame_mbs_only_flag);
> >
> > -desc = ff_h264_guess_level(sps->profile_idc, bit_rate,
> > +if (sps->vui.timing_info_present_flag) {
> > +framerate = sps->vui.time_scale /
> > sps->vui.num_units_in_tick;
>
> > +}
> > +else {
>
> Please merge these lines.
Thanks, will merge these lines.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3 1/1] lavc/h264_levels: add MaxMBPS checking and update fate test.
1. add MaxMBPS checking for level idc setting to align with AVC spec
AnnexA table A-1/A-6 level limits.
2. update h264 level fate test.
Signed-off-by: Decai Lin
---
libavcodec/h264_levels.c | 4 +++
libavcodec/h264_levels.h | 1 +
libavcodec/h264_metadata_bsf.c | 9 ++-
libavcodec/tests/h264_levels.c | 58 +++---
libavcodec/vaapi_encode_h264.c | 7 +
5 files changed, 75 insertions(+), 4 deletions(-)
diff --git a/libavcodec/h264_levels.c b/libavcodec/h264_levels.c
index 7a55116..dd517f1 100644
--- a/libavcodec/h264_levels.c
+++ b/libavcodec/h264_levels.c
@@ -89,6 +89,7 @@ const H264LevelDescriptor *ff_h264_get_level(int level_idc,
const H264LevelDescriptor *ff_h264_guess_level(int profile_idc,
int64_t bitrate,
+ int framerate,
int width, int height,
int max_dec_frame_buffering)
{
@@ -120,6 +121,9 @@ const H264LevelDescriptor *ff_h264_guess_level(int
profile_idc,
FFMIN(level->max_dpb_mbs / (width_mbs * height_mbs), 16);
if (max_dec_frame_buffering > max_dpb_frames)
continue;
+
+if (framerate > (level->max_mbps / (width_mbs * height_mbs)))
+continue;
}
return level;
diff --git a/libavcodec/h264_levels.h b/libavcodec/h264_levels.h
index 4189fc6..0a0f410 100644
--- a/libavcodec/h264_levels.h
+++ b/libavcodec/h264_levels.h
@@ -46,6 +46,7 @@ const H264LevelDescriptor *ff_h264_get_level(int level_idc,
*/
const H264LevelDescriptor *ff_h264_guess_level(int profile_idc,
int64_t bitrate,
+ int framerate,
int width, int height,
int max_dec_frame_buffering);
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index a17987a..0f6ce26 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -223,6 +223,7 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
const H264LevelDescriptor *desc;
int64_t bit_rate;
int width, height, dpb_frames;
+int framerate;
if (sps->vui.nal_hrd_parameters_present_flag) {
bit_rate =
(sps->vui.nal_hrd_parameters.bit_rate_value_minus1[0] + 1) *
@@ -244,7 +245,13 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
height = 16 * (sps->pic_height_in_map_units_minus1 + 1) *
(2 - sps->frame_mbs_only_flag);
-desc = ff_h264_guess_level(sps->profile_idc, bit_rate,
+if (sps->vui.timing_info_present_flag) {
+framerate = sps->vui.time_scale / sps->vui.num_units_in_tick;
+} else {
+framerate = 0;
+}
+
+desc = ff_h264_guess_level(sps->profile_idc, bit_rate, framerate,
width, height, dpb_frames);
if (desc) {
level_idc = desc->level_idc;
diff --git a/libavcodec/tests/h264_levels.c b/libavcodec/tests/h264_levels.c
index 0e00f05..1f2c2eb 100644
--- a/libavcodec/tests/h264_levels.c
+++ b/libavcodec/tests/h264_levels.c
@@ -62,6 +62,48 @@ static const struct {
static const struct {
int width;
int height;
+int framerate;
+int level_idc;
+} test_framerate[] = {
+// Some typical sizes and frame rates.
+// (From H.264 table A-1 and table A-6)
+{ 176, 144, 15, 10 },
+{ 176, 144, 16, 11 },
+{ 320, 240, 10, 11 },
+{ 320, 240, 20, 12 },
+{ 320, 240, 40, 21 },
+{ 352, 288, 30, 13 },
+{ 352, 288, 51, 22 },
+{ 352, 576, 25, 21 },
+{ 352, 576, 26, 30 },
+{ 640, 480, 33, 30 },
+{ 640, 480, 34, 31 },
+{ 720, 480, 50, 31 },
+{ 720, 576, 25, 30 },
+{ 800, 600, 55, 31 },
+{ 1024, 768, 35, 31 },
+{ 1024, 768, 70, 32 },
+{ 1280, 720, 30, 31 },
+{ 1280, 720, 31, 32 },
+{ 1280, 960, 45, 32 },
+{ 1280, 960, 46, 40 },
+{ 1280, 1024, 42, 32 },
+{ 1600, 1200, 32, 40 },
+{ 1600, 1200, 33, 42 },
+{ 1920, 1088, 30, 40 },
+{ 1920, 1088, 55, 42 },
+{ 2048, 1024, 30, 40 },
+{ 2048, 1024, 62, 42 },
+{ 2048, 1088, 60, 42 },
+{ 3680, 1536, 26, 50 },
+{ 4096, 2048, 30, 51 },
+{ 4096, 2048, 59, 52 },
+{ 4096, 2160, 60, 52 },
+};
+
+static const struct {
+int width;
+int height;
int dpb_size;
int level_idc;
} test_dpb[] = {
@@ -147,14 +189,23 @@ int main(void)
} while (0)
for (i = 0; i < FF_ARRAY_ELEMS(test_sizes); i++) {
-level = ff_h264_guess_level(0, 0, test_sizes[i].width,
+level = ff_h264_guess_level(0, 0, 0,
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
2019-03-19 20:11 GMT+01:00, Gyan : > > > On 20-03-2019 12:03 AM, Kieran Kunhya wrote: > > >From a84db9c39d382a37f76ae72e490d25ca451155c4 Mon Sep 17 00:00:00 2001 > >From: Kieran Kunhya > >Date: Tue, 19 Mar 2019 18:31:39 + > >Subject: [PATCH] News: Removal of libndi > > > >--- > > src/index | 5 + > > 1 file changed, 5 insertions(+) > > > >diff --git a/src/index b/src/index > >index 0dcf6c1..a5de03e 100644 > >--- a/src/index > >+++ b/src/index > >@@ -37,6 +37,11 @@ > > News > > > > > >+ March 19th, 2019, libndi removed. > >+ > >+Support for the nonfree NDI protocol has been removed, > > it had been a common source of GPL violations. common? > Do you have citations for these violation*s*? I'm only aware > of Newtek's distribution of ffmpeg in their SDK, as reported > in trac #7589. Are there others? I wish this would have been addressed. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] backport fixes for CVE-2019-9718 and CVE-2019-9721
On Wednesday, 20 March 2019 at 00:48, Carl Eugen Hoyos wrote: > 2019-03-19 23:28 GMT+01:00, Dominik 'Rathann' Mierzejewski > : > > > Were the CVE IDs not known at the time these were pushed to master? > > No, how would this be possible? Easy: you can request the ID at https://cveform.mitre.org/ before pushing the commits. > > Not having them in the commit log made it more difficult to find them. > > I thought the CVE's themselves contains the commits, no? They do, but looking at the commits only I wouldn't know there were CVE IDs associated with them, so the relation is one-way only. I would feel better if the commit log said a CVE ID was being fixed. 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 https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] swscale/ppc: VSX-optimize yuv2rgb_full
./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 \
-s 1200x1440 -f null -vframes 100 -pix_fmt $i -nostats \
-cpuflags 0 -v error -
This uses 32-bit mul, so POWER8 only.
The following output formats get about 4.5x speedup:
rgb24
39980 UNITS in yuv2packed1, 32768 runs, 0 skips
8774 UNITS in yuv2packed1, 32768 runs, 0 skips
bgr24
40069 UNITS in yuv2packed1, 32768 runs, 0 skips
8772 UNITS in yuv2packed1, 32766 runs, 2 skips
rgba
39759 UNITS in yuv2packed1, 32768 runs, 0 skips
8681 UNITS in yuv2packed1, 32767 runs, 1 skips
bgra
39729 UNITS in yuv2packed1, 32768 runs, 0 skips
8696 UNITS in yuv2packed1, 32766 runs, 2 skips
argb
39766 UNITS in yuv2packed1, 32768 runs, 0 skips
8672 UNITS in yuv2packed1, 32766 runs, 2 skips
bgra
39784 UNITS in yuv2packed1, 32768 runs, 0 skips
8659 UNITS in yuv2packed1, 32767 runs, 1 skips
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_vsx.c | 303 +++
1 file changed, 303 insertions(+)
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index 01eb46c..f20c11e 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale/ppc/swscale_vsx.c
@@ -422,6 +422,248 @@ yuv2NBPSX(16, BE, 1, 16, int32_t)
yuv2NBPSX(16, LE, 0, 16, int32_t)
#endif
+static av_always_inline void
+yuv2rgb_full_1_vsx_template(SwsContext *c, const int16_t *buf0,
+ const int16_t *ubuf[2], const int16_t *vbuf[2],
+ const int16_t *abuf0, uint8_t *dest, int dstW,
+ int uvalpha, int y, enum AVPixelFormat target,
+ int hasAlpha)
+{
+const int16_t *ubuf0 = ubuf[0], *vbuf0 = vbuf[0];
+const int16_t *ubuf1 = ubuf[1], *vbuf1 = vbuf[1];
+vector int16_t vy, vu, vv, A = vec_splat_s16(0), tmp16;
+vector int32_t vy32_l, vy32_r, vu32_l, vu32_r, vv32_l, vv32_r, tmp32,
tmp32_2;
+vector int32_t R_l, R_r, G_l, G_r, B_l, B_r;
+vector uint16_t rd16, gd16, bd16;
+vector uint8_t rd, bd, gd, ad, out0, out1, tmp8;
+const vector uint16_t zero16 = vec_splat_u16(0);
+const vector int32_t y_offset = vec_splats(c->yuv2rgb_y_offset);
+const vector int32_t y_coeff = vec_splats(c->yuv2rgb_y_coeff);
+const vector int32_t y_add = vec_splats(1 << 21);
+const vector int32_t v2r_coeff = vec_splats(c->yuv2rgb_v2r_coeff);
+const vector int32_t v2g_coeff = vec_splats(c->yuv2rgb_v2g_coeff);
+const vector int32_t u2g_coeff = vec_splats(c->yuv2rgb_u2g_coeff);
+const vector int32_t u2b_coeff = vec_splats(c->yuv2rgb_u2b_coeff);
+const vector int32_t rgbclip = vec_splats(1 << 30);
+const vector int32_t zero32 = vec_splat_s32(0);
+const vector uint32_t shift2 = vec_splat_u32(2);
+const vector uint32_t shift22 = vec_splats(22U);
+const vector uint16_t sub7 = vec_splats((uint16_t) (128 << 7));
+const vector uint16_t sub8 = vec_splats((uint16_t) (128 << 8));
+const vector int16_t mul4 = vec_splat_s16(4);
+const vector int16_t mul8 = vec_splat_s16(8);
+const vector int16_t add64 = vec_splat_s16(64);
+const vector uint16_t shift7 = vec_splat_u16(7);
+const vector int16_t max255 = vec_splat_s16(255);
+int i;
+
+// Various permutations
+const vector uint8_t perm3rg0 = (vector uint8_t) {0x0, 0x10, 0,
+ 0x1, 0x11, 0,
+ 0x2, 0x12, 0,
+ 0x3, 0x13, 0,
+ 0x4, 0x14, 0,
+ 0x5 };
+const vector uint8_t perm3rg1 = (vector uint8_t) { 0x15, 0,
+ 0x6, 0x16, 0,
+ 0x7, 0x17, 0 };
+const vector uint8_t perm3tb0 = (vector uint8_t) {0x0, 0x1, 0x10,
+ 0x3, 0x4, 0x11,
+ 0x6, 0x7, 0x12,
+ 0x9, 0xa, 0x13,
+ 0xc, 0xd, 0x14,
+ 0xf };
+const vector uint8_t perm3tb1 = (vector uint8_t) { 0x0, 0x15,
+ 0x2, 0x3, 0x16,
+ 0x5, 0x6, 0x17 };
+
+for (i = 0; i < dstW; i += 8) { // The x86 asm also overwrites padding
bytes.
+vy = vec_ld(0, &buf0[i]);
+vy32_l = vec_unpackh(vy);
+vy32_r = vec_unpackl(vy);
+vy32_l = vec_sl(vy32_l, shift2);
+vy32_r = vec_sl(vy32_r, shift2);
+
+vu = vec_ld(0, &ubuf0[i]);
+vv = vec_ld(0, &vbuf0[i]);
+if (uvalpha < 2048) {
+vu = (vector int16_t) vec_sub
Re: [FFmpeg-devel] [PATCH v2] avformat/westwood_aud: Adds PCM format demux.
tis 2019-03-19 klockan 22:53 + skrev Aidan R:
> @@ -69,13 +75,25 @@ static int wsaud_probe(AVProbeData *p)
> if (p->buf[10] & 0xFC)
> return 0;
>
> -if (p->buf[11] != 99 && p->buf[11] != 1)
> +/* valid format values are 99 == adpcm, 1 == snd1 and 0 == pcm */
> +if (p->buf[11] != 99 && p->buf[11] != 1 && p->buf[11] != 0)
> return 0;
>
> -/* read ahead to the first audio chunk and validate the first header
> signature */
> -if (AV_RL32(&p->buf[16]) != AUD_CHUNK_SIGNATURE)
> +/* read ahead to the first audio chunk and validate the first header
> + * signature pcm format does not use a chunk format, so don't check
Missing a period between "pcm" and "format"?
> @@ -130,20 +161,24 @@ static int wsaud_read_packet(AVFormatContext *s,
> AVPacket *pkt)
> {
> AVIOContext *pb = s->pb;
> +AUDDemuxContext *aud = s->priv_data;
> unsigned char preamble[AUD_CHUNK_PREAMBLE_SIZE];
> -unsigned int chunk_size;
> +unsigned int chunk_size, bytes_per_sample;
> int ret = 0;
> AVStream *st = s->streams[0];
>
> -if (avio_read(pb, preamble, AUD_CHUNK_PREAMBLE_SIZE) !=
> -AUD_CHUNK_PREAMBLE_SIZE)
> -return AVERROR(EIO);
> +/* AUD files don't store PCM audio in chunks */
> +if (st->codecpar->codec_id != AV_CODEC_ID_PCM_S16LE) {
What about AV_CODEC_ID_PCM_U8?
A sample + FATE test for this would be nice
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swscale/ppc: VSX-optimize yuv2rgb_full
2019-03-20 13:37 GMT+01:00, Lauri Kasanen :
> @@ -480,5 +722,66 @@ av_cold void ff_sws_init_swscale_vsx(SwsContext *c)
Are there followup patches?
Or why is the following hunk so convoluted?
> +if (c->flags & SWS_BITEXACT)
> +return;
> +#if !HAVE_BIGENDIAN
Are you planning to add big-endian support?
> +if (c->flags & SWS_FULL_CHR_H_INT) {
Iiuc, the first if above and this one can be merged.
> +switch (dstFormat) {
> +case AV_PIX_FMT_RGB24:
> +#if HAVE_POWER8
> +if (cpu_flags & AV_CPU_FLAG_POWER8) {
if (HAVE_POWER8 && cpu_flags & AV_CPU_FLAG_POWER8)
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] backport fixes for CVE-2019-9718 and CVE-2019-9721
2019-03-20 12:08 GMT+01:00, Dominik 'Rathann' Mierzejewski : > On Wednesday, 20 March 2019 at 00:48, Carl Eugen Hoyos wrote: >> 2019-03-19 23:28 GMT+01:00, Dominik 'Rathann' Mierzejewski >> : >> >> > Were the CVE IDs not known at the time these were pushed to master? >> >> No, how would this be possible? > > Easy: you can request the ID at https://cveform.mitre.org/ before > pushing the commits. (Assuming "you" are FFmpeg developers) I don't remember an FFmpeg developer requesting a CVE id. Given the number of issues related to dos or undefined behaviour that are fixed each week, this would probably be a major task. >> > Not having them in the commit log made it more difficult to find them. >> >> I thought the CVE's themselves contains the commits, no? > > They do, but looking at the commits only I wouldn't know there > were CVE IDs associated with them, so the relation is one-way > only. I would feel better if the commit log said a CVE ID was > being fixed. Unfortunately, this is not possible with the available man-power. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swscale/ppc: VSX-optimize yuv2rgb_full
On Wed, 20 Mar 2019 14:41:27 +0100
Carl Eugen Hoyos wrote:
> 2019-03-20 13:37 GMT+01:00, Lauri Kasanen :
>
> > @@ -480,5 +722,66 @@ av_cold void ff_sws_init_swscale_vsx(SwsContext *c)
>
> Are there followup patches?
> Or why is the following hunk so convoluted?
I plan to add the _2 and _X variants later. I don't know yet if they
need power8; if one doesn't, then there'd be plenty of ifdef sprinkling.
> > +if (c->flags & SWS_BITEXACT)
> > +return;
>
> > +#if !HAVE_BIGENDIAN
>
> Are you planning to add big-endian support?
No, I can only test LE.
> > +if (c->flags & SWS_FULL_CHR_H_INT) {
>
> Iiuc, the first if above and this one can be merged.
I plan to add other formats that are used without that flag.
> > +switch (dstFormat) {
> > +case AV_PIX_FMT_RGB24:
>
> > +#if HAVE_POWER8
> > +if (cpu_flags & AV_CPU_FLAG_POWER8) {
>
> if (HAVE_POWER8 && cpu_flags & AV_CPU_FLAG_POWER8)
Will do.
- Lauri
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] swscale/ppc: VSX-optimize yuv2rgb_full
./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 \
-s 1200x1440 -f null -vframes 100 -pix_fmt $i -nostats \
-cpuflags 0 -v error -
This uses 32-bit mul, so POWER8 only.
The following output formats get about 4.5x speedup:
rgb24
39980 UNITS in yuv2packed1, 32768 runs, 0 skips
8774 UNITS in yuv2packed1, 32768 runs, 0 skips
bgr24
40069 UNITS in yuv2packed1, 32768 runs, 0 skips
8772 UNITS in yuv2packed1, 32766 runs, 2 skips
rgba
39759 UNITS in yuv2packed1, 32768 runs, 0 skips
8681 UNITS in yuv2packed1, 32767 runs, 1 skips
bgra
39729 UNITS in yuv2packed1, 32768 runs, 0 skips
8696 UNITS in yuv2packed1, 32766 runs, 2 skips
argb
39766 UNITS in yuv2packed1, 32768 runs, 0 skips
8672 UNITS in yuv2packed1, 32766 runs, 2 skips
bgra
39784 UNITS in yuv2packed1, 32768 runs, 0 skips
8659 UNITS in yuv2packed1, 32767 runs, 1 skips
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_vsx.c | 291
+++ 1 file changed, 291 insertions(+)
v2: HAVE_POWER8 from ifdef to if
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index 01eb46c..062ab0d 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale/ppc/swscale_vsx.c
@@ -422,6 +422,248 @@ yuv2NBPSX(16, BE, 1, 16, int32_t)
yuv2NBPSX(16, LE, 0, 16, int32_t)
#endif
+static av_always_inline void
+yuv2rgb_full_1_vsx_template(SwsContext *c, const int16_t *buf0,
+ const int16_t *ubuf[2], const int16_t *vbuf[2],
+ const int16_t *abuf0, uint8_t *dest, int dstW,
+ int uvalpha, int y, enum AVPixelFormat target,
+ int hasAlpha)
+{
+const int16_t *ubuf0 = ubuf[0], *vbuf0 = vbuf[0];
+const int16_t *ubuf1 = ubuf[1], *vbuf1 = vbuf[1];
+vector int16_t vy, vu, vv, A = vec_splat_s16(0), tmp16;
+vector int32_t vy32_l, vy32_r, vu32_l, vu32_r, vv32_l, vv32_r,
tmp32, tmp32_2;
+vector int32_t R_l, R_r, G_l, G_r, B_l, B_r;
+vector uint16_t rd16, gd16, bd16;
+vector uint8_t rd, bd, gd, ad, out0, out1, tmp8;
+const vector uint16_t zero16 = vec_splat_u16(0);
+const vector int32_t y_offset = vec_splats(c->yuv2rgb_y_offset);
+const vector int32_t y_coeff = vec_splats(c->yuv2rgb_y_coeff);
+const vector int32_t y_add = vec_splats(1 << 21);
+const vector int32_t v2r_coeff = vec_splats(c->yuv2rgb_v2r_coeff);
+const vector int32_t v2g_coeff = vec_splats(c->yuv2rgb_v2g_coeff);
+const vector int32_t u2g_coeff = vec_splats(c->yuv2rgb_u2g_coeff);
+const vector int32_t u2b_coeff = vec_splats(c->yuv2rgb_u2b_coeff);
+const vector int32_t rgbclip = vec_splats(1 << 30);
+const vector int32_t zero32 = vec_splat_s32(0);
+const vector uint32_t shift2 = vec_splat_u32(2);
+const vector uint32_t shift22 = vec_splats(22U);
+const vector uint16_t sub7 = vec_splats((uint16_t) (128 << 7));
+const vector uint16_t sub8 = vec_splats((uint16_t) (128 << 8));
+const vector int16_t mul4 = vec_splat_s16(4);
+const vector int16_t mul8 = vec_splat_s16(8);
+const vector int16_t add64 = vec_splat_s16(64);
+const vector uint16_t shift7 = vec_splat_u16(7);
+const vector int16_t max255 = vec_splat_s16(255);
+int i;
+
+// Various permutations
+const vector uint8_t perm3rg0 = (vector uint8_t) {0x0, 0x10, 0,
+ 0x1, 0x11, 0,
+ 0x2, 0x12, 0,
+ 0x3, 0x13, 0,
+ 0x4, 0x14, 0,
+ 0x5 };
+const vector uint8_t perm3rg1 = (vector uint8_t) { 0x15, 0,
+ 0x6, 0x16, 0,
+ 0x7, 0x17, 0 };
+const vector uint8_t perm3tb0 = (vector uint8_t) {0x0, 0x1, 0x10,
+ 0x3, 0x4, 0x11,
+ 0x6, 0x7, 0x12,
+ 0x9, 0xa, 0x13,
+ 0xc, 0xd, 0x14,
+ 0xf };
+const vector uint8_t perm3tb1 = (vector uint8_t) { 0x0, 0x15,
+ 0x2, 0x3, 0x16,
+ 0x5, 0x6, 0x17 };
+
+for (i = 0; i < dstW; i += 8) { // The x86 asm also overwrites
padding bytes.
+vy = vec_ld(0, &buf0[i]);
+vy32_l = vec_unpackh(vy);
+vy32_r = vec_unpackl(vy);
+vy32_l = vec_sl(vy32_l, shift2);
+vy32_r = vec_sl(vy32_r, shift2);
+
+vu = vec_ld(0, &ubuf0[i]);
+vv = vec_ld(0, &vbuf0[i]);
+if (uvalpha < 2048) {
+
Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Add support for recognizing DNG files
On 3/20/19, Nick Renieris wrote: > Hello, > >>Similarly if we support demuxing "auxilary / secondary or what they are >> called images" and muxing then we should be able to connect these and not >> just be able to extract one image. >>Thats the ideal. The question how to implement this, or if this is the way >> to go or if this is too complex to do is up to the mentor for a GSoC >> project. >>It could be done by spliting into streams at the demuxer level, by using >> side data or decoding the images in sequence in the decoder or other ways. >> Each of these seem to have disadvanatges ... > > Ok, but what does this have to do with my patch though? Isn't > something like this possible with TIFF images too? As far as I know, > that's not supported at the moment either, I only know of -subimage > which I don't think does exactly what you mean. > > Not to mention, this patch is for preliminary support, I don't suppose > you require a massive patchset that implements everything altogether? > Besides, GSoC requirements state that I need to get a minor patch in, > before I can even apply. This is what this patch is for. > >>Here is one file that works just fine with current ffmpeg: >> https://0x0.st/z8pf.dng > > Not sure why this was mentioned? It works with my patch too. > I thought we came to an agreement, that by default it should show a > message, instructing the user to show that they can decode the > thumbnail with -subimage. > This is what my patch does. > > Nick R. > > Στις Τρί, 19 Μαρ 2019 στις 12:58 μ.μ., ο/η Paul B Mahol > έγραψε: >> >> On 3/19/19, Nick Renieris wrote: >> > Yes, obviously this is not complete. As was said, the DNG spec is huge >> > and I did bring up this concern in a personal email to Paul a few days >> > ago. >> > I was told that: >> >> 3 months should be enough to finish most of specification, note you >> >> work >> >> on real world DNG files, so if some feature from spec is not present in >> >> any file you have less work to do >> > which I absolutely agree with. >> > The context of my contribution in this case is GSoC, so let's talk >> > about that: Wouldn't it be better if by the end of GSoC, FFmpeg could >> > open all or most of the DNG files that actually exist out there, >> > instead of having only specific parts of the spec implemented >> > thoroughly? >> > >> >>A design that can only extract one image of many or one stream or one >> >> channel. Cannot preserve all information so it fails that simple use >> >> case. >> > >> >> Shouldn't, ideally, these image files be demuxed as two image streams? >> >> Perhaps with the "main" image as the first stream. >> > >> > Ideally, yes of course. >> > Realistically, I think the images with NewSubFileType != 0 and >> > NewSubFileType != 4 are of secondary interest to decode, as they are >> > commonly simply reduced resolution images of their counterparts. >> > In any case, it will probably not be hard to add once the important >> > parts are implemented. >> > >> >> Still wrong, There are DNG images without thumbnails. >> > >> > I suspected so but didn't have any examples to test with. >> > I just found one. The following happens if -subimage 1 is used: >> > >> > [tiff @ 0x7fffe4099180] DNG images are not supported >> > [tiff @ 0x7fffe4099180] Decoding embedded TIFF thumbnail in DNG image >> > [tiff @ 0x7fffe4099180] This format is not supported (bpp=14, >> > bppcount=1) >> > >> > Is this a problem? If so: >> > I'm still not done reading the spec(s), but as far as I understand it, >> > there is no way that a DNG image with NewSubFileType != 1 would be in >> > a standard TIFF format that we can decode right now. Therefore, I >> > propose a check for this in decode_frame (would also check if dng_mode >> > is enabled) to prevent the above non-user friendly error from >> > happening. >> > >> > I suspect NewSubFileType is not the right way to go though since the >> > actual image format is not specified with it. I looked at the tags >> > from some DNGs and I can't narrow it down to any other better field >> > for this. >> > >> > Any better ideas? Should I perhaps just let it succeed or fail based >> > on the existing decoding code, as it does above? The error checking in >> > that code is the absolute truth of what is actually implemented after >> > all. DNG I posted should be decodeable by default, without need for extra option(s). The subimage option is intended to decode Nth image as is stored in file. The thumbnail option should be implemented to decode only first/best thumbnail. There is way to detect them and ignore them when not that option is set. >> > >> >> I've used their libdng for a project. It's a big LGPL library >> >> implementing >> >> pretty much everything, but no distro really ships it, so it'd have to >> >> be >> >> embedded or built manually by the user. >> > >> > Definitely something to consider. Given the posted GSoC project idea, >> > I assumed it was not possible/preferable for it to be embedded. >> > _
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Tue, 19 Mar 2019, at 21:37, Martin Vignali wrote: > >+Support for the nonfree NDI protocol has been removed, it had > > been a common source of GPL violations. > > > This doesn't justify to break user tools (who respect the ffmpeg licence) tools who depend on a license violation are violating the license too... > and remove contributor's work. Sorry, but lots of contributor work were removed over the years. A software lives. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavc/qsvdec: Add VP9 decoder support
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Mark Thompson > Sent: Tuesday, March 19, 2019 8:18 AM > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] [PATCH 2/3] lavc/qsvdec: Add VP9 decoder support > > From: Zhong Li > > VP9 decoder is supported on Intel kabyLake+ platforms with MSDK Version > 1.19+ > > Signed-off-by: Zhong Li > --- > Tested on Coffee Lake. > > > Changelog | 1 + > configure | 6 ++ > libavcodec/allcodecs.c| 1 + > libavcodec/qsv.c | 5 + > libavcodec/qsvdec_other.c | 31 ++- > 5 files changed, 43 insertions(+), 1 deletion(-) > > diff --git a/Changelog b/Changelog > index 4d80e5b54f..bcb00f0a03 100644 > --- a/Changelog > +++ b/Changelog > @@ -19,6 +19,7 @@ version : > - ARBC decoder > - libaribb24 based ARIB STD-B24 caption support (profiles A and C) > - Support decoding of HEVC 4:4:4 content in nvdec and cuviddec > +- Intel libmfx VP9 decoding Yes, QSV is a marketing name which is no equal to libmfx/MSDK. But would be better to keep consistent with others, such as "Intel QSV-accelerated VP8 video decoding" in pervious changelog? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/hevcdec: decode at most one slice reporting being the first in the picture
On 18/03/2019 20:31, James Almer wrote: > Fixes deadlocks when decoding packets containing more than one of the > aforementioned > slices when using frame threads. > > Signed-off-by: James Almer > --- If there are no other comments / objections, could this be pushed? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] swscale/ppc: VSX-optimize yuv2rgb_full
2019-03-20 15:06 GMT+01:00, Lauri Kasanen :
> +case AV_PIX_FMT_BGRA:
> +if (HAVE_POWER8 && cpu_flags & AV_CPU_FLAG_POWER8) {
> +if (!c->needAlpha) {
> +c->yuv2packed1 = yuv2bgrx32_full_1_vsx;
If only non-alpha is supported, I would have expected the
exact same function to also work for AV_PIX_FMT_BGR0.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] swscale/ppc: VSX-optimize yuv2rgb_full
On Wed, 20 Mar 2019 15:51:20 +0100
Carl Eugen Hoyos wrote:
> 2019-03-20 15:06 GMT+01:00, Lauri Kasanen :
>
> > +case AV_PIX_FMT_BGRA:
> > +if (HAVE_POWER8 && cpu_flags & AV_CPU_FLAG_POWER8) {
> > +if (!c->needAlpha) {
> > +c->yuv2packed1 = yuv2bgrx32_full_1_vsx;
>
> If only non-alpha is supported, I would have expected the
> exact same function to also work for AV_PIX_FMT_BGR0.
I'll check that, and RGB0 as well. Is there an easy way to generate an
alpha test source?
- Lauri
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Add support for recognizing DNG files
Στις Τετ, 20 Μαρ 2019 στις 4:17 μ.μ., ο/η Paul B Mahol έγραψε: > DNG I posted should be decodeable by default, without need for extra > option(s). The DNG contents themselves? As in, not just the thumbnail? That's what the whole GSoC proposal is about though... What about: >On Tue, Mar 19, 2019 at 03:03:20AM +0200, Nick Renieris wrote: >Not to mention, this patch is for preliminary support, I don't suppose you >require a massive patchset that implements everything altogether? Besides, >GSoC requirements state that I need to get a minor patch in, before I can even >apply. This is what this patch is for. > The subimage option is intended to decode Nth image as is stored in file. Nth image? The option is a boolean. _If_ it was an integer though: Given what you said, for -thumbnail I would need to check for NewSubfileType's Bit0==1 and for -subimage, Bit1==1? (Here's where I'm getting my info from so that we're on the same page: https://www.awaresystems.be/imaging/tiff/tifftags/newsubfiletype.html) But it's not an integer as far as I can see, so all of the above is out of scope for this patch. > The thumbnail option should be implemented to decode only first/best > thumbnail. Sounds easy enough. > There is way to detect them and ignore them when not that option is set. Detect/ignore the thumbnails? Yes, that's easy. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: include pkgconfig path as vaapi header search
Currectly just standard header path and be found, check_type/struct will fail if vaapi is installed somewhere else. --- configure | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/configure b/configure index eaf543df96..0e3c2d24bf 100755 --- a/configure +++ b/configure @@ -6024,14 +6024,6 @@ check_type "windows.h d3d11.h" "ID3D11VideoDecoder" check_type "windows.h d3d11.h" "ID3D11VideoContext" check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602 -check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC" -check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth -check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags -check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC" -check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG" -check_type "va/va.h va/va_enc_vp8.h" "VAEncPictureParameterBufferVP8" -check_type "va/va.h va/va_enc_vp9.h" "VAEncPictureParameterBufferVP9" - check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC" if enabled cuda_sdk; then @@ -6469,6 +6461,16 @@ if enabled vaapi; then check_cpp_condition vaapi_1 "va/va.h" "VA_CHECK_VERSION(1, 0, 0)" fi +if enabled vaapi; then +check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC" +check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth +check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags +check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC" +check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG" +check_type "va/va.h va/va_enc_vp8.h" "VAEncPictureParameterBufferVP8" +check_type "va/va.h va/va_enc_vp9.h" "VAEncPictureParameterBufferVP9" +fi + if enabled_all opencl libdrm ; then check_type "CL/cl_intel.h" "clCreateImageFromFdINTEL_fn" && enable opencl_drm_beignet -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] swscale/ppc: VSX-optimize yuv2rgb_full
2019-03-20 16:06 GMT+01:00, Lauri Kasanen :
> On Wed, 20 Mar 2019 15:51:20 +0100
> Carl Eugen Hoyos wrote:
>
>> 2019-03-20 15:06 GMT+01:00, Lauri Kasanen :
>>
>> > +case AV_PIX_FMT_BGRA:
>> > +if (HAVE_POWER8 && cpu_flags & AV_CPU_FLAG_POWER8) {
>> > +if (!c->needAlpha) {
>> > +c->yuv2packed1 = yuv2bgrx32_full_1_vsx;
>>
>> If only non-alpha is supported, I would have expected the
>> exact same function to also work for AV_PIX_FMT_BGR0.
>
> I'll check that, and RGB0 as well.
> Is there an easy way to generate an alpha test source?
Samples can be found in some tickets:
https://trac.ffmpeg.org/ticket/503
https://trac.ffmpeg.org/ticket/644
But you don't need transparency to test BGR0...
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
> > >+Support for the nonfree NDI protocol has been removed, it had > > > been a common source of GPL violations. > > > > > This doesn't justify to break user tools (who respect the ffmpeg licence) > > tools who depend on a license violation are violating the license too... > FFmpeg can be compile with GPL and non free component, if the build is not redistributed. There is no licence violation in this case. It's not because some people doesn't respect the licence, that every user of non free component do the same. > > > and remove contributor's work. > > Sorry, but lots of contributor work were removed over the years. A > software lives. > We don't talk about a contribution remove for technical reason. But a contributor's work remove in order to try to annoy a licence violator. Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Martin Vignali (12019-03-20): > FFmpeg can be compile with GPL and non free component, if the build is not > redistributed. > There is no licence violation in this case. > > It's not because some people doesn't respect the licence, that every user > of non free component do the same. Making it easy to infringe can be considered acting as an accessory. FFmpeg is being an accessory to infringing its own license! Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, at 16:35, Martin Vignali wrote: > > > >+Support for the nonfree NDI protocol has been removed, it had > > > > been a common source of GPL violations. > > > > > > > This doesn't justify to break user tools (who respect the ffmpeg licence) > > > > tools who depend on a license violation are violating the license too... > > > > FFmpeg can be compile with GPL and non free component, if the build is not > redistributed. > There is no licence violation in this case. The non-free flag was done for incompatible open source license, and used for complex compiler licensing issue. Not for obviously-closed-userland libraries. > It's not because some people doesn't respect the licence, that every user > of non free component do the same. Sorry, but that ship has sailed. Complaining over and over will not change it. > > > and remove contributor's work. > > > > Sorry, but lots of contributor work were removed over the years. A > > software lives. > > We don't talk about a contribution remove for technical reason. > But a contributor's work remove in order to try to annoy a licence > violator. Absolutely not. The work was removed because the library is 100% closed source and userland. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/westwood_aud: Adds PCM format demux.
tis 2019-03-19 klockan 22:53 + skrev Aidan R:
> @@ -69,13 +75,25 @@ static int wsaud_probe(AVProbeData *p)
>> if (p->buf[10] & 0xFC)
>> return 0;
>>
>> -if (p->buf[11] != 99 && p->buf[11] != 1)
>> +/* valid format values are 99 == adpcm, 1 == snd1 and 0 == pcm */
>> +if (p->buf[11] != 99 && p->buf[11] != 1 && p->buf[11] != 0)
>> return 0;
>>
>> -/* read ahead to the first audio chunk and validate the first header
>> signature */
>> -if (AV_RL32(&p->buf[16]) != AUD_CHUNK_SIGNATURE)
>> +/* read ahead to the first audio chunk and validate the first header
>> + * signature pcm format does not use a chunk format, so don't check
>
> Missing a period between "pcm" and "format"?
Missing after signature after re-reading it myself.
>
>> @@ -130,20 +161,24 @@ static int wsaud_read_packet(AVFormatContext *s,
>> AVPacket *pkt)
>> {
>> AVIOContext *pb = s->pb;
>> +AUDDemuxContext *aud = s->priv_data;
>> unsigned char preamble[AUD_CHUNK_PREAMBLE_SIZE];
>> -unsigned int chunk_size;
>> +unsigned int chunk_size, bytes_per_sample;
>> int ret = 0;
>> AVStream *st = s->streams[0];
>>
>> -if (avio_read(pb, preamble, AUD_CHUNK_PREAMBLE_SIZE) !=
>> -AUD_CHUNK_PREAMBLE_SIZE)
>> -return AVERROR(EIO);
>> +/* AUD files don't store PCM audio in chunks */
>> +if (st->codecpar->codec_id != AV_CODEC_ID_PCM_S16LE) {
>
>What about AV_CODEC_ID_PCM_U8?
Good catch, I don't think any actually exist in the wild, but I have supported
the possibility in wsaud_read_header and from looking at the audio engine it
looks to support it in theory.
>
>A sample + FATE test for this would be nice
Some guidance on where to start for that would be most welcome. I have short
examples from Blade Runner that could be used but wouldn't distributing them
violate copyright?
--
Aidan Richmond
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/tiff: Support decoding 16bit cmyk
2019-03-09 11:08 GMT+01:00, Carl Eugen Hoyos : > Attached patch improves decoding this image, reported by Ulf Zibis: > http://samples.ffmpeg.org/image-samples/flower-separated-contig-16.tif Patch applied. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/westwood_aud: Adds PCM format demux.
ons 2019-03-20 klockan 15:56 + skrev Aidan R:
> tis 2019-03-19 klockan 22:53 + skrev Aidan R:
> > > @@ -130,20 +161,24 @@ static int wsaud_read_packet(AVFormatContext *s,
> > > AVPacket *pkt)
> > > {
> > > AVIOContext *pb = s->pb;
> > > +AUDDemuxContext *aud = s->priv_data;
> > > unsigned char preamble[AUD_CHUNK_PREAMBLE_SIZE];
> > > -unsigned int chunk_size;
> > > +unsigned int chunk_size, bytes_per_sample;
> > > int ret = 0;
> > > AVStream *st = s->streams[0];
> > >
> > > -if (avio_read(pb, preamble, AUD_CHUNK_PREAMBLE_SIZE) !=
> > > -AUD_CHUNK_PREAMBLE_SIZE)
> > > -return AVERROR(EIO);
> > > +/* AUD files don't store PCM audio in chunks */
> > > +if (st->codecpar->codec_id != AV_CODEC_ID_PCM_S16LE) {
> >
> > What about AV_CODEC_ID_PCM_U8?
>
> Good catch, I don't think any actually exist in the wild, but I have supported
> the possibility in wsaud_read_header and from looking at the audio engine it
> looks to support it in theory.
Given the recent 24-bit ZMBV discussion on this list, I think we should
not implement support for things which we don't have samples for. Using
it in the probe function is probably fine, but we should error out in
wsaud_read_header() until we have an 8-bit sample. The U8
implementation in this patch can be dummied out with #ifdefs until
then, for convenient un-#ifdefing
> >
> > A sample + FATE test for this would be nice
>
> Some guidance on where to start for that would be most welcome. I have short
> examples from Blade Runner that could be used but wouldn't distributing them
> violate copyright?
Cutting them down to a second or two should be fine I think. If we want
to be paranoid we could zero out the sample data as well, but I doubt
anyone cares. There's plenty of such samples in FATE. We could do this
in a separate thread, it doesn't have to hold up this patch
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/qtrle: Do not use aligned writes for odd addresses.
2019-03-15 1:23 GMT+01:00, Carl Eugen Hoyos : > Attached patch fixes another fate crash on 64bit sparc Patch applied. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/sdp: Change configuration pointer from char* to uint8_t*.
2019-03-16 0:11 GMT+01:00, Michael Niedermayer :
> On Fri, Mar 15, 2019 at 12:56:05AM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch silences three warnings with clang and makes the
>> pointer type equal to what the function called with the pointer
>> expects.
>>
>> Please comment, Carl Eugen
>
>> sdp.c |3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>> 9f10029889140041ba33ed19e96c3a296f2edf85
>> 0001-lavf-sdp-Change-pointer-to-configuration-from-char-t.patch
>> From cf06b8cc09acd676ac6fb713168c23342d26e1b8 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos
>> Date: Fri, 15 Mar 2019 00:52:50 +0100
>> Subject: [PATCH] lavf/sdp: Change pointer to configuration from char* to
>> uint8_t*.
>>
>> This is also what av_base64_encode() expects.
>> Fixes the following warnings with clang:
>> libavformat/sdp.c:394:40: warning: implicit conversion from 'int' to
>> 'char' changes value from 254 to -2
>> libavformat/sdp.c:395:40: warning: implicit conversion from 'int' to
>> 'char' changes value from 205 to -51
>> libavformat/sdp.c:396:40: warning: implicit conversion from 'int' to
>> 'char' changes value from 186 to -70
>> ---
>> libavformat/sdp.c |3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/sdp.c b/libavformat/sdp.c
>> index a5d202e..34e9839 100644
>> --- a/libavformat/sdp.c
>> +++ b/libavformat/sdp.c
>> @@ -347,7 +347,8 @@ static char *extradata2config(AVFormatContext *s,
>> AVCodecParameters *par)
>>
>> static char *xiph_extradata2config(AVFormatContext *s, AVCodecParameters
>> *par)
>> {
>> -char *config, *encoded_config;
>> +uint8_t *config;
>> +char *encoded_config;
>> const uint8_t *header_start[3];
>> int headers_len, header_len[3], config_len;
>> int first_header_size;
>
> LGTM
Patch applied.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] swscale/ppc: VSX-optimize yuv2rgb_full
On Wed, 20 Mar 2019 16:31:57 +0100
Carl Eugen Hoyos wrote:
> 2019-03-20 16:06 GMT+01:00, Lauri Kasanen :
> > On Wed, 20 Mar 2019 15:51:20 +0100
> > Carl Eugen Hoyos wrote:
> >
> >> 2019-03-20 15:06 GMT+01:00, Lauri Kasanen :
> >>
> >> > +case AV_PIX_FMT_BGRA:
> >> > +if (HAVE_POWER8 && cpu_flags & AV_CPU_FLAG_POWER8) {
> >> > +if (!c->needAlpha) {
> >> > +c->yuv2packed1 = yuv2bgrx32_full_1_vsx;
> >>
> >> If only non-alpha is supported, I would have expected the
> >> exact same function to also work for AV_PIX_FMT_BGR0.
> >
> > I'll check that, and RGB0 as well.
No need for changes it seems. swcale internals never see those zero
pixfmts:
libswscale/utils.c:case AV_PIX_FMT_RGB0: *format =
AV_PIX_FMT_RGBA ; return 4;
- Lauri
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/truehd_core: Initialize the last bytes of the output buffer
2019-02-14 22:44 GMT+01:00, Carl Eugen Hoyos : > New patch with AV_WN64() attached. Patch applied. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] swscale/ppc: VSX-optimize yuv2rgb_full
2019-03-20 17:24 GMT+01:00, Lauri Kasanen :
> On Wed, 20 Mar 2019 16:31:57 +0100
> Carl Eugen Hoyos wrote:
>
>> 2019-03-20 16:06 GMT+01:00, Lauri Kasanen :
>> > On Wed, 20 Mar 2019 15:51:20 +0100
>> > Carl Eugen Hoyos wrote:
>> >
>> >> 2019-03-20 15:06 GMT+01:00, Lauri Kasanen :
>> >>
>> >> > +case AV_PIX_FMT_BGRA:
>> >> > +if (HAVE_POWER8 && cpu_flags & AV_CPU_FLAG_POWER8) {
>> >> > +if (!c->needAlpha) {
>> >> > +c->yuv2packed1 = yuv2bgrx32_full_1_vsx;
>> >>
>> >> If only non-alpha is supported, I would have expected the
>> >> exact same function to also work for AV_PIX_FMT_BGR0.
>> >
>> > I'll check that, and RGB0 as well.
>
> No need for changes it seems. swcale internals never see those zero
> pixfmts:
>
> libswscale/utils.c:case AV_PIX_FMT_RGB0: *format =
> AV_PIX_FMT_RGBA ; return 4;
I wonder if this is correct in all cases but it should not make
a difference for your patch. (The formats are not identical
if the output has a transparency layer.)
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/spdifenc: Do not overwrite buffer when muxing TrueHD
2019-02-14 20:18 GMT+01:00, Carl Eugen Hoyos : > Currently, when muxing TrueHD in spdif, the buffer is always overwritten. Patch applied, this should be backported imo. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/http: Print metadata updates with loglevel verbose
2019-02-10 1:01 GMT+01:00, Carl Eugen Hoyos : > Attached patch simplifies the debugging of icy metadata, required to > answer the tickets of one regular reporter. Patch applied. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/tiff: Allow decoding of cmyka (five components)
2019-02-07 20:07 GMT+01:00, Carl Eugen Hoyos : > Attached patch fixes ticket #7675. Patch applied. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/arbc: Use AV_WB24() where applicable
2019-01-27 15:18 GMT+01:00, Carl Eugen Hoyos : > Minimal simplification attached. Patch applied. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On 20.03.2019 17:37, Jean-Baptiste Kempf wrote: On Wed, 20 Mar 2019, at 16:35, Martin Vignali wrote: [...] We don't talk about a contribution remove for technical reason. But a contributor's work remove in order to try to annoy a licence violator. Absolutely not. The work was removed because the library is 100% closed source and userland. when do you plan to remove nVidia and BlackmagicDesign parts that is /closed source and userland/ ? -- Maksym Veremeyenko ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf:Constify AVOutputFormat pointer
2019-02-09 15:46 GMT+01:00, Carl Eugen Hoyos :
> 2019-02-09 15:44 GMT+01:00, Carl Eugen Hoyos :
>> 2019-02-09 15:42 GMT+01:00, James Almer :
>>> On 2/9/2019 11:23 AM, Carl Eugen Hoyos wrote:
Hi!
Attached patch is supposed to constify all occurrences of
AVOutputFormat in libavformat.
Please comment, Carl Eugen
0001-lavf-Constify-AVOutputFormat-pointer.patch
From ba32f41824df07b7a6cb45964ef912c5fc05b276 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sat, 9 Feb 2019 15:21:17 +0100
Subject: [PATCH] lavf: Constify AVOutputFormat pointer.
---
libavformat/allformats.c |4
libavformat/avformat.h | 15 ++-
libavformat/fifo.c |4 ++--
libavformat/format.c |6 +++---
libavformat/hdsenc.c |2 +-
libavformat/hlsenc.c |4 ++--
libavformat/mux.c|4 ++--
libavformat/rtp.c|2 +-
libavformat/rtpenc_chain.c |2 +-
libavformat/rtpenc_mpegts.c |4 ++--
libavformat/segment.c|2 +-
libavformat/smoothstreamingenc.c |2 +-
libavformat/version.h|3 +++
libavformat/webm_chunk.c |2 +-
14 files changed, 34 insertions(+), 22 deletions(-)
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0684498..64d0f02 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -595,7 +595,11 @@ AVOutputFormat *av_oformat_next(const
AVOutputFormat
*f)
ff_thread_once(&av_format_next_init, av_format_init_next);
if (f)
+#if FF_API_AVIOFORMAT
+return (AVOutputFormat *) f->next;
+#else
return f->next;
+#endif
else {
void *opaque = NULL;
return (AVOutputFormat *)av_muxer_iterate(&opaque);
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index fdaffa5..52922c0 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -532,7 +532,12 @@ typedef struct AVOutputFormat {
* New public fields should be added right above.
*
*/
-struct AVOutputFormat *next;
+#if FF_API_AVIOFORMAT
+#define av_const59 const
+#else
+#define av_const59
+#endif
>>>
>>> Shouldn't it be the other way around? FF_API_AVIOFORMAT
>>> evaluates to 1 when major is < 59.
>>
>> Yes, I had realized this in the meantime, new patch attached.
>
> And with the correct version in version.h
Patch applied with "ff_const59".
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] backport fixes for CVE-2019-9718 and CVE-2019-9721
On Tue, Mar 19, 2019 at 11:28:01PM +0100, Dominik 'Rathann' Mierzejewski wrote: > Hello, > please backport fixes for CVE-2019-9718 and CVE-2019-9721 to 3.4 > and 4.0 branches. The relevant commits seem to be: > 1f00c97bc3475c477f3c468cf2d924d5761d0982 > 894995c41e0795c7a44f81adc4838dedc3932e65 > > Thanks in advance. these will be backported with the next point releases from these branches Ill try to do these releases rather sooner than later > > Were the CVE IDs not known at the time these were pushed to master? I am pretty sure they where not known because if they where they would have been included. > Not having them in the commit log made it more difficult to find them. > > 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 > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf:Constify AVOutputFormat pointer
On 3/20/2019 2:41 PM, Carl Eugen Hoyos wrote:
> 2019-02-09 15:46 GMT+01:00, Carl Eugen Hoyos :
>> 2019-02-09 15:44 GMT+01:00, Carl Eugen Hoyos :
>>> 2019-02-09 15:42 GMT+01:00, James Almer :
On 2/9/2019 11:23 AM, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch is supposed to constify all occurrences of
> AVOutputFormat in libavformat.
>
> Please comment, Carl Eugen
>
>
> 0001-lavf-Constify-AVOutputFormat-pointer.patch
>
> From ba32f41824df07b7a6cb45964ef912c5fc05b276 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Sat, 9 Feb 2019 15:21:17 +0100
> Subject: [PATCH] lavf: Constify AVOutputFormat pointer.
>
> ---
> libavformat/allformats.c |4
> libavformat/avformat.h | 15 ++-
> libavformat/fifo.c |4 ++--
> libavformat/format.c |6 +++---
> libavformat/hdsenc.c |2 +-
> libavformat/hlsenc.c |4 ++--
> libavformat/mux.c|4 ++--
> libavformat/rtp.c|2 +-
> libavformat/rtpenc_chain.c |2 +-
> libavformat/rtpenc_mpegts.c |4 ++--
> libavformat/segment.c|2 +-
> libavformat/smoothstreamingenc.c |2 +-
> libavformat/version.h|3 +++
> libavformat/webm_chunk.c |2 +-
> 14 files changed, 34 insertions(+), 22 deletions(-)
>
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 0684498..64d0f02 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -595,7 +595,11 @@ AVOutputFormat *av_oformat_next(const
> AVOutputFormat
> *f)
> ff_thread_once(&av_format_next_init, av_format_init_next);
>
> if (f)
> +#if FF_API_AVIOFORMAT
> +return (AVOutputFormat *) f->next;
> +#else
> return f->next;
> +#endif
> else {
> void *opaque = NULL;
> return (AVOutputFormat *)av_muxer_iterate(&opaque);
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index fdaffa5..52922c0 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -532,7 +532,12 @@ typedef struct AVOutputFormat {
> * New public fields should be added right above.
> *
> */
> -struct AVOutputFormat *next;
> +#if FF_API_AVIOFORMAT
> +#define av_const59 const
> +#else
> +#define av_const59
> +#endif
Shouldn't it be the other way around? FF_API_AVIOFORMAT
evaluates to 1 when major is < 59.
>>>
>>> Yes, I had realized this in the meantime, new patch attached.
>>
>> And with the correct version in version.h
>
> Patch applied with "ff_const59".
>
> Carl Eugen
Could you add a comment stating that, much like the FF_API_ defines,
this ff_const59 define is not part of the public API and will eventually
disappear without warning?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf:Constify AVOutputFormat pointer
2019-03-20 18:50 GMT+01:00, James Almer : > Could you add a comment stating that, much like the FF_API_ defines, > this ff_const59 define is not part of the public API and will eventually > disappear without warning? Done. Thank you for the suggestion, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf:Constify AVInputFormat pointer
2019-02-09 15:51 GMT+01:00, Carl Eugen Hoyos :
> 2019-02-09 14:37 GMT+01:00, Carl Eugen Hoyos :
>> 2019-02-01 1:13 GMT+01:00, Michael Niedermayer :
>>> On Thu, Jan 31, 2019 at 09:54:14PM +0100, Carl Eugen Hoyos wrote:
2019-01-31 21:43 GMT+01:00, Carl Eugen Hoyos :
> Hi!
>
> Attached patch persistently uses "const" for AVInputFormat pointer
> after the next version bump.
Now with an actually working version.
Please comment, Carl Eugen
>>>
allformats.c |6 +-
avformat.h | 32 +++-
dashdec.c|3 +++
format.c | 32 ++--
hls.c|3 +++
img2dec.c|2 +-
mpeg.c |3 +++
rtpdec_asf.c |3 +++
sapdec.c |3 +++
utils.c | 11 ---
version.h|3 +++
11 files changed, 93 insertions(+), 8 deletions(-)
d3aece2f0b9a9c3ff8b2a187ceccdc744ea40de2
0001-lavf-Constify-AVInputFormat-pointer.patch
From f383a7f914b2c7240378b404d529a7d73c68941b Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 31 Jan 2019 21:51:56 +0100
Subject: [PATCH] lavf: Constify AVInputFormat pointer.
---
libavformat/allformats.c |6 +-
libavformat/avformat.h | 32 +++-
libavformat/dashdec.c|3 +++
libavformat/format.c | 32 ++--
libavformat/hls.c|3 +++
libavformat/img2dec.c|2 +-
libavformat/mpeg.c |3 +++
libavformat/rtpdec_asf.c |3 +++
libavformat/sapdec.c |3 +++
libavformat/utils.c | 11 ---
libavformat/version.h|3 +++
11 files changed, 93 insertions(+), 8 deletions(-)
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0684498..01c4c14 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -583,7 +583,11 @@ AVInputFormat *av_iformat_next(const AVInputFormat
*f)
ff_thread_once(&av_format_next_init, av_format_init_next);
if (f)
-return f->next;
+return
+#if !FF_API_AVINPUTFORMAT
+ (AVInputFormat *)
+#endif
+ f->next;
else {
void *opaque = NULL;
return (AVInputFormat *)av_demuxer_iterate(&opaque);
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index fdaffa5..7c4ec8f 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -676,7 +676,10 @@ typedef struct AVInputFormat {
* New public fields should be added right above.
*
*/
-struct AVInputFormat *next;
+#if !FF_API_AVINPUTFORMAT
+const
+#endif
+struct AVInputFormat *next;
>>>
>>> some av_const59 which is defined to nothing until version 59
>>> should avoid the repeated #if/endif
>>> it would require an eventual update to change it to const at some
>>> point but it would avoid most preprocessor comands
>>
>> New patch attached.
>
> Now with correct condition.
Patch applied.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf:Constify AVProbeData* in av_probe_input_format()
2019-02-09 23:27 GMT+01:00, Carl Eugen Hoyos : > 2019-02-09 23:26 GMT+01:00, Carl Eugen Hoyos : >> Attached patch constifies a few pointers at the next version bump. > > And the patch. Patch applied. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] backport fixes for CVE-2019-9718 and CVE-2019-9721
On Wed, Mar 20, 2019 at 12:08:52PM +0100, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 20 March 2019 at 00:48, Carl Eugen Hoyos wrote: > > 2019-03-19 23:28 GMT+01:00, Dominik 'Rathann' Mierzejewski > > : > > > > > Were the CVE IDs not known at the time these were pushed to master? > > > > No, how would this be possible? > > Easy: you can request the ID at https://cveform.mitre.org/ before > pushing the commits. do you want to do that ? In general patches are posted to the mailing list so you could if you want. There are probably about 1-2 "Timeout" fixes similar to these a day currently. Most of these are security issues in the sense of making denial of service easier, they do not change black to white. Its not so much that i dont have the time to request 1-2 CVE# a day, its more that iam not sure this is really helpfull to our users. Thanks > > > > Not having them in the commit log made it more difficult to find them. > > > > I thought the CVE's themselves contains the commits, no? > > They do, but looking at the commits only I wouldn't know there were CVE > IDs associated with them, so the relation is one-way only. I would feel > better if the commit log said a CVE ID was being fixed. > > 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 > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf:Constify AVInputFormat pointer
On Wed, Mar 20, 2019, at 9:58 AM, Carl Eugen Hoyos wrote: > > Patch applied. > Breaks compilation for me on x86_64 linux: /usr/bin/ld: libavformat/libavformat.a(allformats.o):(.data.rel.ro+0x398): undefined reference to `ff_kux_demuxer' collect2: error: ld returned 1 exit status make: *** [Makefile:108: ffmpeg_g] Error 1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: On Wed, 20 Mar 2019, at 16:35, Martin Vignali wrote: > > >+Support for the nonfree NDI protocol has been removed, it had > > > been a common source of GPL violations. > > > > > This doesn't justify to break user tools (who respect the ffmpeg licence) > > tools who depend on a license violation are violating the license too... > FFmpeg can be compile with GPL and non free component, if the build is not redistributed. There is no licence violation in this case. The non-free flag was done for incompatible open source license, and used for complex compiler licensing issue. Not for obviously-closed-userland libraries. It's not because some people doesn't respect the licence, that every user of non free component do the same. Sorry, but that ship has sailed. Complaining over and over will not change it. > > and remove contributor's work. > > Sorry, but lots of contributor work were removed over the years. A > software lives. We don't talk about a contribution remove for technical reason. But a contributor's work remove in order to try to annoy a licence violator. Absolutely not. The work was removed because the library is 100% closed source and userland. Then I suggest to put that into the news entry instead. As I described in similar threads before, whether or not the project want closed source support for NDI is a subjective issue, please start a vote about the removal of libndi if you want to seek this through. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] swscale/ppc: VSX-optimize yuv2rgb_full
On Wed, Mar 20, 2019 at 04:06:45PM +0200, Lauri Kasanen wrote:
> ./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 \
> -s 1200x1440 -f null -vframes 100 -pix_fmt $i -nostats \
> -cpuflags 0 -v error -
>
> This uses 32-bit mul, so POWER8 only.
>
> The following output formats get about 4.5x speedup:
>
> rgb24
> 39980 UNITS in yuv2packed1, 32768 runs, 0 skips
>8774 UNITS in yuv2packed1, 32768 runs, 0 skips
> bgr24
> 40069 UNITS in yuv2packed1, 32768 runs, 0 skips
>8772 UNITS in yuv2packed1, 32766 runs, 2 skips
> rgba
> 39759 UNITS in yuv2packed1, 32768 runs, 0 skips
>8681 UNITS in yuv2packed1, 32767 runs, 1 skips
> bgra
> 39729 UNITS in yuv2packed1, 32768 runs, 0 skips
>8696 UNITS in yuv2packed1, 32766 runs, 2 skips
> argb
> 39766 UNITS in yuv2packed1, 32768 runs, 0 skips
>8672 UNITS in yuv2packed1, 32766 runs, 2 skips
> bgra
> 39784 UNITS in yuv2packed1, 32768 runs, 0 skips
>8659 UNITS in yuv2packed1, 32767 runs, 1 skips
>
> Signed-off-by: Lauri Kasanen
> ---
> libswscale/ppc/swscale_vsx.c | 291
> +++ 1 file changed, 291 insertions(+)
>
> v2: HAVE_POWER8 from ifdef to if
>
> diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
> index 01eb46c..062ab0d 100644
> --- a/libswscale/ppc/swscale_vsx.c
> +++ b/libswscale/ppc/swscale_vsx.c
> @@ -422,6 +422,248 @@ yuv2NBPSX(16, BE, 1, 16, int32_t)
> yuv2NBPSX(16, LE, 0, 16, int32_t)
> #endif
>
> +static av_always_inline void
> +yuv2rgb_full_1_vsx_template(SwsContext *c, const int16_t *buf0,
> + const int16_t *ubuf[2], const int16_t *vbuf[2],
> + const int16_t *abuf0, uint8_t *dest, int dstW,
> + int uvalpha, int y, enum AVPixelFormat target,
> + int hasAlpha)
> +{
> +const int16_t *ubuf0 = ubuf[0], *vbuf0 = vbuf[0];
> +const int16_t *ubuf1 = ubuf[1], *vbuf1 = vbuf[1];
> +vector int16_t vy, vu, vv, A = vec_splat_s16(0), tmp16;
> +vector int32_t vy32_l, vy32_r, vu32_l, vu32_r, vv32_l, vv32_r,
> tmp32, tmp32_2;
> +vector int32_t R_l, R_r, G_l, G_r, B_l, B_r;
error: corrupt patch at line 26
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Maksym Veremeyenko (12019-03-20): > when do you plan to remove nVidia and BlackmagicDesign parts that is /closed > source and userland/ ? "They were talking too" is not a good strategy when the teacher tells you to be quiet. But I count you as one vote for removing any non-free components. Thanks. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/arbc: Check nb_segments before allocating and copying frame
On Thu, Mar 14, 2019 at 12:03:17AM +0100, Michael Niedermayer wrote: > Fixes: Timeout (30sec -> 2sec) > Fixes: > 13578/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ARBC_fuzzer-5685625527730176 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/arbc.c | 15 +-- > 1 file changed, 9 insertions(+), 6 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Whats the most studid thing your enemy could do ? Blow himself up Whats the most studid thing you could do ? Give up your rights and freedom because your enemy blew himself up. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/scpr: Perform frame copy later
On Fri, Mar 15, 2019 at 01:30:12AM +0100, Michael Niedermayer wrote: > Optimization found while looking at > 13442/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SCPR_fuzzer-5758293933293568 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/scpr.c | 8 > libavcodec/scpr3.c | 4 > 2 files changed, 8 insertions(+), 4 deletions(-) will apply patchset [...] -- 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: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavd/v4l2: Return FFERROR_REDO when receiving a frame of unexpected size
I had found that when capturing video for some hours from USB Camera-B4.09.24.1 (Manufacturer: OmniVision Technologies, Inc.), sometimes when invoking the ioctl DQBUF, the returned buffer is not filled with the size we expect for the raw video frame. Here are two examples for such occurrences: [video4linux2,v4l2 @ 0x258b440] Dequeued v4l2 buffer contains 609596 bytes, but 614400 were expected. Flags: 0x0001. /dev/video1: Invalid data found when processing input [video4linux2,v4l2 @ 0x225f440] Dequeued v4l2 buffer contains 609508 bytes, but 614400 were expected. Flags: 0x0001. /dev/video1: Invalid data found when processing input The ffmpeg CLI tool will then stop capturing and exit. To avoid this, return FFERROR_REDO instead. I have not seen the issue appearing twice or more often in a row. It was more like one single error every two hours. While searching for the above quoted error message I found a ticket that mentions this type of problem on our tracker. Fixes #4795 --- libavdevice/v4l2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c index 1b9c6e7..5a1b324 100644 --- a/libavdevice/v4l2.c +++ b/libavdevice/v4l2.c @@ -542,7 +542,7 @@ static int mmap_read_frame(AVFormatContext *ctx, AVPacket *pkt) "Dequeued v4l2 buffer contains %d bytes, but %d were expected. Flags: 0x%08X.\n", buf.bytesused, s->frame_size, buf.flags); enqueue_buffer(s, &buf); -return AVERROR_INVALIDDATA; +return FFERROR_REDO; } } -- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavdevice/v4l2: Return EAGAIN when receiving a frame of unexpected size
On 2019-03-18 23:26 +0100, Alexander Strasser wrote: > On 2019-03-18 00:24 +0100, Nicolas George wrote: > > Alexander Strasser (12019-03-18): > > > I tested the EAGAIN version and it worked. I also tested returning a > > > > ffmpeg.c uses the non-blocking mode. > > That would explain it. I now tested, the FFERROR_REDO approach, > and I think it works fine. As I don't have it available anymore, > I can't test with the device that gave me the errors. So I modified > the code to create the error condition. > > Using FFERROR_REDO would work for blocking mode as well as non-blocking, > right? > > It handles the error on a lower level inside the libs and doesn't > bubble up to the lib user AFAICT. > > > > > zero-sized packet, like in the case where V4L flags the data as corrupt, > > > that worked too. See commit 28f20d2ff487aa589643d8f70eaf614b78839685 > > > > > > Do you think the zero-sized packet would be better than returning > > > FFERROR_REDO? > > > > I think it depends on what happens exactly with that frame? What is the > > partial packet returned? Is there a timestamp? Etc. > > As mentioned above I can't dump more data to get a clue. I guess > the frame was just truncated and the timestamps were correct. > > As we wouldn't pass on frame data to the user anyway, I would actually > prefer the FFERROR_REDO version. I sent a new patch changing the returned error code to FFERROR_REDO. This patch can be considered rejected. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/westwood_aud: Adds PCM format demux.
On Tue, Mar 19, 2019 at 10:53:11PM +, Aidan R wrote:
> PCM format AUD files are found in Westwood's Blade Runner game.
> ---
> libavformat/westwood_aud.c | 83
> --
> 1 file changed, 66 insertions(+), 17 deletions(-)
>
> diff --git a/libavformat/westwood_aud.c b/libavformat/westwood_aud.c
> index 9c2d35cb8a..b25d299bf0 100644
> --- a/libavformat/westwood_aud.c
> +++ b/libavformat/westwood_aud.c
> @@ -41,6 +41,12 @@
> #define AUD_HEADER_SIZE 12
> #define AUD_CHUNK_PREAMBLE_SIZE 8
> #define AUD_CHUNK_SIGNATURE 0xDEAF
> +#define AUD_PCM_CHUNK_SIZE 2048 /* arbitrary size to pull out of PCM data*/
> +
> +typedef struct AUDDemuxContext {
> +int size;
> +int pos;
> +} AUDDemuxContext;
>
> static int wsaud_probe(AVProbeData *p)
> {
> @@ -50,10 +56,10 @@ static int wsaud_probe(AVProbeData *p)
> * so perform sanity checks on various header parameters:
> * 8000 <= sample rate (16 bits) <= 48000 ==> 40001 acceptable numbers
> * flags <= 0x03 (2 LSBs are used) ==> 4 acceptable numbers
> - * compression type (8 bits) = 1 or 99 ==> 2 acceptable numbers
> + * compression type (8 bits) = 0, 1 or 99 ==> 3 acceptable numbers
> * first audio chunk signature (32 bits) ==> 1 acceptable number
> - * The number space contains 2^64 numbers. There are 40001 * 4 * 2 * 1 =
> - * 320008 acceptable number combinations.
> + * The number space contains 2^64 numbers. There are 40001 * 4 * 3 * 1 =
> + * 480012 acceptable number combinations.
> */
>
> if (p->buf_size < AUD_HEADER_SIZE + AUD_CHUNK_PREAMBLE_SIZE)
> @@ -69,13 +75,25 @@ static int wsaud_probe(AVProbeData *p)
> if (p->buf[10] & 0xFC)
> return 0;
>
> -if (p->buf[11] != 99 && p->buf[11] != 1)
> +/* valid format values are 99 == adpcm, 1 == snd1 and 0 == pcm */
> +if (p->buf[11] != 99 && p->buf[11] != 1 && p->buf[11] != 0)
> return 0;
>
> -/* read ahead to the first audio chunk and validate the first header
> signature */
> -if (AV_RL32(&p->buf[16]) != AUD_CHUNK_SIGNATURE)
> +/* read ahead to the first audio chunk and validate the first header
> + * signature pcm format does not use a chunk format, so don't check
> + * for that codec */
> +if (p->buf[11] != 0 && AV_RL32(&p->buf[16]) != AUD_CHUNK_SIGNATURE)
> return 0;
>
> +/* if we have pcm format then compressed size should equal
> + * uncompressed size */
> +if (p->buf[11] == 0) {
> +if (AV_RL32(&p->buf[2]) != AV_RL32(&p->buf[6]))
> +return 0;
> +if (AV_RL32(&p->buf[2]) + AUD_HEADER_SIZE < p->buf_size)
> +return 0;
> +}
> +
> /* return 1/2 certainty since this file check is a little sketchy */
> return AVPROBE_SCORE_EXTENSION;
> }
fails probetest:
tools/probetest 256 4096
testing size=1
testing size=2
testing size=4
testing size=8
testing size=16
testing size=32
Failure of wsaud probing code with score=50 type=3 p=2D8 size=32
testing size=64
testing size=128
testing size=256
testing size=512
testing size=1024
testing size=2048
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, at 18:03, Maksym Veremeyenko wrote: > On 20.03.2019 17:37, Jean-Baptiste Kempf wrote: > > On Wed, 20 Mar 2019, at 16:35, Martin Vignali wrote: > [...] > >> We don't talk about a contribution remove for technical reason. > >> But a contributor's work remove in order to try to annoy a licence > >> violator. > > > > Absolutely not. The work was removed because the library is 100% closed > > source and userland. > > when do you plan to remove nVidia and BlackmagicDesign parts that is > /closed source and userland/ ? 0) addressing me directly like that is unfair, and unjust; notably when NDI was not removed by me. But let's say that this is just a miscommunication, and not a personal attack; so I will try to do a summary about those issues. 1) First, I've been quite vocal on those 2 topics, in the last few weeks, including today, about those 2, on IRC. And I've talked to the maintainers of those parts, notably Philip. 2) Both of those are addressing drivers for actual cards. So we're not talking about userland, but accessing drivers which are part of the OS, and are therefore exempted by the GPL. This is the case for both nVidia and Decklink. Not NDI. So, your point about userland does not really stand. 3) Both of those have headers that are open source. Not NDI. 3a) nVidia headers have a repository, that is actually maintained by people from this very project. The question about non-free on nVidia is about the compiler nvcc that is not open source. There is currently no-consensus whether this compiler is covered by the GPL exemption: are we in a similar case than java before openjdk, or the GNU project before gcc was created? 3b) Decklink headers are open source, but are normally distributed in a package that is not open-source. Whether the license of the headers is stronger than the package license is not clear. It is also not clear if someone who agreed to the package license can redistribute those headers to the other people? Best, -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: > As I described in similar threads before, whether or not the project want > closed source support for NDI is a subjective issue, please start a vote > about the removal of libndi if you want to seek this through. The removal of libndi is actually done and committed. So I would suggest you start a vote to get the inclusion of libndi instead. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: As I described in similar threads before, whether or not the project want closed source support for NDI is a subjective issue, please start a vote about the removal of libndi if you want to seek this through. The removal of libndi is actually done and committed. That is just sad an unfair. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Marton Balint (12019-03-20): > That is just sad an unfair. Maybe. But let us be very clear about this: the people to blame for this mess are those who chose a proprietary license for their library in the first place. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: > On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: > >> As I described in similar threads before, whether or not the project want > >> closed source support for NDI is a subjective issue, please start a vote > >> about the removal of libndi if you want to seek this through. > > > > The removal of libndi is actually done and committed. > > That is just sad an unfair. Sad, maybe. Unfair, I disagree. If NDI wants to be in, they know what to do. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: >> As I described in similar threads before, whether or not the project want >> closed source support for NDI is a subjective issue, please start a vote >> about the removal of libndi if you want to seek this through. > > The removal of libndi is actually done and committed. That is just sad an unfair. Sad, maybe. Unfair, I disagree. If NDI wants to be in, they know what to do. It is unfair towards the people who expressied disapproval, yet this change was committed without neither vote nor consensus. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On 21-03-2019 01:32 AM, Marton Balint wrote: On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: >> As I described in similar threads before, whether or not the project want >> closed source support for NDI is a subjective issue, please start a vote >> about the removal of libndi if you want to seek this through. > > The removal of libndi is actually done and committed. That is just sad an unfair. Sad, maybe. Unfair, I disagree. If NDI wants to be in, they know what to do. It is unfair towards the people who expressied disapproval, yet this change was committed without neither vote nor consensus. +1. This was a political decision, not a technical one. A formal(-ish) survey should have happened on the ML. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, at 21:02, Marton Balint wrote: > On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: > >> On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > >> > >> > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: > >> >> As I described in similar threads before, whether or not the project > >> >> want > >> >> closed source support for NDI is a subjective issue, please start a > >> >> vote > >> >> about the removal of libndi if you want to seek this through. > >> > > >> > The removal of libndi is actually done and committed. > >> > >> That is just sad an unfair. > > > > Sad, maybe. > > Unfair, I disagree. If NDI wants to be in, they know what to do. > > It is unfair towards the people who expressied disapproval, yet this > change was committed without neither vote nor consensus. Sorry, from my understanding, the majority is for removal. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Jean-Baptiste Kempf (12019-03-20): > 2) Both of those are addressing drivers for actual cards. > So we're not talking about userland, but accessing drivers which are > part of the OS, and are therefore exempted by the GPL. I am not sure I agree with that interpretation. The wording is quite obscure, even for legalese, but the way I understand it, a library is a system library if, when somebody uses that particular operating system, we can be sure they have that library. It is not relevant for drivers, because drivers are not called directly, they are called by the kernel, and applications only call standard kernel interfaces. If some piece of hardware requires a library to be used, that library is not really a driver, and it does not count as a system library. That is my interpretation. Furthermore, the wording makes the case of system libraries an exception to the general rune, and AFAIK, in legal documents, exceptions are supposed to be interpreted in a very narrow way. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019 at 23:02, Marton Balint wrote: > > > On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > > On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: > >> On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > >> > >> > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: > >> >> As I described in similar threads before, whether or not the project > want > >> >> closed source support for NDI is a subjective issue, please start a > vote > >> >> about the removal of libndi if you want to seek this through. > >> > > >> > The removal of libndi is actually done and committed. > >> > >> That is just sad an unfair. > > > > Sad, maybe. > > Unfair, I disagree. If NDI wants to be in, they know what to do. > > It is unfair towards the people who expressied disapproval, yet this > change was committed without neither vote nor consensus. > > Regards, > Marton > > > At the very best, the lack of consensus on this implies vindictive intent. Is there something that the FFmpeg developers (see below) have against Newtek, as a company? Clearly, they took down the offending FFmpeg build: https://trac.ffmpeg.org/ticket/7589?cversion=0&cnum_hist=10 We've seen other violations, such as this one by Amazon: https://trac.ffmpeg.org/ticket/7214 that were handled in a much more graceful manner. The primary agitator here seems to be kierank: https://trac.ffmpeg.org/ticket/7589?cversion=0&cnum_hist=10#comment:5 What undisclosed history do you have with Newtek (see the reference to "Andrew") above that isn't disclosed above? Secondly, you're quite influential in the broadcast industry: https://www.obe.tv/author/obe/ There's an aura of hostility around this commit, and whatever that is seems to have spilled over into this. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, at 21:20, Nicolas George wrote: > Jean-Baptiste Kempf (12019-03-20): > > 2) Both of those are addressing drivers for actual cards. > > So we're not talking about userland, but accessing drivers which are > > part of the OS, and are therefore exempted by the GPL. > > I am not sure I agree with that interpretation. The wording is quite > [...] > It is not relevant for drivers, because drivers are not called directly, > [...] > That is my interpretation. Furthermore, the wording makes the case of This is the current interpretation by most people from the FSF and people from the open source legal community: "drivers and libraries installed usually with the drivers" are covered by the GPL exception. I checked last time with Bradley and Karen, but I can re-check next time I talk to them, if you do wish. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, at 21:20, Dennis Mungai wrote: > At the very best, the lack of consensus on this implies vindictive intent. > Is there something that the FFmpeg developers (see below) have against > Newtek, as a company? > Clearly, they took down the offending FFmpeg build: > https://trac.ffmpeg.org/ticket/7589?cversion=0&cnum_hist=10 That does not make the library NDI open-source or free... > We've seen other violations, such as this one by Amazon: > https://trac.ffmpeg.org/ticket/7214 that were handled in a much more > graceful manner. Amazon does not have a library inside FFMpeg that profits from the FFmpeg project. > The primary agitator here seems to be kierank: > > What undisclosed history do you have with Newtek (see the reference to > "Andrew") above that isn't disclosed above? > Secondly, you're quite influential in the broadcast industry: > https://www.obe.tv/author/obe/ Please refrain from ad hominem attacks. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/v4l2: Return FFERROR_REDO when receiving a frame of unexpected size
Hi all! On 2019-03-20 19:56 +0100, Alexander Strasser wrote: > I had found that when capturing video for some hours from > USB Camera-B4.09.24.1 (Manufacturer: OmniVision Technologies, Inc.), > sometimes when invoking the ioctl DQBUF, the returned buffer is not > filled with the size we expect for the raw video frame. > > Here are two examples for such occurrences: > > [video4linux2,v4l2 @ 0x258b440] Dequeued v4l2 buffer contains 609596 > bytes, but 614400 were expected. Flags: 0x0001. > /dev/video1: Invalid data found when processing input > > [video4linux2,v4l2 @ 0x225f440] Dequeued v4l2 buffer contains 609508 > bytes, but 614400 were expected. Flags: 0x0001. > /dev/video1: Invalid data found when processing input > > The ffmpeg CLI tool will then stop capturing and exit. > > To avoid this, return FFERROR_REDO instead. I have not seen the > issue appearing twice or more often in a row. It was more like > one single error every two hours. After thinking about the FFERROR_REDO approach some more, I think it is not ideal in the case where a driver permanently delivers frames of unexpected size. The FFmpeg lib call would not return to the client, potentially freezing the running program. So maybe the zero-sized package approach, like we do with the corrupted frames, is more robust here? Any opinions? Best regards, Alexander > > While searching for the above quoted error message I found a ticket > that mentions this type of problem on our tracker. > > Fixes #4795 > --- > libavdevice/v4l2.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c > index 1b9c6e7..5a1b324 100644 > --- a/libavdevice/v4l2.c > +++ b/libavdevice/v4l2.c > @@ -542,7 +542,7 @@ static int mmap_read_frame(AVFormatContext *ctx, AVPacket > *pkt) > "Dequeued v4l2 buffer contains %d bytes, but %d were > expected. Flags: 0x%08X.\n", > buf.bytesused, s->frame_size, buf.flags); > enqueue_buffer(s, &buf); > -return AVERROR_INVALIDDATA; > +return FFERROR_REDO; > } > } > > -- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] backport fixes for CVE-2019-9718 and CVE-2019-9721
On Wednesday, 20 March 2019 at 18:42, Michael Niedermayer wrote: > On Tue, Mar 19, 2019 at 11:28:01PM +0100, Dominik 'Rathann' Mierzejewski > wrote: > > Hello, > > please backport fixes for CVE-2019-9718 and CVE-2019-9721 to 3.4 > > and 4.0 branches. The relevant commits seem to be: > > 1f00c97bc3475c477f3c468cf2d924d5761d0982 > > 894995c41e0795c7a44f81adc4838dedc3932e65 > > > > Thanks in advance. > > these will be backported with the next point releases from these branches > > Ill try to do these releases rather sooner than later Thank you. We've backported them downstream (in RPM Fusion), so there's no rush from our point of view. We'll drop the downstream patches when rebasing to the next release. > > Were the CVE IDs not known at the time these were pushed to master? > > I am pretty sure they where not known because if they where they would > have been included. That's what I thought. 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 https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] backport fixes for CVE-2019-9718 and CVE-2019-9721
On Wednesday, 20 March 2019 at 19:18, Michael Niedermayer wrote: > On Wed, Mar 20, 2019 at 12:08:52PM +0100, Dominik 'Rathann' Mierzejewski > wrote: > > On Wednesday, 20 March 2019 at 00:48, Carl Eugen Hoyos wrote: > > > 2019-03-19 23:28 GMT+01:00, Dominik 'Rathann' Mierzejewski > > > : > > > > > > > Were the CVE IDs not known at the time these were pushed to master? > > > > > > No, how would this be possible? > > > > Easy: you can request the ID at https://cveform.mitre.org/ before > > pushing the commits. > > do you want to do that ? > In general patches are posted to the mailing list so you could if > you want. > There are probably about 1-2 "Timeout" fixes similar to these a day > currently. Most of these are security issues in the sense of making denial > of service easier, they do not change black to white. > > Its not so much that i dont have the time to request 1-2 CVE# a day, its > more that iam not sure this is really helpfull to our users. Understood. Reading https://cve.mitre.org/cve/request_id.html it looks like a project (like FFmpeg) could request a range of CVE IDs in advance and assign them on their own, without asking Mitre for each and every one of them. But, I'm not volunteering for that (I would if I had time). Thanks for the responses. 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 https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Hi, On Wed, Mar 20, 2019 at 4:15 PM Gyan wrote: > > > On 21-03-2019 01:32 AM, Marton Balint wrote: > > > > > > On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > > >> On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: > >>> On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > >>> > >>> > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: > >>> >> As I described in similar threads before, whether or not the > >>> project want >> closed source support for NDI is a subjective issue, > >>> please start a vote >> about the removal of libndi if you want to > >>> seek this through. > >>> > > >>> > The removal of libndi is actually done and committed. > >>> > >>> That is just sad an unfair. > >> > >> Sad, maybe. > >> Unfair, I disagree. If NDI wants to be in, they know what to do. > > > > It is unfair towards the people who expressied disapproval, yet this > > change was committed without neither vote nor consensus. > > +1. This was a political decision, not a technical one. A formal(-ish) > survey should have happened on the ML. > I agree we need a formal vote on this. I would like to set a wider project policy w.r.t. closed-source software integration, this is just one instance of a more general issue. Who wants to organize it? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/westwood_aud: Adds PCM format demux.
From: ffmpeg-devel on behalf of Michael Niedermayer Sent: 20 March 2019 19:08 To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH v2] avformat/westwood_aud: Adds PCM format demux. > fails probetest: > > > tools/probetest 256 4096 > testing size=1 > testing size=2 > testing size=4 > testing size=8 > testing size=16 > testing size=32 > Failure of wsaud probing code with score=50 type=3 p=2D8 size=32 > testing size=64 > testing size=128 > testing size=256 > testing size=512 > testing size=1024 > testing size=2048 What is the appropriate way to resolve this if the format doesn't provide enough information to identify it uniquely? Return AVPROBE_SCORE_RETRY when we know we can't identify a file with a high enough confidence? -- Aidan Richmond ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf:Constify AVInputFormat pointer
2019-03-20 19:23 GMT+01:00, Lou Logan : > On Wed, Mar 20, 2019, at 9:58 AM, Carl Eugen Hoyos wrote: >> >> Patch applied. >> > > Breaks compilation for me on x86_64 linux: Should be fixed, sorry for the nuisance. Thank you for the report, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/westwood_aud: Adds PCM format demux.
2019-03-20 23:20 GMT+01:00, Aidan R : > From: ffmpeg-devel on behalf of Michael > Niedermayer > Sent: 20 March 2019 19:08 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH v2] avformat/westwood_aud: Adds PCM > format demux. > >> fails probetest: >> >> >> tools/probetest 256 4096 >> testing size=1 >> testing size=2 >> testing size=4 >> testing size=8 >> testing size=16 >> testing size=32 >> Failure of wsaud probing code with score=50 type=3 p=2D8 size=32 >> testing size=64 >> testing size=128 >> testing size=256 >> testing size=512 >> testing size=1024 >> testing size=2048 > > What is the appropriate way to resolve this if the format doesn't > provide enough information to identify it uniquely? Return > AVPROBE_SCORE_RETRY when we know we can't identify > a file with a high enough confidence? Another possibility would be to commit the patch without the change to the probe function (you can still force the format) and then think about the probe function independently. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/v4l2: Return FFERROR_REDO when receiving a frame of unexpected size
2019-03-20 22:26 GMT+01:00, Alexander Strasser : > Hi all! > > On 2019-03-20 19:56 +0100, Alexander Strasser wrote: >> I had found that when capturing video for some hours from >> USB Camera-B4.09.24.1 (Manufacturer: OmniVision Technologies, Inc.), >> sometimes when invoking the ioctl DQBUF, the returned buffer is not >> filled with the size we expect for the raw video frame. >> >> Here are two examples for such occurrences: >> >> [video4linux2,v4l2 @ 0x258b440] Dequeued v4l2 buffer contains 609596 >> bytes, but 614400 were expected. Flags: 0x0001. >> /dev/video1: Invalid data found when processing input >> >> [video4linux2,v4l2 @ 0x225f440] Dequeued v4l2 buffer contains 609508 >> bytes, but 614400 were expected. Flags: 0x0001. >> /dev/video1: Invalid data found when processing input >> >> The ffmpeg CLI tool will then stop capturing and exit. >> >> To avoid this, return FFERROR_REDO instead. I have not seen the >> issue appearing twice or more often in a row. It was more like >> one single error every two hours. > > > After thinking about the FFERROR_REDO approach some more, I think it > is not ideal in the case where a driver permanently delivers frames > of unexpected size. The FFmpeg lib call would not return to the client, > potentially freezing the running program. > > So maybe the zero-sized package approach, like we do with the corrupted > frames, is more robust here? Any opinions? You could check if a sane frame was already received before the wrong size. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/hevcdec: decode at most one slice reporting being the first in the picture
On 3/20/2019 11:41 AM, Derek Buitenhuis wrote: > On 18/03/2019 20:31, James Almer wrote: >> Fixes deadlocks when decoding packets containing more than one of the >> aforementioned >> slices when using frame threads. >> >> Signed-off-by: James Almer >> --- > > If there are no other comments / objections, could this be pushed? > > - Derek Pushed. It can always be reverted and a better fix committed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/flvdec: added support for KUX container
Okay, I found out the metadata block contains fields like: logo (a url to thumbnail), tags (in Chinese), title (in Chinese as well), and other information which mostly seem to be related to streaming. I'm not sure though if anything is much useful. Please do suggest if you think any of these can be used. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/latmenc: Error out for invalid codecs
2017-11-01 3:39 GMT+01:00, Michael Niedermayer : > On Wed, Nov 01, 2017 at 02:17:06AM +0100, Carl Eugen Hoyos wrote: >> 2017-10-31 17:38 GMT+01:00 Michael Niedermayer : >> > On Mon, Oct 30, 2017 at 11:51:30PM +0100, Carl Eugen Hoyos wrote: >> >> Hi! >> >> >> >> Attached patch makes sure the loas muxer does not try to write >> >> anything but aac and latm. >> >> >> >> Please comment, Carl Eugen >> > >> >> latmenc.c |4 >> >> 1 file changed, 4 insertions(+) >> >> 2b64f3d5ecb189e77b85dbab7a6cbfe9657701f2 >> >> 0001-lavf-latmenc-Error-out-for-invalid-codecs.patch >> >> From 9f8f39b402f77b53613a395129f96feee5e873ba Mon Sep 17 00:00:00 2001 >> >> From: Carl Eugen Hoyos >> >> Date: Mon, 30 Oct 2017 23:49:29 +0100 >> >> Subject: [PATCH] lavf/latmenc: Error out for invalid codecs. >> > >> > isnt AV_CODEC_ID_MP4ALS supported too ? (i see ALS >> > related code in latmenc.c) >> >> New patch attached. >> >> Thank you, Carl Eugen > >> latmenc.c |4 >> 1 file changed, 4 insertions(+) >> c18fb099cde57aae9a9811b5ee1bf0da08cd9365 >> 0001-lavf-latmenc-Error-out-for-unsupported-codecs.patch >> From d31193d8d2702b0c340b0b4fd2f1682f09b3035c Mon Sep 17 00:00:00 2001 >> From: Carl Eugen Hoyos >> Date: Wed, 1 Nov 2017 02:15:10 +0100 >> Subject: [PATCH] lavf/latmenc: Error out for unsupported codecs. > > probably ok Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/flvdec: added support for KUX container
2019-03-21 0:04 GMT+01:00, Swaraj Hota : > Okay, I found out the metadata block contains fields like: > logo (a url to thumbnail), tags (in Chinese), > title (in Chinese as well), Can you convert the title to something that your terminal (set to utf8) can display? There is "title" metadata, so this can be useful. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Use packet DTS to correct frame PTS for PTS missing video in nvidia cuvid decoder
0001-Use-packet-DTS-to-correct-frame-PTS-for-PTS-missing-.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/v4l2: Return FFERROR_REDO when receiving a frame of unexpected size
On Wed, 20 Mar 2019, Carl Eugen Hoyos wrote: 2019-03-20 22:26 GMT+01:00, Alexander Strasser : Hi all! On 2019-03-20 19:56 +0100, Alexander Strasser wrote: I had found that when capturing video for some hours from USB Camera-B4.09.24.1 (Manufacturer: OmniVision Technologies, Inc.), sometimes when invoking the ioctl DQBUF, the returned buffer is not filled with the size we expect for the raw video frame. Here are two examples for such occurrences: [video4linux2,v4l2 @ 0x258b440] Dequeued v4l2 buffer contains 609596 bytes, but 614400 were expected. Flags: 0x0001. /dev/video1: Invalid data found when processing input [video4linux2,v4l2 @ 0x225f440] Dequeued v4l2 buffer contains 609508 bytes, but 614400 were expected. Flags: 0x0001. /dev/video1: Invalid data found when processing input The ffmpeg CLI tool will then stop capturing and exit. To avoid this, return FFERROR_REDO instead. I have not seen the issue appearing twice or more often in a row. It was more like one single error every two hours. After thinking about the FFERROR_REDO approach some more, I think it is not ideal in the case where a driver permanently delivers frames of unexpected size. The FFmpeg lib call would not return to the client, potentially freezing the running program. So maybe the zero-sized package approach, like we do with the corrupted frames, is more robust here? Any opinions? You could check if a sane frame was already received before the wrong size. Maybe just set the packet corrupt flag and log an error, but return the partial buffer? Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Use packet DTS to correct frame PTS for PTS missing video in nvidia cuvid decoder
- Current Status
In cuvid decoder wrapper, PTS is resolved based on input packet PTS.
When PTS is missing, cuvid decoder produces monotorically increasing numbers
with same interval.
This does not occur problem when every single frame in video has same frame
duration like fixed frame rate video.
- Problem
For variable frame rate video with missing PTS, however, resolving PTS based on
monotorically increasing number with same interval do not reflect actual frame
position in timedomain.
Test sample is AVI without PTS info, and has missing frames which means this is
variable frame rate video. When cuvid decoder processes this video, various
frame duration is ignored due to missing PTS. This directly leads to AV sync
problem and a lot of frame duplication at end of video.
- Solution
To correct each frame duration, packet DTS is passed through
cuvidParseVideoData() to resolve output frame duration.
Since passed packet DTS is not actual PTS, resolved value through
CuvidParsedFrame is stored in frame->best_effort_timestamp like any other
decoder wrapper.
Signed-off-by: JoonsikBaek
---
libavcodec/cuviddec.c | 36 +++-
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index 291bb93..c9f0ff1 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -81,6 +81,8 @@ typedef struct CuvidContext
int internal_error;
int decoder_flushing;
+int use_best_effort_pts_from_dts;
+
int *key_frame;
cudaVideoCodec codec_type;
@@ -384,6 +386,7 @@ static int cuvid_decode_packet(AVCodecContext *avctx, const
AVPacket *avpkt)
AVPacket filter_packet = { 0 };
AVPacket filtered_packet = { 0 };
int ret = 0, eret = 0, is_flush = ctx->decoder_flushing;
+int64_t timestamp = AV_NOPTS_VALUE;
av_log(avctx, AV_LOG_TRACE, "cuvid_decode_packet\n");
@@ -426,11 +429,18 @@ static int cuvid_decode_packet(AVCodecContext *avctx,
const AVPacket *avpkt)
cupkt.payload = avpkt->data;
if (avpkt->pts != AV_NOPTS_VALUE) {
+timestamp = avpkt->pts;
+} else if (avpkt->dts != AV_NOPTS_VALUE) {
+ctx->use_best_effort_pts_from_dts = 1;
+timestamp = avpkt->dts;
+}
+
+if (timestamp != AV_NOPTS_VALUE) {
cupkt.flags = CUVID_PKT_TIMESTAMP;
if (avctx->pkt_timebase.num && avctx->pkt_timebase.den)
-cupkt.timestamp = av_rescale_q(avpkt->pts,
avctx->pkt_timebase, (AVRational){1, 1000});
+cupkt.timestamp = av_rescale_q(timestamp, avctx->pkt_timebase,
(AVRational){1, 1000});
else
-cupkt.timestamp = avpkt->pts;
+cupkt.timestamp = timestamp;
}
} else {
cupkt.flags = CUVID_PKT_ENDOFSTREAM;
@@ -506,6 +516,7 @@ static int cuvid_output_frame(AVCodecContext *avctx,
AVFrame *frame)
unsigned int pitch = 0;
int offset = 0;
int i;
+int64_t timestamp;
av_fifo_generic_read(ctx->frame_queue, &parsed_frame,
sizeof(CuvidParsedFrame), NULL);
@@ -610,22 +621,29 @@ static int cuvid_output_frame(AVCodecContext *avctx,
AVFrame *frame)
frame->key_frame = ctx->key_frame[parsed_frame.dispinfo.picture_index];
frame->width = avctx->width;
frame->height = avctx->height;
+
if (avctx->pkt_timebase.num && avctx->pkt_timebase.den)
-frame->pts = av_rescale_q(parsed_frame.dispinfo.timestamp,
(AVRational){1, 1000}, avctx->pkt_timebase);
+timestamp = av_rescale_q(parsed_frame.dispinfo.timestamp,
(AVRational){1, 1000}, avctx->pkt_timebase);
else
-frame->pts = parsed_frame.dispinfo.timestamp;
+timestamp = parsed_frame.dispinfo.timestamp;
if (parsed_frame.second_field) {
if (ctx->prev_pts == INT64_MIN) {
-ctx->prev_pts = frame->pts;
-frame->pts += (avctx->pkt_timebase.den * avctx->framerate.den)
/ (avctx->pkt_timebase.num * avctx->framerate.num);
+ctx->prev_pts = timestamp;
+timestamp += (avctx->pkt_timebase.den * avctx->framerate.den)
/ (avctx->pkt_timebase.num * avctx->framerate.num);
} else {
-int pts_diff = (frame->pts - ctx->prev_pts) / 2;
-ctx->prev_pts = frame->pts;
-frame->pts += pts_diff;
+int pts_diff = (timestamp - ctx->prev_pts) / 2;
+ctx->prev_pts = timestamp;
+timestamp += pts_diff;
}
}
+if(ctx->use_best_effort_pts_from_dts) {
+frame->best_effort_timestamp = timestamp;
+} else {
+frame->pts = timestamp;
+}
+
/* CUVIDs opaque reordering breaks the internal pkt logic.
* So set pkt_pts and clear all the other pkt_ fields.
*/
--
1.8.3.1
[FFmpeg-devel] [PATCH] avcodec/dxv: Check remaining space in CHECKPOINT()
Fixes: Timeout (77sec -> 1sec)
Fixes:
13407/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXV_fuzzer-5093143018471424
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/dxv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c
index aef5ec19dd..6fe5516505 100644
--- a/libavcodec/dxv.c
+++ b/libavcodec/dxv.c
@@ -256,6 +256,8 @@ static int decompress_texture_thread(AVCodecContext *avctx,
void *arg,
#define CHECKPOINT(x) \
do { \
if (state == 0) { \
+if (bytestream2_get_bytes_left(gbc) < 4) \
+return AVERROR_INVALIDDATA; \
value = bytestream2_get_le32(gbc);\
state = 16; \
} \
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Dennis Mungai , 20 Mar 2019 Çar, 23:20 tarihinde şunu yazdı: > On Wed, 20 Mar 2019 at 23:02, Marton Balint wrote: > > > > > > > On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > > > > On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: > > >> On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > >> > > >> > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: > > >> >> As I described in similar threads before, whether or not the > project > > want > > >> >> closed source support for NDI is a subjective issue, please start a > > vote > > >> >> about the removal of libndi if you want to seek this through. > > >> > > > >> > The removal of libndi is actually done and committed. > > >> > > >> That is just sad an unfair. > > > > > > Sad, maybe. > > > Unfair, I disagree. If NDI wants to be in, they know what to do. > > > > It is unfair towards the people who expressied disapproval, yet this > > change was committed without neither vote nor consensus. > > > > Regards, > > Marton > > > > > > > At the very best, the lack of consensus on this implies vindictive intent. > Is there something that the FFmpeg developers (see below) have against > Newtek, as a company? > Clearly, they took down the offending FFmpeg build: > https://trac.ffmpeg.org/ticket/7589?cversion=0&cnum_hist=10 > > We've seen other violations, such as this one by Amazon: > https://trac.ffmpeg.org/ticket/7214 that were handled in a much more > graceful manner. > > The primary agitator here seems to be kierank: > https://trac.ffmpeg.org/ticket/7589?cversion=0&cnum_hist=10#comment:5 > > What undisclosed history do you have with Newtek (see the reference to > "Andrew") above that isn't disclosed above? > Secondly, you're quite influential in the broadcast industry: > https://www.obe.tv/author/obe/ > > There's an aura of hostility around this commit, and whatever that is seems > to have spilled over into this. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel The way of removal is not nice. There were an expectation to have a voting for removal at the previous ML chain. It feels the feeling of the patch is committed without any notice. Sad, for the users who follow git-master and get notice for removal after the commit. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avfilter/af_astats: add support for selecting measured statistics
On Tue, 12 Mar 2019, Marton Balint wrote: On Tue, 5 Mar 2019, Marton Balint wrote: set_metadata with many entries is not very efficient, and with small audio frames the performance loss is noticable. Also with this very simple calculations (like peak) can be even further optimized. Unfoturnately there are some small differences in metadata and av_log info output, so factorizing calculations and output might not worth the hassle. Ping for the series. Applied. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavf: Constify the probe function argument
Hi! Attached patch makes the only argument to the common probe() function const. Please comment, Carl Eugen From 2d8fe30a4fe88c932e8c9c9dfb55150d6aa45f5f Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Thu, 21 Mar 2019 01:18:37 +0100 Subject: [PATCH] lavf: Constify the probe function argument. --- libavformat/3dostr.c |2 +- libavformat/4xm.c |2 +- libavformat/aacdec.c |2 +- libavformat/aadec.c|2 +- libavformat/ac3dec.c |6 ++--- libavformat/acm.c |2 +- libavformat/act.c |2 +- libavformat/adp.c |2 +- libavformat/ads.c |2 +- libavformat/adxdec.c |2 +- libavformat/aea.c |2 +- libavformat/aiffdec.c |2 +- libavformat/aixdec.c |2 +- libavformat/amr.c |6 ++--- libavformat/anm.c |2 +- libavformat/apc.c |2 +- libavformat/ape.c |2 +- libavformat/apngdec.c |2 +- libavformat/aqtitledec.c |2 +- libavformat/asfdec_f.c |2 +- libavformat/asfdec_o.c |2 +- libavformat/assdec.c |2 +- libavformat/astdec.c |2 +- libavformat/au.c |2 +- libavformat/avformat.h |2 +- libavformat/avidec.c |2 +- libavformat/avr.c |2 +- libavformat/avs.c |2 +- libavformat/bethsoftvid.c |2 +- libavformat/bfi.c |2 +- libavformat/bink.c |2 +- libavformat/bintext.c |6 ++--- libavformat/bit.c |2 +- libavformat/boadec.c |2 +- libavformat/brstm.c|4 +-- libavformat/c93.c |2 +- libavformat/cafdec.c |2 +- libavformat/cavsvideodec.c |2 +- libavformat/cdxl.c |2 +- libavformat/cinedec.c |2 +- libavformat/codec2.c |2 +- libavformat/concatdec.c|2 +- libavformat/dashdec.c |2 +- libavformat/davs2.c|2 +- libavformat/dcstr.c|2 +- libavformat/dfa.c |2 +- libavformat/dhav.c |2 +- libavformat/diracdec.c |2 +- libavformat/dnxhddec.c |2 +- libavformat/dsfdec.c |2 +- libavformat/dsicin.c |2 +- libavformat/dss.c |2 +- libavformat/dtsdec.c |2 +- libavformat/dtshddec.c |2 +- libavformat/dv.c |2 +- libavformat/dvbsub.c |2 +- libavformat/dvbtxt.c |2 +- libavformat/dxa.c |2 +- libavformat/eacdata.c |2 +- libavformat/electronicarts.c |2 +- libavformat/epafdec.c |2 +- libavformat/ffmetadec.c|2 +- libavformat/fitsdec.c |2 +- libavformat/flacdec.c |4 +-- libavformat/flic.c |2 +- libavformat/flvdec.c |6 ++--- libavformat/frmdec.c |2 +- libavformat/fsb.c |2 +- libavformat/gdv.c |2 +- libavformat/genh.c |2 +- libavformat/gifdec.c |2 +- libavformat/gsmdec.c |2 +- libavformat/gxf.c |2 +- libavformat/h261dec.c |2 +- libavformat/h263dec.c |2 +- libavformat/h264dec.c |2 +- libavformat/hcom.c |2 +- libavformat/hevcdec.c |2 +- libavformat/hls.c |2 +- libavformat/hnm.c |2 +- libavformat/icodec.c |2 +- libavformat/idcin.c|2 +- libavformat/idroqdec.c |2 +- libavformat/iff.c |2 +- libavformat/ilbc.c |2 +- libavformat/img2_alias_pix.c |2 +- libavformat/img2_brender_pix.c |2 +- libavformat/img2dec.c | 54 libavformat/ingenientdec.c |2 +- libavformat/ipmovie.c |2 +- libavformat/ircamdec.c |2 +- libavformat/iss.c |2 +- libavformat/iv8.c |2 +- libavformat/ivfdec.c |2 +- libavformat/jacosubdec.c |2 +- libavformat/jvdec.c|2 +- libavformat/libgme.c |2 +- libavformat/libmodplug.c |2 +- libavformat/libopenmpt.c |2 +- libavformat/lmlm4.c|2 +- libavformat/loasdec.c |2 +- libavformat/lrcdec.c |2 +- libavformat/lvfdec.c |2 +- libavformat/lxfdec.c |2 +- libavformat/m4vdec.c |2 +- libavformat/matroskadec.c |2 +- libavformat/mgsts.c|2 +- libavformat/microdvddec.c |2 +- libavformat/mj2kdec.c |2 +- libavformat/mlpdec.c |6 ++--- libavformat/ml
Re: [FFmpeg-devel] Add 16-bit Depth pixel format
2018-11-19 18:41 GMT+01:00, Carl Eugen Hoyos :
> 2018-11-19 18:21 GMT+01:00, Pablo Rubio Fernández :
>
>> It's my first time here. I want to create a patch to add Z16 pixel
>> format.
>> I have did some changes, and I want to know if I'll need change any other
>> file.
>
> Isn't attached poc sufficient?
Patch attached that imo makes using z16 a little easier,
will push if there are no objections.
Carl Eugen
From b33aac84ecce24cbe9125415c0c0e7732887dc5f Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 21 Mar 2019 01:24:42 +0100
Subject: [PATCH] lavd/v4l2-common: Add an entry for Z16.
---
libavdevice/v4l2-common.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/libavdevice/v4l2-common.c b/libavdevice/v4l2-common.c
index 2d6bfac..b5b4448 100644
--- a/libavdevice/v4l2-common.c
+++ b/libavdevice/v4l2-common.c
@@ -46,6 +46,9 @@ const struct fmt_map ff_fmt_conversion_table[] = {
#ifdef V4L2_PIX_FMT_Y16
{ AV_PIX_FMT_GRAY16LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_Y16 },
#endif
+#ifdef V4L2_PIX_FMT_Z16
+{ AV_PIX_FMT_GRAY16LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_Z16 },
+#endif
{ AV_PIX_FMT_NV12,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_NV12},
{ AV_PIX_FMT_NONE,AV_CODEC_ID_MJPEG,V4L2_PIX_FMT_MJPEG },
{ AV_PIX_FMT_NONE,AV_CODEC_ID_MJPEG,V4L2_PIX_FMT_JPEG},
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v7] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.
It enabled MULTIPLE SIMPLE filter graph concurrency, which bring above about
4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration
Below are some test cases and comparison as reference.
(Hardware platform: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz)
(Software: Intel iHD driver - 16.9.00100, CentOS 7)
For 1:N transcode by GPU acceleration with vaapi:
./ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi \
-hwaccel_output_format vaapi \
-i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
-vf "scale_vaapi=1280:720" -c:v h264_vaapi -f null /dev/null \
-vf "scale_vaapi=720:480" -c:v h264_vaapi -f null /dev/null
test results:
2 encoders 5 encoders 10 encoders
Improved 6.1%6.9% 5.5%
For 1:N transcode by GPU acceleration with QSV:
./ffmpeg -hwaccel qsv -c:v h264_qsv \
-i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
-vf "scale_qsv=1280:720:format=nv12" -c:v h264_qsv -f null /dev/null \
-vf "scale_qsv=720:480:format=nv12" -c:v h264_qsv -f null /dev/null
test results:
2 encoders 5 encoders 10 encoders
Improved 6% 4% 15%
For Intel GPU acceleration case, 1 decode to N scaling, by QSV:
./ffmpeg -hwaccel qsv -c:v h264_qsv \
-i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
-vf "scale_qsv=1280:720:format=nv12,hwdownload" -pix_fmt nv12 -f null
/dev/null \
-vf "scale_qsv=720:480:format=nv12,hwdownload" -pix_fmt nv12 -f null
/dev/null
test results:
2 scale 5 scale 10 scale
Improved 12% 21%21%
For CPU only 1 decode to N scaling:
./ffmpeg -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
-vf "scale=1280:720" -pix_fmt nv12 -f null /dev/null \
-vf "scale=720:480" -pix_fmt nv12 -f null /dev/null
test results:
2 scale 5 scale 10 scale
Improved 25%107% 148%
Signed-off-by: Wang, Shaofei
Reviewed-by: Michael Niedermayer
Reviewed-by: Mark Thompson
---
The patch will only effect on multiple SIMPLE filter graphs pipeline,
Passed fate and refine the possible data race,
AFL tested, without introducing extra crashs/hangs:
american fuzzy lop 2.52b (ffmpeg_g)
┌─ process timing ─┬─ overall results
─┐
│run time : 0 days, 9 hrs, 48 min, 48 sec │ cycles done : 0
│
│ last new path : 0 days, 0 hrs, 0 min, 0 sec│ total paths :
1866 │
│ last uniq crash : none seen yet │ uniq crashes : 0
│
│ last uniq hang : 0 days, 9 hrs, 19 min, 23 sec │ uniq hangs : 35
│
├─ cycle progress ┬─ map coverage
─┴───┤
│ now processing : 0 (0.00%) │map density : 24.91% / 36.60%
│
│ paths timed out : 0 (0.00%) │ count coverage : 2.40 bits/tuple
│
├─ stage progress ┼─ findings in depth
┤
│ now trying : calibration │ favored paths : 1 (0.05%)
│
│ stage execs : 0/8 (0.00%) │ new edges on : 1100 (58.95%)
│
│ total execs : 123k │ total crashes : 0 (0 unique)
│
│ exec speed : 3.50/sec (...)│ total tmouts : 52 (47 unique)
│
├─ fuzzing strategy yields ───┴───┬─ path geometry
┤
│ bit flips : 0/0, 0/0, 0/0 │levels : 2
│
│ byte flips : 0/0, 0/0, 0/0 │ pending : 1866
│
│ arithmetics : 0/0, 0/0, 0/0 │ pend fav : 1
│
│ known ints : 0/0, 0/0, 0/0 │ own finds : 1862
│
│ dictionary : 0/0, 0/0, 0/0 │ imported : n/a
│
│ havoc : 0/0, 0/0 │ stability : 76.69%
│
│trim : 0.00%/1828, n/a
├┘
└─┘ [cpu000:
59%]
fftools/ffmpeg.c | 172 +--
fftools/ffmpeg.h | 13 +
2 files changed, 169 insertions(+), 16 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 544f1a1..59a953a 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -164,7 +164,13 @@ static struct termios oldtty;
static int restore_tty;
#endif
+/* enable abr threads when there were multiple simple filter graphs*/
+static int abr_threads_enabled = 0;
+
#if HAVE_THREADS
+pthread_mutex_t fg_config_mutex;
+pthread_mutex_t ost_init_mutex;
+
static void free_input_threads(void);
#endif
@@ -509,6 +515,17 @@ static void ffmpeg_cleanup(int ret)
}
av_fifo_freep(&fg->inputs[j]->ist->sub2video.sub_queue);
}
+#if HAVE_THREADS
+if (abr_threads_enabled) {
+av_frame_free(&fg->inputs[
[FFmpeg-devel] [PATCH v1 2/2] lavc/libdavs2: fix frame dumping error description
Signed-off-by: hwrenx
---
libavcodec/libdavs2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index b0eb4fd..218f3ec 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -107,7 +107,7 @@ static int davs2_dump_frames(AVCodecContext *avctx,
davs2_picture_t *pic, int *g
frame->buf[plane] = av_buffer_alloc(size_line * pic->lines[plane]);
if (!frame->buf[plane]){
-av_log(avctx, AV_LOG_ERROR, "dump error: alloc failed.\n");
+av_log(avctx, AV_LOG_ERROR, "Decoder error: allocation failure,
can't dump frames.\n");
return AVERROR(ENOMEM);
}
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v1 1/2] lavc/libdavs2: add davs2_flush
Signed-off-by: hwrenx
---
libavcodec/libdavs2.c | 16
1 file changed, 16 insertions(+)
diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index 0808721..b0eb4fd 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -129,6 +129,21 @@ static int davs2_dump_frames(AVCodecContext *avctx,
davs2_picture_t *pic, int *g
return 0;
}
+static void davs2_flush(AVCodecContext *avctx)
+{
+DAVS2Context *cad = avctx->priv_data;
+int ret = DAVS2_GOT_FRAME;
+
+while (ret == DAVS2_GOT_FRAME) {
+ret = davs2_decoder_flush(cad->decoder, &cad->headerset,
&cad->out_frame);
+davs2_decoder_frame_unref(cad->decoder, &cad->out_frame);
+}
+
+if (ret == DAVS2_ERROR) {
+av_log(avctx, AV_LOG_WARNING, "Decoder flushing failed.\n");
+}
+}
+
static int send_delayed_frame(AVCodecContext *avctx, AVFrame *frame, int
*got_frame)
{
DAVS2Context *cad = avctx->priv_data;
@@ -205,6 +220,7 @@ AVCodec ff_libdavs2_decoder = {
.init = davs2_init,
.close = davs2_end,
.decode = davs2_decode_frame,
+.flush = davs2_flush,
.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
AV_PIX_FMT_NONE },
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v1 1/2] lavc/libdavs2: add davs2_flush
> 在 2019年3月21日，上午9:58，hwrenx 写道：
>
> Signed-off-by: hwrenx
> ---
> libavcodec/libdavs2.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
> index 0808721..b0eb4fd 100644
> --- a/libavcodec/libdavs2.c
> +++ b/libavcodec/libdavs2.c
> @@ -129,6 +129,21 @@ static int davs2_dump_frames(AVCodecContext *avctx,
> davs2_picture_t *pic, int *g
> return 0;
> }
>
> +static void davs2_flush(AVCodecContext *avctx)
> +{
> +DAVS2Context *cad = avctx->priv_data;
> +int ret = DAVS2_GOT_FRAME;
> +
> +while (ret == DAVS2_GOT_FRAME) {
> +ret = davs2_decoder_flush(cad->decoder, &cad->headerset,
> &cad->out_frame);
> +davs2_decoder_frame_unref(cad->decoder, &cad->out_frame);
> +}
> +
> +if (ret == DAVS2_ERROR) {
> +av_log(avctx, AV_LOG_WARNING, "Decoder flushing failed.\n");
> +}
> +}
> +
> static int send_delayed_frame(AVCodecContext *avctx, AVFrame *frame, int
> *got_frame)
> {
> DAVS2Context *cad = avctx->priv_data;
> @@ -205,6 +220,7 @@ AVCodec ff_libdavs2_decoder = {
> .init = davs2_init,
> .close = davs2_end,
> .decode = davs2_decode_frame,
> +.flush = davs2_flush,
> .capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
> .pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
> AV_PIX_FMT_NONE },
> --
> 2.7.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
patchset look good to me
Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v9 2/2] doc: Add libsvt_hevc encoder docs
Add docs for libsvt_hevc encoder in encoders.texi and general.texi
Signed-off-by: Jun Zhao
Signed-off-by: Zhengxu Huang
Signed-off-by: Hassene Tmar
Signed-off-by: Jing Sun
---
doc/encoders.texi | 147 ++
doc/general.texi | 8 +++
2 files changed, 155 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 94337d0..c85950c 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1569,6 +1569,153 @@ Set maximum NAL size in bytes.
Allow skipping frames to hit the target bitrate if set to 1.
@end table
+@section libsvt_hevc
+
+Scalable Video Technology for HEVC (SVT-HEVC) encoder wrapper.
+
+This encoder requires the presence of the headers and
+library during configuration. You need to explicitly configure the
+build with @code{--enable-libsvthevc}. The library is detected using
+@command{pkg-config}.
+
+For more information about the library see
+@url{https://github.com/intel/SVT-HEVC.git}.
+
+@subsection Options
+
+The following FFmpeg global options affect the configurations of the
+libsvt_hevc encoder.
+
+@table @option
+@item b (@emph{bitrate})
+Set the bitrate (as a number of bits per second). Default is 7M.
+
+@item g / @option{gop_size}
+Set the GOP size. Default is -2 (unspecified).
+
+@item flags +cgop
+Enable closed GOP.
+
+@item qmin (@emph{min-q})
+Default is 10
+
+@item qmax (@emph{max-q})
+Default is 48
+
+Set minimum/maximum quantisation values. Valid range is from 0 to 51
+(Only used when bit rate control mode @option{rc} is set to 1(vbr) mode.
+It is required that qmax >= qmin).
+
+@item profile (@emph{profile})
+Set profile restrictions. Can assume one of the following possible values:
+
+@table @samp
+@item main
+main profile
+@item main10
+main10 profile
+@end table
+
+Default is 2 (main10).
+
+@item level (@emph{level})
+
+@option{level} sets the value of @emph{level}.
+Set level (level_idc). Default is 0 (to be determined by the encoder).
+
+The encoder also has its own specific options:
+
+@table @option
+@item vui
+Enables or disables the vui structure in the HEVC elementary
+bitstream. 0 = Off, 1 = On. Default is 0 (Off).
+
+@item aud (@emph{aud})
+Enable use of access unit delimiters when set to 1. Default is 0 (Off).
+
+@item hielevel
+Set hierarchical levels. Can assume one of the following possible values:
+
+@table @samp
+@item flat
+none hierarchy level
+@item 2level
+2-level hierarchy
+@item 3level
+3-level hierarchy
+@item 4level
+4-level hierarchy
+@end table
+
+Default is 3.
+
+@item la_depth
+Set look-ahead depth, depending on @option{rc}: for @var{vbr}, it's recommended
+to unset it and use the default value (the intra period); for @var{cqp}, better
+specify the look-ahead depth.
+
+The range is @var{-1-256}. Default is -1 (unset and the default value to be
used).
+
+@item preset
+Set the quality vs density tradeoff point at which the encoding is to be
performed.
+Higher perset value, higher density and lower quality.
+
+The range is @var{0-12}. Default is 9.
+
+@item tier
+Set @emph{general_tier_flag}. This may affect the level chosen for the stream
+if it is not explicitly specified. Can assume one of the following possible
values:
+
+@table @samp
+@item main
+main tier
+@item high
+high tier
+@end table
+
+Default is 1 (main).
+
+@item rc
+Set bit rate control mode. Can assume one of the following possible values:
+
+@table @samp
+@item cqp
+Constant QP (CQP) mode
+@item vbr
+Variable Bit Rate (VBR) mode
+@end table
+
+Default is 0 (cqp).
+
+@item qp
+Initial quantization parameter for the intra pictures used when
+@option{rc} is cqp mode. The range is from @var{0-51}. Default is 32.
+
+@item sc_detection
+Enables or disables the scene change detection algorithm. Default is 0
(disabled).
+
+@item tune
+Set quality tuning mode. Can assume one of the following possible values:
+
+@table @samp
+@item sq
+Visually optimized mode
+@item oq
+PSNR / SSIM optimized mode
+@item vmaf
+VMAF optimized mode
+@end table
+
+Default is 1 (oq).
+
+@item bl_mode
+Enables or disables Random Access Prediction. Default is 0 (disabled).
+@end table
+
+@item hdr
+High dynamic range input. Default is 0 (disabled).
+@end table
+
@section libtheora
libtheora Theora encoder wrapper.
diff --git a/doc/general.texi b/doc/general.texi
index fe94c40..f90e188 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -234,6 +234,14 @@ FFmpeg can use the OpenJPEG libraries for
decoding/encoding J2K videos. Go to
instructions. To enable using OpenJPEG in FFmpeg, pass
@code{--enable-libopenjpeg} to
@file{./configure}.
+@section Scalable Video Technology for HEVC
+
+FFmpeg can make use of the SVT-HEVC library for HEVC encoding.
+
+Go to @url{https://github.com/intel/SVT-HEVC.git} and follow the instructions
+for installing the library. Pass @code{--enable-libsvthevc} to configure to
+enable it.
+
@section TwoLAME
FFmpeg can make use of the TwoLAME library for MP2 encoding.
--
1.8.3.1
_
[FFmpeg-devel] [PATCH v9 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper
Signed-off-by: Zhengxu Huang
Signed-off-by: Hassene Tmar
Signed-off-by: Jun Zhao
Signed-off-by: Jing Sun
---
configure| 4 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/libsvt_hevc.c | 505 +++
4 files changed, 511 insertions(+)
create mode 100644 libavcodec/libsvt_hevc.c
diff --git a/configure b/configure
index 938ff10..2aabac4 100755
--- a/configure
+++ b/configure
@@ -264,6 +264,7 @@ External library support:
--enable-libspeexenable Speex de/encoding via libspeex [no]
--enable-libsrt enable Haivision SRT protocol via libsrt [no]
--enable-libssh enable SFTP protocol via libssh [no]
+ --enable-libsvthevc enable HEVC encoding via svt [no]
--enable-libtensorflow enable TensorFlow as a DNN module backend
for DNN based filters like sr [no]
--enable-libtesseractenable Tesseract, needed for ocr filter [no]
@@ -1784,6 +1785,7 @@ EXTERNAL_LIBRARY_LIST="
libspeex
libsrt
libssh
+libsvthevc
libtensorflow
libtesseract
libtheora
@@ -3173,6 +3175,7 @@ libshine_encoder_select="audio_frame_queue"
libspeex_decoder_deps="libspeex"
libspeex_encoder_deps="libspeex"
libspeex_encoder_select="audio_frame_queue"
+libsvt_hevc_encoder_deps="libsvthevc"
libtheora_encoder_deps="libtheora"
libtwolame_encoder_deps="libtwolame"
libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
@@ -6209,6 +6212,7 @@ enabled libsoxr && require libsoxr soxr.h
soxr_create -lsoxr
enabled libssh&& require_pkg_config libssh libssh libssh/sftp.h
sftp_init
enabled libspeex && require_pkg_config libspeex speex speex/speex.h
speex_decoder_init
enabled libsrt&& require_pkg_config libsrt "srt >= 1.3.0"
srt/srt.h srt_socket
+enabled libsvthevc&& require_pkg_config libsvthevc SvtHevcEnc EbApi.h
EbInitHandle
enabled libtensorflow && require libtensorflow tensorflow/c/c_api.h
TF_Version -ltensorflow
enabled libtesseract && require_pkg_config libtesseract tesseract
tesseract/capi.h TessBaseAPICreate
enabled libtheora && require libtheora theora/theoraenc.h th_info_init
-ltheoraenc -ltheoradec -logg
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 15c43a8..c93e545 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -987,6 +987,7 @@ OBJS-$(CONFIG_LIBOPUS_ENCODER)+= libopusenc.o
libopus.o \
OBJS-$(CONFIG_LIBSHINE_ENCODER) += libshine.o
OBJS-$(CONFIG_LIBSPEEX_DECODER) += libspeexdec.o
OBJS-$(CONFIG_LIBSPEEX_ENCODER) += libspeexenc.o
+OBJS-$(CONFIG_LIBSVT_HEVC_ENCODER)+= libsvt_hevc.o
OBJS-$(CONFIG_LIBTHEORA_ENCODER) += libtheoraenc.o
OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b26aeca..e93f66f 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -703,6 +703,7 @@ extern AVCodec ff_librsvg_decoder;
extern AVCodec ff_libshine_encoder;
extern AVCodec ff_libspeex_encoder;
extern AVCodec ff_libspeex_decoder;
+extern AVCodec ff_libsvt_hevc_encoder;
extern AVCodec ff_libtheora_encoder;
extern AVCodec ff_libtwolame_encoder;
extern AVCodec ff_libvo_amrwbenc_encoder;
diff --git a/libavcodec/libsvt_hevc.c b/libavcodec/libsvt_hevc.c
new file mode 100644
index 000..9c958f5
--- /dev/null
+++ b/libavcodec/libsvt_hevc.c
@@ -0,0 +1,505 @@
+/*
+* Scalable Video Technology for HEVC encoder library plugin
+*
+* Copyright (c) 2018 Intel Corporation
+*
+* This file is part of FFmpeg.
+*
+* FFmpeg is free software; you can redistribute it and/or
+* modify it under the terms of the GNU Lesser General Public
+* License as published by the Free Software Foundation; either
+* version 2.1 of the License, or (at your option) any later version.
+*
+* FFmpeg is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+* Lesser General Public License for more details.
+*
+* You should have received a copy of the GNU Lesser General Public
+* License along with this program; if not, write to the Free Software
+* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+*/
+
+#include "EbErrorCodes.h"
+#include "EbTime.h"
+#include "EbApi.h"
+
+#include "libavutil/common.h"
+#include "libavutil/frame.h"
+#include "libavutil/opt.h"
+
+#include "internal.h"
+#include "avcodec.h"
+
+typedef enum eos_status {
+EOS_NOT_REACHED = 0,
+EOS_REACHED,
+EOS_TOTRIGGER
+}EOS_STATUS;
+
+typedef struct SvtContext {
+AVClass *class;
+
+EB_H265_ENC_CONFIGURATION enc_params;
+EB_COMPONENTTYPE *svt_handle;
+EB_BUFFERHEADERTYPE in_buf;
+EOS_STATUS eos_flag;
+
+// User options.
+int vui_info;
+
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, Mar 21, 2019, 02:35 Ali KIZIL wrote: > Dennis Mungai , 20 Mar 2019 Çar, 23:20 tarihinde şunu > yazdı: > > > On Wed, 20 Mar 2019 at 23:02, Marton Balint wrote: > > > > > > > > > > > On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > > > > > > On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: > > > >> On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > > >> > > > >> > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: > > > >> >> As I described in similar threads before, whether or not the > > project > > > want > > > >> >> closed source support for NDI is a subjective issue, please > start a > > > vote > > > >> >> about the removal of libndi if you want to seek this through. > > > >> > > > > >> > The removal of libndi is actually done and committed. > > > >> > > > >> That is just sad an unfair. > > > > > > > > Sad, maybe. > > > > Unfair, I disagree. If NDI wants to be in, they know what to do. > > > > > > It is unfair towards the people who expressied disapproval, yet this > > > change was committed without neither vote nor consensus. > > > > > > Regards, > > > Marton > > > > > > > > > > > At the very best, the lack of consensus on this implies vindictive > intent. > > Is there something that the FFmpeg developers (see below) have against > > Newtek, as a company? > > Clearly, they took down the offending FFmpeg build: > > https://trac.ffmpeg.org/ticket/7589?cversion=0&cnum_hist=10 > > > > We've seen other violations, such as this one by Amazon: > > https://trac.ffmpeg.org/ticket/7214 that were handled in a much more > > graceful manner. > > > > The primary agitator here seems to be kierank: > > https://trac.ffmpeg.org/ticket/7589?cversion=0&cnum_hist=10#comment:5 > > > > What undisclosed history do you have with Newtek (see the reference to > > "Andrew") above that isn't disclosed above? > > Secondly, you're quite influential in the broadcast industry: > > https://www.obe.tv/author/obe/ > > > > There's an aura of hostility around this commit, and whatever that is > seems > > to have spilled over into this. > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > The way of removal is not nice. There were an expectation to have a voting > for removal at the previous ML chain. > It feels the feeling of the patch is committed without any notice. > Sad, for the users who follow git-master and get notice for removal after > the commit. > And apparently calling out specific parties involved in this was translated as an ad hominem attack. Citing Newtek NDI as a "common" violator of the GPL *without* offering any evidence (a history of repeated prior behavior) is simply vindictive. What's the point of a consensus when it's assumed "the majority" agreed *without* an ML vote on the same? At this point, Kizil: Let sleeping dogs lie. This removal is purely political. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
