Re: [FFmpeg-devel] [PATCH] Enhanced require_pkg_config() in configure to fallback to require() if pkg-config is missing
On Fri, Apr 14, 2017 at 2:56 AM, Aaron Levinson wrote:
> From 48f7daba16e0fcdb83d9abd254800c7b9f4ab684 Mon Sep 17 00:00:00 2001
> From: Aaron Levinson
> Date: Thu, 13 Apr 2017 17:30:47 -0700
> Subject: [PATCH] Enhanced require_pkg_config() in configure to fallback to
> require() if pkg-config is missing
>
> Purpose: Enhanced require_pkg_config() in configure to
> fallback to require() if pkg-config is missing
>
> Notes: This is likely mainly of relevance when building with MSVC on
> Windows. In my case, I used this approach to get libmfx when invoking
> configure with --enable-libmfx, which is used for QuickSync (QSV).
>
> Comments:
>
> -- configure: Enhanced require_pkg_config() function to first check if
>$pkg_config is not false. If not false, it goes through the
>standard steps of calling use_pkg_config(), but if false, it issues
>a log message and then calls require() with all the inputted
>arguments and an additional argument: -l$1. So, for something like
>"require_pkg_config libmfx "mfx/mfxvideo.h" MFXInit", this becomes
>"require libmfx "mfx/mfxvideo.h" MFXInit -llibmfx". This is not a
>perfect solution, but the previous approach didn't work at all
>before when require_pkg_config() is used.
> ---
> configure | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 7f2b653..ad08b82 100755
> --- a/configure
> +++ b/configure
> @@ -1347,7 +1347,12 @@ use_pkg_config(){
> }
>
> require_pkg_config(){
> -use_pkg_config "$@" || die "ERROR: $pkg not found using
> pkg-config$pkg_config_fail_message"
> +if test $pkg_config != false; then
> +use_pkg_config "$@" || die "ERROR: $pkg not found using
> pkg-config$pkg_config_fail_message"
> +else
> +log require_pkg_config "No pkg-config, using require for $@"
> +require "$@ -l$1"
> +fi
> }
>
pkg-config typically provides more then just a location of the files,
and while it happens to work for mfx in your case, I don't think this
generic fallback is a good idea.
We already require a linux-esque build environment, even for MSVC
builds (ie. msys or cygwin, etc), having pkg-config on top of the
other required tools isn't that hard of a dependency to fullfill - I
do that all the time.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 3.3
On Thu, Apr 13, 2017 at 09:00:33PM +0100, Rostislav Pehlivanov wrote: > Signed-off-by: Rostislav Pehlivanov > --- > src/index | 53 + > 1 file changed, 53 insertions(+) > > diff --git a/src/index b/src/index > index c203676..1b8a037 100644 > --- a/src/index > +++ b/src/index > @@ -37,6 +37,59 @@ > News > > > + April 13th, 2017, FFmpeg 3.3 "Hilbert" > + > +FFmpeg 3.3 "Hilbert", a new > +major release, is now available! Some of the highlights: > + > + > + > + Apple Pixlet decoder > + NewTek SpeedHQ decoder > + QDMC audio decoder > + PSD (Photoshop Document) decoder > + FM Screen Capture decoder > + ScreenPressor decoder > + XPM decoder > + DNxHR decoder fixes for HQX and high resolution videos > + ClearVideo decoder (partial) > + 16.8 and 24.0 floating point PCM decoder > + Intel QSV-accelerated VP8 video decoding > + > + > + native Opus encoder > + DNxHR 444 and HQX encoding > + Quality improvements for the (M)JPEG encoder > + VAAPI-accelerated MPEG-2 and VP8 encoding > + > + > + premultiply video filter > + abitscope multimedia filter > + readeia608 filter > + threshold filter > + midequalizer filter > + MPEG-7 Video Signature filter > + add internal ebur128 library, remove external libebur128 > dependency > + Intel QSV video scaling and deinterlacing filters > + > + > + Sample Dump eXchange demuxer > + MIDI Sample Dump Standard demuxer > + Scenarist Closed Captions demuxer and muxer > + Support MOV with multiple sample description tables > + Pro-MPEG CoP #3-R2 FEC protocol > + Support for spherical videos > + > + > + CrystalHD decoder moved to new decode API > + configure now fails if autodetect-libraries are requested but not > found > + > + > + > +We strongly recommend users, distributors, and system integrators to > +upgrade unless they use current git master. as some developers had concerns about the release in relation to merges prior to it, iam not sure we should recommand that or not. We could also wait with adding such recommandition and for example add it for 3.3.1 when no major issues are reported on release/3.3 either way patch LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates 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] opus_pvq: add resynth support and band encoding cost function
On 14 April 2017 at 05:50, Carl Eugen Hoyos wrote: > 2017-04-13 9:51 GMT+02:00 Rostislav Pehlivanov : > > On 13 April 2017 at 07:13, Carl Eugen Hoyos wrote: > > > >> 2017-04-13 4:02 GMT+02:00 Rostislav Pehlivanov : > >> > On 12 April 2017 at 23:50, Carl Eugen Hoyos > wrote: > >> > > >> >> 2017-04-13 0:26 GMT+02:00 Rostislav Pehlivanov >: > >> >> > >> >> > +/* Undo the sample reorganization going from time > >> >> > order to frequency order */ > >> >> > +if (B0 > 1) > >> >> > +celt_interleave_hadamard(f->scratch, X, > >> >> > N_B >> recombine, > >> >> > + B0< >> >> > >> >> Is this the same code as in opus/celt/bands.c? > >> >> Who wrote it? > >> > > >> > This exact line is also on line 1206 of the same file for PVQ > decoding . > >> > Most of the PVQ encoder is copied from our decoder since they're very > >> > similar. This commit just copies more. > >> > >> > The reason why you can find the same string in libopus is because that > >> > decoder was cut down, modified and ported as our native decoder. > >> > >> Then I suggest you add the missing copyright notices to the decoder > >> and the encoder. > > > There's nothing to do: > >> * Copyright (c) 2012 Andrew D'Addesio > >> * Copyright (c) 2013-2014 Mozilla Corporation > >> * Copyright (c) 2017 Rostislav Pehlivanov > > > > Mozilla relicensed the decoder to LGPL when it was ported. > > Sorry, I don't understand: > You write above that FFmpeg's opus decoder is based on libopus, > this also explains the similar code I saw (above). libopus is - afaict - > copyright Xiph.Org Foundation. > I suggested to add this copyright to our codec and your answer > is that there is nothing to do but I don't see Xiph mentioned: What > am I missing? > You then continue that the code was relicensed to LGPL: How is > that related to the missing copyright notice? > > Thank you, Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Point is, I have used only code from libavcodec/opus_pvq.c from the FFmpeg project. I don't have to do anything as all credit has been given where due. If libavcodec/opus_pvq.c's license header is wrong, it's not and wasn't my problem, the code's been in libavcodec for 4 years now. You'll have to submit a separate patch if you believe that's the case. And I advise you to contact all the authors as well as libav from whom this code was merged first. As I see no technical issues not license issues I've pushed the patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avcodec/h264: change RETs into REP_RETs where appropriate
On 2017-04-05 22:26, Henrik Gramner wrote: > On Wed, Apr 5, 2017 at 3:53 AM, James Darnley wrote: >> call h264_idct_add8_mmx_plane >> -RET >> +RET ; TODO: check rep ret after a function call > > call followed by RET should be replaced by the TAIL_CALL macro instead > which outputs a jmp instruction if there's no function epilogue. Do you want me to change this patch to add that? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vaapi_encode: Fix the vaapi h264 encoder VBR/CBR metadata setting error.
On 14/04/17 02:01, Jun Zhao wrote:
> On 2017/4/13 22:05, Mark Thompson wrote:
>> On 13/04/17 13:34, Jun Zhao wrote:
>>> From 1fa48b45fe962d8c342d158d9c16ce24139ffd84 Mon Sep 17 00:00:00 2001
>>> From: Jun Zhao
>>> Date: Thu, 13 Apr 2017 20:07:10 +0800
>>> Subject: [PATCH] vaapi_encode: Fix the vaapi h264 encoder VBR/CBR metadata
>>> setting error.
>>>
>>> before this fix, mediainfo check the bit rate control mode metadata info
>>> is wrong.
>>>
>>> Reproduce step:
>>> encode with CBR or VBR mode like this:
>>> ./ffmpeg -y -hwaccel vaapi -vaapi_device /dev/dri/renderD128 \
>>> -hwaccel_output_format vaapi -i input.mp4 -an -c:v h264_vaapi \
>>> -maxrate 5M -b:v 5M output_cbr.mp4
>>>
>>> ./ffmpeg -y -hwaccel vaapi -vaapi_device /dev/dri/renderD128 \
>>> -hwaccel_output_format vaapi -i input.mp4 -an -c:v h264_vaapi \
>>> -maxrate 6M -b:v 5M output_cbr.mp4
>>>
>>> then use the mediainfo check the bit rate control mode.
>>>
>>> Signed-off-by: Jun Zhao
>>
>> Not yet generating the HRD and timing information in VBR mode was
>> deliberate, because I don't know enough about the conformance properties of
>> the new proprietary rate controller which the Intel driver has switched to.
>> The old CBR mode was straightforward to verify from the source code, and it
>> seemed reasonable to assume that the new CBR mode would be too given the
>> constraints on it (and also because existing versions of lavc couldn't be
>> modified).
>>
>> Can you say anything about the HRD conformance of the Intel driver here, or
>> was this patch purely for the metadata output (which may not actually match
>> the stream, hence my concern)?
>>
>> Only the Intel driver is relevant to this as far as I know - the Mesa driver
>> does not support the packed headers necessary for this information to be
>> included in the stream.
>>
>>
>
> I don't know the details about Intel driver's HRD conformance model, this
> patch
> just want to correct the bit rate mode metadata information.
>
>>> ---
>>> libavcodec/vaapi_encode_h264.c | 7 +++
>>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
>>> index 92e2955..47d0c94 100644
>>> --- a/libavcodec/vaapi_encode_h264.c
>>> +++ b/libavcodec/vaapi_encode_h264.c
>>> @@ -760,7 +760,7 @@ static int
>>> vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
>>> char tmp[256];
>>> size_t header_len;
>>>
>>> -if (index == 0 && ctx->va_rc_mode == VA_RC_CBR) {
>>> +if (index == 0 && (ctx->va_rc_mode == VA_RC_CBR || ctx->va_rc_mode ==
>>> VA_RC_VBR)) {
>>> *type = VAEncPackedHeaderH264_SEI;
>>>
>>> init_put_bits(&pbc, tmp, sizeof(tmp));
>>> @@ -868,7 +868,7 @@ static int
>>> vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
>>> mseq->fixed_frame_rate_flag = 0;
>>> }
>>>
>>> -if (ctx->va_rc_mode == VA_RC_CBR) {
>>> +if (ctx->va_rc_mode == VA_RC_CBR || ctx->va_rc_mode == VA_RC_VBR) {
>>> priv->send_timing_sei = 1;
>>> mseq->nal_hrd_parameters_present_flag = 1;
>>>
>>> @@ -886,8 +886,7 @@ static int
>>> vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
>>> mseq->cpb_size_value_minus1[0] =
>>> (ctx->hrd_params.hrd.buffer_size >> mseq->cpb_size_scale +
>>> 4) - 1;
>>>
>>> -// CBR mode isn't actually available here, despite naming.
>>> -mseq->cbr_flag[0] = 0;
>>> +mseq->cbr_flag[0] = (ctx->va_rc_mode == VA_RC_CBR ? 1 : 0);
>>
>> As the comment notes, the necessary CBR mode isn't actually available.
>> Drivers only offer "soft" CBR, which can result in HRD overflow; this
>> specifies "hard" CBR, so if you want to set this flag you would need to
>> insert filler NAL units as well.
>>
>
> In 1.8.0 release driver
> (https://lists.01.org/pipermail/intel-vaapi-media/2017-March/16.html),
> I can't reproduce the overflow issue with CBR mode. So I guess the new driver
> fix the HRD overflow
> issue (I don't dig in the 1.8.0 driver) .
Try encoding video of a solid colour:
ffmpeg -y -vaapi_device /dev/dri/renderD128 -f lavfi -i color=s=1280x720:r=30
-vf format=nv12,hwupload -c:v h264_vaapi -b 1M -maxrate 1M out.h264
I get output packets that are about 1600 bits each after the initial few. With
cbr_flag set the HSS must add 100 bits to the CPB every second, but we are
only removing 30 packets totalling about 30*1600 = 48000 bits in that same
time. Hence it will always overflow after not very long.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] avcodec/h264: add avx 8-bit h264_idct_add
On 2017-04-06 18:06, James Almer wrote: > Your numbers are really confusing. Could you post the actual numbers for > each function instead of doing comparisons? These figures are the actual numbers! Using the figures from Haswell above: > ff_h264_idct_add_8_mmx = 52 cycles > ff_h264_idct_add_8_sse2 = 49 cycles > ff_h264_idct_add_8_avx = 46 cycles Coming back to this draft I saved I removed a fair bit of ranting and cut it down to the essential point. Also, I forgot about the Pentium I tested previous patches on. I added SSE2. From that commit message: > Kaby Lake Pentium: > - ff_h264_idct_add_8_sse2:~1.18x faster than mmxext > - ff_h264_idct_dc_add_8_sse2: ~1.07x faster than mmxext ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Ignore expired cookies
On 2017-04-08 09:05 PM, Micah Galizia wrote: Signed-off-by: Micah Galizia Hello, Has anyone had a chance to review this? I was hoping to get the rework (if needed) done this weekend. Thanks, ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function
2017-04-14 13:11 GMT+02:00 Rostislav Pehlivanov : > On 14 April 2017 at 05:50, Carl Eugen Hoyos wrote: > >> 2017-04-13 9:51 GMT+02:00 Rostislav Pehlivanov : >> > On 13 April 2017 at 07:13, Carl Eugen Hoyos wrote: >> > >> >> 2017-04-13 4:02 GMT+02:00 Rostislav Pehlivanov : >> >> > On 12 April 2017 at 23:50, Carl Eugen Hoyos >> wrote: >> >> > >> >> >> 2017-04-13 0:26 GMT+02:00 Rostislav Pehlivanov > >: >> >> >> >> >> >> > +/* Undo the sample reorganization going from time >> >> >> > order to frequency order */ >> >> >> > +if (B0 > 1) >> >> >> > +celt_interleave_hadamard(f->scratch, X, >> >> >> > N_B >> recombine, >> >> >> > + B0<> >> >> >> >> >> Is this the same code as in opus/celt/bands.c? >> >> >> Who wrote it? >> >> > >> >> > This exact line is also on line 1206 of the same file for PVQ >> decoding . >> >> > Most of the PVQ encoder is copied from our decoder since they're very >> >> > similar. This commit just copies more. >> >> >> >> > The reason why you can find the same string in libopus is because that >> >> > decoder was cut down, modified and ported as our native decoder. >> >> >> >> Then I suggest you add the missing copyright notices to the decoder >> >> and the encoder. >> >> > There's nothing to do: >> >> * Copyright (c) 2012 Andrew D'Addesio >> >> * Copyright (c) 2013-2014 Mozilla Corporation >> >> * Copyright (c) 2017 Rostislav Pehlivanov >> > >> > Mozilla relicensed the decoder to LGPL when it was ported. >> >> Sorry, I don't understand: >> You write above that FFmpeg's opus decoder is based on libopus, >> this also explains the similar code I saw (above). libopus is - afaict - >> copyright Xiph.Org Foundation. >> I suggested to add this copyright to our codec and your answer >> is that there is nothing to do but I don't see Xiph mentioned: What >> am I missing? >> You then continue that the code was relicensed to LGPL: How is >> that related to the missing copyright notice? > Point is, I have used only code from libavcodec/opus_pvq.c from > the FFmpeg project. I don't have to do anything as all credit has > been given where due. I don't understand: The file opus_pvq.c contains copyright notices from Andrew D'Addesio and Mozilla. If you have used code from opus_pvq.c, shouldn't you add these copyright notices to the opus encoder? > If libavcodec/opus_pvq.c's license header is wrong, it's not and > wasn't my problem, the code's been in libavcodec for 4 years now. This is (of course!) true, it is the problem of all FFmpeg developers (including the two of us who realized it first). > You'll have to submit a separate patch if you believe that's the case. Since you explained above who the actual authors of opus_pvq.c are, I was hoping you would fix the copyright notice: I don't know who wrote it (but from a very quick look, your analysis that it was written by the libopus authors is correct and makes sense). Why don't you want to fix it? > And I advise you to contact all the authors as well as libav from > whom this code was merged first. We know that the avconv developers are violating the copyright of many people, we fix that in the FFmpeg code as soon as we are aware of it, there are many examples in gitlog. I don't see how this case would be different. > As I see no technical issues not license issues I've pushed the patch. I am not sure that this was such a good idea (esp. as you have explained the issue) but fortunately, this the license issues can still be fixed. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function
2017-04-14 14:30 GMT+02:00 Carl Eugen Hoyos : > 2017-04-14 13:11 GMT+02:00 Rostislav Pehlivanov : >> Point is, I have used only code from libavcodec/opus_pvq.c from >> the FFmpeg project. I don't have to do anything as all credit has >> been given where due. > > I don't understand: > The file opus_pvq.c contains copyright notices from Andrew > D'Addesio and Mozilla. If you have used code from opus_pvq.c, > shouldn't you add these copyright notices to the opus encoder? Or did you mean that you only used code that was already present in libavcodec/opus_pvq.c without copying anything to the new files you wrote (what "using" implied to me)? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avcodec/h264: change RETs into REP_RETs where appropriate
On Fri, Apr 14, 2017 at 1:19 PM, James Darnley wrote: > Do you want me to change this patch to add that? Either the same patch or a different one, pick whichever is most convenient for you. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function
On Fri, 14 Apr 2017 14:30:28 +0200 Carl Eugen Hoyos wrote: > We know that the avconv developers are violating the > copyright of many people, we fix that in the FFmpeg code as > soon as we are aware of it, there are many examples in gitlog. > I don't see how this case would be different. Defamation is not only against the CoC - it's also illegal. In addition to this, your behavior is quite embarrassing to the FFmpeg behavior, especially since your dictatorship over the bug tracker makes you sometimes seem "representative" of FFmpeg - which you are not, but nonetheless hurts our reputation. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffserver: fix memory leaks pointed out by valgrind.
Many memory leaks were created upon HTTP client disconnect.
Many clients connecting & disconnecting rapidly could very
quickly create leaks going into Gigabytes of memory.
From 29d36664c55b3a7078ebe57f8642e1d7dc389f16 Mon Sep 17 00:00:00 2001
From: Zalewa
Date: Fri, 14 Apr 2017 09:26:18 +0200
Subject: [PATCH] ffserver: fix memory leaks pointed out by valgrind.
Many memory leaks were created upon HTTP client disconnect.
Many clients connecting & disconnecting rapidly could very
quickly create leaks going into Gigabytes of memory.
---
ffserver.c | 46 ++
1 file changed, 34 insertions(+), 12 deletions(-)
diff --git a/ffserver.c b/ffserver.c
index 8b819b6..416438d 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -237,6 +237,7 @@ static int rtp_new_av_stream(HTTPContext *c,
static size_t htmlencode (const char *src, char **dest);
static inline void cp_html_entity (char *buffer, const char *entity);
static inline int check_codec_match(LayeredAVStream *ccf, AVStream *ccs, int stream);
+static void close_format_context(AVFormatContext *ctx);
static const char *my_program_name;
@@ -936,9 +937,7 @@ static void close_connection(HTTPContext *c)
ctx = c->rtp_ctx[i];
if (ctx) {
av_write_trailer(ctx);
-av_dict_free(&ctx->metadata);
-av_freep(&ctx->streams[0]);
-av_freep(&ctx);
+avformat_free_context(ctx);
}
ffurl_close(c->rtp_handles[i]);
}
@@ -954,11 +953,10 @@ static void close_connection(HTTPContext *c)
avio_close_dyn_buf(ctx->pb, &c->pb_buffer);
}
}
-for(i=0; inb_streams; i++)
-av_freep(&ctx->streams[i]);
-av_freep(&ctx->streams);
-av_freep(&ctx->priv_data);
-}
+close_format_context(ctx);
+av_freep(&ctx->internal);
+av_freep(&c->pfmt_ctx);
+}
if (c->stream && !c->post && c->stream->stream_type == STREAM_TYPE_LIVE)
current_bandwidth -= c->stream->bandwidth;
@@ -3724,6 +3722,32 @@ int check_codec_match(LayeredAVStream *ccf, AVStream *ccs, int stream)
return matches;
}
+static void close_format_context(AVFormatContext *ctx)
+{
+int i = 0;
+
+if (ctx->oformat && ctx->oformat->deinit)
+ctx->oformat->deinit(ctx);
+for (i=0; inb_streams; i++) {
+if (ctx->streams[i]->internal) {
+avcodec_free_context(&ctx->streams[i]->internal->avctx);
+}
+av_freep(&ctx->streams[i]->info);
+av_freep(&ctx->streams[i]->priv_data);
+av_freep(&ctx->streams[i]->priv_pts);
+av_freep(&ctx->streams[i]->internal);
+av_freep(&ctx->streams[i]);
+}
+av_opt_free(ctx);
+if (ctx->iformat && ctx->iformat->priv_class && ctx->priv_data)
+av_opt_free(ctx->priv_data);
+if (ctx->oformat && ctx->oformat->priv_class && ctx->priv_data)
+av_opt_free(ctx->priv_data);
+av_freep(&ctx->streams);
+ctx->nb_streams = 0;
+av_freep(&ctx->priv_data);
+}
+
/* compute the needed AVStream for each feed */
static int build_feed_streams(void)
{
@@ -3836,7 +3860,7 @@ drop:
}
s->oformat = feed->fmt;
for (i = 0; inb_streams; i++) {
-AVStream *st = avformat_new_stream(s, NULL); // FIXME free this
+AVStream *st = avformat_new_stream(s, NULL);
if (!st) {
http_log("Failed to allocate stream\n");
goto bail;
@@ -3852,10 +3876,8 @@ drop:
goto bail;
}
/* XXX: need better API */
-av_freep(&s->priv_data);
+close_format_context(s);
avio_closep(&s->pb);
-s->streams = NULL;
-s->nb_streams = 0;
avformat_free_context(s);
}
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffserver: fix memory leaks pointed out by valgrind.
On Fri, 14 Apr 2017 15:00:05 +0200
Zalewa wrote:
> From 29d36664c55b3a7078ebe57f8642e1d7dc389f16 Mon Sep 17 00:00:00 2001
> From: Zalewa
> Date: Fri, 14 Apr 2017 09:26:18 +0200
> Subject: [PATCH] ffserver: fix memory leaks pointed out by valgrind.
>
> Many memory leaks were created upon HTTP client disconnect.
> Many clients connecting & disconnecting rapidly could very
> quickly create leaks going into Gigabytes of memory.
> ---
> ffserver.c | 46 ++
> 1 file changed, 34 insertions(+), 12 deletions(-)
>
> diff --git a/ffserver.c b/ffserver.c
> index 8b819b6..416438d 100644
> --- a/ffserver.c
> +++ b/ffserver.c
> @@ -237,6 +237,7 @@ static int rtp_new_av_stream(HTTPContext *c,
> static size_t htmlencode (const char *src, char **dest);
> static inline void cp_html_entity (char *buffer, const char *entity);
> static inline int check_codec_match(LayeredAVStream *ccf, AVStream *ccs, int
> stream);
> +static void close_format_context(AVFormatContext *ctx);
>
> static const char *my_program_name;
>
> @@ -936,9 +937,7 @@ static void close_connection(HTTPContext *c)
> ctx = c->rtp_ctx[i];
> if (ctx) {
> av_write_trailer(ctx);
> -av_dict_free(&ctx->metadata);
> -av_freep(&ctx->streams[0]);
> -av_freep(&ctx);
> +avformat_free_context(ctx);
> }
> ffurl_close(c->rtp_handles[i]);
> }
> @@ -954,11 +953,10 @@ static void close_connection(HTTPContext *c)
> avio_close_dyn_buf(ctx->pb, &c->pb_buffer);
> }
> }
> -for(i=0; inb_streams; i++)
> -av_freep(&ctx->streams[i]);
> -av_freep(&ctx->streams);
> -av_freep(&ctx->priv_data);
> -}
> +close_format_context(ctx);
> +av_freep(&ctx->internal);
> +av_freep(&c->pfmt_ctx);
> +}
>
> if (c->stream && !c->post && c->stream->stream_type == STREAM_TYPE_LIVE)
> current_bandwidth -= c->stream->bandwidth;
> @@ -3724,6 +3722,32 @@ int check_codec_match(LayeredAVStream *ccf, AVStream
> *ccs, int stream)
> return matches;
> }
>
> +static void close_format_context(AVFormatContext *ctx)
> +{
> +int i = 0;
> +
> +if (ctx->oformat && ctx->oformat->deinit)
> +ctx->oformat->deinit(ctx);
> +for (i=0; inb_streams; i++) {
> +if (ctx->streams[i]->internal) {
> +avcodec_free_context(&ctx->streams[i]->internal->avctx);
> +}
> +av_freep(&ctx->streams[i]->info);
> +av_freep(&ctx->streams[i]->priv_data);
> +av_freep(&ctx->streams[i]->priv_pts);
> +av_freep(&ctx->streams[i]->internal);
> +av_freep(&ctx->streams[i]);
> +}
> +av_opt_free(ctx);
> +if (ctx->iformat && ctx->iformat->priv_class && ctx->priv_data)
> +av_opt_free(ctx->priv_data);
> +if (ctx->oformat && ctx->oformat->priv_class && ctx->priv_data)
> +av_opt_free(ctx->priv_data);
> +av_freep(&ctx->streams);
> +ctx->nb_streams = 0;
> +av_freep(&ctx->priv_data);
> +}
> +
This accesses plenty of internal fields. (Maybe did so before, but no
matter.)
The plan is that if ffserver is not fixed before the next bump, it will
be removed.
So doing the freeing correctly (if even possible) would be better for
the survival of ffserver.
> /* compute the needed AVStream for each feed */
> static int build_feed_streams(void)
> {
> @@ -3836,7 +3860,7 @@ drop:
> }
> s->oformat = feed->fmt;
> for (i = 0; inb_streams; i++) {
> -AVStream *st = avformat_new_stream(s, NULL); // FIXME free
> this
> +AVStream *st = avformat_new_stream(s, NULL);
> if (!st) {
> http_log("Failed to allocate stream\n");
> goto bail;
> @@ -3852,10 +3876,8 @@ drop:
> goto bail;
> }
> /* XXX: need better API */
> -av_freep(&s->priv_data);
> +close_format_context(s);
> avio_closep(&s->pb);
> -s->streams = NULL;
> -s->nb_streams = 0;
> avformat_free_context(s);
> }
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/hlsenc: add hls encrypt options
2017-04-06 23:02 GMT+08:00 Steven Liu :
> refer to:
> https://git.libav.org/?p=libav.git;a=commitdiff;h=
> 0a4b9d0ccd10b3c39105f99bd320f696f69a75a2
> add hls encrypt options looks like libav's libavformat/hlsenc.c
>
> Signed-off-by: Steven Liu
> ---
> doc/muxers.texi | 16 +++
> libavformat/hlsenc.c | 122 ++
> ++---
> 2 files changed, 133 insertions(+), 5 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 166c929369..db1c3db999 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -597,6 +597,22 @@ ffmpeg -f lavfi -re -i testsrc -c:v h264 -hls_flags
> delete_segments \
>-hls_key_info_file file.keyinfo out.m3u8
> @end example
>
> +@item -hls_enc @var{enc}
> +Enable (1) or disable (0) the AES128 encryption.
> +When enabled every segment generated is encrypted and the encryption key
> +is saved as @var{playlist name}.key.
> +
> +@item -hls_enc_key @var{key}
> +Hex-coded 16byte key to encrypt the segments, by default it
> +is randomly generated.
> +
> +@item -hls_enc_key_url @var{keyurl}
> +If set, @var{keyurl} is prepended instead of @var{baseurl} to the key
> filename
> +in the playlist.
> +
> +@item -hls_enc_iv @var{iv}
> +Hex-coded 16byte initialization vector for every segment instead
> +of the autogenerated ones.
>
> @item hls_flags @var{flags}
> Possible values:
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index e6c378df2e..f359bb9036 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -26,10 +26,18 @@
> #include
> #endif
>
> +#if CONFIG_GCRYPT
> +#include
> +#elif CONFIG_OPENSSL
> +#include
> +#endif
> +
> #include "libavutil/avassert.h"
> #include "libavutil/mathematics.h"
> #include "libavutil/parseutils.h"
> #include "libavutil/avstring.h"
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/random_seed.h"
> #include "libavutil/opt.h"
> #include "libavutil/log.h"
> #include "libavutil/time_internal.h"
> @@ -139,6 +147,12 @@ typedef struct HLSContext {
> char *subtitle_filename;
> AVDictionary *format_options;
>
> +int encrypt;
> +char *key;
> +char *key_url;
> +char *iv;
> +char *key_basename;
> +
> char *key_info_file;
> char key_file[LINE_BUFFER_SIZE + 1];
> char key_uri[LINE_BUFFER_SIZE + 1];
> @@ -349,6 +363,89 @@ fail:
> return ret;
> }
>
> +static int randomize(uint8_t *buf, int len)
> +{
> +#if CONFIG_GCRYPT
> +gcry_randomize(buf, len, GCRY_VERY_STRONG_RANDOM);
> +return 0;
> +#elif CONFIG_OPENSSL
> +if (RAND_bytes(buf, len))
> +return 0;
> +#else
> +return AVERROR(ENOSYS);
> +#endif
> +return AVERROR(EINVAL);
> +}
> +
> +static int do_encrypt(AVFormatContext *s)
> +{
> +HLSContext *hls = s->priv_data;
> +int ret;
> +int len;
> +AVIOContext *pb;
> +uint8_t key[KEYSIZE];
> +
> +len = strlen(hls->basename) + 4 + 1;
> +hls->key_basename = av_mallocz(len);
> +if (!hls->key_basename)
> +return AVERROR(ENOMEM);
> +
> +av_strlcpy(hls->key_basename, s->filename, len);
> +av_strlcat(hls->key_basename, ".key", len);
> +
> +if (hls->key_url) {
> +strncpy(hls->key_file, hls->key_url, sizeof(hls->key_file));
> +strncpy(hls->key_uri, hls->key_url, sizeof(hls->key_uri));
> +} else {
> +strncpy(hls->key_file, hls->key_basename, sizeof(hls->key_file));
> +strncpy(hls->key_uri, hls->key_basename, sizeof(hls->key_uri));
> +}
> +
> +if (!*hls->iv_string) {
> +uint8_t iv[16] = { 0 };
> +char buf[33];
> +
> +if (!hls->iv) {
> +AV_WB64(iv + 8, hls->sequence);
> +} else {
> +memcpy(iv, hls->iv, sizeof(iv));
> +}
> +ff_data_to_hex(buf, iv, sizeof(iv), 0);
> +buf[32] = '\0';
> +memcpy(hls->iv_string, buf, sizeof(hls->iv_string));
> +}
> +
> +if (!*hls->key_uri) {
> +av_log(hls, AV_LOG_ERROR, "no key URI specified in key info
> file\n");
> +return AVERROR(EINVAL);
> +}
> +
> +if (!*hls->key_file) {
> +av_log(hls, AV_LOG_ERROR, "no key file specified in key info
> file\n");
> +return AVERROR(EINVAL);
> +}
> +
> +if (!*hls->key_string) {
> +if (!hls->key) {
> +if ((ret = randomize(key, sizeof(key))) < 0) {
> +av_log(s, AV_LOG_ERROR, "Cannot generate a strong random
> key\n");
> +return ret;
> +}
> +} else {
> +memcpy(key, hls->key, sizeof(key));
> +}
> +
> +ff_data_to_hex(hls->key_string, key, sizeof(key), 0);
> +if ((ret = s->io_open(s, &pb, hls->key_file, AVIO_FLAG_WRITE,
> NULL)) < 0)
> +return ret;
> +avio_seek(pb, 0, SEEK_CUR);
> +avio_write(pb, key, KEYSIZE);
> +avio_close(pb);
> +}
> +return 0;
> +}
> +
> +
> static int hls_encryption_start(AVFormatContext *s)
> {
> HLSContext *hls = s->priv_data;
> @
Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function
On 14 April 2017 at 13:34, Carl Eugen Hoyos wrote: > 2017-04-14 14:30 GMT+02:00 Carl Eugen Hoyos : > > 2017-04-14 13:11 GMT+02:00 Rostislav Pehlivanov : > > >> Point is, I have used only code from libavcodec/opus_pvq.c from > >> the FFmpeg project. I don't have to do anything as all credit has > >> been given where due. > > > > I don't understand: > > The file opus_pvq.c contains copyright notices from Andrew > > D'Addesio and Mozilla. If you have used code from opus_pvq.c, > > shouldn't you add these copyright notices to the opus encoder? > > Or did you mean that you only used code that was already > present in libavcodec/opus_pvq.c without copying anything > to the new files you wrote (what "using" implied to me)? > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Yes, that is what I mean. Initially, all code from opus_pvq.c was in opus_celt.c. To tidy the decoder and reuse the code there for the encoder, I created opus_pvq.c, copying the header and keeping all the copyright as is. I then implemented encoding functionality (modifying existing code and writing new code) and added my copyright there as well. That's all. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function
On Fri, 14 Apr 2017 14:30:28 +0200 Carl Eugen Hoyos wrote: i understand you want to fix the copyright header of the file, that is a good idea. >We know that the avconv developers are violating the >copyright of many people, we fix that in the FFmpeg code as >soon as we are aware of it, there are many examples in gitlog. >I don't see how this case would be different. please refrain from making accusations and starting fights in ffmpeg mailing lists. this mailing list is for development, not fights. if you have a specific problem, feel free to blog about it on your personal website, like many other developers do. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 3.3
Hi, On Fri, Apr 14, 2017 at 4:24 AM, Michael Niedermayer wrote: > On Thu, Apr 13, 2017 at 09:00:33PM +0100, Rostislav Pehlivanov wrote: > > +We strongly recommend users, distributors, and system integrators to > > +upgrade unless they use current git master. > > as some developers had concerns about the release in relation to > merges prior to it, iam not sure we should recommand that or not. > > We could also wait with adding such recommandition and for example > add it for 3.3.1 when no major issues are reported on release/3.3 It's unusual to make a release if we're not sure users should upgrade to it? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function
On Fri, Apr 14, 2017 at 02:30:28PM +0200, Carl Eugen Hoyos wrote: [...] > We know that the avconv developers are violating the > copyright of many people, we fix that in the FFmpeg code as > soon as we are aware of it, there are many examples in gitlog. This is a serious accusation, what are you referring to? Please be careful when using "we" in such declaration, you are mistaken if you think this attitude represents the FFmpeg project. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function
2017-04-14 14:50 GMT+02:00 wm4 : > especially since your dictatorship over the bug tracker makes you This reminds me: Who is supposed to fix the regressions that you create and that users report on trac? Please try to refrain from such accusations. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavc/opus_pvg: Add missing copyright notices
Hi! As analyzed by Rostislav. Please comment, Carl Eugen From 66e02de36c53cc373e7ee4eeb8d134fa28d0641f Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Sat, 15 Apr 2017 00:32:43 +0200 Subject: [PATCH] lavc/opus_pvq: Add missing copyright notices from libopus. The file is based on libopus, analyzed by Rostislav Pehlivanov. --- libavcodec/opus_pvq.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/opus_pvq.c b/libavcodec/opus_pvq.c index 508..e424cb2 100644 --- a/libavcodec/opus_pvq.c +++ b/libavcodec/opus_pvq.c @@ -1,4 +1,7 @@ /* + * Copyright (c) 2007-2008 CSIRO + * Copyright (c) 2007-2009 Xiph.Org Foundation + * Copyright (c) 2008-2009 Gregory Maxwell * Copyright (c) 2012 Andrew D'Addesio * Copyright (c) 2013-2014 Mozilla Corporation * Copyright (c) 2017 Rostislav Pehlivanov -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function
2017-04-14 23:27 GMT+02:00 Clément Bœsch : > On Fri, Apr 14, 2017 at 02:30:28PM +0200, Carl Eugen Hoyos wrote: > [...] >> We know that the avconv developers are violating the >> copyright of many people, we fix that in the FFmpeg code as >> soon as we are aware of it, there are many examples in gitlog. > > This is a serious accusation, what are you referring to? To the same (many) commits in the avconv repository that violate the copyright of FFmpeg developers as many times before - sorry, I don't understand: Are you implying you don't remember such a commit? > Please be careful when using "we" in such declaration, you are > mistaken if you think this attitude represents the FFmpeg project. I see your point about "we" but don't you agree that our gitlog implies exactly this: That we - FFmpeg - believe that such commits exist? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function
2017-04-14 18:18 GMT+02:00 Rostislav Pehlivanov : > On 14 April 2017 at 13:34, Carl Eugen Hoyos wrote: > >> 2017-04-14 14:30 GMT+02:00 Carl Eugen Hoyos : >> > 2017-04-14 13:11 GMT+02:00 Rostislav Pehlivanov : >> >> >> Point is, I have used only code from libavcodec/opus_pvq.c from >> >> the FFmpeg project. I don't have to do anything as all credit has >> >> been given where due. >> > >> > I don't understand: >> > The file opus_pvq.c contains copyright notices from Andrew >> > D'Addesio and Mozilla. If you have used code from opus_pvq.c, >> > shouldn't you add these copyright notices to the opus encoder? >> >> Or did you mean that you only used code that was already >> present in libavcodec/opus_pvq.c without copying anything >> to the new files you wrote (what "using" implied to me)? > Yes, that is what I mean. > Initially, all code from opus_pvq.c was in opus_celt.c. To tidy the decoder > and reuse the code there for the encoder, I created opus_pvq.c, copying the > header and keeping all the copyright as is. I then implemented encoding > functionality (modifying existing code and writing new code) and added my > copyright there as well. That's all. Thank you for the clarification, patch sent. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 3.3
On Fri, Apr 14, 2017 at 04:07:41PM -0400, Ronald S. Bultje wrote: > Hi, > > On Fri, Apr 14, 2017 at 4:24 AM, Michael Niedermayer > wrote: > > > On Thu, Apr 13, 2017 at 09:00:33PM +0100, Rostislav Pehlivanov wrote: > > > +We strongly recommend users, distributors, and system integrators to > > > +upgrade unless they use current git master. > > > > as some developers had concerns about the release in relation to > > merges prior to it, iam not sure we should recommand that or not. > > > > We could also wait with adding such recommandition and for example > > add it for 3.3.1 when no major issues are reported on release/3.3 > > > It's unusual to make a release if we're not sure users should upgrade to it? iam not sure i understand what you are trying to say? but ill try to awnser anyway I dont think its unusual that after a large number of changes or a long time since the last release theres higher uncertanity in the code state. Nor is it unusual that one doesnt suggest everyone to upgrade to a "dot zero" release but waits for .1, for example ubuntu does that AFAIK Iam not sure what the team prefers, how can i be sure without asking? and thats what i did above, i asked [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data 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] opus_pvq: add resynth support and band encoding cost function
On Sat, 15 Apr 2017 00:29:44 +0200 Carl Eugen Hoyos wrote: > 2017-04-14 14:50 GMT+02:00 wm4 : > > > especially since your dictatorship over the bug tracker makes you > > This reminds me: Who is supposed to fix the regressions > that you create and that users report on trac? I know nothing of such regressions, which apparently marks your total failure to properly drainage issues on the bug tracker and reporting issues to the responsible developers. What are you doing on the bug tracker again, other than detracting people from the ffmpeg project? > Please try to refrain from such accusations. It's not an accusation if it's fact. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 3.3
On 4/14/2017 8:32 PM, Michael Niedermayer wrote: > On Fri, Apr 14, 2017 at 04:07:41PM -0400, Ronald S. Bultje wrote: >> Hi, >> >> On Fri, Apr 14, 2017 at 4:24 AM, Michael Niedermayer >> wrote: >> >>> On Thu, Apr 13, 2017 at 09:00:33PM +0100, Rostislav Pehlivanov wrote: +We strongly recommend users, distributors, and system integrators to +upgrade unless they use current git master. >>> >>> as some developers had concerns about the release in relation to >>> merges prior to it, iam not sure we should recommand that or not. >>> >>> We could also wait with adding such recommandition and for example >>> add it for 3.3.1 when no major issues are reported on release/3.3 >> >> >> It's unusual to make a release if we're not sure users should upgrade to it? > > iam not sure i understand what you are trying to say? > but ill try to awnser anyway > > I dont think its unusual that after a large number of changes or a long > time since the last release theres higher uncertanity in the code state. > > Nor is it unusual that one doesnt suggest everyone to upgrade to a > "dot zero" release but waits for .1, for example ubuntu does that AFAIK > > Iam not sure what the team prefers, how can i be sure without asking? > and thats what i did above, i asked IMO, since the "we strongly recommend" line has been a constant in all releases, removing it now will (for those that notice it) rise quite a few red flags and make people come to the conclusion they should probably skip it altogether. If we expect people to use it and hopefully report any issues with it, we shouldn't do something that will scare them away. And really, the tree wasn't any more "unstable" when we branched it for 3.3 than how it had been when we branched previous releases. All new release branches featured merges up to some arbitrary point. It's even been two weeks since the branch was cut, and no outstanding issues were found even in master, so lets try to not start spreading uncertainty. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function
On Sat, 15 Apr 2017 00:28:19 +0200 Carl Eugen Hoyos wrote: > 2017-04-14 23:27 GMT+02:00 Clément Bœsch : > > On Fri, Apr 14, 2017 at 02:30:28PM +0200, Carl Eugen Hoyos wrote: > > [...] > >> We know that the avconv developers are violating the > >> copyright of many people, we fix that in the FFmpeg code as > >> soon as we are aware of it, there are many examples in gitlog. > > > > This is a serious accusation, what are you referring to? > > To the same (many) commits in the avconv repository that > violate the copyright of FFmpeg developers as many times > before - sorry, I don't understand: Are you implying you don't > remember such a commit? Of course you keep repeating your defamation without providing proof, ever. > > Please be careful when using "we" in such declaration, you are > > mistaken if you think this attitude represents the FFmpeg project. > > I see your point about "we" but don't you agree that our gitlog > implies exactly this: That we - FFmpeg - believe that such commits > exist? You don't speak for the FFmpeg project (fortunately). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Enhanced require_pkg_config() in configure to fallback to require() if pkg-config is missing
On 4/14/2017 1:09 AM, Hendrik Leppkes wrote:
On Fri, Apr 14, 2017 at 2:56 AM, Aaron Levinson wrote:
From 48f7daba16e0fcdb83d9abd254800c7b9f4ab684 Mon Sep 17 00:00:00 2001
From: Aaron Levinson
Date: Thu, 13 Apr 2017 17:30:47 -0700
Subject: [PATCH] Enhanced require_pkg_config() in configure to fallback to
require() if pkg-config is missing
Purpose: Enhanced require_pkg_config() in configure to
fallback to require() if pkg-config is missing
Notes: This is likely mainly of relevance when building with MSVC on
Windows. In my case, I used this approach to get libmfx when invoking
configure with --enable-libmfx, which is used for QuickSync (QSV).
Comments:
-- configure: Enhanced require_pkg_config() function to first check if
$pkg_config is not false. If not false, it goes through the
standard steps of calling use_pkg_config(), but if false, it issues
a log message and then calls require() with all the inputted
arguments and an additional argument: -l$1. So, for something like
"require_pkg_config libmfx "mfx/mfxvideo.h" MFXInit", this becomes
"require libmfx "mfx/mfxvideo.h" MFXInit -llibmfx". This is not a
perfect solution, but the previous approach didn't work at all
before when require_pkg_config() is used.
---
configure | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 7f2b653..ad08b82 100755
--- a/configure
+++ b/configure
@@ -1347,7 +1347,12 @@ use_pkg_config(){
}
require_pkg_config(){
-use_pkg_config "$@" || die "ERROR: $pkg not found using
pkg-config$pkg_config_fail_message"
+if test $pkg_config != false; then
+use_pkg_config "$@" || die "ERROR: $pkg not found using
pkg-config$pkg_config_fail_message"
+else
+log require_pkg_config "No pkg-config, using require for $@"
+require "$@ -l$1"
+fi
}
pkg-config typically provides more then just a location of the files,
and while it happens to work for mfx in your case, I don't think this
generic fallback is a good idea.
We already require a linux-esque build environment, even for MSVC
builds (ie. msys or cygwin, etc), having pkg-config on top of the
other required tools isn't that hard of a dependency to fullfill - I
do that all the time.
- Hendrik
OK. Please disregard this patch, and I will submit a different one that
does something more specific for libmfx.
Thanks,
Aaron Levinson
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 3.3
On Fri, Apr 14, 2017 at 08:48:55PM -0300, James Almer wrote: > On 4/14/2017 8:32 PM, Michael Niedermayer wrote: > > On Fri, Apr 14, 2017 at 04:07:41PM -0400, Ronald S. Bultje wrote: > >> Hi, > >> > >> On Fri, Apr 14, 2017 at 4:24 AM, Michael Niedermayer > >> >>> wrote: > >> > >>> On Thu, Apr 13, 2017 at 09:00:33PM +0100, Rostislav Pehlivanov wrote: > +We strongly recommend users, distributors, and system integrators to > +upgrade unless they use current git master. > >>> > >>> as some developers had concerns about the release in relation to > >>> merges prior to it, iam not sure we should recommand that or not. > >>> > >>> We could also wait with adding such recommandition and for example > >>> add it for 3.3.1 when no major issues are reported on release/3.3 > >> > >> > >> It's unusual to make a release if we're not sure users should upgrade to > >> it? > > > > iam not sure i understand what you are trying to say? > > but ill try to awnser anyway > > > > I dont think its unusual that after a large number of changes or a long > > time since the last release theres higher uncertanity in the code state. > > > > Nor is it unusual that one doesnt suggest everyone to upgrade to a > > "dot zero" release but waits for .1, for example ubuntu does that AFAIK > > > > Iam not sure what the team prefers, how can i be sure without asking? > > and thats what i did above, i asked > > IMO, since the "we strongly recommend" line has been a constant in all > releases, removing it now will (for those that notice it) rise quite a > few red flags and make people come to the conclusion they should > probably skip it altogether. > If we expect people to use it and hopefully report any issues with it, > we shouldn't do something that will scare them away. > > And really, the tree wasn't any more "unstable" when we branched it > for 3.3 than how it had been when we branched previous releases. All > new release branches featured merges up to some arbitrary point. > It's even been two weeks since the branch was cut, and no outstanding > issues were found even in master, so lets try to not start spreading > uncertainty. sure, lets do what people prefer [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. 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] opus_pvq: add resynth support and band encoding cost function
On 4/15/17, wm4 wrote: > On Sat, 15 Apr 2017 00:28:19 +0200 > Carl Eugen Hoyos wrote: > >> 2017-04-14 23:27 GMT+02:00 Clément Bœsch : >> > On Fri, Apr 14, 2017 at 02:30:28PM +0200, Carl Eugen Hoyos wrote: >> > [...] >> >> We know that the avconv developers are violating the >> >> copyright of many people, we fix that in the FFmpeg code as >> >> soon as we are aware of it, there are many examples in gitlog. >> > >> > This is a serious accusation, what are you referring to? >> >> To the same (many) commits in the avconv repository that >> violate the copyright of FFmpeg developers as many times >> before - sorry, I don't understand: Are you implying you don't >> remember such a commit? > > Of course you keep repeating your defamation without providing proof, > ever. http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=attribution I found the above link in the "Reintroducing FFmpeg to Debian" thread (2014). It still works :D I do remember that in 2014 Ronald was pressuring Libav (e.g. Vittorio) about proper attribution to the changes done by multiple Libav developers when merging ffvp9. (AKA who exactly changed what). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function
On Sat, 15 Apr 2017 03:14:12 +0300 Ivan Kalvachev wrote: > On 4/15/17, wm4 wrote: > > On Sat, 15 Apr 2017 00:28:19 +0200 > > Carl Eugen Hoyos wrote: > > > >> 2017-04-14 23:27 GMT+02:00 Clément Bœsch : > >> > On Fri, Apr 14, 2017 at 02:30:28PM +0200, Carl Eugen Hoyos wrote: > >> > [...] > >> >> We know that the avconv developers are violating the > >> >> copyright of many people, we fix that in the FFmpeg code as > >> >> soon as we are aware of it, there are many examples in gitlog. > >> > > >> > This is a serious accusation, what are you referring to? > >> > >> To the same (many) commits in the avconv repository that > >> violate the copyright of FFmpeg developers as many times > >> before - sorry, I don't understand: Are you implying you don't > >> remember such a commit? > > > > Of course you keep repeating your defamation without providing proof, > > ever. > > http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=attribution > > I found the above link in the "Reintroducing FFmpeg to Debian" thread (2014). > It still works :D > > I do remember that in 2014 Ronald was pressuring Libav (e.g. Vittorio) > about proper attribution to the changes done by multiple Libav developers when > merging ffvp9. (AKA who exactly changed what). Legally, all these copyright headers are meaningless, as long as the license is correct. If they weren't, FFmpeg would be in trouble for changing the copyright headers of all files added by Libav from "Libav" to "FFmpeg". It's possible that Libav is not always careful with attribution, but it's the same with FFmpeg. For example, af_pan.c is LGPL, even though it was ported from MPlayer GPL code, and the author could not be contacted. Recently, I contacted the same author about relicensing the same MPlayer code (of which af_pan.c was a subset of) to LGPL, and he explicitly denied relicensing. So if I had been cehoyos, I probably wouldn't shut up about how FFmpeg violates copyrights (fortunately I'm not cehoyos). I think nowadays af_pan.c certainly does not violate the original author's copyright though, because absolutely all code was removed/replaced. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/opus_pvg: Add missing copyright notices
On 15 April 2017 at 01:52, Rostislav Pehlivanov wrote: > > > On 14 April 2017 at 23:35, Carl Eugen Hoyos wrote: > >> Hi! >> >> As analyzed by Rostislav. >> >> Please comment, Carl Eugen >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> > LGTM, apply and get this thread over with > But change the commit message to pvq, its not pvg ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/opus_pvg: Add missing copyright notices
On 14 April 2017 at 23:35, Carl Eugen Hoyos wrote: > Hi! > > As analyzed by Rostislav. > > Please comment, Carl Eugen > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > LGTM, apply and get this thread over with ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Enhanced require_pkg_config() in configure to fallback to require() if pkg-config is missing
On 4/13/2017 9:56 PM, Aaron Levinson wrote:
> From 48f7daba16e0fcdb83d9abd254800c7b9f4ab684 Mon Sep 17 00:00:00 2001
> From: Aaron Levinson
> Date: Thu, 13 Apr 2017 17:30:47 -0700
> Subject: [PATCH] Enhanced require_pkg_config() in configure to fallback to
> require() if pkg-config is missing
>
> Purpose: Enhanced require_pkg_config() in configure to
> fallback to require() if pkg-config is missing
>
> Notes: This is likely mainly of relevance when building with MSVC on
> Windows. In my case, I used this approach to get libmfx when invoking
> configure with --enable-libmfx, which is used for QuickSync (QSV).
>
> Comments:
>
> -- configure: Enhanced require_pkg_config() function to first check if
>$pkg_config is not false. If not false, it goes through the
>standard steps of calling use_pkg_config(), but if false, it issues
>a log message and then calls require() with all the inputted
>arguments and an additional argument: -l$1. So, for something like
>"require_pkg_config libmfx "mfx/mfxvideo.h" MFXInit", this becomes
>"require libmfx "mfx/mfxvideo.h" MFXInit -llibmfx". This is not a
>perfect solution, but the previous approach didn't work at all
>before when require_pkg_config() is used.
> ---
> configure | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 7f2b653..ad08b82 100755
> --- a/configure
> +++ b/configure
> @@ -1347,7 +1347,12 @@ use_pkg_config(){
> }
>
> require_pkg_config(){
> -use_pkg_config "$@" || die "ERROR: $pkg not found using
> pkg-config$pkg_config_fail_message"
> +if test $pkg_config != false; then
> +use_pkg_config "$@" || die "ERROR: $pkg not found using
> pkg-config$pkg_config_fail_message"
> +else
> +log require_pkg_config "No pkg-config, using require for $@"
> +require "$@ -l$1"
> +fi
This will fail in a thousand ways with packages that require other
packages, specific cflags, specific ldflags, or that state specific
versions.
As Hendrik said, pkg-config is not just a fancy way to add -I and -L
options to the compiler and linker.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Enhanced configure and Makefile to copy .pdb files to bindir for MSVC builds for make install
From 1059473c449c3079f03461bb42c2d3cc21d1b2c1 Mon Sep 17 00:00:00 2001
From: Aaron Levinson
Date: Fri, 14 Apr 2017 18:14:21 -0700
Subject: [PATCH] Enhanced configure and Makefile to copy .pdb files to
bindir for MSVC builds for make install
Purpose: Enhanced configure and Makefile to copy .pdb files to bindir
for MSVC builds for make install. Files are also uninstalled
appropriately when make uninstall is exercised. Placing the PDB files
in the same directory as other binaries can make it easier to debug,
especially if the files are copied to another system.
Note: General idea for how to properly handle the copying of PDB files
associated with programs suggested by Hendrik Leppkes.
Comments:
-- configure:
a) Leveraged already existing SLIB_INSTALL_EXTRA_SHLIB facility (which
is already pretty specific to Windows) to add .pdb files, in
addition to .lib files, for shared libraries to bindir during make
install.
b) Added PROG_INSTALL_EXTRA_BIN variable for MSVC builds and also
added it to the section that causes it to be added to config.mak.
This is used in Makefile to copy any additional files associated
with programs. For MSVC, it is used to copy the pdb files
associated with any executables that are built. Note that such
executables are build with _g in the file name and are later copied
to a filename without _g in the file name. As such, the PDB files
have _g in the file name.
-- Makefile: Enhanced install-progs and uninstall-progs targets to
handle PROG_INSTALL_EXTRA_BIN if defined. It uses a similar
procedure as already in place for SLIB_INSTALL_EXTRA_SHLIB in
library.mak.
---
Makefile | 2 ++
configure | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index d5b51de..45c42c6 100644
--- a/Makefile
+++ b/Makefile
@@ -165,6 +165,7 @@ install-progs-$(CONFIG_SHARED): install-libs
install-progs: install-progs-yes $(AVPROGS)
$(Q)mkdir -p "$(BINDIR)"
$(INSTALL) -c -m 755 $(INSTPROGS) "$(BINDIR)"
+ $(if $(PROG_INSTALL_EXTRA_BIN), $(INSTALL) -m 644
$(PROG_INSTALL_EXTRA_BIN) "$(BINDIR)")
install-data: $(DATA_FILES) $(EXAMPLES_FILES)
$(Q)mkdir -p "$(DATADIR)/examples"
@@ -175,6 +176,7 @@ uninstall: uninstall-libs uninstall-headers uninstall-progs
uninstall-data
uninstall-progs:
$(RM) $(addprefix "$(BINDIR)/", $(ALLAVPROGS))
+ $(if $(PROG_INSTALL_EXTRA_BIN), $(RM) $(addprefix "$(BINDIR)/",
$(PROG_INSTALL_EXTRA_BIN)))
uninstall-data:
$(RM) -r "$(DATADIR)"
diff --git a/configure b/configure
index 18d79ab..88206e3 100755
--- a/configure
+++ b/configure
@@ -4947,9 +4947,10 @@ case $target_os in
SLIB_CREATE_DEF_CMD='$(SRC_PATH)/compat/windows/makedef
$(SUBDIR)lib$(NAME).ver $(OBJS) > $$(@:$(SLIBSUF)=.def)'
SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)'
SLIB_INSTALL_LINKS=
-SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)'
+SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)
$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.pdb)'
SLIB_INSTALL_EXTRA_LIB='$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
SHFLAGS='-dll -def:$$(@:$(SLIBSUF)=.def)
-implib:$(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib)'
+PROG_INSTALL_EXTRA_BIN='$(AVPROGS-yes:%=%$(PROGSSUF)_g.pdb)'
objformat="win32"
ranlib=:
enable dos_paths
@@ -6796,6 +6797,7 @@ SLIB_INSTALL_NAME=${SLIB_INSTALL_NAME}
SLIB_INSTALL_LINKS=${SLIB_INSTALL_LINKS}
SLIB_INSTALL_EXTRA_LIB=${SLIB_INSTALL_EXTRA_LIB}
SLIB_INSTALL_EXTRA_SHLIB=${SLIB_INSTALL_EXTRA_SHLIB}
+PROG_INSTALL_EXTRA_BIN=${PROG_INSTALL_EXTRA_BIN}
VERSION_SCRIPT_POSTPROCESS_CMD=${VERSION_SCRIPT_POSTPROCESS_CMD}
SAMPLES:=${samples:-\$(FATE_SAMPLES)}
NOREDZONE_FLAGS=$noredzone_flags
--
2.10.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 3.3
On Thu, Apr 13, 2017 at 09:00:33PM +0100, Rostislav Pehlivanov wrote: > Signed-off-by: Rostislav Pehlivanov > --- > src/index | 53 + > 1 file changed, 53 insertions(+) > > diff --git a/src/index b/src/index > index c203676..1b8a037 100644 > --- a/src/index > +++ b/src/index > @@ -37,6 +37,59 @@ > News > > > + April 13th, 2017, FFmpeg 3.3 "Hilbert" > + > +FFmpeg 3.3 "Hilbert", a new > +major release, is now available! Some of the highlights: > + > + > + is this valid html ? it looked funky and so i checked and found: http://stackoverflow.com/questions/2161337/can-we-use-any-other-tag-inside-ul-along-with-li which says no [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Added require fallback for libmfx in the case that pkg-config cannot find libmfx
From e0c73c054add0137901d0bf7a7893e42e7e566c8 Mon Sep 17 00:00:00 2001
From: Aaron Levinson
Date: Fri, 14 Apr 2017 18:38:37 -0700
Subject: [PATCH] Added require fallback for libmfx in the case that
pkg-config cannot find libmfx
Purpose: Added require fallback for libmfx in the case that pkg-config
cannot find libmfx. On Linux, most people likely get libmfx via
https://github.com/lu-zero/mfx_dispatch , but on Windows, the most
well-known way to get libmfx is via the Intel Media SDK, which
provides a static build of libmfx.lib and also provides the source
code for building libmfx yourself. If built this way, there are no
pkg-config files to be found. The changes utilize a similar approach
to that already done for libx264 in configure.
Comments:
-- configure: Altered enabled libmfx step to use use_pkg_config()
instead of require_pkg_config(), and, if use_pkg_config() fails, it
falls back to require(). Note that the reason that require() is
passed -llibmfx as the last argument, instead of -lmfx, is the file
name for the library produced from the Intel Media SDK starts with
"libmfx". Apparently, the filename for the library produced via
https://github.com/lu-zero/mfx_dispatch starts with "mfx".
---
configure | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 3bea057..b20a0b4 100755
--- a/configure
+++ b/configure
@@ -5819,7 +5819,8 @@ enabled libgsm&& { for gsm_hdr in "gsm.h"
"gsm/gsm.h"; do
done || die "ERROR: libgsm not found"; }
enabled libilbc && require libilbc ilbc.h WebRtcIlbcfix_InitDecode
-lilbc
enabled libkvazaar&& require_pkg_config "kvazaar >= 0.8.1" kvazaar.h
kvz_api_get
-enabled libmfx&& require_pkg_config libmfx "mfx/mfxvideo.h" MFXInit
+enabled libmfx&& { use_pkg_config libmfx "mfx/mfxvideo.h" MFXInit
||
+ { require libmfx "mfx/mfxvideo.h" MFXInit
-llibmfx && warn "using libmfx without pkg-config"; } }
enabled libmodplug&& require_pkg_config libmodplug
libmodplug/modplug.h ModPlug_Load
enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h
lame_set_VBR_quality -lmp3lame
enabled libnut&& require libnut libnut.h nut_demuxer_init -lnut
--
2.10.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/6 v3] AVX functions for 8-bit H.264 IDCT
Changes: - Added sse2 functions - Fixed an incorrect xmm register count I did not make the change suggested by Gramner about TAIL_CALL and I did leave the TODOs there. If there are no further objections I will push by Monday at the latest. I want to get this out the door. James Darnley (6): avcodec/h264: change RETs into REP_RETs where appropriate avcodec/h264: change some labels to be macro-local avcodec/h264: use some 3 operand forms avcodec/h264: add avx 8-bit h264_idct_add avcodec/h264: add avx 8-bit h264_idct_dc_add avcodec/h264: add sse2 versions of previous idct functions libavcodec/x86/h264_idct.asm | 117 +++--- libavcodec/x86/h264dsp_init.c | 10 2 files changed, 96 insertions(+), 31 deletions(-) -- 2.8.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/6] avcodec/h264: change RETs into REP_RETs where appropriate
--- libavcodec/x86/h264_idct.asm | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm index c36fea5..878ff02 100644 --- a/libavcodec/x86/h264_idct.asm +++ b/libavcodec/x86/h264_idct.asm @@ -695,7 +695,7 @@ cglobal h264_idct_add8_8, 5, 8 + npicregs, 0, dst1, block_offset, block, stride, addr0mp, gprsize %endif call h264_idct_add8_mmx_plane -RET +RET ; TODO: check rep ret after a function call cglobal h264_idct_add8_422_8, 5, 8 + npicregs, 0, dst1, block_offset, block, stride, nnzc, cntr, coeff, dst2, picreg ; dst1, block_offset, block, stride, nnzc, cntr, coeff, dst2, picreg @@ -727,7 +727,7 @@ cglobal h264_idct_add8_422_8, 5, 8 + npicregs, 0, dst1, block_offset, block, str add r5, 4 call h264_idct_add8_mmx_plane -RET +RET ; TODO: check rep ret after a function call h264_idct_add8_mmxext_plane: movsxdifnidn r3, r3d @@ -795,7 +795,7 @@ cglobal h264_idct_add8_8, 5, 8 + npicregs, 0, dst1, block_offset, block, stride, addr0mp, gprsize %endif call h264_idct_add8_mmxext_plane -RET +RET ; TODO: check rep ret after a function call ; r0 = uint8_t *dst, r2 = int16_t *block, r3 = int stride, r6=clobbered h264_idct_dc_add8_mmxext: @@ -878,7 +878,7 @@ cglobal h264_idct_add16_8, 5, 5 + ARCH_X86_64, 8 add16_sse2_cycle 5, 0x24 add16_sse2_cycle 6, 0x1e add16_sse2_cycle 7, 0x26 -RET +REP_RET %macro add16intra_sse2_cycle 2 movzx r0, word [r4+%2] @@ -925,7 +925,7 @@ cglobal h264_idct_add16intra_8, 5, 7 + ARCH_X86_64, 8 add16intra_sse2_cycle 5, 0x24 add16intra_sse2_cycle 6, 0x1e add16intra_sse2_cycle 7, 0x26 -RET +REP_RET %macro add8_sse2_cycle 2 movzx r0, word [r4+%2] @@ -980,7 +980,7 @@ cglobal h264_idct_add8_8, 5, 7 + ARCH_X86_64, 8 %endif add8_sse2_cycle 2, 0x5c add8_sse2_cycle 3, 0x64 -RET +REP_RET ;void ff_h264_luma_dc_dequant_idct_mmx(int16_t *output, int16_t *input, int qmul) -- 2.8.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/6] avcodec/h264: use some 3 operand forms
--- libavcodec/x86/h264_idct.asm | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm index dde40e9..bc4dce4 100644 --- a/libavcodec/x86/h264_idct.asm +++ b/libavcodec/x86/h264_idct.asm @@ -87,10 +87,9 @@ cglobal h264_idct_add_8, 3, 3, 0 RET %macro IDCT8_1D 2 -mova m0, m1 -psrawm1, 1 -mova m4, m5 -psrawm4, 1 +psrawm0, m1, 1 +SWAP 0, 1 +psrawm4, m5, 1 paddwm4, m5 paddwm1, m0 paddwm4, m7 @@ -107,10 +106,9 @@ cglobal h264_idct_add_8, 3, 3, 0 psubwm0, m3 psubwm5, m7 -mova m7, m1 -psrawm1, 2 -mova m3, m4 -psrawm3, 2 +psrawm7, m1, 2 +SWAP 7,1 +psrawm3, m4, 2 paddwm3, m0 psrawm0, 2 paddwm1, m5 @@ -118,10 +116,9 @@ cglobal h264_idct_add_8, 3, 3, 0 psubwm0, m4 psubwm7, m5 -mova m5, m6 -psrawm6, 1 -mova m4, m2 -psrawm4, 1 +psrawm5, m6, 1 +SWAP 5,6 +psrawm4, m2, 1 paddwm6, m2 psubwm4, m5 -- 2.8.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/6] avcodec/h264: add avx 8-bit h264_idct_add
Haswell:
- 1.11x faster (522±0.4 vs. 469±1.8 decicycles) compared with mmxext
Skylake-U:
- 1.21x faster (671±5.5 vs. 555±1.4 decicycles) compared with mmxext
---
libavcodec/x86/h264_idct.asm | 33 -
libavcodec/x86/h264dsp_init.c | 3 +++
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm
index bc4dce4..24fb4d2 100644
--- a/libavcodec/x86/h264_idct.asm
+++ b/libavcodec/x86/h264_idct.asm
@@ -65,7 +65,15 @@ SECTION .text
IDCT4_1D w, 0, 1, 2, 3, 4, 5
mova m6, [pw_32]
-TRANSPOSE4x4W 0, 1, 2, 3, 4
+%if mmsize == 8
+TRANSPOSE4x4W 0, 1, 2, 3, 4
+%else
+punpcklwd m0, m1
+punpcklwd m2, m3
+SBUTTERFLY dq, 0, 2, 4
+MOVHL m1, m0
+MOVHL m3, m2
+%endif
paddwm0, m6
IDCT4_1D w, 0, 1, 2, 3, 4, 5
pxor m7, m7
@@ -1131,3 +1139,26 @@ INIT_MMX mmx
IDCT_DC_DEQUANT 0
INIT_MMX sse2
IDCT_DC_DEQUANT 7
+
+INIT_XMM avx
+
+; %unmacro STORE_DIFFx2 8 ; remove macro from x86util.asm but yasm doesn't
have this yet
+%macro STORE_DIFFx2 8 ; add1, add2, reg1, reg2, zero, shift, source, stride
+movd %3, [%7]
+movd %4, [%7+%8]
+psraw %1, %6
+psraw %2, %6
+punpcklbw %3, %5
+punpcklbw %4, %5
+paddw %3, %1
+paddw %4, %2
+packuswb %3, %5
+packuswb %4, %5
+movd [%7], %3
+movd [%7+%8], %4
+%endmacro
+
+cglobal h264_idct_add_8, 3, 3, 8, dst_, block_, stride_
+movsxdifnidn stride_q, stride_d
+IDCT4_ADDdst_q, block_q, stride_q
+RET
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index 0643b37..8ba085f 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -32,6 +32,7 @@ void ff_h264_idct ## NUM ## _add_ ## DEPTH ## _ ##
OPT(uint8_t *dst,\
int stride);
IDCT_ADD_FUNC(, 8, mmx)
+IDCT_ADD_FUNC(, 8, avx)
IDCT_ADD_FUNC(, 10, sse2)
IDCT_ADD_FUNC(_dc, 8, mmxext)
IDCT_ADD_FUNC(_dc, 10, mmxext)
@@ -337,6 +338,8 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const
int bit_depth,
c->h264_h_loop_filter_chroma =
ff_deblock_h_chroma422_8_avx;
c->h264_h_loop_filter_chroma_intra =
ff_deblock_h_chroma422_intra_8_avx;
}
+
+c->h264_idct_add= ff_h264_idct_add_8_avx;
}
} else if (bit_depth == 10) {
if (EXTERNAL_MMXEXT(cpu_flags)) {
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/6] avcodec/h264: add sse2 versions of previous idct functions
Kaby Lake Pentium:
- ff_h264_idct_add_8_sse2:~1.18x faster than mmxext
- ff_h264_idct_dc_add_8_sse2: ~1.07x faster than mmxext
---
libavcodec/x86/h264_idct.asm | 11 +--
libavcodec/x86/h264dsp_init.c | 5 +
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm
index 43f7791..5d83d91 100644
--- a/libavcodec/x86/h264_idct.asm
+++ b/libavcodec/x86/h264_idct.asm
@@ -1140,8 +1140,6 @@ IDCT_DC_DEQUANT 0
INIT_MMX sse2
IDCT_DC_DEQUANT 7
-INIT_XMM avx
-
; %unmacro STORE_DIFFx2 8 ; remove macro from x86util.asm but yasm doesn't
have this yet
%macro STORE_DIFFx2 8 ; add1, add2, reg1, reg2, zero, shift, source, stride
movd %3, [%7]
@@ -1170,6 +1168,10 @@ INIT_XMM avx
packuswb m1, m1
%endmacro
+%macro IDCT_XMM 1
+
+INIT_XMM %1
+
cglobal h264_idct_add_8, 3, 3, 8, dst_, block_, stride_
movsxdifnidn stride_q, stride_d
IDCT4_ADDdst_q, block_q, stride_q
@@ -1182,3 +1184,8 @@ cglobal h264_idct_dc_add_8, 3, 4, 6, dst_, block_, stride_
DC_ADD_INIT r3
DC_ADD_MMXEXT_OP movd, dst_q, stride_q, r3
RET
+
+%endmacro
+
+IDCT_XMM sse2
+IDCT_XMM avx
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index bf74937..ce7179f 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -32,9 +32,11 @@ void ff_h264_idct ## NUM ## _add_ ## DEPTH ## _ ##
OPT(uint8_t *dst,\
int stride);
IDCT_ADD_FUNC(, 8, mmx)
+IDCT_ADD_FUNC(, 8, sse2)
IDCT_ADD_FUNC(, 8, avx)
IDCT_ADD_FUNC(, 10, sse2)
IDCT_ADD_FUNC(_dc, 8, mmxext)
+IDCT_ADD_FUNC(_dc, 8, sse2)
IDCT_ADD_FUNC(_dc, 8, avx)
IDCT_ADD_FUNC(_dc, 10, mmxext)
IDCT_ADD_FUNC(8_dc, 8, mmxext)
@@ -316,6 +318,9 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const
int bit_depth,
c->h264_h_loop_filter_chroma =
ff_deblock_h_chroma422_8_sse2;
c->h264_h_loop_filter_chroma_intra =
ff_deblock_h_chroma422_intra_8_sse2;
}
+
+c->h264_idct_add= ff_h264_idct_add_8_sse2;
+c->h264_idct_dc_add = ff_h264_idct_dc_add_8_sse2;
}
if (EXTERNAL_SSSE3(cpu_flags)) {
c->biweight_h264_pixels_tab[0] = ff_h264_biweight_16_ssse3;
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/6] avcodec/h264: change some labels to be macro-local
The labels get stripped leading to (slightly) nicer disassembly from objdump. --- libavcodec/x86/h264_idct.asm | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm index 878ff02..dde40e9 100644 --- a/libavcodec/x86/h264_idct.asm +++ b/libavcodec/x86/h264_idct.asm @@ -846,7 +846,7 @@ h264_add8x4_idct_sse2: %macro add16_sse2_cycle 2 movzx r0, word [r4+%2] testr0, r0 -jz .cycle%1end +jz %%skip movr0d, dword [r1+%1*8] %if ARCH_X86_64 add r0, r5 @@ -854,7 +854,7 @@ h264_add8x4_idct_sse2: add r0, r0m %endif callh264_add8x4_idct_sse2 -.cycle%1end: +%%skip: %if %1 < 7 add r2, 64 %endif @@ -883,7 +883,7 @@ REP_RET %macro add16intra_sse2_cycle 2 movzx r0, word [r4+%2] testr0, r0 -jz .try%1dc +jz %%trydc movr0d, dword [r1+%1*8] %if ARCH_X86_64 add r0, r7 @@ -891,11 +891,11 @@ REP_RET add r0, r0m %endif callh264_add8x4_idct_sse2 -jmp .cycle%1end -.try%1dc: +jmp %%skip +%%trydc: movsx r0, word [r2 ] or r0w, word [r2+32] -jz .cycle%1end +jz %%skip movr0d, dword [r1+%1*8] %if ARCH_X86_64 add r0, r7 @@ -903,7 +903,7 @@ REP_RET add r0, r0m %endif callh264_idct_dc_add8_mmxext -.cycle%1end: +%%skip: %if %1 < 7 add r2, 64 %endif @@ -930,7 +930,7 @@ REP_RET %macro add8_sse2_cycle 2 movzx r0, word [r4+%2] testr0, r0 -jz .try%1dc +jz %%trydc %if ARCH_X86_64 movr0d, dword [r1+(%1&1)*8+64*(1+(%1>>1))] add r0, [r7] @@ -940,11 +940,11 @@ REP_RET add r0, dword [r1+(%1&1)*8+64*(1+(%1>>1))] %endif callh264_add8x4_idct_sse2 -jmp .cycle%1end -.try%1dc: +jmp %%cycle_end +%%trydc: movsx r0, word [r2 ] or r0w, word [r2+32] -jz .cycle%1end +jz %%cycle_end %if ARCH_X86_64 movr0d, dword [r1+(%1&1)*8+64*(1+(%1>>1))] add r0, [r7] @@ -954,7 +954,7 @@ REP_RET add r0, dword [r1+(%1&1)*8+64*(1+(%1>>1))] %endif callh264_idct_dc_add8_mmxext -.cycle%1end: +%%cycle_end: %if %1 == 1 add r2, 384+64 %elif %1 < 3 -- 2.8.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Enhanced require_pkg_config() in configure to fallback to require() if pkg-config is missing
On 4/14/2017 6:04 PM, James Almer wrote:
On 4/13/2017 9:56 PM, Aaron Levinson wrote:
From 48f7daba16e0fcdb83d9abd254800c7b9f4ab684 Mon Sep 17 00:00:00 2001
From: Aaron Levinson
Date: Thu, 13 Apr 2017 17:30:47 -0700
Subject: [PATCH] Enhanced require_pkg_config() in configure to fallback to
require() if pkg-config is missing
Purpose: Enhanced require_pkg_config() in configure to
fallback to require() if pkg-config is missing
Notes: This is likely mainly of relevance when building with MSVC on
Windows. In my case, I used this approach to get libmfx when invoking
configure with --enable-libmfx, which is used for QuickSync (QSV).
Comments:
-- configure: Enhanced require_pkg_config() function to first check if
$pkg_config is not false. If not false, it goes through the
standard steps of calling use_pkg_config(), but if false, it issues
a log message and then calls require() with all the inputted
arguments and an additional argument: -l$1. So, for something like
"require_pkg_config libmfx "mfx/mfxvideo.h" MFXInit", this becomes
"require libmfx "mfx/mfxvideo.h" MFXInit -llibmfx". This is not a
perfect solution, but the previous approach didn't work at all
before when require_pkg_config() is used.
---
configure | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 7f2b653..ad08b82 100755
--- a/configure
+++ b/configure
@@ -1347,7 +1347,12 @@ use_pkg_config(){
}
require_pkg_config(){
-use_pkg_config "$@" || die "ERROR: $pkg not found using
pkg-config$pkg_config_fail_message"
+if test $pkg_config != false; then
+use_pkg_config "$@" || die "ERROR: $pkg not found using
pkg-config$pkg_config_fail_message"
+else
+log require_pkg_config "No pkg-config, using require for $@"
+require "$@ -l$1"
+fi
This will fail in a thousand ways with packages that require other
packages, specific cflags, specific ldflags, or that state specific
versions.
As Hendrik said, pkg-config is not just a fancy way to add -I and -L
options to the compiler and linker.
I responded earlier today to Hendrik's response and indicated that I was
abandoning the patch. I just submitted a new patch that does something
more specific for libmfx.
Thanks,
Aaron Levinson
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/6] avcodec/h264: add avx 8-bit h264_idct_dc_add
Haswell:
- 1.02x faster (405±0.7 vs. 397±0.8 decicycles) compared with mmxext
Skylake-U:
- 1.06x faster (498±1.8 vs. 470±1.3 decicycles) compared with mmxext
---
libavcodec/x86/h264_idct.asm | 20
libavcodec/x86/h264dsp_init.c | 2 ++
2 files changed, 22 insertions(+)
diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm
index 24fb4d2..43f7791 100644
--- a/libavcodec/x86/h264_idct.asm
+++ b/libavcodec/x86/h264_idct.asm
@@ -1158,7 +1158,27 @@ INIT_XMM avx
movd [%7+%8], %4
%endmacro
+%macro DC_ADD_INIT 1
+add %1d, 32
+sar %1d, 6
+movd m0, %1d
+pshuflw m0, m0, 0
+lea %1, [3*stride_q]
+pxor m1, m1
+psubwm1, m0
+packuswb m0, m0
+packuswb m1, m1
+%endmacro
+
cglobal h264_idct_add_8, 3, 3, 8, dst_, block_, stride_
movsxdifnidn stride_q, stride_d
IDCT4_ADDdst_q, block_q, stride_q
RET
+
+cglobal h264_idct_dc_add_8, 3, 4, 6, dst_, block_, stride_
+movsxdifnidn stride_q, stride_d
+movsx r3d, word [block_q]
+mov dword [block_q], 0
+DC_ADD_INIT r3
+DC_ADD_MMXEXT_OP movd, dst_q, stride_q, r3
+RET
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index 8ba085f..bf74937 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -35,6 +35,7 @@ IDCT_ADD_FUNC(, 8, mmx)
IDCT_ADD_FUNC(, 8, avx)
IDCT_ADD_FUNC(, 10, sse2)
IDCT_ADD_FUNC(_dc, 8, mmxext)
+IDCT_ADD_FUNC(_dc, 8, avx)
IDCT_ADD_FUNC(_dc, 10, mmxext)
IDCT_ADD_FUNC(8_dc, 8, mmxext)
IDCT_ADD_FUNC(8_dc, 10, sse2)
@@ -340,6 +341,7 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const
int bit_depth,
}
c->h264_idct_add= ff_h264_idct_add_8_avx;
+c->h264_idct_dc_add = ff_h264_idct_dc_add_8_avx;
}
} else if (bit_depth == 10) {
if (EXTERNAL_MMXEXT(cpu_flags)) {
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Enhanced configure to improve compiler options associated with debugging with Visual C++ (MSVC)
On 4/13/2017 5:03 PM, Aaron Levinson wrote:
> From 558b957eb85a669899750b2e150eba7cdee8dcd9 Mon Sep 17 00:00:00 2001
> From: Aaron Levinson
> Date: Thu, 13 Apr 2017 16:46:59 -0700
> Subject: [PATCH] Enhanced configure to improve compiler options associated
> with debugging with Visual C++ (MSVC)
>
> Purpose: Enhanced configure to improve compiler options
> associated with debugging with Visual C++ (MSVC)
Please disregard the earlier version of the patch. I've included a new version
below that eliminates -MTd from the command-line options, based on a discussion
that I had on IRC with Hendrik Leppkes.
Thanks,
Aaron Levinson
---
From 4e78a20cf811d87f7a16715f3f9f3553a0d56ce3 Mon Sep 17 00:00:00 2001
From: Aaron Levinson
Date: Fri, 14 Apr 2017 18:59:46 -0700
Subject: [PATCH] Enhanced configure to improve compiler options associated
with debugging with Visual C++ (MSVC)
Purpose: Enhanced configure to improve compiler options associated
with debugging with Visual C++ (MSVC)
Comments:
-- configure:
a) In msvc_common_flags() function, replaced the use of -Z7 with -Zi.
Effectively, there was no point to using -Z7 anymore given than
-debug is passed to the linker already (per the line "enabled debug
&& add_ldflags -debug" elsewhere in the file), which causes a .pdb
to be generated anyway. -Z7 causes Codeview debug info to be
placed in .obj files, while -Zi causes debug info to be placed in
.pdb files. As a result of switching from -Z7 to -Zi, this may
result in slightly faster builds with MSVC, since it is apparently
slower to process Codeview debug info.
b) In probe_cc() function, added _cflags_noopt declaration for MSVC.
This is set to the following: "-Od -Og". See comments for more
details. This is exposed when --disable-optimizations is used with
configure. In addition, now adding -Zo (or -d2Zi+, depending on
the compiler version) to all the different _cflags_ variables to
make it easier to debug optimized builds. See changes and comments
for further details.
---
configure | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 1703111..c2d8b48 100755
--- a/configure
+++ b/configure
@@ -3844,7 +3844,7 @@ msvc_common_flags(){
-std=c99) ;;
# Common flags
-fomit-frame-pointer) ;;
--g) echo -Z7 ;;
+-g) echo -Zi ;;
-fno-math-errno) ;;
-fno-common) ;;
-fno-signed-zeros);;
@@ -4153,6 +4153,33 @@ probe_cc(){
_DEPFLAGS='$(CPPFLAGS) $(CFLAGS) -showIncludes -Zs'
_cflags_speed="-O2"
_cflags_size="-O1"
+# Need to use -Og with -Od because otherwise has link issues with
+# "if (ARCH_...)" code. Unfortunately, this isn't quite the same as
+# a fully debug build. If the Dead Code Elimination (DCE) compiler
+# optimization requirement is ever removed, this can be replaced
+# with just -Od. Note that the use of -Og results in a compiler
+# deprecation warning.
+_cflags_noopt="-Od -Og"
+cl_major_ver=$(cl 2>&1 | sed -n 's/.*Version
\([[:digit:]]\{1,\}\)\..*/\1/p')
+
+# Make it easier to debug release builds.
+# See https://msdn.microsoft.com/en-us/library/dn785163.aspx for more
+# details.
+# It may not be necessary to add -Zo to _cflags_noopt due to the use
+# of -Od, but because -Og is also added currently, it is best to
+# add -Zo for now to make sure the best debugging experience is
+# possible. If the DCE compiler optimization requirement is ever
+# removed, the _cflags_noopt lines can be removed.
+if [ -z "$cl_major_ver" ] || [ $cl_major_ver -ge 18 ]; then
+_cflags_speed="${_cflags_speed} -Zo"
+_cflags_size="${_cflags_size} -Zo"
+_cflags_noopt="${_cflags_noopt} -Zo"
+else
+_cflags_speed="${_cflags_speed} -d2Zi+"
+_cflags_size="${_cflags_size} -d2Zi+"
+_cflags_noopt="${_cflags_noopt} -d2Zi+"
+fi
+
if $_cc -nologo- 2>&1 | grep -q Linker; then
_ld_o='-out:$@'
else
--
2.10.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/opus_pvg: Add missing copyright notices
2017-04-15 2:52 GMT+02:00 Rostislav Pehlivanov : > On 14 April 2017 at 23:35, Carl Eugen Hoyos wrote: > >> Hi! >> >> As analyzed by Rostislav. >> >> Please comment, Carl Eugen > LGTM, apply and get this thread over with Done. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function
2017-04-15 2:35 GMT+02:00 wm4 : > Legally, all these copyright headers are meaningless, as long as the > license is correct. You are joking, right? > If they weren't, FFmpeg would be in trouble for changing the copyright > headers of all files added by Libav from "Libav" to "FFmpeg". Nobody is talking about the project name. > It's possible that Libav is not always careful with attribution, but > it's the same with FFmpeg. For example, af_pan.c is LGPL, even though > it was ported from MPlayer GPL code, and the author could not be > contacted. Recently, I contacted the same author about relicensing the > same MPlayer code (of which af_pan.c was a subset of) to LGPL, and he > explicitly denied relicensing. So if I had been cehoyos, I probably > wouldn't shut up about how FFmpeg violates copyrights (fortunately I'm > not cehoyos). I think nowadays af_pan.c certainly does not violate the > original author's copyright though, because absolutely all code was > removed/replaced. Do I understand correctly that you are neither defaming Clement nor doing something that is illegal? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
