[FFmpeg-devel] compile ffmpeg errors
I use below commands to compile ffmpeg, but make command reports some errors. git clone https://github.com/FFmpeg/FFmpeg.git cd FFmpeg git checkout origin/release/2.8 PKG_CONFIG_PATH="${DEST}/build/lib/pkgconfig" ./configure --prefix="${DEST}/build" \ --extra-cflags="-I${DEST}/build/include" --extra-ldflags="-L${DEST}/build/lib" bindir="${DEST}/bin" \ --pkg-config-flags="--static" --enable-shared --enable-pic --enable-gpl --enable-nonfree --enable-libfdk-aac --enable-libfreetype \ --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 make libavfilter/avf_showcqt.c:38:10: error: #include expects "FILENAME" or libavfilter/vf_drawtext.c:69:10: error: #include expects "FILENAME" or libavfilter/vf_drawtext.c:70:10: error: #include expects "FILENAME" or libavfilter/vf_drawtext.c:71:10: error: #include expects "FILENAME" or libavfilter/vf_drawtext.c:275:10: error: #include expects "FILENAME" or ffplay.c:3217:46: error: missing binary operator before token "(" ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] nvenc set slice number to 1 to improve encoding quality and clamp initial qp value to [1, 51]
On 2015/12/11 11:10, Agatha Hu wrote: --- libavcodec/nvenc.c | 19 +++ 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c index 43b8e78..6365434 100644 --- a/libavcodec/nvenc.c +++ b/libavcodec/nvenc.c @@ -762,6 +762,17 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx) } } +switch (avctx->codec->id) { +case AV_CODEC_ID_H264: +ctx->encode_config.encodeCodecConfig.h264Config.sliceMode = 3; +ctx->encode_config.encodeCodecConfig.h264Config.sliceModeData = 1; +break; +case AV_CODEC_ID_H265: +ctx->encode_config.encodeCodecConfig.hevcConfig.sliceMode = 3; +ctx->encode_config.encodeCodecConfig.hevcConfig.sliceModeData = 1; +break; +} + /* when there're b frames, set dts offset */ if (ctx->encode_config.frameIntervalP >= 2) ctx->last_dts = -2; @@ -843,10 +854,10 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx) ctx->encode_config.rcParams.initialRCQP.qpInterP = qp_inter_p; if(avctx->i_quant_factor != 0.0 && avctx->b_quant_factor != 0.0) { -ctx->encode_config.rcParams.initialRCQP.qpIntra = qp_inter_p * fabs(avctx->i_quant_factor); -ctx->encode_config.rcParams.initialRCQP.qpIntra += avctx->i_quant_offset; -ctx->encode_config.rcParams.initialRCQP.qpInterB = qp_inter_p * fabs(avctx->b_quant_factor); -ctx->encode_config.rcParams.initialRCQP.qpInterB += avctx->b_quant_offset; +ctx->encode_config.rcParams.initialRCQP.qpIntra = av_clip( +qp_inter_p * fabs(avctx->i_quant_factor) + avctx->i_quant_offset, 0, 51); +ctx->encode_config.rcParams.initialRCQP.qpInterB = av_clip( +qp_inter_p * fabs(avctx->b_quant_factor) + avctx->b_quant_offset, 0, 51); } else { ctx->encode_config.rcParams.initialRCQP.qpIntra = qp_inter_p; ctx->encode_config.rcParams.initialRCQP.qpInterB = qp_inter_p; Hi all, before switching to the new released nvenc6.0 header, can you take a look at this fix? Agatha Hu ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] nvenc set slice number to 1 to improve encoding quality and clamp initial qp value to [1, 51]
--- libavcodec/nvenc.c | 19 +++ 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c index 43b8e78..6365434 100644 --- a/libavcodec/nvenc.c +++ b/libavcodec/nvenc.c @@ -762,6 +762,17 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx) } } +switch (avctx->codec->id) { +case AV_CODEC_ID_H264: +ctx->encode_config.encodeCodecConfig.h264Config.sliceMode = 3; +ctx->encode_config.encodeCodecConfig.h264Config.sliceModeData = 1; +break; +case AV_CODEC_ID_H265: +ctx->encode_config.encodeCodecConfig.hevcConfig.sliceMode = 3; +ctx->encode_config.encodeCodecConfig.hevcConfig.sliceModeData = 1; +break; +} + /* when there're b frames, set dts offset */ if (ctx->encode_config.frameIntervalP >= 2) ctx->last_dts = -2; @@ -843,10 +854,10 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx) ctx->encode_config.rcParams.initialRCQP.qpInterP = qp_inter_p; if(avctx->i_quant_factor != 0.0 && avctx->b_quant_factor != 0.0) { -ctx->encode_config.rcParams.initialRCQP.qpIntra = qp_inter_p * fabs(avctx->i_quant_factor); -ctx->encode_config.rcParams.initialRCQP.qpIntra += avctx->i_quant_offset; -ctx->encode_config.rcParams.initialRCQP.qpInterB = qp_inter_p * fabs(avctx->b_quant_factor); -ctx->encode_config.rcParams.initialRCQP.qpInterB += avctx->b_quant_offset; +ctx->encode_config.rcParams.initialRCQP.qpIntra = av_clip( +qp_inter_p * fabs(avctx->i_quant_factor) + avctx->i_quant_offset, 0, 51); +ctx->encode_config.rcParams.initialRCQP.qpInterB = av_clip( +qp_inter_p * fabs(avctx->b_quant_factor) + avctx->b_quant_offset, 0, 51); } else { ctx->encode_config.rcParams.initialRCQP.qpIntra = qp_inter_p; ctx->encode_config.rcParams.initialRCQP.qpInterB = qp_inter_p; -- 1.9.5.github.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] nvenc set slice number to 1 to improve encoding quality and clamp initial qp value to [1, 51]
--- libavcodec/nvenc.c | 19 +++ 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c index 43b8e78..6365434 100644 --- a/libavcodec/nvenc.c +++ b/libavcodec/nvenc.c @@ -762,6 +762,17 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx) } } +switch (avctx->codec->id) { +case AV_CODEC_ID_H264: +ctx->encode_config.encodeCodecConfig.h264Config.sliceMode = 3; +ctx->encode_config.encodeCodecConfig.h264Config.sliceModeData = 1; +break; +case AV_CODEC_ID_H265: +ctx->encode_config.encodeCodecConfig.hevcConfig.sliceMode = 3; +ctx->encode_config.encodeCodecConfig.hevcConfig.sliceModeData = 1; +break; +} + /* when there're b frames, set dts offset */ if (ctx->encode_config.frameIntervalP >= 2) ctx->last_dts = -2; @@ -843,10 +854,10 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx) ctx->encode_config.rcParams.initialRCQP.qpInterP = qp_inter_p; if(avctx->i_quant_factor != 0.0 && avctx->b_quant_factor != 0.0) { -ctx->encode_config.rcParams.initialRCQP.qpIntra = qp_inter_p * fabs(avctx->i_quant_factor); -ctx->encode_config.rcParams.initialRCQP.qpIntra += avctx->i_quant_offset; -ctx->encode_config.rcParams.initialRCQP.qpInterB = qp_inter_p * fabs(avctx->b_quant_factor); -ctx->encode_config.rcParams.initialRCQP.qpInterB += avctx->b_quant_offset; +ctx->encode_config.rcParams.initialRCQP.qpIntra = av_clip( +qp_inter_p * fabs(avctx->i_quant_factor) + avctx->i_quant_offset, 0, 51); +ctx->encode_config.rcParams.initialRCQP.qpInterB = av_clip( +qp_inter_p * fabs(avctx->b_quant_factor) + avctx->b_quant_offset, 0, 51); } else { ctx->encode_config.rcParams.initialRCQP.qpIntra = qp_inter_p; ctx->encode_config.rcParams.initialRCQP.qpInterB = qp_inter_p; -- 1.9.5.github.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Fw: Fw: [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c
I do agree that calling ff_mov_read_stsd_entries() in mov.c is an ugly hack, though. But don't blame me, I didn't write it ;) It would be better to manage the palette inside of matroskadec.c, of course, even if it seems to work just fine as it is right now. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ - Forwarded Message - From: Mats Peterson To: FFmpeg Development Discussions and Patches Sent: Friday, December 11, 2015 2:02 AM Subject: [FFmpeg-devel] Fw: [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c I should say "QuickTime video in a Matroska file", not "QuickTime file". -- Mats Peterson http://matsp888.no-ip.org/~mats/ - Forwarded Message - From: Mats Peterson To: FFmpeg development discussions and patches Sent: Friday, December 11, 2015 2:00 AM Subject: Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c It's not replacing the private data at all.It allocates extradata separately from it. No program I know of uses this extradata *in Quicktime video in Matroska using a palette* for anything but tacking the palette onto a BITMAPINFOHEADER, like MPlayer. This is by far the best solution to make MPlayer recognize the palette in a QuickTime file, just like it does with V_MS/VFW/FOURCC. The problem is that it can't use an offset into the private data for QuickTime video as it does with V_MS/VFW/FOURCC, since the QT video often doesn't have any palette in the private data, has to get the default Macintosh palette. It's not my hack for the record. But it's a hack that works. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ From: Hendrik Leppkes To: FFmpeg development discussions and patches Sent: Friday, December 11, 2015 1:53 AM Subject: Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c On Thu, Dec 10, 2015 at 12:06 PM, Mats Peterson wrote: > I've attached a unified diff of the latest Git version of matroskadec.c that > does two things: > 1. It allows FFmpeg to recognize QuickTime version 0 sound sample > descriptions by using 36 instead of 86 as the minimum private data size for > A_QUICKTIME. > 2. The palette, in QuickTime video that has one, is put in extradata, to make > MPlayer recognize it and tack it to the end of its "fake" BITMAPINFOHEADER. > This patch is an improvement and tidying-up of a proposed patch by Martin > Storsjö, for the record. The version 0 sound sample description stuff is made > by me long ago, though. > This is an extremely ugly hack. Replacing priv_data and calling into the mov demuxer? Rather come up with a better solution without the potential for a whole load of side-effects. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/matroskadec: Set codec_tag also for audio codecs
On Thu, Dec 10, 2015 at 11:50:45PM +0100, Carl Eugen Hoyos wrote: > Hi! > > Attached patch is definitely a good idea imo, the mov demuxer also > sets codec_tag reading the same atom, for "A_MS/ACM" codec_tag is > already set. > > Please comment, Carl Eugen > matroskadec.c |1 + > 1 file changed, 1 insertion(+) > 2304ec17547647dad8121a55cac95f099a8e6ef1 patchmkvaudiofourcc.diff > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c > index aad567a..95cebdd 100644 > --- a/libavformat/matroskadec.c > +++ b/libavformat/matroskadec.c > @@ -2124,6 +2124,7 @@ static int matroska_parse_tracks(AVFormatContext *s) > } > } else if (track->type == MATROSKA_TRACK_TYPE_AUDIO) { > st->codec->codec_type = AVMEDIA_TYPE_AUDIO; > +st->codec->codec_tag = fourcc; > st->codec->sample_rate = track->audio.out_samplerate; > st->codec->channels= track->audio.channels; > if (!st->codec->bits_per_coded_sample) this changes things like: Stream #0:7(jpn): Audio: adpcm_ima_wav ([17][0][0][0] / 0x0011), 11025 Hz, 2 channels, s16p, 88 kb/s to Stream #0:7(jpn): Audio: adpcm_ima_wav, 11025 Hz, 2 channels, s16p, 88 kb/s in [CCCP]_Mega_Weird_Audio_Test.mkv is that intended ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Fw: [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c
I should say "QuickTime video in a Matroska file", not "QuickTime file". -- Mats Peterson http://matsp888.no-ip.org/~mats/ - Forwarded Message - From: Mats Peterson To: FFmpeg development discussions and patches Sent: Friday, December 11, 2015 2:00 AM Subject: Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c It's not replacing the private data at all.It allocates extradata separately from it. No program I know of uses this extradata *in Quicktime video in Matroska using a palette* for anything but tacking the palette onto a BITMAPINFOHEADER, like MPlayer. This is by far the best solution to make MPlayer recognize the palette in a QuickTime file, just like it does with V_MS/VFW/FOURCC. The problem is that it can't use an offset into the private data for QuickTime video as it does with V_MS/VFW/FOURCC, since the QT video often doesn't have any palette in the private data, has to get the default Macintosh palette. It's not my hack for the record. But it's a hack that works. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ From: Hendrik Leppkes To: FFmpeg development discussions and patches Sent: Friday, December 11, 2015 1:53 AM Subject: Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c On Thu, Dec 10, 2015 at 12:06 PM, Mats Peterson wrote: > I've attached a unified diff of the latest Git version of matroskadec.c that > does two things: > 1. It allows FFmpeg to recognize QuickTime version 0 sound sample > descriptions by using 36 instead of 86 as the minimum private data size for > A_QUICKTIME. > 2. The palette, in QuickTime video that has one, is put in extradata, to make > MPlayer recognize it and tack it to the end of its "fake" BITMAPINFOHEADER. > This patch is an improvement and tidying-up of a proposed patch by Martin > Storsjö, for the record. The version 0 sound sample description stuff is made > by me long ago, though. > This is an extremely ugly hack. Replacing priv_data and calling into the mov demuxer? Rather come up with a better solution without the potential for a whole load of side-effects. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c
It's not replacing the private data at all.It allocates extradata separately from it. No program I know of uses this extradata *in Quicktime video in Matroska using a palette* for anything but tacking the palette onto a BITMAPINFOHEADER, like MPlayer. This is by far the best solution to make MPlayer recognize the palette in a QuickTime file, just like it does with V_MS/VFW/FOURCC. The problem is that it can't use an offset into the private data for QuickTime video as it does with V_MS/VFW/FOURCC, since the QT video often doesn't have any palette in the private data, has to get the default Macintosh palette. It's not my hack for the record. But it's a hack that works. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ From: Hendrik Leppkes To: FFmpeg development discussions and patches Sent: Friday, December 11, 2015 1:53 AM Subject: Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c On Thu, Dec 10, 2015 at 12:06 PM, Mats Peterson wrote: > I've attached a unified diff of the latest Git version of matroskadec.c that > does two things: > 1. It allows FFmpeg to recognize QuickTime version 0 sound sample > descriptions by using 36 instead of 86 as the minimum private data size for > A_QUICKTIME. > 2. The palette, in QuickTime video that has one, is put in extradata, to make > MPlayer recognize it and tack it to the end of its "fake" BITMAPINFOHEADER. > This patch is an improvement and tidying-up of a proposed patch by Martin > Storsjö, for the record. The version 0 sound sample description stuff is made > by me long ago, though. > This is an extremely ugly hack. Replacing priv_data and calling into the mov demuxer? Rather come up with a better solution without the potential for a whole load of side-effects. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c
On Thu, Dec 10, 2015 at 12:06 PM, Mats Peterson wrote: > I've attached a unified diff of the latest Git version of matroskadec.c that > does two things: > 1. It allows FFmpeg to recognize QuickTime version 0 sound sample > descriptions by using 36 instead of 86 as the minimum private data size for > A_QUICKTIME. > 2. The palette, in QuickTime video that has one, is put in extradata, to make > MPlayer recognize it and tack it to the end of its "fake" BITMAPINFOHEADER. > This patch is an improvement and tidying-up of a proposed patch by Martin > Storsjö, for the record. The version 0 sound sample description stuff is made > by me long ago, though. > This is an extremely ugly hack. Replacing priv_data and calling into the mov demuxer? Rather come up with a better solution without the potential for a whole load of side-effects. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c
I'm not very versed at (or planning to become) using Git and its utilites, that's why I provide a patch here for you to examine. I hope this approach is accepted. And although it's about two different issues, they are both concerning the same file, i.e. matroskadec.c. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ From: Michael Niedermayer To: FFmpeg development discussions and patches Sent: Friday, December 11, 2015 1:30 AM Subject: Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c On Thu, Dec 10, 2015 at 11:06:58AM +, Mats Peterson wrote: > I've attached a unified diff of the latest Git version of matroskadec.c that > does two things: > 1. It allows FFmpeg to recognize QuickTime version 0 sound sample > descriptions by using 36 instead of 86 as the minimum private data size for > A_QUICKTIME. > 2. The palette, in QuickTime video that has one, is put in extradata, to make > MPlayer recognize it and tack it to the end of its "fake" BITMAPINFOHEADER. > This patch is an improvement and tidying-up of a proposed patch by Martin > Storsjö, for the record. The version 0 sound sample description stuff is made > by me long ago, though. > > Comments welcome. This sounds like 2 independant changes each independant change should be in its own patch and commit. you can easily split changes into commits with git add -p and git commit this also produces git compatible patches with commit messages (with git format-patch or git send-email) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add SOFAlizer audio filter
On Fri, Dec 11, 2015 at 12:03:34AM +0100, Paul B Mahol wrote: [...] > +static int query_formats(AVFilterContext *ctx) > +{ > +struct SOFAlizerContext *s = ctx->priv; > +AVFilterFormats *formats = NULL; > +AVFilterChannelLayouts *layouts = NULL; > +static int sample_rates[] = { 48000, -1 }; [...] > +sample_rates[0] = s->sample_rate; > +formats = ff_make_format_list(sample_rates); is this intended to be a non constant static/global ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c
On Thu, Dec 10, 2015 at 11:06:58AM +, Mats Peterson wrote: > I've attached a unified diff of the latest Git version of matroskadec.c that > does two things: > 1. It allows FFmpeg to recognize QuickTime version 0 sound sample > descriptions by using 36 instead of 86 as the minimum private data size for > A_QUICKTIME. > 2. The palette, in QuickTime video that has one, is put in extradata, to make > MPlayer recognize it and tack it to the end of its "fake" BITMAPINFOHEADER. > This patch is an improvement and tidying-up of a proposed patch by Martin > Storsjö, for the record. The version 0 sound sample description stuff is made > by me long ago, though. > > Comments welcome. This sounds like 2 independant changes each independant change should be in its own patch and commit. you can easily split changes into commits with git add -p and git commit this also produces git compatible patches with commit messages (with git format-patch or git send-email) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header
On 2015-12-08 02:53, Timo Rothenpieler wrote: Nvidia finaly decided to put a propper MIT license on their nvenc header, so it can be included, removing any external dependencies for nvenc and making it no longer require the non-free flag. nvenc.h is the original nvEncodeApi.h from the NVENC SDK 6.0.1, with a slight modification to make it work on cygwin. Works for me. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header
On Fri, Dec 11, 2015 at 12:03 AM, Carl Eugen Hoyos wrote: > On Monday 07 December 2015 07:53:31 pm Timo Rothenpieler wrote: >> @@ -4807,7 +4807,6 @@ die_license_disabled gpl x11grab >> >> die_license_disabled nonfree libaacplus >> die_license_disabled nonfree libfaac >> -die_license_disabled nonfree nvenc > > Sorry, but this makes absolutely no sense imo: > I asked you if nvenc is a system library and your answer did > not indicate that you are certain it is a system library (and > I did ask you if I maybe misunderstood your answer), > > If it is not a system library, you must not remove this line. > > If it is a system library, please enable auto-detection as we > already have enough untested features and as we generally do > autodetect system libraries. > You should read the entire discussion, we have already touched on all of these points. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/softfloat: Assert that the exponent did not overflow the legal range in av_normalize1_sf()
On Mon, Nov 09, 2015 at 09:17:34PM +0100, Andreas Cadhalpun wrote: > On 08.11.2015 21:51, Andreas Cadhalpun wrote: > > On 08.11.2015 13:41, Michael Niedermayer wrote: > >> From: Michael Niedermayer > >> > >> Signed-off-by: Michael Niedermayer > >> --- > >> libavutil/softfloat.h |1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/libavutil/softfloat.h b/libavutil/softfloat.h > >> index 023ccd0..ed1aab3 100644 > >> --- a/libavutil/softfloat.h > >> +++ b/libavutil/softfloat.h > >> @@ -79,6 +79,7 @@ static inline av_const SoftFloat > >> av_normalize1_sf(SoftFloat a){ > >> a.mant>>=1; > >> } > >> av_assert2(a.mant < 0x4000 && a.mant > -0x4000); > >> +av_assert2(a.exp <= MAX_EXP); > >> return a; > >> #elif 1 > >> int t= a.mant + 0x4000 < 0; > >> > > > > This assert would be triggered by more than 15% of my test samples for > > aac_fixed. > > So unless that changes, this assert shouldn't be added. > > I've sent a patch fixing this. Once the patch is applied, this assert should > be fine. i assume this has been fixed so ill apply this soon thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/libvo-aac: Mark the encoder as experimental
On Fri, Dec 11, 2015 at 12:07 AM, Carl Eugen Hoyos wrote: > On Wednesday 09 December 2015 09:24:06 pm Hendrik Leppkes wrote: >> On Wed, Dec 9, 2015 at 7:09 PM, James Almer wrote: >> > On 12/5/2015 9:31 PM, Carl Eugen Hoyos wrote: >> >> Hi! >> >> >> >> I prefer attached patch over removing the encoder immediately. > >> And its quality is horrible. >> >> No idea why we would mark it experimental however. The built-in >> encoder will always take precedence, so a user has to explicitly >> request it as it is. > > I am thinking of the many scripts using libvo-aac and the many > users who automatically request it with -c:a whenever they encode > aac. > So you intentionally want to break all the scripts? Doesn't sound like a good thing. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header
On 11.12.2015 00:03, Carl Eugen Hoyos wrote: > On Monday 07 December 2015 07:53:31 pm Timo Rothenpieler wrote: >> @@ -4807,7 +4807,6 @@ die_license_disabled gpl x11grab >> >> die_license_disabled nonfree libaacplus >> die_license_disabled nonfree libfaac >> -die_license_disabled nonfree nvenc > > Sorry, but this makes absolutely no sense imo: > I asked you if nvenc is a system library and your answer did > not indicate that you are certain it is a system library (and > I did ask you if I maybe misunderstood your answer), Well, the problem is that the answer may depend on the system. > If it is not a system library, you must not remove this line. > > If it is a system library, please enable auto-detection as we > already have enough untested features and as we generally do > autodetect system libraries. What should be done if it is a system library on Windows, but not on Debian? Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aac_fixed: fix overflow in sbr_sum_square_c
On 02.12.2015 20:58, Andreas Cadhalpun wrote: > On 19.11.2015 01:01, Andreas Cadhalpun wrote: >> Subject: [PATCH] sbrdsp_fixed: assert that input values for sbr_sum_square_c >> are valid >> >> Larger values can cause overflows, leading to this function returning a >> negative value. >> >> Signed-off-by: Andreas Cadhalpun >> --- >> libavcodec/sbrdsp_fixed.c | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/libavcodec/sbrdsp_fixed.c b/libavcodec/sbrdsp_fixed.c >> index 5b7b7a6..f4e3de0 100644 >> --- a/libavcodec/sbrdsp_fixed.c >> +++ b/libavcodec/sbrdsp_fixed.c >> @@ -38,9 +38,14 @@ static SoftFloat sbr_sum_square_c(int (*x)[2], int n) >> int i, nz, round; >> >> for (i = 0; i < n; i += 2) { >> +// Larger values are inavlid and could cause overflows of accu. >> +av_assert2(FFABS(x[i + 0][0]) >> 29 == 0); >> accu += (int64_t)x[i + 0][0] * x[i + 0][0]; >> +av_assert2(FFABS(x[i + 0][1]) >> 29 == 0); >> accu += (int64_t)x[i + 0][1] * x[i + 0][1]; >> +av_assert2(FFABS(x[i + 1][0]) >> 29 == 0); >> accu += (int64_t)x[i + 1][0] * x[i + 1][0]; >> +av_assert2(FFABS(x[i + 1][1]) >> 29 == 0); >> accu += (int64_t)x[i + 1][1] * x[i + 1][1]; >> } >> > > Ping. I pushed this now. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header
On Monday 07 December 2015 07:53:31 pm Timo Rothenpieler wrote: > @@ -4807,7 +4807,6 @@ die_license_disabled gpl x11grab > > die_license_disabled nonfree libaacplus > die_license_disabled nonfree libfaac > -die_license_disabled nonfree nvenc Sorry, but this makes absolutely no sense imo: I asked you if nvenc is a system library and your answer did not indicate that you are certain it is a system library (and I did ask you if I maybe misunderstood your answer), If it is not a system library, you must not remove this line. If it is a system library, please enable auto-detection as we already have enough untested features and as we generally do autodetect system libraries. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sbr_qmf_analysis: sanitize input for 32-bit imdct
On 02.12.2015 20:58, Andreas Cadhalpun wrote: > On 19.11.2015 01:02, Andreas Cadhalpun wrote: >> If the input contains too many too large values, the imdct can overflow. >> Even if it didn't, the output would be larger than the valid range of 29 >> bits. >> >> Note that this is a very delicate limit: Allowing values up to 1<<25 >> does not prevent input larger than 1<<29 from arriving at >> sbr_sum_square, while limiting values to 1<<23 breaks the >> fate-aac-fixed-al_sbr_hq_cm_48_5.1 test. >> >> Signed-off-by: Andreas Cadhalpun >> --- >> >> Nedeljko, do you have an explanation why larger input values here >> are invalid? >> >> By the way, the imdct calculations in imdct_and_windowing and >> sbr_qmf_synthesis can also overflow, so maybe need a similar check. >> >> --- >> libavcodec/aacsbr_template.c | 18 ++ >> 1 file changed, 18 insertions(+) >> >> diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c >> index 66f4159..f48ddd0 100644 >> --- a/libavcodec/aacsbr_template.c >> +++ b/libavcodec/aacsbr_template.c >> @@ -1153,6 +1153,9 @@ static void sbr_qmf_analysis(AVFloatDSPContext *dsp, >> FFTContext *mdct, >> INTFLOAT z[320], INTFLOAT W[2][32][32][2], int >> buf_idx) >> { >> int i; >> +#if USE_FIXED >> +int j; >> +#endif >> memcpy(x, x+1024, (320-32)*sizeof(x[0])); >> memcpy(x+288, in, 1024*sizeof(x[0])); >> for (i = 0; i < 32; i++) { // numTimeSlots*RATE = 16*2 as 960 sample >> frames >> @@ -1160,6 +1163,21 @@ static void sbr_qmf_analysis(AVFloatDSPContext *dsp, >> FFTContext *mdct, >> dsp->vector_fmul_reverse(z, sbr_qmf_window_ds, x, 320); >> sbrdsp->sum64x5(z); >> sbrdsp->qmf_pre_shuffle(z); >> +#if USE_FIXED >> +for (j = 64; j < 128; j++) { >> +if (z[j] > 1<<24) { >> +av_log(NULL, AV_LOG_WARNING, >> + "sbr_qmf_analysis: value %09d too large, setting to >> %09d\n", >> + z[j], 1<<24); >> +z[j] = 1<<24; >> +} else if (z[j] < -(1<<24)) { >> +av_log(NULL, AV_LOG_WARNING, >> + "sbr_qmf_analysis: value %09d too small, setting to >> %09d\n", >> + z[j], -(1<<24)); >> +z[j] = -(1<<24); >> +} >> +} >> +#endif >> mdct->imdct_half(mdct, z, z+64); >> sbrdsp->qmf_post_shuffle(W[buf_idx][i], z); >> x += 32; >> > > Ping. > > If nobody objects, I'll push this soon, as it fixes crashes. I pushed this now. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] aacsbr: ensure strictly monotone time borders
On 02.12.2015 20:57, Andreas Cadhalpun wrote: > On 08.11.2015 22:04, Andreas Cadhalpun wrote: >> This fixes a SIGFPE crash in the aac_fixed decoder. >> >> Signed-off-by: Andreas Cadhalpun >> --- >> libavcodec/aacsbr_template.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c >> index 66f4159..f69d2f8 100644 >> --- a/libavcodec/aacsbr_template.c >> +++ b/libavcodec/aacsbr_template.c >> @@ -718,8 +718,8 @@ static int read_sbr_grid(AACContext *ac, >> SpectralBandReplication *sbr, >> } >> >> for (i = 1; i <= ch_data->bs_num_env; i++) { >> -if (ch_data->t_env[i-1] > ch_data->t_env[i]) { >> -av_log(ac->avctx, AV_LOG_ERROR, "Non monotone time borders\n"); >> +if (ch_data->t_env[i-1] >= ch_data->t_env[i]) { >> +av_log(ac->avctx, AV_LOG_ERROR, "Not strictly monotone time >> borders\n"); >> return -1; >> } >> } >> > > Ping. > > Unless there are objections, I'll push this soon, as it fixes crashes. I pushed this now. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/libvo-aac: Mark the encoder as experimental
On Wednesday 09 December 2015 09:24:06 pm Hendrik Leppkes wrote: > On Wed, Dec 9, 2015 at 7:09 PM, James Almer wrote: > > On 12/5/2015 9:31 PM, Carl Eugen Hoyos wrote: > >> Hi! > >> > >> I prefer attached patch over removing the encoder immediately. > And its quality is horrible. > > No idea why we would mark it experimental however. The built-in > encoder will always take precedence, so a user has to explicitly > request it as it is. I am thinking of the many scripts using libvo-aac and the many users who automatically request it with -c:a whenever they encode aac. I will commit in a few days if there are no objections. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] x86/hevc_sao: simplify sao_band_filter 10/12bit
Signed-off-by: James Almer --- libavcodec/x86/hevc_sao_10bit.asm | 142 +++--- 1 file changed, 57 insertions(+), 85 deletions(-) diff --git a/libavcodec/x86/hevc_sao_10bit.asm b/libavcodec/x86/hevc_sao_10bit.asm index f45fc56..3a7048a 100644 --- a/libavcodec/x86/hevc_sao_10bit.asm +++ b/libavcodec/x86/hevc_sao_10bit.asm @@ -83,7 +83,6 @@ SECTION .text mova [rsp+mmsize*6], m6 mova m1, [pw_mask %+ %1] pxor m0, m0 -%assign MMSIZE mmsize %define m14 m0 %define m13 m1 %define m9 m2 @@ -93,37 +92,6 @@ DEFINE_ARGS dst, src, dststride, srcstride, offset, height mov heightd, r7m %endmacro -%macro HEVC_SAO_BAND_FILTER_COMPUTE 3 -psraw %2, %3, %1-5 -%if ARCH_X86_64 -pcmpeqw m10, %2, m0 -pcmpeqw m11, %2, m1 -pcmpeqw m12, %2, m2 -pcmpeqw %2, m3 -pand m10, m4 -pand m11, m5 -pand m12, m6 -pand %2, m7 -por m10, m11 -por m12, %2 -por m10, m12 -paddw %3, m10 -%else ; ARCH_X86_32 -pcmpeqw m4, %2, [rsp+MMSIZE*0] -pcmpeqw m5, %2, [rsp+MMSIZE*1] -pcmpeqw m6, %2, [rsp+MMSIZE*2] -pcmpeqw %2, [rsp+MMSIZE*3] -pand m4, [rsp+MMSIZE*4] -pand m5, [rsp+MMSIZE*5] -pand m6, [rsp+MMSIZE*6] -pand %2, m7 -por m4, m5 -por m6, %2 -por m4, m6 -paddw %3, m4 -%endif ; ARCH -%endmacro - ;void ff_hevc_sao_band_filter___(uint8_t *_dst, uint8_t *_src, ptrdiff_t _stride_dst, ptrdiff_t _stride_src, ; int16_t *sao_offset_val, int sao_left_class, int width, int height); %macro HEVC_SAO_BAND_FILTER 3 @@ -132,43 +100,47 @@ cglobal hevc_sao_band_filter_%2_%1, 6, 6, 15, 7*mmsize*ARCH_X86_32, dst, src, ds align 16 .loop: -%if %2 == 8 -movu m8, [srcq] -HEVC_SAO_BAND_FILTER_COMPUTE %1, m9, m8 -CLIPW m8, m14, m13 -movu [dstq], m8 -%endif %assign i 0 +%assign j 0 %rep %3 -mova m8, [srcq + i] -HEVC_SAO_BAND_FILTER_COMPUTE %1, m9, m8 -CLIPW m8, m14, m13 -mova [dstq + i], m8 - -mova m9, [srcq + i + mmsize] -HEVC_SAO_BAND_FILTER_COMPUTE %1, m8, m9 -CLIPW m9, m14, m13 -mova [dstq + i + mmsize], m9 -%assign i i+mmsize*2 +%assign k 8+(j&1) +%assign l 9-(j&1) +mova m %+ k, [srcq + i] +psraw m %+ l, m %+ k, %1-5 +%if ARCH_X86_64 +pcmpeqw m10, m %+ l, m0 +pcmpeqw m11, m %+ l, m1 +pcmpeqw m12, m %+ l, m2 +pcmpeqw m %+ l, m3 +pand m10, m4 +pand m11, m5 +pand m12, m6 +pand m %+ l, m7 +por m10, m11 +por m12, m %+ l +por m10, m12 +paddw m %+ k, m10 +%else ; ARCH_X86_32 +pcmpeqw m4, m %+ l, [rsp+mmsize*0] +pcmpeqw m5, m %+ l, [rsp+mmsize*1] +pcmpeqw m6, m %+ l, [rsp+mmsize*2] +pcmpeqw m %+ l, [rsp+mmsize*3] +pand m4, [rsp+mmsize*4] +pand m5, [rsp+mmsize*5] +pand m6, [rsp+mmsize*6] +pand m %+ l, m7 +por m4, m5 +por m6, m %+ l +por m4, m6 +paddw m %+ k, m4 +%endif ; ARCH +CLIPW m %+ k, m14, m13 +mova [dstq + i], m %+ k +%assign i i+mmsize +%assign j j+1 %endrep -%if %2 == 48 -INIT_XMM cpuname -mova m8, [srcq + i] -HEVC_SAO_BAND_FILTER_COMPUTE %1, m9, m8 -CLIPW m8, m14, m13 -mova [dstq + i], m8 - -mova m9, [srcq + i + mmsize] -HEVC_SAO_BAND_FILTER_COMPUTE %1, m8, m9 -CLIPW m9, m14, m13 -mova [dstq + i + mmsize], m9 -%if cpuflag(avx2) -INIT_YMM cpuname -%endif -%endif ; %1 == 48 - add dstq, dststrideq add srcq, srcstrideq dec heightd @@ -177,17 +149,17 @@ INIT_YMM cpuname %endmacro %macro HEVC_SAO_BAND_FILTER_FUNCS 0 -HEVC_SAO_BAND_FILTER 10, 8, 0 -HEVC_SAO_BAND_FILTER 10, 16, 1 -HEVC_SAO_BAND_FILTER 10, 32, 2 -HEVC_SAO_BAND_FILTER 10, 48, 2 -HEVC_SAO_BAND_FILTER 10, 64, 4 - -HEVC_SAO_BAND_FILTER 12, 8, 0 -HEVC_SAO_BAND_FILTER 12, 16, 1 -HEVC_SAO_BAND_FILTER 12, 32, 2 -HEVC_SAO_BAND_FILTER 12, 48, 2 -HEVC_SAO_BAND_FILTER 12, 64, 4 +HEVC_SAO_BAND_FILTER 10, 8, 1 +HEVC_SAO_BAND_FILTER 10, 16, 2 +HEVC_SAO_BAND_FILTER 10, 32, 4 +HEVC_SAO_BAND_FILTER 10, 48, 6 +HEVC_SAO_BAND_FILTER 10, 64, 8 + +HEVC_SAO_BAND_FILTER 12, 8, 1 +HEVC_SAO_BAND_FILTER 12, 16, 2 +HEVC_SAO_BAND_FILTER 12, 32, 4 +HEVC_SAO_BAND_FILTER 12, 48, 6 +HEVC_SAO_BAND_FILTER
[FFmpeg-devel] [PATCH] avfilter: add SOFAlizer audio filter
Signed-off-by: Paul B Mahol --- Lite version of one sent to VLC mailing list with only slow but high quality mode present. To use you need recent netCDF library, SOFA file(s), multichannel audio and headphones. --- configure | 4 + libavfilter/Makefile | 1 + libavfilter/af_sofalizer.c | 932 + libavfilter/allfilters.c | 1 + libavfilter/formats.c | 11 + libavfilter/formats.h | 3 + 6 files changed, 952 insertions(+) create mode 100644 libavfilter/af_sofalizer.c diff --git a/configure b/configure index afac1bc..71b2d36 100755 --- a/configure +++ b/configure @@ -279,6 +279,7 @@ External library support: --disable-lzma disable lzma [autodetect] --enable-decklinkenable Blackmagic DeckLink I/O support [no] --enable-mmalenable decoding via MMAL [no] + --enable-netcdf enable NetCDF, needed for sofalizer filter [no] --enable-nvenc enable NVIDIA NVENC support [no] --enable-openal enable OpenAL 1.1 capture support [no] --enable-opencl enable OpenCL code @@ -1504,6 +1505,7 @@ EXTERNAL_LIBRARY_LIST=" libzvbi lzma mmal +netcdf nvenc openal opencl @@ -2891,6 +2893,7 @@ showfreqs_filter_deps="avcodec" showfreqs_filter_select="fft" showspectrum_filter_deps="avcodec" showspectrum_filter_select="rdft" +sofalizer_filter_deps="netcdf" spp_filter_deps="gpl avcodec" spp_filter_select="fft idctdsp fdctdsp me_cmp pixblockdsp" stereo3d_filter_deps="gpl" @@ -5502,6 +5505,7 @@ enabled mmal && { check_lib interface/mmal/mmal.h mmal_port_connect check_lib interface/mmal/mmal.h mmal_port_connect ; } check_lib interface/mmal/mmal.h mmal_port_connect ; } || die "ERROR: mmal not found"; } +enabled netcdf&& require_pkg_config netcdf netcdf.h nc_inq_libvers enabled nvenc && { check_header nvEncodeAPI.h || die "ERROR: nvEncodeAPI.h not found."; } && { check_cpp_condition nvEncodeAPI.h "NVENCAPI_MAJOR_VERSION >= 5" || die "ERROR: NVENC API version 4 or older is not supported"; } && diff --git a/libavfilter/Makefile b/libavfilter/Makefile index 8884d1d..d7a3f61 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -87,6 +87,7 @@ OBJS-$(CONFIG_SIDECHAINCOMPRESS_FILTER) += af_sidechaincompress.o OBJS-$(CONFIG_SIDECHAINGATE_FILTER) += af_agate.o OBJS-$(CONFIG_SILENCEDETECT_FILTER) += af_silencedetect.o OBJS-$(CONFIG_SILENCEREMOVE_FILTER) += af_silenceremove.o +OBJS-$(CONFIG_SOFALIZER_FILTER) += af_sofalizer.o OBJS-$(CONFIG_STEREOTOOLS_FILTER)+= af_stereotools.o OBJS-$(CONFIG_STEREOWIDEN_FILTER)+= af_stereowiden.o OBJS-$(CONFIG_TREBLE_FILTER) += af_biquads.o diff --git a/libavfilter/af_sofalizer.c b/libavfilter/af_sofalizer.c new file mode 100644 index 000..52cd09c --- /dev/null +++ b/libavfilter/af_sofalizer.c @@ -0,0 +1,932 @@ +/* + * sofalizer.c : SOFAlizer filter for virtual binaural acoustics + * + * Copyright (C) 2013-2015 Andreas Fuchs, Wolfgang Hrauda, + * Acoustics Research Institute (ARI), Vienna, Austria + * + * Authors: Andreas Fuchs + * Wolfgang Hrauda + * + * SOFAlizer project coordinator at ARI, main developer of SOFA: + * Piotr Majdak + * + * This program 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. + * + * This program 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 +#include + +#include "libavutil/opt.h" +#include "avfilter.h" +#include "internal.h" +#include "audio.h" + +typedef struct NCSofa { /* contains data of one SOFA file */ +int ncid;/* netCDF ID of the opened SOFA file */ +int n_samples; /* length of one impulse response (IR) */ +int m_dim; /* number of measurement positions */ +int *data_delay; /* broadband delay of each IR */ +
[FFmpeg-devel] [PATCH 3/3] x86/hevc_sao: add ff_hevc_sao_edge_filter_{8, 16}_{10, 12}
Signed-off-by: James Almer --- libavcodec/x86/hevc_sao_10bit.asm | 9 - libavcodec/x86/hevcdsp_init.c | 8 ++-- 2 files changed, 10 insertions(+), 7 deletions(-) diff --git a/libavcodec/x86/hevc_sao_10bit.asm b/libavcodec/x86/hevc_sao_10bit.asm index 79776ac..f81e2d5 100644 --- a/libavcodec/x86/hevc_sao_10bit.asm +++ b/libavcodec/x86/hevc_sao_10bit.asm @@ -252,7 +252,7 @@ cglobal hevc_sao_edge_filter_%2_%1, 1, 6, 8, 5*mmsize, dst, src, dststride, a_st %endif ; ARCH -%if cpuflag(avx2) +%if mmsize > 16 SPLATWm8, [offsetq+2] SPLATWm9, [offsetq+4] SPLATW m10, [offsetq+0] @@ -352,11 +352,18 @@ HEVC_SAO_EDGE_FILTER 12, 48, 6 HEVC_SAO_EDGE_FILTER 12, 64, 8 %if HAVE_AVX2_EXTERNAL +INIT_XMM avx2 +HEVC_SAO_EDGE_FILTER 10, 8, 1 INIT_YMM avx2 +HEVC_SAO_EDGE_FILTER 10, 16, 1 HEVC_SAO_EDGE_FILTER 10, 32, 2 HEVC_SAO_EDGE_FILTER 10, 48, 3 HEVC_SAO_EDGE_FILTER 10, 64, 4 +INIT_XMM avx2 +HEVC_SAO_EDGE_FILTER 12, 8, 1 +INIT_YMM avx2 +HEVC_SAO_EDGE_FILTER 12, 16, 1 HEVC_SAO_EDGE_FILTER 12, 32, 2 HEVC_SAO_EDGE_FILTER 12, 48, 3 HEVC_SAO_EDGE_FILTER 12, 64, 4 diff --git a/libavcodec/x86/hevcdsp_init.c b/libavcodec/x86/hevcdsp_init.c index 2181f6d..0de0163 100644 --- a/libavcodec/x86/hevcdsp_init.c +++ b/libavcodec/x86/hevcdsp_init.c @@ -1045,9 +1045,7 @@ void ff_hevc_dsp_init_x86(HEVCDSPContext *c, const int bit_depth) c->put_hevc_qpel_bi[9][1][1] = ff_hevc_put_hevc_bi_qpel_hv64_10_avx2; } SAO_BAND_INIT(10, avx2); -c->sao_edge_filter[2] = ff_hevc_sao_edge_filter_32_10_avx2; -c->sao_edge_filter[3] = ff_hevc_sao_edge_filter_48_10_avx2; -c->sao_edge_filter[4] = ff_hevc_sao_edge_filter_64_10_avx2; +SAO_EDGE_INIT(10, avx2); c->transform_add[2] = ff_hevc_transform_add16_10_avx2; c->transform_add[3] = ff_hevc_transform_add32_10_avx2; @@ -1101,9 +1099,7 @@ void ff_hevc_dsp_init_x86(HEVCDSPContext *c, const int bit_depth) c->idct_dc[3] = ff_hevc_idct32x32_dc_12_avx2; SAO_BAND_INIT(12, avx2); -c->sao_edge_filter[2] = ff_hevc_sao_edge_filter_32_12_avx2; -c->sao_edge_filter[3] = ff_hevc_sao_edge_filter_48_12_avx2; -c->sao_edge_filter[4] = ff_hevc_sao_edge_filter_64_12_avx2; +SAO_EDGE_INIT(12, avx2); } } } -- 2.6.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] x86/hevc_sao: simplify sao_edge_filter 10/12bit
Signed-off-by: James Almer --- libavcodec/x86/hevc_sao_10bit.asm | 150 ++ 1 file changed, 54 insertions(+), 96 deletions(-) diff --git a/libavcodec/x86/hevc_sao_10bit.asm b/libavcodec/x86/hevc_sao_10bit.asm index 3a7048a..79776ac 100644 --- a/libavcodec/x86/hevc_sao_10bit.asm +++ b/libavcodec/x86/hevc_sao_10bit.asm @@ -221,46 +221,6 @@ HEVC_SAO_BAND_FILTER 12, 64, 4 addb_strideq, tmpq %endmacro -%macro HEVC_SAO_EDGE_FILTER_COMPUTE 0 -PMINUWm4, m1, m2, m6 -PMINUWm5, m1, m3, m7 -pcmpeqw m2, m4 -pcmpeqw m3, m5 -pcmpeqw m4, m1 -pcmpeqw m5, m1 -psubw m4, m2 -psubw m5, m3 - -paddw m4, m5 -pcmpeqw m2, m4, [pw_m2] -%if ARCH_X86_64 -pcmpeqw m3, m4, m13 -pcmpeqw m5, m4, m0 -pcmpeqw m6, m4, m14 -pcmpeqw m7, m4, m15 -pand m2, m8 -pand m3, m9 -pand m5, m10 -pand m6, m11 -pand m7, m12 -%else -pcmpeqw m3, m4, [pw_m1] -pcmpeqw m5, m4, m0 -pcmpeqw m6, m4, [pw_1] -pcmpeqw m7, m4, [pw_2] -pand m2, [rsp+MMSIZE*0] -pand m3, [rsp+MMSIZE*1] -pand m5, [rsp+MMSIZE*2] -pand m6, [rsp+MMSIZE*3] -pand m7, [rsp+MMSIZE*4] -%endif -paddw m2, m3 -paddw m5, m6 -paddw m2, m7 -paddw m2, m1 -paddw m2, m5 -%endmacro - ;void ff_hevc_sao_edge_filter___(uint8_t *_dst, uint8_t *_src, ptrdiff_t stride_dst, int16_t *sao_offset_val, ; int eo, int width, int height); %macro HEVC_SAO_EDGE_FILTER 3 @@ -274,7 +234,6 @@ cglobal hevc_sao_edge_filter_%2_%1, 4, 9, 16, dst, src, dststride, offset, eo, a %else ; ARCH_X86_32 cglobal hevc_sao_edge_filter_%2_%1, 1, 6, 8, 5*mmsize, dst, src, dststride, a_stride, b_stride, height -%assign MMSIZE mmsize %define eoq srcq %define tmpq heightq %define tmp2q dststrideq @@ -325,54 +284,53 @@ cglobal hevc_sao_edge_filter_%2_%1, 1, 6, 8, 5*mmsize, dst, src, dststride, a_st align 16 .loop: -%if %2 == 8 -mova m1, [srcq] -movu m2, [srcq+a_strideq] -movu m3, [srcq+b_strideq] - -HEVC_SAO_EDGE_FILTER_COMPUTE -CLIPW m2, m0, [pw_mask %+ %1] -movu [dstq], m2 -%endif - %assign i 0 %rep %3 mova m1, [srcq + i] movu m2, [srcq+a_strideq + i] movu m3, [srcq+b_strideq + i] -HEVC_SAO_EDGE_FILTER_COMPUTE -CLIPW m2, m0, [pw_mask %+ %1] -mova [dstq + i], m2 +PMINUWm4, m1, m2, m6 +PMINUWm5, m1, m3, m7 +pcmpeqw m2, m4 +pcmpeqw m3, m5 +pcmpeqw m4, m1 +pcmpeqw m5, m1 +psubw m4, m2 +psubw m5, m3 -mova m1, [srcq + i + mmsize] -movu m2, [srcq+a_strideq + i + mmsize] -movu m3, [srcq+b_strideq + i + mmsize] -HEVC_SAO_EDGE_FILTER_COMPUTE +paddw m4, m5 +pcmpeqw m2, m4, [pw_m2] +%if ARCH_X86_64 +pcmpeqw m3, m4, m13 +pcmpeqw m5, m4, m0 +pcmpeqw m6, m4, m14 +pcmpeqw m7, m4, m15 +pand m2, m8 +pand m3, m9 +pand m5, m10 +pand m6, m11 +pand m7, m12 +%else +pcmpeqw m3, m4, [pw_m1] +pcmpeqw m5, m4, m0 +pcmpeqw m6, m4, [pw_1] +pcmpeqw m7, m4, [pw_2] +pand m2, [rsp+mmsize*0] +pand m3, [rsp+mmsize*1] +pand m5, [rsp+mmsize*2] +pand m6, [rsp+mmsize*3] +pand m7, [rsp+mmsize*4] +%endif +paddw m2, m3 +paddw m5, m6 +paddw m2, m7 +paddw m2, m1 +paddw m2, m5 CLIPW m2, m0, [pw_mask %+ %1] -mova [dstq + i + mmsize], m2 -%assign i i+mmsize*2 +mova [dstq + i], m2 +%assign i i+mmsize %endrep -%if %2 == 48 -INIT_XMM cpuname -mova m1, [srcq + i] -movu m2, [srcq+a_strideq + i] -movu m3, [srcq+b_strideq + i] -HEVC_SAO_EDGE_FILTER_COMPUTE -CLIPW m2, m0, [pw_mask %+ %1] -mova [dstq + i], m2 - -mova m1, [srcq + i + mmsize] -movu m2, [srcq+a_strideq + i + mmsize] -movu m3, [srcq+b_strideq + i + mmsize] -HEVC_SAO_EDGE_FILTER_COMPUTE -CLIPW m2, m0, [pw_mask %+ %1] -mova [dstq + i + mmsize], m2 -%if cpuflag(avx2) -INIT_YMM cpuname -%endif -%end
[FFmpeg-devel] [PATCH]lavf/matroskadec: Set codec_tag also for audio codecs
Hi! Attached patch is definitely a good idea imo, the mov demuxer also sets codec_tag reading the same atom, for "A_MS/ACM" codec_tag is already set. Please comment, Carl Eugen diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c index aad567a..95cebdd 100644 --- a/libavformat/matroskadec.c +++ b/libavformat/matroskadec.c @@ -2124,6 +2124,7 @@ static int matroska_parse_tracks(AVFormatContext *s) } } else if (track->type == MATROSKA_TRACK_TYPE_AUDIO) { st->codec->codec_type = AVMEDIA_TYPE_AUDIO; +st->codec->codec_tag = fourcc; st->codec->sample_rate = track->audio.out_samplerate; st->codec->channels= track->audio.channels; if (!st->codec->bits_per_coded_sample) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avformat/mpegtsenc: Add basic multi program support
From: Michael Niedermayer Signed-off-by: Michael Niedermayer --- libavformat/mpegtsenc.c | 57 ++- 1 file changed, 42 insertions(+), 15 deletions(-) diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c index 055e441..19032f3 100644 --- a/libavformat/mpegtsenc.c +++ b/libavformat/mpegtsenc.c @@ -273,6 +273,12 @@ static int mpegts_write_pmt(AVFormatContext *s, MpegTSService *service) MpegTSWriteStream *ts_st = st->priv_data; AVDictionaryEntry *lang = av_dict_get(st->metadata, "language", NULL, 0); +if (s->nb_programs) { +AVProgram *program = av_find_program_from_stream(s, NULL, i); +if (program->id != service->sid) +continue; +} + if (q - data > SECTION_LENGTH - 32) { err = 1; break; @@ -719,22 +725,43 @@ static int mpegts_write_header(AVFormatContext *s) ts->tsid = ts->transport_stream_id; ts->onid = ts->original_network_id; -/* allocate a single DVB service */ -title = av_dict_get(s->metadata, "service_name", NULL, 0); -if (!title) -title = av_dict_get(s->metadata, "title", NULL, 0); -service_name = title ? title->value : DEFAULT_SERVICE_NAME; -provider = av_dict_get(s->metadata, "service_provider", NULL, 0); -provider_name = provider ? provider->value : DEFAULT_PROVIDER_NAME; -service = mpegts_add_service(ts, ts->service_id, - provider_name, service_name); - -if (!service) -return AVERROR(ENOMEM); +if (!s->nb_programs) { +/* allocate a single DVB service */ +title = av_dict_get(s->metadata, "service_name", NULL, 0); +if (!title) +title = av_dict_get(s->metadata, "title", NULL, 0); +service_name = title ? title->value : DEFAULT_SERVICE_NAME; +provider = av_dict_get(s->metadata, "service_provider", NULL, 0); +provider_name = provider ? provider->value : DEFAULT_PROVIDER_NAME; +service = mpegts_add_service(ts, ts->service_id, + provider_name, service_name); + +if (!service) +return AVERROR(ENOMEM); + +service->pmt.write_packet = section_write_packet; +service->pmt.opaque = s; +service->pmt.cc = 15; +} else { +for (i = 0; i < s->nb_programs; i++) { +AVProgram *program = s->programs[i]; +title = av_dict_get(program->metadata, "service_name", NULL, 0); +if (!title) +title = av_dict_get(program->metadata, "title", NULL, 0); +service_name = title ? title->value : DEFAULT_SERVICE_NAME; +provider = av_dict_get(program->metadata, "service_provider", NULL, 0); +provider_name = provider ? provider->value : DEFAULT_PROVIDER_NAME; +service = mpegts_add_service(ts, program->id, + provider_name, service_name); + +if (!service) +return AVERROR(ENOMEM); -service->pmt.write_packet = section_write_packet; -service->pmt.opaque = s; -service->pmt.cc = 15; +service->pmt.write_packet = section_write_packet; +service->pmt.opaque = s; +service->pmt.cc = 15; +} +} ts->pat.pid = PAT_PID; /* Initialize at 15 so that it wraps and is equal to 0 for the -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] diracdec: Fix FPE on invalid low_delay data
On Wed, Dec 09, 2015 at 12:56:02AM +, Kieran Kunhya wrote: > --- > libavcodec/diracdec.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c > index 6a53f38..0542ad7 100644 > --- a/libavcodec/diracdec.c > +++ b/libavcodec/diracdec.c > @@ -2043,6 +2043,11 @@ static int dirac_decode_data_unit(AVCodecContext > *avctx, const uint8_t *buf, int > if (s->version.minor == 2 && parse_code == 0x88) > s->ld_picture = 1; > > +if (s->low_delay && !(s->ld_picture || s->hq_picture) ) { > +av_log(avctx, AV_LOG_ERROR, "Invalid low delay flag\n"); > +return AVERROR_INVALIDDATA; > +} this should be merged with the patch needing this bugfix or commited before it LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 10/11] diracdec: Read picture types by using parse_code
On Wed, Dec 09, 2015 at 12:05:36AM +, Kieran Kunhya wrote: > --- > libavcodec/diracdec.c | 57 > +-- > 1 file changed, 42 insertions(+), 15 deletions(-) should be ok thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 08/11] diracdec: Support new extended quantiser range
On Wed, Dec 09, 2015 at 12:05:34AM +, Kieran Kunhya wrote: > --- > libavcodec/diracdec.c | 58 > --- > 1 file changed, 37 insertions(+), 21 deletions(-) LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avformat: Add av_program_add_stream_index()
From: Michael Niedermayer This will be used by the subsequent commit(s) Signed-off-by: Michael Niedermayer --- doc/APIchanges |3 +++ libavformat/avformat.h |2 ++ libavformat/hls.c |2 +- libavformat/internal.h |2 -- libavformat/mpegts.c |4 ++-- libavformat/utils.c|2 +- 6 files changed, 9 insertions(+), 6 deletions(-) diff --git a/doc/APIchanges b/doc/APIchanges index 5b91bb4..499bff8 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -14,6 +14,9 @@ libavutil: 2015-08-28 API changes, most recent first: +2015-12-XX - xxx - lavf xx.xx.xxx - avformat.h + Add av_program_add_stream_index() + 2015-11-29 - xxx - lavc 57.16.101 - avcodec.h Deprecate rtp_callback without replacement, i.e. it won't be possible to get image slices before the full frame is encoded any more. The libavformat diff --git a/libavformat/avformat.h b/libavformat/avformat.h index 36f9d02..ddf07b1 100644 --- a/libavformat/avformat.h +++ b/libavformat/avformat.h @@ -2114,6 +2114,8 @@ int avformat_find_stream_info(AVFormatContext *ic, AVDictionary **options); */ AVProgram *av_find_program_from_stream(AVFormatContext *ic, AVProgram *last, int s); +void av_program_add_stream_index(AVFormatContext *ac, int progid, unsigned int idx); + /** * Find the "best" stream in the file. * The best stream is determined according to various heuristics as the most diff --git a/libavformat/hls.c b/libavformat/hls.c index ccae270..2d4ee13 100644 --- a/libavformat/hls.c +++ b/libavformat/hls.c @@ -1668,7 +1668,7 @@ static int hls_read_header(AVFormatContext *s) for (k = 0; k < pls->ctx->nb_streams; k++) { struct AVStream *st = s->streams[pls->stream_offset + k]; -ff_program_add_stream_index(s, i, pls->stream_offset + k); +av_program_add_stream_index(s, i, pls->stream_offset + k); /* Set variant_bitrate for streams unique to this variant */ if (!is_shared && v->bandwidth) diff --git a/libavformat/internal.h b/libavformat/internal.h index 90f0a61..4297cb8 100644 --- a/libavformat/internal.h +++ b/libavformat/internal.h @@ -156,8 +156,6 @@ char *ff_data_to_hex(char *buf, const uint8_t *src, int size, int lowercase); */ int ff_hex_to_data(uint8_t *data, const char *p); -void ff_program_add_stream_index(AVFormatContext *ac, int progid, unsigned int idx); - /** * Add packet to AVFormatContext->packet_buffer list, determining its * interleaved position using compare() function argument. diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c index 4a6a5e5..7a905a4 100644 --- a/libavformat/mpegts.c +++ b/libavformat/mpegts.c @@ -1958,7 +1958,7 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t *section, int section_len add_pid_to_pmt(ts, h->id, pid); -ff_program_add_stream_index(ts->stream, h->id, st->index); +av_program_add_stream_index(ts->stream, h->id, st->index); desc_list_len = get16(&p, p_end); if (desc_list_len < 0) @@ -1975,7 +1975,7 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t *section, int section_len if (pes && prog_reg_desc == AV_RL32("HDMV") && stream_type == 0x83 && pes->sub_st) { -ff_program_add_stream_index(ts->stream, h->id, +av_program_add_stream_index(ts->stream, h->id, pes->sub_st->index); pes->sub_st->codec->codec_tag = st->codec->codec_tag; } diff --git a/libavformat/utils.c b/libavformat/utils.c index 1103a64..2f864c6 100644 --- a/libavformat/utils.c +++ b/libavformat/utils.c @@ -3915,7 +3915,7 @@ AVChapter *avpriv_new_chapter(AVFormatContext *s, int id, AVRational time_base, return chapter; } -void ff_program_add_stream_index(AVFormatContext *ac, int progid, unsigned idx) +void av_program_add_stream_index(AVFormatContext *ac, int progid, unsigned idx) { int i, j; AVProgram *program = NULL; -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] ffmpeg: Add basic support to mux multiple programs
From: Michael Niedermayer TODO: add docs Signed-off-by: Michael Niedermayer --- ffmpeg.h |2 ++ ffmpeg_opt.c | 38 ++ 2 files changed, 40 insertions(+) diff --git a/ffmpeg.h b/ffmpeg.h index 82ab1ee..fa24910 100644 --- a/ffmpeg.h +++ b/ffmpeg.h @@ -216,6 +216,8 @@ typedef struct OptionsContext { intnb_discard; SpecifierOpt *disposition; intnb_disposition; +SpecifierOpt *program; +intnb_program; } OptionsContext; typedef struct InputFilter { diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c index 131dd89..0102113 100644 --- a/ffmpeg_opt.c +++ b/ffmpeg_opt.c @@ -2414,6 +2414,42 @@ loop_end: } } +/* process manually set programs */ +for (i = 0; i < o->nb_program; i++) { +const char *p = o->program[i].u.str; +int progid = i+1; +AVProgram *program = av_new_program(oc, progid); + +while(*p) { +const char *p2 = av_get_token(&p, ":"); +char *key; +if (!p2) +break; +if(*p) p++; + +key = av_get_token(&p2, "="); +if (!key) { +av_log(NULL, AV_LOG_FATAL, + "No '=' character in program string %s.\n", + p2); +exit_program(1); +} +if (!*p2) +exit_program(1); +p2++; + +if (!strcmp(key, "title")) { +av_dict_set(&program->metadata, "title", p2, 0); +} else if (!strcmp(key, "st")) { +int st_num = strtol(p2, NULL, 0); +av_program_add_stream_index(oc, progid, st_num); +} else { +av_log(NULL, AV_LOG_FATAL, "Unknown program key %s.\n", key); +exit_program(1); +} +} +} + return 0; } @@ -3093,6 +3129,8 @@ const OptionDef options[] = { "set the recording timestamp ('now' to set the current time)", "time" }, { "metadata", HAS_ARG | OPT_STRING | OPT_SPEC | OPT_OUTPUT, { .off = OFFSET(metadata) }, "add metadata", "string=string" }, +{ "program",HAS_ARG | OPT_STRING | OPT_SPEC | OPT_OUTPUT, { .off = OFFSET(program) }, +"add program with specified streams", "string=name:st0:st1:..." }, { "dframes",HAS_ARG | OPT_PERFILE | OPT_EXPERT | OPT_OUTPUT, { .func_arg = opt_data_frames }, "set the number of data frames to output", "number" }, -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avutil/random_seed: use arc4random() when available
On Wed, Dec 9, 2015 at 8:08 AM, Ganesh Ajjanagadde wrote: > On Sun, Dec 6, 2015 at 10:56 PM, Ganesh Ajjanagadde > wrote: >> arc4random() was designed as a superior interface for system random >> number generation, designed for OpenBSD. It is thus an improvement to >> use it whenever available. >> >> As a side note, this may or may not get included in glibc, and there is >> a proposal to create a posix_random family based on these ideas: >> http://austingroupbugs.net/view.php?id=859. >> >> Untested as I lack OpenBSD. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> configure | 2 ++ >> libavutil/random_seed.c | 4 >> 2 files changed, 6 insertions(+) >> >> diff --git a/configure b/configure >> index 7530c88..e676269 100755 >> --- a/configure >> +++ b/configure >> @@ -1840,6 +1840,7 @@ MATH_FUNCS=" >> SYSTEM_FUNCS=" >> access >> aligned_malloc >> +arc4random >> clock_gettime >> closesocket >> CommandLineToArgvW >> @@ -5218,6 +5219,7 @@ check_func ${malloc_prefix}memalign&& >> enable memalign >> check_func ${malloc_prefix}posix_memalign && enable posix_memalign >> >> check_func access >> +check_func arc4random >> check_func_headers time.h clock_gettime || { check_func_headers time.h >> clock_gettime -lrt && add_extralibs -lrt && LIBRT="-lrt"; } >> check_func fcntl >> check_func fork >> diff --git a/libavutil/random_seed.c b/libavutil/random_seed.c >> index 8aa8c38..205a636 100644 >> --- a/libavutil/random_seed.c >> +++ b/libavutil/random_seed.c >> @@ -121,6 +121,10 @@ uint32_t av_get_random_seed(void) >> } >> #endif >> >> +#if HAVE_ARC4RANDOM >> +return arc4random(); >> +#endif >> + >> if (read_random(&seed, "/dev/urandom") == sizeof(seed)) >> return seed; >> if (read_random(&seed, "/dev/random") == sizeof(seed)) >> -- >> 2.6.3 >> > > any objections to this: all objections so far have been for 2/2, i.e > for the more controversial one that harnesses libbsd for non-native > functionality? To clarify, none of wm4's comments apply here. It will provide benefits not just to OpenBSD, but also to other BSD's, Mac OS X, and some alternative libc's (not glibc, which refused and continues to refuse arc4random). @Ronald, or anyone else with a Mac: can you please try at least a build test? I have now shelved 2/2, as it has got drawn into a stalemate. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 10.12.2015 20:37, Nicolas George wrote: > Le decadi 20 frimaire, an CCXXIV, Andreas Cadhalpun a écrit : >> Using the header, one could create a dummy libfoo.so containing only >> stub functions. > > Exactly. > >> I don't think the FSF would agree [1]. > > They do not make the law. Neither do you or I. > Claiming that the GPL enforces more than it can is obviously their game. Ultimately, the only definitive answer can come from a court decision, which will hopefully not be needed here. >> The GPL does not require that programs can run, only that distributors >> provide the source code of everything that is needed to run the program, >> except system libraries. >> >> So you can distribute e.g. a GPL binary linking with libfoo.so, without >> distributing libfoo.so, as long as you distribute the source code >> of libfoo.so. >> However, claiming that libfoo.so is not required to run the binary >> would be bizarre. > > Once again, exactly. I agree that having the program not work at all would > probably not be sustainable. But for an optional feature (a codec, for > example), having a GPL-compatible stub libfoo.so that just prints "feature > not available" is perfectly legal. One could argue endlessly about where to draw the line... On the other hand I think we agreed to not enable nvenc by default, so lets just do it that way. That leaves the question of whether or not to include the header, but I have no strong opinion on that. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
Le decadi 20 frimaire, an CCXXIV, Andreas Cadhalpun a écrit : > Using the header, one could create a dummy libfoo.so containing only > stub functions. Exactly. > I don't think the FSF would agree [1]. They do not make the law. Claiming that the GPL enforces more than it can is obviously their game. > The GPL does not require that programs can run, only that distributors > provide the source code of everything that is needed to run the program, > except system libraries. > > So you can distribute e.g. a GPL binary linking with libfoo.so, without > distributing libfoo.so, as long as you distribute the source code > of libfoo.so. > However, claiming that libfoo.so is not required to run the binary > would be bizarre. Once again, exactly. I agree that having the program not work at all would probably not be sustainable. But for an optional feature (a codec, for example), having a GPL-compatible stub libfoo.so that just prints "feature not available" is perfectly legal. And then, you just have to propose the customers to download, on their own responsibility, a proprietary libfoo.so. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 10.12.2015 19:48, Matt Oliver wrote: > On 11 December 2015 at 04:23, Andreas Cadhalpun < > andreas.cadhal...@googlemail.com> wrote: > >> On 10.12.2015 17:42, Matt Oliver wrote: >>> Im not sure that Debian not including libcuda is a valid argument for it >>> not being a system library as thats just one OS. >> >> The GPL defines a system library only in the context of a specific >> operating system. So what is a system library differs from one OS to >> another. >> Therefore one can't just claim something is a system library and thus it's >> fine to use it, unless specifying the specific OS one talks about. >> > > So does that mean that the discussion is not so much about whether it is a > system lib or not but on what OSs it can be considered a system lib? Yes, that's the relevant topic. >> So I dont believe that just because >>> some systems dont have it doesnt stop it from being a system library. >> >> You're treating being a system library as something OS-agnostic, which >> it isn't. A library can be a system library on Windows, but not on Android. >> >> Whether or not it's a system library on Windows doesn't matter for any >> other OS. >> > > OK so by that logic does that mean we can say that it IS a system lib on > Windows and is therefore GPL compliant? If it is a system library on Windows (which I don't know), it is GPL-compatible to distribute a FFmpeg binary for Windows with nvenc enabled. > So then the issue becomes what OSs can we say it is a system lib on. > If the option is disabled by default on > these other OSs then would you agree that ffmpeg is remaining GPL compliant > and its upto the OS distributors who enable the nvenc option when packaging > ffmpeg to be doing so as they also have the appropriate nvenc system libs. Yes, the FFmpeg project doesn't distribute binaries itself, only sources, which is GPL compliant. Thus nvenc is only a potential problem for distributors of compiled ffmpeg binaries. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 10.12.2015 19:03, Nicolas George wrote: > Le decadi 20 frimaire, an CCXXIV, Andreas Cadhalpun a écrit : >> I'm not sure it's that easy. If that were correct, it would become >> GPL-compatible to distribute a GPL-licensed program linked with a >> proprietary library by simply inserting a MIT licensed header in the middle. > > But yes, it is that easy. Well, if you want to use -lfoo instead of > dlopen(), you need libfoo.so too, not just foo.h. Using the header, one could create a dummy libfoo.so containing only stub functions. > But the gist of it is that with dynamic linking, the copyleft limitations > of the GPL are trivial to circumvent. I don't think the FSF would agree [1]. > This is in fact, a good thing, because that shows that copyright is weak. > Remember that the GPL is not a good thing, it is an evil thing: using the > weapons of your enemies against them. If the weapons are weaker than > expected, so much the better. This is not about good or evil. >> The GPL-3 requires that the 'Corresponding Source' of the distributed object >> code >> is also distributed. This is defined as [1]: >> The “Corresponding Source” for a work in object code form means all the >> source >> code needed to generate, install, and (for an executable work) run the object >> code[...] > > Remember that copyright is for works of art. Art has no obligation to work. > If you can run the program until it crashes with "error while loading shared > libraries", then technically it fulfills the requirements of the GPL. > Otherwise, you would be violating the GPL each time you make a bug. The GPL does not require that programs can run, only that distributors provide the source code of everything that is needed to run the program, except system libraries. So you can distribute e.g. a GPL binary linking with libfoo.so, without distributing libfoo.so, as long as you distribute the source code of libfoo.so. However, claiming that libfoo.so is not required to run the binary would be bizarre. Best regards, Andreas 1: https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/8] avfilter/vf_overlay: fix memory leaks
On Thu, Dec 10, 2015 at 7:54 AM, Ganesh Ajjanagadde wrote: > On Thu, Dec 10, 2015 at 3:47 AM, Paul B Mahol wrote: >> On 12/10/15, Ganesh Ajjanagadde wrote: >>> On Wed, Dec 9, 2015 at 6:09 PM, Paul B Mahol wrote: On 12/9/15, Ganesh Ajjanagadde wrote: > On Fri, Dec 4, 2015 at 9:39 AM, Ganesh Ajjanagadde > wrote: >> Recent commits 6aaac24d72a7da631173209841a3944fcb4a3309 and >> 3835554bf8ed78539a3492c239f979c0ab03a15f made progress towards cleaning >> up usage of the formats API, and in particular fixed possible NULL >> pointer >> dereferences. >> >> This commit addresses the issue of possible resource leaks when some >> intermediate >> call fails. >> >> Tested with valgrind --leak-check=full --show-leak-kinds=all, and manual >> simulation >> of malloc/realloc failures. >> >> Fixes: CID 1338327. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavfilter/vf_overlay.c | 32 +++- >> 1 file changed, 23 insertions(+), 9 deletions(-) >> >> diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c >> index 3c61731..68cfb1b 100644 >> --- a/libavfilter/vf_overlay.c >> +++ b/libavfilter/vf_overlay.c >> @@ -252,23 +252,31 @@ static int query_formats(AVFilterContext *ctx) >> switch (s->format) { >> case OVERLAY_FORMAT_YUV420: >> if (!(main_formats= >> ff_make_format_list(main_pix_fmts_yuv420)) || >> -!(overlay_formats = >> ff_make_format_list(overlay_pix_fmts_yuv420))) >> -return AVERROR(ENOMEM); >> +!(overlay_formats = >> ff_make_format_list(overlay_pix_fmts_yuv420))) { >> +ret = AVERROR(ENOMEM); >> +goto fail; >> +} >> break; >> case OVERLAY_FORMAT_YUV422: >> if (!(main_formats= >> ff_make_format_list(main_pix_fmts_yuv422)) || >> -!(overlay_formats = >> ff_make_format_list(overlay_pix_fmts_yuv422))) >> -return AVERROR(ENOMEM); >> +!(overlay_formats = >> ff_make_format_list(overlay_pix_fmts_yuv422))) { >> +ret = AVERROR(ENOMEM); >> +goto fail; >> +} >> break; >> case OVERLAY_FORMAT_YUV444: >> if (!(main_formats= >> ff_make_format_list(main_pix_fmts_yuv444)) || >> -!(overlay_formats = >> ff_make_format_list(overlay_pix_fmts_yuv444))) >> -return AVERROR(ENOMEM); >> +!(overlay_formats = >> ff_make_format_list(overlay_pix_fmts_yuv444))) { >> +ret = AVERROR(ENOMEM); >> +goto fail; >> +} >> break; >> case OVERLAY_FORMAT_RGB: >> if (!(main_formats= ff_make_format_list(main_pix_fmts_rgb)) >> || >> -!(overlay_formats = >> ff_make_format_list(overlay_pix_fmts_rgb))) >> -return AVERROR(ENOMEM); >> +!(overlay_formats = >> ff_make_format_list(overlay_pix_fmts_rgb))) { >> +ret = AVERROR(ENOMEM); >> +goto fail; >> +} >> break; >> default: >> av_assert0(0); >> @@ -277,9 +285,15 @@ static int query_formats(AVFilterContext *ctx) >> if ((ret = ff_formats_ref(main_formats , >> &ctx->inputs[MAIN]->out_formats )) < 0 || >> (ret = ff_formats_ref(overlay_formats, >> &ctx->inputs[OVERLAY]->out_formats)) < 0 || >> (ret = ff_formats_ref(main_formats , >> &ctx->outputs[MAIN]->in_formats )) < 0) >> -return ret; >> +goto fail; >> >> return 0; >> +fail: >> +av_freep(&main_formats->formats); >> +av_freep(&main_formats); >> +av_freep(&overlay_formats->formats); >> +av_freep(&overlay_formats); >> +return ret; >> } >> >> static const enum AVPixelFormat alpha_pix_fmts[] = { >> -- >> 2.6.3 >> > > pushed, with the necessary modification described by Clement This tries to dereference uninitialized value. >>> >>> See right above; I did the desired modification and believe there is no >>> issue. >>> I might be wrong; but if so, could you please refer to the relevant >>> cvslog message? >>> Thanks. >> >> libavfilter/vf_overlay.c:275:13: warning: variable 'overlay_formats' >> is used uninitialized whenever '||' condition is true >> [-Wsometimes-uninitialized] >> if (!(main_formats= ff_make_format_list(main_pix_fmts_rgb)) || >> ^~~ >> libavfilter/vf_overlay.c:295:9: note: uninitialized use occurs here >> if (overlay_formats) >> ^~~ >> libavfilter/vf_overlay.c:275:13: note: remove the '|
[FFmpeg-devel] [PATCH] ffmpeg: change command line option -dump to work without -loglevel debug
-hex and -dump command line options do nothing unless -loglevel debug is set. -dump by itself is useful for monitoring live streams (to get the current PTS for example) however when it is used with -loglevel debug for an RTMP stream, librtmp also dumps the packet data which makes the output too noisy. do_pkt_dump is only set in check_keyboard_interaction or by the -dump command line option so this change should have no effect on any other parts of the code.. diff --git a/ffmpeg.c b/ffmpeg.c index a866f72..6ff45d9 100644 --- a/ffmpeg.c +++ b/ffmpeg.c @@ -3797,7 +3797,7 @@ static int process_input(int file_index) reset_eagain(); if (do_pkt_dump) { -av_pkt_dump_log2(NULL, AV_LOG_DEBUG, &pkt, do_hex_dump, +av_pkt_dump_log2(NULL, AV_LOG_INFO, &pkt, do_hex_dump, is->streams[pkt.stream_index]); } /* the following test is needed in case new streams appear ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 11 December 2015 at 04:23, Andreas Cadhalpun < andreas.cadhal...@googlemail.com> wrote: > On 10.12.2015 17:42, Matt Oliver wrote: > >> > >> What is a system library depends on the system. > >> For example, Debian (main) does not even include libcuda or > >> libnvidia-encode, so they certainly cannot be system libraries > there. > > > >> > > > > Im not sure that Debian not including libcuda is a valid argument for it > > not being a system library as thats just one OS. > > The GPL defines a system library only in the context of a specific > operating system. So what is a system library differs from one OS to > another. > Therefore one can't just claim something is a system library and thus it's > fine to use it, unless specifying the specific OS one talks about. > So does that mean that the discussion is not so much about whether it is a system lib or not but on what OSs it can be considered a system lib? > To me thats the same as > > saying that win32 stuff is not part of a system library because Debian > > doesnt have it (for obvious reasons). > > That's not correct, because Debian does have wine. ;) > lol, good point, probably wasnt the best example to use (its very late here so ill use that as an excuse for brain not working) > So I dont believe that just because > > some systems dont have it doesnt stop it from being a system library. > > You're treating being a system library as something OS-agnostic, which > it isn't. A library can be a system library on Windows, but not on Android. > > Whether or not it's a system library on Windows doesn't matter for any > other OS. > OK so by that logic does that mean we can say that it IS a system lib on Windows and is therefore GPL compliant? So then the issue becomes what OSs can we say it is a system lib on. If the option is disabled by default on these other OSs then would you agree that ffmpeg is remaining GPL compliant and its upto the OS distributors who enable the nvenc option when packaging ffmpeg to be doing so as they also have the appropriate nvenc system libs. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
Le decadi 20 frimaire, an CCXXIV, Andreas Cadhalpun a écrit : > I'm not sure it's that easy. If that were correct, it would become > GPL-compatible to distribute a GPL-licensed program linked with a > proprietary library by simply inserting a MIT licensed header in the middle. But yes, it is that easy. Well, if you want to use -lfoo instead of dlopen(), you need libfoo.so too, not just foo.h. But the gist of it is that with dynamic linking, the copyleft limitations of the GPL are trivial to circumvent. This is in fact, a good thing, because that shows that copyright is weak. Remember that the GPL is not a good thing, it is an evil thing: using the weapons of your enemies against them. If the weapons are weaker than expected, so much the better. > The GPL-3 requires that the 'Corresponding Source' of the distributed object > code > is also distributed. This is defined as [1]: > The “Corresponding Source” for a work in object code form means all the source > code needed to generate, install, and (for an executable work) run the object > code[...] Remember that copyright is for works of art. Art has no obligation to work. If you can run the program until it crashes with "error while loading shared libraries", then technically it fulfills the requirements of the GPL. Otherwise, you would be violating the GPL each time you make a bug. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 10.12.2015 17:42, Matt Oliver wrote: >> >> What is a system library depends on the system. >> For example, Debian (main) does not even include libcuda or >> libnvidia-encode, so they certainly cannot be system libraries there. > >> > > Im not sure that Debian not including libcuda is a valid argument for it > not being a system library as thats just one OS. The GPL defines a system library only in the context of a specific operating system. So what is a system library differs from one OS to another. Therefore one can't just claim something is a system library and thus it's fine to use it, unless specifying the specific OS one talks about. > To me thats the same as > saying that win32 stuff is not part of a system library because Debian > doesnt have it (for obvious reasons). That's not correct, because Debian does have wine. ;) > So I dont believe that just because > some systems dont have it doesnt stop it from being a system library. You're treating being a system library as something OS-agnostic, which it isn't. A library can be a system library on Windows, but not on Android. > And > if a system doesnt have the required propriety libs then they wont be > loaded at runtime and therefore no proprietary code is ever used at all. But distributors of compiled nvenc still have to comply with the GPL. >>> The ffmpeg binary that results from including nvEncodeAPI.h is GPL compatible because nvEncodeAPI.h is MIT licenced. >>> >>> I'm not sure it's that easy. If that were correct, it would become >>> GPL-compatible to distribute a GPL-licensed program linked with a >>> proprietary library by simply inserting a MIT licensed header in the >> middle. >> > > In this case thats not what is being said as we are not actually linking > against anything. Linking via ld.so or dlopen isn't really different from a license point of view. > As if we did link against a propriety lib then you would > be correct and this would brake GPL but that is not the case as the nvenc > binaries are only accessed at runtime. All were doing here is including a > single header file. And again: including the header is not the problem. >>> The only time the GPL ffmpeg and the proprietary licenced nvidia >> libraries are combined is on the end user system so no distribution occurs, so >> the GPL language doesn't apply at that stage. >>> >>> However, the object code compiled from nvenc.c would get distributed as >> part of >>> the ffmpeg binaries, which is governed by the GPL. >> > > The object code from nvenc.c is written using LGPL and just includes > declarations (no actual code definitions) from a MIT header file which to > me suggests that the part of ffmpeg that would be distributed is still GPL > compliant. At no point during the entire compilation and linking stage is > any proprietary component touched so I dont see how this brakes anything. However, running most of the generated object code from nvenc.c requires the non-free blobs. And the GPL specifically also requires the source code for libraries only required at run-time. > So sorry for being verbose (and potential just stating the obvious) but the > only argument here is whether we can consider the libs accessed at runtime > as system libs or not. Yes. > To use windows as a further example all the actual binary code required for > nvenc to work is part of the graphics drivers. So the only time anything > not GPL compliant is ever used is when the dll's are loaded at runtime from > the driver. This definitely puts it in the category of a system component > in my mind. If drivers are not considered system libs then we have far more > serious problems than nvenc ;) Whether or not it's a system library on Windows doesn't matter for any other OS. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 10.12.2015 17:34, Hendrik Leppkes wrote: > Am 10.12.2015 17:10 schrieb "Andreas Cadhalpun" < > andreas.cadhal...@googlemail.com>: >> If that's the only thing that allows distribution of compiled nvenc.c, >> it shouldn't be enabled by default. >> > > I don't mind disabling it by default, if that alleviates some concerns. If it's enabled by default, it could cause problems for distributors, where the system library exception doesn't apply. So not enabling it is a safer default. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
> > > I don't mind disabling it by default, if that alleviates some concerns. > One caveat to my previous comments is that just like avisynth I think that nvenc should be disabled by default aswell. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
Am 10.12.2015 17:10 schrieb "Andreas Cadhalpun" < andreas.cadhal...@googlemail.com>: > > On 10.12.2015 16:49, Hendrik Leppkes wrote: > > On Thu, Dec 10, 2015 at 4:25 PM, Andreas Cadhalpun > > wrote: > >> The GPL-3 requires that the 'Corresponding Source' of the distributed object code > >> is also distributed. This is defined as [1]: > >> The “Corresponding Source” for a work in object code form means all the source > >> code needed to generate, install, and (for an executable work) run the object > >> code[...] > >> For example, Corresponding Source includes [...] the source code for [...] > >> dynamically linked subprograms that the work is specifically designed to require, > >> such as by intimate data communication or control flow between those subprograms > >> and other parts of the work. > >> > > > > This rule does not apply to system libraries, > > Yes. > > > which I still am quite > > sure a hardware driver would fall under (and we can argue about that > > all day, you won't get any "proof" either way) > > If a particular system does not actually package this particular > > library, then their distribution of FFmpeg should probably just not > > enable nvenc, its of no use without the library anyway. > > But if it did, it would certainly not fall under the system library exception. > If that's the only thing that allows distribution of compiled nvenc.c, > it shouldn't be enabled by default. > I don't mind disabling it by default, if that alleviates some concerns. > > You could argue the same thing for QuickSync, the only difference is > > that it depends on some sort of "dispatcher" library that sits between > > FFmpeg and the closed-source library. > > Yes, that looks like a similar problem. > > > Does the existence of a tiny dispatcher library suddenly "fix" these > > rules? > > I don't think so, but I haven't looked at the code. > > > That would be silly. Yet it is widely accepted that linking > > against libmfx for qsv is fine. > > If it is 'widely accepted' that distribution of the resulting object > code is GPL compatible, then you can certainly provide links > to statements from experts saying so, e.g. from someone from the FSF. > Unless you do, 'widely accepted' is a void argument. > > Best regards, > Andreas > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
> > > >>> What is a system library depends on the system. > > >>> For example, Debian (main) does not even include libcuda or > > >>> libnvidia-encode, so they certainly cannot be system libraries there. > > >> > Im not sure that Debian not including libcuda is a valid argument for it not being a system library as thats just one OS. To me thats the same as saying that win32 stuff is not part of a system library because Debian doesnt have it (for obvious reasons). So I dont believe that just because some systems dont have it doesnt stop it from being a system library. And if a system doesnt have the required propriety libs then they wont be loaded at runtime and therefore no proprietary code is ever used at all. > > The ffmpeg binary that results from including nvEncodeAPI.h is GPL > > > compatible because nvEncodeAPI.h is MIT licenced. > > > > I'm not sure it's that easy. If that were correct, it would become > > GPL-compatible to distribute a GPL-licensed program linked with a > > proprietary library by simply inserting a MIT licensed header in the > middle. > In this case thats not what is being said as we are not actually linking against anything. As if we did link against a propriety lib then you would be correct and this would brake GPL but that is not the case as the nvenc binaries are only accessed at runtime. All were doing here is including a single header file. > > The only time the GPL ffmpeg and the proprietary licenced nvidia > libraries > > > are combined is on the end user system so no distribution occurs, so > the > > > GPL language doesn't apply at that stage. > > > > However, the object code compiled from nvenc.c would get distributed as > part of > > the ffmpeg binaries, which is governed by the GPL. > The object code from nvenc.c is written using LGPL and just includes declarations (no actual code definitions) from a MIT header file which to me suggests that the part of ffmpeg that would be distributed is still GPL compliant. At no point during the entire compilation and linking stage is any proprietary component touched so I dont see how this brakes anything. So sorry for being verbose (and potential just stating the obvious) but the only argument here is whether we can consider the libs accessed at runtime as system libs or not. To use windows as a further example all the actual binary code required for nvenc to work is part of the graphics drivers. So the only time anything not GPL compliant is ever used is when the dll's are loaded at runtime from the driver. This definitely puts it in the category of a system component in my mind. If drivers are not considered system libs then we have far more serious problems than nvenc ;) Admittedly, we are solving someone else's problem, but the header is > buried inside the SDK download which is hidden behind a click-through on > nvidia's web page. So it's not made available in a way that is readily > consumable by an end user or by a distribution vendor. > > With the new licencing, a distro vendor *could* take the header and package > it up themselves, but that's the sort of them that's exceptionally hard to > convince them to do. > > And in the case of windows (where nvenc works too), there is no distro > vendor > and nvidia certainly won't make the header more accessible than it already > is. I agree with Philip here as the nvEncodeApi header is not part of a cuda sdk install and requires a separate download. One which is not as easily accessible and one that requires a good 90MB download just to use 1 header file. Since the header is all that is needed and it is not part of a standard sdk then I think the inclusion of avisynths headers already sets a precedent to also include this one. Including it also allows ffmpeg to ensure that the correct newer MIT licensed version is the only one being used. Of course this does put the burden on ffmpeg to ensure that the header is kept up to date but as long as someone does that then I support its inclusion (I dont see an issue with keeping it up to date as anyone adding new features will inherently update it and any breakage would be a result of the interfaces changing which would brake ffmpeg anyway). So the updated patch looks good to me. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 10.12.2015 16:49, Hendrik Leppkes wrote: > On Thu, Dec 10, 2015 at 4:25 PM, Andreas Cadhalpun > wrote: >> The GPL-3 requires that the 'Corresponding Source' of the distributed object >> code >> is also distributed. This is defined as [1]: >> The “Corresponding Source” for a work in object code form means all the >> source >> code needed to generate, install, and (for an executable work) run the object >> code[...] >> For example, Corresponding Source includes [...] the source code for [...] >> dynamically linked subprograms that the work is specifically designed to >> require, >> such as by intimate data communication or control flow between those >> subprograms >> and other parts of the work. >> > > This rule does not apply to system libraries, Yes. > which I still am quite > sure a hardware driver would fall under (and we can argue about that > all day, you won't get any "proof" either way) > If a particular system does not actually package this particular > library, then their distribution of FFmpeg should probably just not > enable nvenc, its of no use without the library anyway. But if it did, it would certainly not fall under the system library exception. If that's the only thing that allows distribution of compiled nvenc.c, it shouldn't be enabled by default. > You could argue the same thing for QuickSync, the only difference is > that it depends on some sort of "dispatcher" library that sits between > FFmpeg and the closed-source library. Yes, that looks like a similar problem. > Does the existence of a tiny dispatcher library suddenly "fix" these > rules? I don't think so, but I haven't looked at the code. > That would be silly. Yet it is widely accepted that linking > against libmfx for qsv is fine. If it is 'widely accepted' that distribution of the resulting object code is GPL compatible, then you can certainly provide links to statements from experts saying so, e.g. from someone from the FSF. Unless you do, 'widely accepted' is a void argument. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On Thu, Dec 10, 2015 at 4:25 PM, Andreas Cadhalpun wrote: > On 10.12.2015 15:18, Philip Langdale wrote: >> On 2015-12-10 06:05, Andreas Cadhalpun wrote: >>> On 09.12.2015 17:38, Hendrik Leppkes wrote: On Wed, Dec 9, 2015 at 5:33 PM, Timo Rothenpieler wrote: > If I understand carl right, the question is not about the header, but > about if dlopen'ing a non-free library, the CUDA and NVENC ones in this > case, makes ffmpeg non-free, or if they are system libraries and thus > it's ok to link against them. > The generated binary contains no non-free code, not even used a non-free header, nor does it depend on any non-free binary to run. >>> >>> Well, most of the binary code generated from nvenc.c requires the >>> non-free libcuda.so and libnvidia-encode.so.1 blobs to run. >>> And even if you want to cite that particular rule - if drivers are not considered part of the system, then I don't know what is. >>> >>> What is a system library depends on the system. >>> For example, Debian (main) does not even include libcuda or >>> libnvidia-encode, so they certainly cannot be system libraries there. >> >> I am not a lawyer, etc, so make of this what you will, but: > > Neither am I and I'm not giving any legal advice here. > I just wanted to point out that the system library exception obviously > doesn't apply and since your rationale below doesn't mention it, > I think you agree. > >> The GPL controls distribution of the work and derived works because that's >> what the licence can control. > > Agreed. > >> The nvidia cuda and nvenc libraries are clearly not derived works of ffmpeg >> and the nvEncodeAPI.h is also clearly not a derived work. > > True. > >> The ffmpeg binary that results from including nvEncodeAPI.h is GPL >> compatible because nvEncodeAPI.h is MIT licenced. > > I'm not sure it's that easy. If that were correct, it would become > GPL-compatible to distribute a GPL-licensed program linked with a > proprietary library by simply inserting a MIT licensed header in the middle. > >> The only time the GPL ffmpeg and the proprietary licenced nvidia libraries >> are combined is on the end user system so no distribution occurs, so the >> GPL language doesn't apply at that stage. > > However, the object code compiled from nvenc.c would get distributed as part > of > the ffmpeg binaries, which is governed by the GPL. > >> The whole deal with proprietary drivers for the linux kernel is controversial >> because the proprietary driver can be considered a derived work of the kernel >> because it implements kernel interfaces and uses kernel code and is intended >> for use with the kernel. Clearly the nvenc library and API have no >> relationship >> with ffmpeg - they are independently developed works with other consumers and >> using them from ffmpeg does not change this fact. > > That's unrelated to the problem at hand. > >> Additionally, including nvEncodeAPI.h does not inhibit anybody's ability to >> modify or replace any part of ffmpeg as they wish, including modifying it to >> no longer have anything to do with nvenc. > > Including nvEncodeAPI.h is not causing the license problem, distributing the > object code generated from nvenc.c is. > >> So really, I'm not sure what the rationale is for thinking it's a GPL >> violation >> to include the MIT licenced nvEncodeAPI.h and to distribute a binary with >> nvenc >> support in it. I'd be interested to hear the reasoning. > > The GPL-3 requires that the 'Corresponding Source' of the distributed object > code > is also distributed. This is defined as [1]: > The “Corresponding Source” for a work in object code form means all the source > code needed to generate, install, and (for an executable work) run the object > code[...] > For example, Corresponding Source includes [...] the source code for [...] > dynamically linked subprograms that the work is specifically designed to > require, > such as by intimate data communication or control flow between those > subprograms > and other parts of the work. > This rule does not apply to system libraries, which I still am quite sure a hardware driver would fall under (and we can argue about that all day, you won't get any "proof" either way) If a particular system does not actually package this particular library, then their distribution of FFmpeg should probably just not enable nvenc, its of no use without the library anyway. You could argue the same thing for QuickSync, the only difference is that it depends on some sort of "dispatcher" library that sits between FFmpeg and the closed-source library. Does the existence of a tiny dispatcher library suddenly "fix" these rules? That would be silly. Yet it is widely accepted that linking against libmfx for qsv is fine. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/nellymoserdec: replace pow by exp2
On Wed, Dec 09, 2015 at 07:02:02PM -0500, Ganesh Ajjanagadde wrote: > exp2 suffices here. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavcodec/nellymoserdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 10.12.2015 15:18, Philip Langdale wrote: > On 2015-12-10 06:05, Andreas Cadhalpun wrote: >> On 09.12.2015 17:38, Hendrik Leppkes wrote: >>> On Wed, Dec 9, 2015 at 5:33 PM, Timo Rothenpieler >>> wrote: If I understand carl right, the question is not about the header, but about if dlopen'ing a non-free library, the CUDA and NVENC ones in this case, makes ffmpeg non-free, or if they are system libraries and thus it's ok to link against them. >>> >>> The generated binary contains no non-free code, not even used a >>> non-free header, nor does it depend on any non-free binary to run. >> >> Well, most of the binary code generated from nvenc.c requires the >> non-free libcuda.so and libnvidia-encode.so.1 blobs to run. >> >>> And even if you want to cite that particular rule - if drivers are not >>> considered part of the system, then I don't know what is. >> >> What is a system library depends on the system. >> For example, Debian (main) does not even include libcuda or >> libnvidia-encode, so they certainly cannot be system libraries there. > > I am not a lawyer, etc, so make of this what you will, but: Neither am I and I'm not giving any legal advice here. I just wanted to point out that the system library exception obviously doesn't apply and since your rationale below doesn't mention it, I think you agree. > The GPL controls distribution of the work and derived works because that's > what the licence can control. Agreed. > The nvidia cuda and nvenc libraries are clearly not derived works of ffmpeg > and the nvEncodeAPI.h is also clearly not a derived work. True. > The ffmpeg binary that results from including nvEncodeAPI.h is GPL > compatible because nvEncodeAPI.h is MIT licenced. I'm not sure it's that easy. If that were correct, it would become GPL-compatible to distribute a GPL-licensed program linked with a proprietary library by simply inserting a MIT licensed header in the middle. > The only time the GPL ffmpeg and the proprietary licenced nvidia libraries > are combined is on the end user system so no distribution occurs, so the > GPL language doesn't apply at that stage. However, the object code compiled from nvenc.c would get distributed as part of the ffmpeg binaries, which is governed by the GPL. > The whole deal with proprietary drivers for the linux kernel is controversial > because the proprietary driver can be considered a derived work of the kernel > because it implements kernel interfaces and uses kernel code and is intended > for use with the kernel. Clearly the nvenc library and API have no > relationship > with ffmpeg - they are independently developed works with other consumers and > using them from ffmpeg does not change this fact. That's unrelated to the problem at hand. > Additionally, including nvEncodeAPI.h does not inhibit anybody's ability to > modify or replace any part of ffmpeg as they wish, including modifying it to > no longer have anything to do with nvenc. Including nvEncodeAPI.h is not causing the license problem, distributing the object code generated from nvenc.c is. > So really, I'm not sure what the rationale is for thinking it's a GPL > violation > to include the MIT licenced nvEncodeAPI.h and to distribute a binary with > nvenc > support in it. I'd be interested to hear the reasoning. The GPL-3 requires that the 'Corresponding Source' of the distributed object code is also distributed. This is defined as [1]: The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code[...] For example, Corresponding Source includes [...] the source code for [...] dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work. Why should that not apply to the dynamically linked libcuda/libnvidia-encode? Best regards, Andreas 1: https://www.gnu.org/licenses/gpl-3.0-standalone.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH RFC] avfilter/vf_delogo: Use AVPixFmtDescriptor.nb_components
Relying on AVPixFmtDescriptor.nb_components is cleaner and faster than checking data and linesize for every possible plane. Signed-off-by: Jean Delvare --- I see that most filters use AVPixFmtDescriptor.nb_components while others still check data and linesize. Am I correct assuming that the former is faster and preferred? libavfilter/vf_delogo.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- ffmpeg.orig/libavfilter/vf_delogo.c 2015-12-10 13:06:16.212908502 +0100 +++ ffmpeg/libavfilter/vf_delogo.c 2015-12-10 13:07:04.877966120 +0100 @@ -256,7 +256,7 @@ static int filter_frame(AVFilterLink *in if (!sar.num) sar.num = sar.den = 1; -for (plane = 0; plane < 4 && in->data[plane] && in->linesize[plane]; plane++) { +for (plane = 0; plane < desc->nb_components; plane++) { int hsub = plane == 1 || plane == 2 ? hsub0 : 0; int vsub = plane == 1 || plane == 2 ? vsub0 : 0; -- Jean Delvare SUSE L3 Support ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 2015-12-09 21:34, wm4 wrote: On Mon, 7 Dec 2015 19:34:20 +0100 Timo Rothenpieler wrote: > I don't remember if this was discussed when avisynth and other headers > where included, but what's the advantage of directly including the > header and burden the FFmpeg sources, rather than asking the user to > download them in case of need? The nvenc sdk isn't exactly a common thing that distributions provide. As distributions can now easily ship ffmpeg with nvenc support, this propably helps users who now no longer need to build ffmpeg themselves for nvenc support. So why would distros build with nvenc support, if they can't even do a simple thing like installing a single header file? Are we really talking about including a huge 3rd party header because distros are so lazy? What's next, do we add Windows headers to the FFmpeg tree, because MinGW lags severely behind the newest definitions like HEVC DXVA support? We could just provide a download link for the nvenc header somewhere if the problem is finding the header. Admittedly, we are solving someone else's problem, but the header is buried inside the SDK download which is hidden behind a click-through on nvidia's web page. So it's not made available in a way that is readily consumable by an end user or by a distribution vendor. With the new licencing, a distro vendor *could* take the header and package it up themselves, but that's the sort of them that's exceptionally hard to convince them to do. And in the case of windows (where nvenc works too), there is no distro vendor and nvidia certainly won't make the header more accessible than it already is. If the goal is to make the feature as available as possible to as many users as possible, then this is the way to do it. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 2015-12-10 06:05, Andreas Cadhalpun wrote: On 09.12.2015 17:38, Hendrik Leppkes wrote: On Wed, Dec 9, 2015 at 5:33 PM, Timo Rothenpieler wrote: If I understand carl right, the question is not about the header, but about if dlopen'ing a non-free library, the CUDA and NVENC ones in this case, makes ffmpeg non-free, or if they are system libraries and thus it's ok to link against them. The generated binary contains no non-free code, not even used a non-free header, nor does it depend on any non-free binary to run. Well, most of the binary code generated from nvenc.c requires the non-free libcuda.so and libnvidia-encode.so.1 blobs to run. And even if you want to cite that particular rule - if drivers are not considered part of the system, then I don't know what is. What is a system library depends on the system. For example, Debian (main) does not even include libcuda or libnvidia-encode, so they certainly cannot be system libraries there. I am not a lawyer, etc, so make of this what you will, but: The GPL controls distribution of the work and derived works because that's what the licence can control. The nvidia cuda and nvenc libraries are clearly not derived works of ffmpeg and the nvEncodeAPI.h is also clearly not a derived work. The ffmpeg binary that results from including nvEncodeAPI.h is GPL compatible because nvEncodeAPI.h is MIT licenced. The only time the GPL ffmpeg and the proprietary licenced nvidia libraries are combined is on the end user system so no distribution occurs, so the GPL language doesn't apply at that stage. The whole deal with proprietary drivers for the linux kernel is controversial because the proprietary driver can be considered a derived work of the kernel because it implements kernel interfaces and uses kernel code and is intended for use with the kernel. Clearly the nvenc library and API have no relationship with ffmpeg - they are independently developed works with other consumers and using them from ffmpeg does not change this fact. Additionally, including nvEncodeAPI.h does not inhibit anybody's ability to modify or replace any part of ffmpeg as they wish, including modifying it to no longer have anything to do with nvenc. So really, I'm not sure what the rationale is for thinking it's a GPL violation to include the MIT licenced nvEncodeAPI.h and to distribute a binary with nvenc support in it. I'd be interested to hear the reasoning. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 7/9] avcodec/mdct_template: use lrint instead of floor hack
On Sun, Dec 6, 2015 at 8:20 AM, Ganesh Ajjanagadde wrote: > On Tue, Dec 1, 2015 at 7:27 PM, Ganesh Ajjanagadde > wrote: >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavcodec/mdct_template.c | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/libavcodec/mdct_template.c b/libavcodec/mdct_template.c >> index e7e5f62..ecdeb54 100644 >> --- a/libavcodec/mdct_template.c >> +++ b/libavcodec/mdct_template.c >> @@ -23,6 +23,7 @@ >> #include >> #include "libavutil/common.h" >> #include "libavutil/mathematics.h" >> +#include "libavutil/libm.h" >> #include "fft.h" >> #include "fft-internal.h" >> >> @@ -82,8 +83,8 @@ av_cold int ff_mdct_init(FFTContext *s, int nbits, int >> inverse, double scale) >> for(i=0;i> alpha = 2 * M_PI * (i + theta) / n; >> #if FFT_FIXED_32 >> -s->tcos[i*tstep] = (FFTSample)floor(-cos(alpha) * 2147483648.0 + >> 0.5); >> -s->tsin[i*tstep] = (FFTSample)floor(-sin(alpha) * 2147483648.0 + >> 0.5); >> +s->tcos[i*tstep] = lrint(-cos(alpha) * 2147483648.0); >> +s->tsin[i*tstep] = lrint(-sin(alpha) * 2147483648.0); >> #else >> s->tcos[i*tstep] = FIX15(-cos(alpha) * scale); >> s->tsin[i*tstep] = FIX15(-sin(alpha) * scale); >> -- >> 2.6.2 >> > > Ping for this one, it is relatively important among the lrint patches > as this is frequently used and table may be large, making speed > benefit somewhat useful. > I have noted the header alphabetical include order mistake above. This is going in soon, as it actually fixes a bug since cos, sin can be positive in the relevant ranges here. Last call. Note: I think there might be undefined behavior here (before and after the patch) since cos(alpha) can be -1 (or very close it) here. That is a separate issue that I will examine some time. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][WIP][PATCH] avfilter: add SOFAlizer audio filter
On Thu, Dec 10, 2015 at 12:43:58AM +0100, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > libavfilter/Makefile | 1 + > libavfilter/af_sofalizer.c | 816 > + > libavfilter/allfilters.c | 1 + > 3 files changed, 818 insertions(+) > create mode 100644 libavfilter/af_sofalizer.c > > diff --git a/libavfilter/Makefile b/libavfilter/Makefile > index 8884d1d..d7a3f61 100644 > --- a/libavfilter/Makefile > +++ b/libavfilter/Makefile > @@ -87,6 +87,7 @@ OBJS-$(CONFIG_SIDECHAINCOMPRESS_FILTER) += > af_sidechaincompress.o > OBJS-$(CONFIG_SIDECHAINGATE_FILTER) += af_agate.o > OBJS-$(CONFIG_SILENCEDETECT_FILTER) += af_silencedetect.o > OBJS-$(CONFIG_SILENCEREMOVE_FILTER) += af_silenceremove.o > +OBJS-$(CONFIG_SOFALIZER_FILTER) += af_sofalizer.o > OBJS-$(CONFIG_STEREOTOOLS_FILTER)+= af_stereotools.o > OBJS-$(CONFIG_STEREOWIDEN_FILTER)+= af_stereowiden.o > OBJS-$(CONFIG_TREBLE_FILTER) += af_biquads.o > diff --git a/libavfilter/af_sofalizer.c b/libavfilter/af_sofalizer.c > new file mode 100644 > index 000..8e4da74 > --- /dev/null > +++ b/libavfilter/af_sofalizer.c > @@ -0,0 +1,816 @@ > +/* > + * sofalizer.c : SOFAlizer filter for virtual binaural acoustics > + > * > + * Copyright (C) 2013-2015 Andreas Fuchs, Wolfgang Hrauda, > + * Acoustics Research Institute (ARI), Vienna, > Austria > + * > + * Authors: Andreas Fuchs > + * Wolfgang Hrauda > + * > + * SOFAlizer project coordinator at ARI, main developer of SOFA: > + * Piotr Majdak > + * > + * This program 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. > + * > + * This program 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 make distclean ; ./configure && make -j12 libavfilter/af_sofalizer.c:28:20: fatal error: netcdf.h: No such file or directory compilation terminated. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/8] avfilter/vf_overlay: fix memory leaks
On Thu, Dec 10, 2015 at 3:47 AM, Paul B Mahol wrote: > On 12/10/15, Ganesh Ajjanagadde wrote: >> On Wed, Dec 9, 2015 at 6:09 PM, Paul B Mahol wrote: >>> On 12/9/15, Ganesh Ajjanagadde wrote: On Fri, Dec 4, 2015 at 9:39 AM, Ganesh Ajjanagadde wrote: > Recent commits 6aaac24d72a7da631173209841a3944fcb4a3309 and > 3835554bf8ed78539a3492c239f979c0ab03a15f made progress towards cleaning > up usage of the formats API, and in particular fixed possible NULL > pointer > dereferences. > > This commit addresses the issue of possible resource leaks when some > intermediate > call fails. > > Tested with valgrind --leak-check=full --show-leak-kinds=all, and manual > simulation > of malloc/realloc failures. > > Fixes: CID 1338327. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavfilter/vf_overlay.c | 32 +++- > 1 file changed, 23 insertions(+), 9 deletions(-) > > diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c > index 3c61731..68cfb1b 100644 > --- a/libavfilter/vf_overlay.c > +++ b/libavfilter/vf_overlay.c > @@ -252,23 +252,31 @@ static int query_formats(AVFilterContext *ctx) > switch (s->format) { > case OVERLAY_FORMAT_YUV420: > if (!(main_formats= > ff_make_format_list(main_pix_fmts_yuv420)) || > -!(overlay_formats = > ff_make_format_list(overlay_pix_fmts_yuv420))) > -return AVERROR(ENOMEM); > +!(overlay_formats = > ff_make_format_list(overlay_pix_fmts_yuv420))) { > +ret = AVERROR(ENOMEM); > +goto fail; > +} > break; > case OVERLAY_FORMAT_YUV422: > if (!(main_formats= > ff_make_format_list(main_pix_fmts_yuv422)) || > -!(overlay_formats = > ff_make_format_list(overlay_pix_fmts_yuv422))) > -return AVERROR(ENOMEM); > +!(overlay_formats = > ff_make_format_list(overlay_pix_fmts_yuv422))) { > +ret = AVERROR(ENOMEM); > +goto fail; > +} > break; > case OVERLAY_FORMAT_YUV444: > if (!(main_formats= > ff_make_format_list(main_pix_fmts_yuv444)) || > -!(overlay_formats = > ff_make_format_list(overlay_pix_fmts_yuv444))) > -return AVERROR(ENOMEM); > +!(overlay_formats = > ff_make_format_list(overlay_pix_fmts_yuv444))) { > +ret = AVERROR(ENOMEM); > +goto fail; > +} > break; > case OVERLAY_FORMAT_RGB: > if (!(main_formats= ff_make_format_list(main_pix_fmts_rgb)) > || > -!(overlay_formats = > ff_make_format_list(overlay_pix_fmts_rgb))) > -return AVERROR(ENOMEM); > +!(overlay_formats = > ff_make_format_list(overlay_pix_fmts_rgb))) { > +ret = AVERROR(ENOMEM); > +goto fail; > +} > break; > default: > av_assert0(0); > @@ -277,9 +285,15 @@ static int query_formats(AVFilterContext *ctx) > if ((ret = ff_formats_ref(main_formats , > &ctx->inputs[MAIN]->out_formats )) < 0 || > (ret = ff_formats_ref(overlay_formats, > &ctx->inputs[OVERLAY]->out_formats)) < 0 || > (ret = ff_formats_ref(main_formats , > &ctx->outputs[MAIN]->in_formats )) < 0) > -return ret; > +goto fail; > > return 0; > +fail: > +av_freep(&main_formats->formats); > +av_freep(&main_formats); > +av_freep(&overlay_formats->formats); > +av_freep(&overlay_formats); > +return ret; > } > > static const enum AVPixelFormat alpha_pix_fmts[] = { > -- > 2.6.3 > pushed, with the necessary modification described by Clement >>> >>> This tries to dereference uninitialized value. >> >> See right above; I did the desired modification and believe there is no >> issue. >> I might be wrong; but if so, could you please refer to the relevant >> cvslog message? >> Thanks. > > libavfilter/vf_overlay.c:275:13: warning: variable 'overlay_formats' > is used uninitialized whenever '||' condition is true > [-Wsometimes-uninitialized] > if (!(main_formats= ff_make_format_list(main_pix_fmts_rgb)) || > ^~~ > libavfilter/vf_overlay.c:295:9: note: uninitialized use occurs here > if (overlay_formats) > ^~~ > libavfilter/vf_overlay.c:275:13: note: remove the '||' if its > condition is always false > if (!(main_formats= ff_make_format_list(main_pix_fmts_rgb)) || > ^~ > l
Re: [FFmpeg-devel] [PATCH] avformat/mov: Enable parser for mp3s by old HandBrake
On Thu, Dec 10, 2015 at 10:37:42AM +0100, Moritz Barsnick wrote: > On Wed, Dec 09, 2015 at 22:24:08 +0100, Michael Niedermayer wrote: > > +if (sscanf(str, "HandBrake %d.%d.%d", &major, &minor, µ) > > == 3) { > > +c->handbrake_version = 100*major + 1000*minor + micro; > [...] > > +if (mov->handbrake_version && > > +mov->handbrake_version <= 100*0 + 1000*10 + 0 && > > Really hard to read for all the '1's and '0'. You're checking for "<= > 0.10.0"? Perhaps better to clearly document that. comment added > > So starting with 0.10.1, behavior is different? we have a file from 0.10.0 which is affected, i do not know if later versions are affected, if somone knows or someone submits files from later versions which are affected then this can be updated [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] QSV : making three qsv routines public
Hello Hendrik, Thursday, December 10, 2015, 2:00:51 PM, you wrote: >> What is wrong then? HL> The public qsv.h uses config.h, thats not allowed. ah, got it, thank. -- Best regards, Ivanmailto:ivan.us...@nablet.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Make FFmpeg recognize QT version 0 sound sample descriptions and store the palette in matroskadec.c
I've attached a unified diff of the latest Git version of matroskadec.c that does two things: 1. It allows FFmpeg to recognize QuickTime version 0 sound sample descriptions by using 36 instead of 86 as the minimum private data size for A_QUICKTIME. 2. The palette, in QuickTime video that has one, is put in extradata, to make MPlayer recognize it and tack it to the end of its "fake" BITMAPINFOHEADER. This patch is an improvement and tidying-up of a proposed patch by Martin Storsjö, for the record. The version 0 sound sample description stuff is made by me long ago, though. Comments welcome. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/--- matroskadec.c.orig 2015-12-08 11:01:40.640478749 +0100 +++ matroskadec.c 2015-12-08 13:56:46.0 +0100 @@ -310,10 +310,12 @@ /* File has SSA subtitles which prevent incremental cluster parsing. */ int contains_ssa; /* WebM DASH Manifest live flag/ */ int is_live; + +uint8_t *pal; } MatroskaDemuxContext; typedef struct MatroskaBlock { uint64_t duration; int64_t reference; @@ -1853,22 +1855,27 @@ if (ret < 0) return ret; codec_id = st->codec->codec_id; extradata_offset = FFMIN(track->codec_priv.size, 18); } else if (!strcmp(track->codec_id, "A_QUICKTIME") - && (track->codec_priv.size >= 86) + && (track->codec_priv.size >= 36) && (track->codec_priv.data)) { fourcc = AV_RL32(track->codec_priv.data + 4); codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc); if (ff_codec_get_id(ff_codec_movaudio_tags, AV_RL32(track->codec_priv.data))) { fourcc = AV_RL32(track->codec_priv.data); codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc); } } else if (!strcmp(track->codec_id, "V_QUICKTIME") && (track->codec_priv.size >= 21) && (track->codec_priv.data)) { -fourcc = AV_RL32(track->codec_priv.data + 4); +AVIOContext pb; +MOVContext *mc; +MOVStreamContext *msc; +void *priv_data; +int nb_streams; +fourcc = AV_RL32(track->codec_priv.data + 4); codec_id = ff_codec_get_id(ff_codec_movvideo_tags, fourcc); if (ff_codec_get_id(ff_codec_movvideo_tags, AV_RL32(track->codec_priv.data))) { fourcc = AV_RL32(track->codec_priv.data); codec_id = ff_codec_get_id(ff_codec_movvideo_tags, fourcc); } @@ -1878,10 +1885,49 @@ char buf[32]; av_get_codec_tag_string(buf, sizeof(buf), fourcc); av_log(matroska->ctx, AV_LOG_ERROR, "mov FourCC not found %s.\n", buf); } +priv_data = st->priv_data; +nb_streams = s->nb_streams; +mc = av_mallocz(sizeof(*mc)); +if (! mc) +return AVERROR(ENOMEM); +mc->fc = s; +st->priv_data = msc = av_mallocz(sizeof(MOVStreamContext)); +if (!msc) { +av_free(mc); +st->priv_data = priv_data; +return AVERROR(ENOMEM); +} +ffio_init_context(&pb, track->codec_priv.data, track->codec_priv.size, 0, NULL, NULL, NULL, NULL); +/* ff_mov_read_stsd_entries updates stream s->nb_streams-1, + * so set it temporarily to indicate which stream to update. */ +s->nb_streams = st->index + 1; +ff_mov_read_stsd_entries(mc, &pb, 1); +if (msc->has_palette) { +if ((matroska->pal = av_malloc(AVPALETTE_SIZE))) { +memcpy(matroska->pal, msc->palette, AVPALETTE_SIZE); +if ((extradata = av_malloc(AVPALETTE_SIZE))) { +memcpy(extradata, msc->palette, AVPALETTE_SIZE); +extradata_size = AVPALETTE_SIZE; +} +} +if (!matroska->pal || !extradata) { +av_free(msc); +av_free(mc); +if (matroska->pal) av_freep(&matroska->pal); +if (extradata) av_freep(&extradata); +st->priv_data = priv_data; +s->nb_streams = nb_streams; +return AVERROR(ENOMEM); +} +} +av_free(msc); +av_free(mc); +st->priv_data = priv_data; +s->nb_streams = nb_streams; } else if (codec_id == AV_CODEC_ID_PCM_S16BE) { switch (track->audio.bitdepth) { case 8: codec_id = AV_CODEC_ID_PCM_U8; break; @@ -2322,10 +2368,19 @@ AVPacket *pkt) { if (matroska->num_packets > 0) { memcpy
Re: [FFmpeg-devel] [PATCH] QSV : making three qsv routines public
On Thu, Dec 10, 2015 at 11:20 AM, Ivan Uskov wrote: > Hello Hendrik, > > Thursday, December 10, 2015, 1:10:59 PM, you wrote: > > This patch expose 3 QSV functions as public. > This is needed because the VPP needs access to these functions too. > > Please review. > >>> >>> HL> public API is not allowed to use config.h, it needs to be config and >>> HL> OS agnostic. >>> Any qsv_* function can not be public since are all under CONFIG_QSV, >>> correct? >>> > > HL> Thats not necessarily true, if its supposed to be public API, it just > HL> has to always be present, so it would have to be changed to just do > HL> nothing and return an error if QSV is not enabled, but the functions > HL> still exist. > But it is exactly that Sven did, there are dummies for all public function > into the qsv_api.c for the case if CONFIG_QSV==0 > What is wrong then? The public qsv.h uses config.h, thats not allowed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Ideas to replace the options system
Replying to everybody at once: To Ronald, regarding "rewrite EVERYTHING!!!" versus "added as extensions of the current API": My gut feeling is that starting from scratch would prove less efforts in total. The current code is already quite convoluted, even adding a single type requires adding code in various places, and it is already not easy to know what places are mandatory and what places are optional or squarely redundant. There are functions with similar names because one was added after the other, etc. The way I see it, just getting the current code into shape for serious extensions would require a big refactoring. I believe this is a situation where the desired new features are significantly larger that the current code base, and in these case, not worrying with the existing, taking only what is useful as it comes seems easier. But of course, this is up to whoever does the work. To Paul, about dynamic options changing: This one, I think, is rather orthogonal to what I am suggesting. Right now, you could call av_opt_set() on a filter or a codec that is already in use. It would give awful results, but not because of the options system, because filters and codec are not ready for options changing below their feet. Of course, some support from the options system would help, like a flag telling us if an option can be changed later or not (dynamic read/write status), but the bulk of the effort seems to be getting filters into shape. To James, regarding allowing only simple string arguments: I do not quite understand what you are proposing. How would the user specify a PAN matrix like "FL signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] QSV : making three qsv routines public
Hello Hendrik, Thursday, December 10, 2015, 1:10:59 PM, you wrote: This patch expose 3 QSV functions as public. This is needed because the VPP needs access to these functions too. Please review. >> >> HL> public API is not allowed to use config.h, it needs to be config and >> HL> OS agnostic. >> Any qsv_* function can not be public since are all under CONFIG_QSV, correct? >> HL> Thats not necessarily true, if its supposed to be public API, it just HL> has to always be present, so it would have to be changed to just do HL> nothing and return an error if QSV is not enabled, but the functions HL> still exist. But it is exactly that Sven did, there are dummies for all public function into the qsv_api.c for the case if CONFIG_QSV==0 What is wrong then? -- Best regards, Ivanmailto:ivan.us...@nablet.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] QSV : making three qsv routines public
On Thu, Dec 10, 2015 at 11:01 AM, Ivan Uskov wrote: > Hello Hendrik, > > Thursday, December 10, 2015, 12:19:23 PM, you wrote: > > HL> On Thu, Dec 10, 2015 at 10:16 AM, Sven Dueking wrote: >>> This patch expose 3 QSV functions as public. >>> This is needed because the VPP needs access to these functions too. >>> >>> Please review. >>> > > HL> public API is not allowed to use config.h, it needs to be config and > HL> OS agnostic. > Any qsv_* function can not be public since are all under CONFIG_QSV, correct? > Thats not necessarily true, if its supposed to be public API, it just has to always be present, so it would have to be changed to just do nothing and return an error if QSV is not enabled, but the functions still exist. Using config.h in public headers is not something you can somehow work around however. The public interface needs to be stable, independent of how ffmpeg was built. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] QSV : making three qsv routines public
Hello Hendrik, Thursday, December 10, 2015, 12:19:23 PM, you wrote: HL> On Thu, Dec 10, 2015 at 10:16 AM, Sven Dueking wrote: >> This patch expose 3 QSV functions as public. >> This is needed because the VPP needs access to these functions too. >> >> Please review. >> HL> public API is not allowed to use config.h, it needs to be config and HL> OS agnostic. Any qsv_* function can not be public since are all under CONFIG_QSV, correct? -- Best regards, Ivanmailto:ivan.us...@nablet.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: Enable parser for mp3s by old HandBrake
On Wed, Dec 09, 2015 at 22:24:08 +0100, Michael Niedermayer wrote: > +if (sscanf(str, "HandBrake %d.%d.%d", &major, &minor, µ) == > 3) { > +c->handbrake_version = 100*major + 1000*minor + micro; [...] > +if (mov->handbrake_version && > +mov->handbrake_version <= 100*0 + 1000*10 + 0 && Really hard to read for all the '1's and '0'. You're checking for "<= 0.10.0"? Perhaps better to clearly document that. So starting with 0.10.1, behavior is different? Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] QSV : making three qsv routines public
On Thu, Dec 10, 2015 at 10:16 AM, Sven Dueking wrote: > This patch expose 3 QSV functions as public. > This is needed because the VPP needs access to these functions too. > > Please review. > public API is not allowed to use config.h, it needs to be config and OS agnostic. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] QSV : making three qsv routines public
This patch expose 3 QSV functions as public. This is needed because the VPP needs access to these functions too. Please review. Thanks, Sven 0001-make-some-internal-QSV-routines-public.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/8] avfilter/vf_overlay: fix memory leaks
On 12/10/15, Ganesh Ajjanagadde wrote: > On Wed, Dec 9, 2015 at 6:09 PM, Paul B Mahol wrote: >> On 12/9/15, Ganesh Ajjanagadde wrote: >>> On Fri, Dec 4, 2015 at 9:39 AM, Ganesh Ajjanagadde >>> wrote: Recent commits 6aaac24d72a7da631173209841a3944fcb4a3309 and 3835554bf8ed78539a3492c239f979c0ab03a15f made progress towards cleaning up usage of the formats API, and in particular fixed possible NULL pointer dereferences. This commit addresses the issue of possible resource leaks when some intermediate call fails. Tested with valgrind --leak-check=full --show-leak-kinds=all, and manual simulation of malloc/realloc failures. Fixes: CID 1338327. Signed-off-by: Ganesh Ajjanagadde --- libavfilter/vf_overlay.c | 32 +++- 1 file changed, 23 insertions(+), 9 deletions(-) diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c index 3c61731..68cfb1b 100644 --- a/libavfilter/vf_overlay.c +++ b/libavfilter/vf_overlay.c @@ -252,23 +252,31 @@ static int query_formats(AVFilterContext *ctx) switch (s->format) { case OVERLAY_FORMAT_YUV420: if (!(main_formats= ff_make_format_list(main_pix_fmts_yuv420)) || -!(overlay_formats = ff_make_format_list(overlay_pix_fmts_yuv420))) -return AVERROR(ENOMEM); +!(overlay_formats = ff_make_format_list(overlay_pix_fmts_yuv420))) { +ret = AVERROR(ENOMEM); +goto fail; +} break; case OVERLAY_FORMAT_YUV422: if (!(main_formats= ff_make_format_list(main_pix_fmts_yuv422)) || -!(overlay_formats = ff_make_format_list(overlay_pix_fmts_yuv422))) -return AVERROR(ENOMEM); +!(overlay_formats = ff_make_format_list(overlay_pix_fmts_yuv422))) { +ret = AVERROR(ENOMEM); +goto fail; +} break; case OVERLAY_FORMAT_YUV444: if (!(main_formats= ff_make_format_list(main_pix_fmts_yuv444)) || -!(overlay_formats = ff_make_format_list(overlay_pix_fmts_yuv444))) -return AVERROR(ENOMEM); +!(overlay_formats = ff_make_format_list(overlay_pix_fmts_yuv444))) { +ret = AVERROR(ENOMEM); +goto fail; +} break; case OVERLAY_FORMAT_RGB: if (!(main_formats= ff_make_format_list(main_pix_fmts_rgb)) || -!(overlay_formats = ff_make_format_list(overlay_pix_fmts_rgb))) -return AVERROR(ENOMEM); +!(overlay_formats = ff_make_format_list(overlay_pix_fmts_rgb))) { +ret = AVERROR(ENOMEM); +goto fail; +} break; default: av_assert0(0); @@ -277,9 +285,15 @@ static int query_formats(AVFilterContext *ctx) if ((ret = ff_formats_ref(main_formats , &ctx->inputs[MAIN]->out_formats )) < 0 || (ret = ff_formats_ref(overlay_formats, &ctx->inputs[OVERLAY]->out_formats)) < 0 || (ret = ff_formats_ref(main_formats , &ctx->outputs[MAIN]->in_formats )) < 0) -return ret; +goto fail; return 0; +fail: +av_freep(&main_formats->formats); +av_freep(&main_formats); +av_freep(&overlay_formats->formats); +av_freep(&overlay_formats); +return ret; } static const enum AVPixelFormat alpha_pix_fmts[] = { -- 2.6.3 >>> >>> pushed, with the necessary modification described by Clement >> >> This tries to dereference uninitialized value. > > See right above; I did the desired modification and believe there is no > issue. > I might be wrong; but if so, could you please refer to the relevant > cvslog message? > Thanks. libavfilter/vf_overlay.c:275:13: warning: variable 'overlay_formats' is used uninitialized whenever '||' condition is true [-Wsometimes-uninitialized] if (!(main_formats= ff_make_format_list(main_pix_fmts_rgb)) || ^~~ libavfilter/vf_overlay.c:295:9: note: uninitialized use occurs here if (overlay_formats) ^~~ libavfilter/vf_overlay.c:275:13: note: remove the '||' if its condition is always false if (!(main_formats= ff_make_format_list(main_pix_fmts_rgb)) || ^~ libavfilter/vf_overlay.c:268:13: warning: variable 'overlay_formats' is used uninitialized whenever '||' condition is true [-Wsometimes-uninitialized] if (!(main_formats= ff_make_format_list
Re: [FFmpeg-devel] Detecting invalid filter parameters
On Thu, 10 Dec 2015 08:58:05 +0100, Nicolas George wrote: > Le decadi 20 frimaire, an CCXXIV, Jean Delvare a écrit : > > This brings two additional questions: > > > > 1* Can a filter declare which midstream changes it does or does not > > support? > > > > 2* Can a filter be called back on midstream changes, or does it have to > > detect it by itself? > > Midstream changes are not supported yet at all. They work by chance for a > few selected whitelisted filters, that is all. No need to worry yet. OK, thanks. That will make things easier. I'll write down a note before the checks on what would need to be done if support is ever added. -- Jean Delvare SUSE L3 Support ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel