Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Removed pthread dependency
On 4/15/2017 7:41 AM, Marton Balint wrote: > > On Thu, 13 Apr 2017, Aaron Levinson wrote: > >> On 4/13/2017 3:40 PM, Marton Balint wrote: >>> >>> On Thu, 13 Apr 2017, Aaron Levinson wrote: >>> On 4/13/2017 2:12 AM, Hendrik Leppkes wrote: > On Thu, Apr 13, 2017 at 10:36 AM, Aaron Levinson wrote: > Give it some time for the other changes to be reviewed by the people > that actually know decklink itself, you can include that in any new > versions of the patch then, no need to send one for that right now. > > - Hendrik Actually, the coding changes made to the decklink source files in this patch have pretty much nothing to do with decklink itself, and anyone with familiarity with semaphores and pthread could review those changes. In fact, all I really did was use already existing approaches for replacing a semaphore with the combination of a condition variable, mutex, and counter, and there are plenty of examples of how to do this on the Web. >>> >>> Yeah, the changes look fine, please send an updated patch, I will apply >>> it after some final testing. >>> >>> Thanks, >>> Marton >> >> Here's a new version of the patch with the pthreads dependency replaced with >> threads. >> > > Thanks, applied. Wouldn't it be simpler to add posix semaphore emulation to w32threads and os2threads? The former should be trivial, and probably even without the need to use mutexes or conditional variables given there's CreateSemaphore and ReleaseSemaphore for this purpose. Not sure about the latter. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] web/index: add news entry for release 3.3
On Sun, Apr 16, 2017 at 12:40:16AM +0100, Rostislav Pehlivanov wrote: > Signed-off-by: Rostislav Pehlivanov > --- > src/index | 43 +++ > 1 file changed, 43 insertions(+) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] web/index: add news entry for release 3.3
Signed-off-by: Rostislav Pehlivanov --- src/index | 43 +++ 1 file changed, 43 insertions(+) diff --git a/src/index b/src/index index c203676..79c6627 100644 --- a/src/index +++ b/src/index @@ -37,6 +37,49 @@ 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. + + October 30th, 2016, Results: Summer Of Code 2016. This has been a long time coming but we wanted to give a proper closure to our participation in this run of the program and it takes time. Sometimes it's just to get the final report for each project trimmed down, others, is finalizing whatever was still in progress when the program finished: final patches need to be merged, TODO lists stabilized, future plans agreed; you name it. -- 2.12.2.762.g0e3151a226 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/6] avformat/movenc: always check for new extradata on a packet
On Thu, Apr 13, 2017 at 04:54:12PM -0300, James Almer wrote: > Don't just look at zero sized packets, and also check for AAC extradata > updates, in preparation for the following patches. > > Signed-off-by: James Almer > --- > libavformat/movenc.c | 34 ++ > 1 file changed, 18 insertions(+), 16 deletions(-) should be ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- 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 1/2] opus_pvq: add resynth support and band encoding cost function
Hi, On Fri, Apr 14, 2017 at 8:14 PM, Ivan Kalvachev wrote: > I do remember that in 2014 Ronald was pressuring Libav (e.g. Vittorio) [..] Keep me out of this discussion, I want nothing to do with this. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg; check return code of avcodec_send_frame when flushing encoders
Fixes Coverity CID 1404841.
Signed-off-by: Marton Balint
---
ffmpeg.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index e4b94b2..dd179b0 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -1904,8 +1904,6 @@ static void flush_encoders(void)
if (enc->codec_type != AVMEDIA_TYPE_VIDEO && enc->codec_type !=
AVMEDIA_TYPE_AUDIO)
continue;
-avcodec_send_frame(enc, NULL);
-
for (;;) {
const char *desc = NULL;
AVPacket pkt;
@@ -1927,7 +1925,17 @@ static void flush_encoders(void)
pkt.size = 0;
update_benchmark(NULL);
-ret = avcodec_receive_packet(enc, &pkt);
+
+while ((ret = avcodec_receive_packet(enc, &pkt)) ==
AVERROR(EAGAIN)) {
+ret = avcodec_send_frame(enc, NULL);
+if (ret < 0) {
+av_log(NULL, AV_LOG_FATAL, "%s encoding failed: %s\n",
+ desc,
+ av_err2str(ret));
+exit_program(1);
+}
+}
+
update_benchmark("flush_%s %d.%d", desc, ost->file_index,
ost->index);
if (ret < 0 && ret != AVERROR_EOF) {
av_log(NULL, AV_LOG_FATAL, "%s encoding failed: %s\n",
--
2.10.2
___
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 15:53:36 +0200 "Jean-Baptiste Kempf" wrote: > > 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. > > Rewriting based on the same ideas also does not change the copyright. > It is a derivative work under the Berne convention. > I know it's not cool, but that's the international IP laws. Well, that's not good. I bet this happened a lot when libswscale was relicensed from GPL to LGPL. (But I don't have specific cases at hand.) I'm fairly sure that ideas themselves are not copyrightable, though. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add Falcom Xanadu demuxer
On 2017-04-15 17:56, James Almer wrote:
> On 4/15/2017 10:36 AM, James Darnley wrote:
>> ---
>> libavformat/Makefile | 1 +
>> libavformat/allformats.c | 1 +
>> libavformat/falcom_xa.c | 98
>>
>> 3 files changed, 100 insertions(+)
>> create mode 100644 libavformat/falcom_xa.c
>
> Changelog/version.h/etc before you push.
Sure.
>>
>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>> index 6bdfbe6789..06b6b5da57 100644
>> --- a/libavformat/Makefile
>> +++ b/libavformat/Makefile
>> @@ -158,6 +158,7 @@ OBJS-$(CONFIG_EA_DEMUXER)+=
>> electronicarts.o
>> OBJS-$(CONFIG_EAC3_DEMUXER) += ac3dec.o rawdec.o
>> OBJS-$(CONFIG_EAC3_MUXER)+= rawenc.o
>> OBJS-$(CONFIG_EPAF_DEMUXER) += epafdec.o pcm.o
>> +OBJS-$(CONFIG_FALCOM_XA_DEMUXER) += falcom_xa.o
>> OBJS-$(CONFIG_FFM_DEMUXER) += ffmdec.o
>> OBJS-$(CONFIG_FFM_MUXER) += ffmenc.o
>> OBJS-$(CONFIG_FFMETADATA_DEMUXER)+= ffmetadec.o
>> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
>> index 09e62c3cfc..0c23ea9df0 100644
>> --- a/libavformat/allformats.c
>> +++ b/libavformat/allformats.c
>> @@ -117,6 +117,7 @@ static void register_all(void)
>> REGISTER_MUXDEMUX(EAC3, eac3);
>> REGISTER_DEMUXER (EPAF, epaf);
>> REGISTER_MUXER (F4V, f4v);
>> +REGISTER_DEMUXER (FALCOM_XA,falcom_xa);
>
> Maybe just Xanadu?
>
>> REGISTER_MUXDEMUX(FFM, ffm);
>> REGISTER_MUXDEMUX(FFMETADATA, ffmetadata);
>> REGISTER_MUXER (FIFO, fifo);
>> diff --git a/libavformat/falcom_xa.c b/libavformat/falcom_xa.c
>> new file mode 100644
>> index 00..4c5f32a1b6
>> --- /dev/null
>> +++ b/libavformat/falcom_xa.c
>> @@ -0,0 +1,98 @@
>> +/*
>> + * Falcom Xanadu demuxer
>> + * Copyright (c) 2016 James Darnley
>
> 2017?
I wrote it in November 2016 and have only just remembered about it.
>> + *
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
>> USA
>> + */
>> +
>> +#include "avformat.h"
>> +
>> +typedef struct FalcomXADemuxContext {
>> +const AVClass *class;
>> +unsigned frame_size;
>> +} FalcomXADemuxContext;
>> +
>> +static av_cold
>> +int falcom_xa_read_header(AVFormatContext *s)
>
> A probe function should be added if possible.
>
>> +{
>> +int sample_rate, bit_depth, channels;
>> +AVStream *st;
>> +AVIOContext *pb = s->pb;
>> +
>> +avio_seek(pb, 22, SEEK_SET);
>
> avio_skip() is more in line with most demuxers.
>
> What are those first 22 bytes? I assume header magic (which you should
> check in a probe function) and maybe some version byte?
> If the latter, better check it here.
It is a riff or wave header with incorrect data. I can probe for the
commonalities for all the files but I couldn't be bothered at the time.
>> +channels = avio_rl16(pb);
>> +if (channels != 2)
>> +return AVERROR_INVALIDDATA;
>
> If there are real world files with more than two channels, you could
> instead return PATCHWELCOME and even ask for a sample.
I wonder. I only wanted it to decode the 24 files from the game.
>> +
>> +sample_rate = avio_rl32(pb);
>> +if (sample_rate != 44100)
>> +return AVERROR_INVALIDDATA;
>
> Same.
>
>> +
>> +avio_seek(pb, 34, SEEK_SET);
>
> avio_skip().
>
>> +bit_depth = avio_rl16(pb);
>> +if (bit_depth != 16)
>> +return AVERROR_INVALIDDATA;
>> +
>> +avio_seek(pb, 44, SEEK_SET);
>
> Same.
All noted.
>> +
>> +st = avformat_new_stream(s, NULL);
>> +if (!st)
>> +return AVERROR(ENOMEM);
>> +
>> +st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
>> +st->codecpar->codec_id = AV_CODEC_ID_ADPCM_MS;
>> +st->codecpar->sample_rate = sample_rate;
>> +st->codecpar->channels = channels;
>> +st->codecpar->block_align = 2048;
>> +
>> +return 0;
>> +}
>> +
>> +static
>> +int falcom_xa_read_packet(AVFormatContext *s, AVPacket *pkt)
>> +{
>> +FalcomXADemuxContext *ctx = s->priv_data;
>> +
>> +if (ctx->frame_size == 0) {
>> +unsigned tell = avio_tell(s->pb);
>
> avio_tell() returns int64_t.
I know but none o
Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function
On Sat, 15 Apr 2017 16:33:41 +0200 Carl Eugen Hoyos wrote: > 2017-04-15 15:06 GMT+02:00 wm4 : > > On Sat, 15 Apr 2017 07:55:50 +0200 > > Carl Eugen Hoyos wrote: > > > >> 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? > > > > Well, are you joking? While it may seem so, you apparently aren't. > > I am not joking: Oh that's unfortunate. > The first paragraph of all open source licenses I know of say something > similar to "you may distribute this source code as long as you > don't change above copyright notice". If you say now that this > copyright notice is meaningless, you are either joking or - well, > you can imagine. So changing the project name (like FFmpeg does it all the time) does not constitute changing the copyright notice? Or does FFmpeg violate the law? Or are you joking? Some files don't even have a name in the copyright notice. And I bet no file lists all copyright headers in the notice. Thus it's meaningless. What really counts is who actually has the copyright on a piece of code. > >> > 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? > > > > Is that some sort of trick question? I'm doing neither. > > Clement says that he wrote the code he committed by himself and > that it is not based on MPlayer code. You say he violated somebody's > copyright: Who is defaming anybody here? http://ffmpeg.org/pipermail/ffmpeg-devel/2011-November/116431.html Panning was later reimplemented in libswresample (independently? unknown), and some time after that, this code was removed and replaced by using libswresample API. > > But what _you_ do is defaming the entire Libav project > > No. > I am (to quote you) stating "facts" namely that 1) FFmpeg's > gitlog contains many commits that indicate avconv developers > have not correctly given attribution to FFmpeg developers > when moving or copying code and 2) that other commits in > addition to those linked by Ivan (probably myself in the past, > I didn't remember) exist. > > > (and possibly me), > > I don't remember doing this. There are a lot of good doctors who specialize in memory problems. > > which is illegal > > Please stop calling my actions illegal Can you tell me why I should do this? Or are you joking? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add Mandsoft Screen Capture Codec decoder
On 4/15/17, Carl Eugen Hoyos wrote: > 2017-04-15 13:49 GMT+02:00 Paul B Mahol : > >> +case 32: avctx->pix_fmt = AV_PIX_FMT_BGRA; break; > > (I am thankful for this patch and, yes, I believe we had this > discussion before.) > If this is a screen capture codec, I believe BGR0 is the correct > colorspace. I understand that you tested that the encoder can > really encode transparency but the issue - imo - is, that if the > codec is (or actually was) used to record 32bit Windows screens > then some parts of the screen will contain "0xff" as alpha value > and others (sprites?) will contain "0x00" producing funny output > if you just transcode to png. > > In the past, I also put BGRA there (for some other codec) and > it was fixed after another developer tested the same sample I > had tested but (correctly!) explained that the output (that I > considered useful originally) makes no sense and the > colorspace (or actually the transparency in the output file) is > wrong. > > (If this is not a screen capture codec, BGRA is of course > most likely correct.) > > Please don't let this stop you! Using bgr0 when there is already valid transparency is bad as that will kill it, on other side if its bgra like it is now one can just ignore alpha component if its not interesting. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add Falcom Xanadu demuxer
On 4/15/2017 10:36 AM, James Darnley wrote:
> ---
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/falcom_xa.c | 98
>
> 3 files changed, 100 insertions(+)
> create mode 100644 libavformat/falcom_xa.c
Changelog/version.h/etc before you push.
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 6bdfbe6789..06b6b5da57 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -158,6 +158,7 @@ OBJS-$(CONFIG_EA_DEMUXER)+=
> electronicarts.o
> OBJS-$(CONFIG_EAC3_DEMUXER) += ac3dec.o rawdec.o
> OBJS-$(CONFIG_EAC3_MUXER)+= rawenc.o
> OBJS-$(CONFIG_EPAF_DEMUXER) += epafdec.o pcm.o
> +OBJS-$(CONFIG_FALCOM_XA_DEMUXER) += falcom_xa.o
> OBJS-$(CONFIG_FFM_DEMUXER) += ffmdec.o
> OBJS-$(CONFIG_FFM_MUXER) += ffmenc.o
> OBJS-$(CONFIG_FFMETADATA_DEMUXER)+= ffmetadec.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 09e62c3cfc..0c23ea9df0 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -117,6 +117,7 @@ static void register_all(void)
> REGISTER_MUXDEMUX(EAC3, eac3);
> REGISTER_DEMUXER (EPAF, epaf);
> REGISTER_MUXER (F4V, f4v);
> +REGISTER_DEMUXER (FALCOM_XA,falcom_xa);
Maybe just Xanadu?
> REGISTER_MUXDEMUX(FFM, ffm);
> REGISTER_MUXDEMUX(FFMETADATA, ffmetadata);
> REGISTER_MUXER (FIFO, fifo);
> diff --git a/libavformat/falcom_xa.c b/libavformat/falcom_xa.c
> new file mode 100644
> index 00..4c5f32a1b6
> --- /dev/null
> +++ b/libavformat/falcom_xa.c
> @@ -0,0 +1,98 @@
> +/*
> + * Falcom Xanadu demuxer
> + * Copyright (c) 2016 James Darnley
2017?
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include "avformat.h"
> +
> +typedef struct FalcomXADemuxContext {
> +const AVClass *class;
> +unsigned frame_size;
> +} FalcomXADemuxContext;
> +
> +static av_cold
> +int falcom_xa_read_header(AVFormatContext *s)
A probe function should be added if possible.
> +{
> +int sample_rate, bit_depth, channels;
> +AVStream *st;
> +AVIOContext *pb = s->pb;
> +
> +avio_seek(pb, 22, SEEK_SET);
avio_skip() is more in line with most demuxers.
What are those first 22 bytes? I assume header magic (which you should
check in a probe function) and maybe some version byte?
If the latter, better check it here.
> +channels = avio_rl16(pb);
> +if (channels != 2)
> +return AVERROR_INVALIDDATA;
If there are real world files with more than two channels, you could
instead return PATCHWELCOME and even ask for a sample.
> +
> +sample_rate = avio_rl32(pb);
> +if (sample_rate != 44100)
> +return AVERROR_INVALIDDATA;
Same.
> +
> +avio_seek(pb, 34, SEEK_SET);
avio_skip().
> +bit_depth = avio_rl16(pb);
> +if (bit_depth != 16)
> +return AVERROR_INVALIDDATA;
> +
> +avio_seek(pb, 44, SEEK_SET);
Same.
> +
> +st = avformat_new_stream(s, NULL);
> +if (!st)
> +return AVERROR(ENOMEM);
> +
> +st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
> +st->codecpar->codec_id = AV_CODEC_ID_ADPCM_MS;
> +st->codecpar->sample_rate = sample_rate;
> +st->codecpar->channels = channels;
> +st->codecpar->block_align = 2048;
> +
> +return 0;
> +}
> +
> +static
> +int falcom_xa_read_packet(AVFormatContext *s, AVPacket *pkt)
> +{
> +FalcomXADemuxContext *ctx = s->priv_data;
> +
> +if (ctx->frame_size == 0) {
> +unsigned tell = avio_tell(s->pb);
avio_tell() returns int64_t.
> +unsigned size = avio_rl32(s->pb);
> +av_log(ctx, AV_LOG_DEBUG, "read size %u (0x%x) at offset %u
> (0x%x)\n",
> +size, size, tell, tell);
> +if (size % 2048)
Nit: size & 2047.
> +return AVERROR_INVALIDDATA;
> +ctx->frame_size = size;
> +avio_skip(s->pb, 4); // unknown bytes
> +}
> +
> +ctx->frame_size -= 2048;
> +return av_get_packet(s->pb, pkt, 2048);
> +}
> +
> +static const AVClass falcom_xa_demux_class = {
> +.class_name = "Fal
Re: [FFmpeg-devel] [PATCH 2/6] avcodec/h264: change some labels to be macro-local
What about just using strip -x on the assembly files to discard the local symbols? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add Falcom Xanadu demuxer
On 2017-04-15 15:36, James Darnley wrote: > add Falcom Xanadu demuxer I mean Xanadu Next, not the original one. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add Mandsoft Screen Capture Codec decoder
2017-04-15 13:49 GMT+02:00 Paul B Mahol : > +case 32: avctx->pix_fmt = AV_PIX_FMT_BGRA; break; (I am thankful for this patch and, yes, I believe we had this discussion before.) If this is a screen capture codec, I believe BGR0 is the correct colorspace. I understand that you tested that the encoder can really encode transparency but the issue - imo - is, that if the codec is (or actually was) used to record 32bit Windows screens then some parts of the screen will contain "0xff" as alpha value and others (sprites?) will contain "0x00" producing funny output if you just transcode to png. In the past, I also put BGRA there (for some other codec) and it was fixed after another developer tested the same sample I had tested but (correctly!) explained that the output (that I considered useful originally) makes no sense and the colorspace (or actually the transparency in the output file) is wrong. (If this is not a screen capture codec, BGRA is of course most likely correct.) Please don't let this stop you! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/6] avcodec/h264: change some labels to be macro-local
On 2017-04-15 14:29, Ronald S. Bultje wrote: > Hi, > > On Fri, Apr 14, 2017 at 9:46 PM, James Darnley wrote: > >> 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 > > > So I've thought about it some more. I think I'd first need to understand > what you're doing here and why. > > It seems to me that the issue you're trying to address is that when you > look at disassembly (in e.g. a debugger or objdump), it goes from label to > label (where function entry is also a label), and so every function-local > label means disassembly is cut off as a block, right? (Each block then > represents a jump target or loop or something like that.) > > And you don't like that, so you're getting rid of the labels, right? Yes. I didn't like that because the function I was looking at had (I think) 16 labels showing in objdump output. Strictly speaking, I'm not getting rid of the labels but just changing them into a format that lets STRIP strip them. Make will run STRIP to strip labels that begin ..@ (if configure has determined that your STRIP supports it). Usually I don't have a problem with labels representing a loop (or 2 nested ones) because it makes it easy to see where the code jumps back to. > So, if all of this is correct, then I agree that the output of tools like > debugger/objdump is irritating. In fact, it has irritated me forever in any > codec's DSP functions. But it also seems like we're moving away from a de > facto convention if we don't use dot-labels anymore. If we do it for > h264_idct, we should do it everywhere (for consistency). Is that what > people want? Maybe we should follow convention and fix objdump to include > all dot labels in a block if a CLI option is provided? ... I don't know what to say. ___ 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 15:53 GMT+02:00 Jean-Baptiste Kempf : > Hi, > > On Sat, 15 Apr 2017, at 02:35, wm4 wrote: >> > 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. > > +1 > Especially in countries with civil laws that have inalienable moral > author rights (where FFmpeg and its forks were always developed) I believe you are mixing up things here: We had a discussion in the past where you (most likely correctly) argued that no copyright notice is necessary to "get" (I don't know a better word) copyright, and I said it is still nice(r) to have copyright notices on new files written by a developer. This is not what this discussion is about. I sincerely hope you are not implying that it is ok to remove "(c) Jean-Baptiste Kempf" from the top of GPL (or LGPL) files you wrote when copying them into another open-source project. 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 15:06 GMT+02:00 wm4 : > On Sat, 15 Apr 2017 07:55:50 +0200 > Carl Eugen Hoyos wrote: > >> 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? > > Well, are you joking? While it may seem so, you apparently aren't. I am not joking: The first paragraph of all open source licenses I know of say something similar to "you may distribute this source code as long as you don't change above copyright notice". If you say now that this copyright notice is meaningless, you are either joking or - well, you can imagine. >> > 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. > > OK? We are not talking about the project name in the license text (it of course has to be adjusted), I am talking about the copyright notice above. >> > 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? > > Is that some sort of trick question? I'm doing neither. Clement says that he wrote the code he committed by himself and that it is not based on MPlayer code. You say he violated somebody's copyright: Who is defaming anybody here? > But what _you_ do is defaming the entire Libav project No. I am (to quote you) stating "facts" namely that 1) FFmpeg's gitlog contains many commits that indicate avconv developers have not correctly given attribution to FFmpeg developers when moving or copying code and 2) that other commits in addition to those linked by Ivan (probably myself in the past, I didn't remember) exist. > (and possibly me), I don't remember doing this. > which is illegal Please stop calling my actions illegal Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Added require fallback for libmfx in the case that pkg-config cannot find libmfx
On 15 April 2017 at 13:41, Aaron Levinson wrote:
> Doesn't require() already do that? Here is the contents of require():
>
> require(){
> log require "$@"
> name_version="$1"
> headers="$2"
> func="$3"
> shift 3
> check_lib "$headers" $func "$@" || die "ERROR: $name_version not found"
> }
Right. Desregard my comment.
___
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
Hi, On Sat, 15 Apr 2017, at 02:35, wm4 wrote: > > 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. +1 Especially in countries with civil laws that have inalienable moral author rights (where FFmpeg and its forks were always developed) > If they weren't, FFmpeg would be in trouble for changing the copyright > headers of all files added by Libav from "Libav" to "FFmpeg". +1 See the copyright on collaborative projects. > 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. Refusal to answer does not allow in any way relicensing. > 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. Rewriting based on the same ideas also does not change the copyright. It is a derivative work under the Berne convention. I know it's not cool, but that's the international IP laws. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] add Falcom Xanadu demuxer
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/falcom_xa.c | 98
3 files changed, 100 insertions(+)
create mode 100644 libavformat/falcom_xa.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 6bdfbe6789..06b6b5da57 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -158,6 +158,7 @@ OBJS-$(CONFIG_EA_DEMUXER)+= electronicarts.o
OBJS-$(CONFIG_EAC3_DEMUXER) += ac3dec.o rawdec.o
OBJS-$(CONFIG_EAC3_MUXER)+= rawenc.o
OBJS-$(CONFIG_EPAF_DEMUXER) += epafdec.o pcm.o
+OBJS-$(CONFIG_FALCOM_XA_DEMUXER) += falcom_xa.o
OBJS-$(CONFIG_FFM_DEMUXER) += ffmdec.o
OBJS-$(CONFIG_FFM_MUXER) += ffmenc.o
OBJS-$(CONFIG_FFMETADATA_DEMUXER)+= ffmetadec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 09e62c3cfc..0c23ea9df0 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -117,6 +117,7 @@ static void register_all(void)
REGISTER_MUXDEMUX(EAC3, eac3);
REGISTER_DEMUXER (EPAF, epaf);
REGISTER_MUXER (F4V, f4v);
+REGISTER_DEMUXER (FALCOM_XA,falcom_xa);
REGISTER_MUXDEMUX(FFM, ffm);
REGISTER_MUXDEMUX(FFMETADATA, ffmetadata);
REGISTER_MUXER (FIFO, fifo);
diff --git a/libavformat/falcom_xa.c b/libavformat/falcom_xa.c
new file mode 100644
index 00..4c5f32a1b6
--- /dev/null
+++ b/libavformat/falcom_xa.c
@@ -0,0 +1,98 @@
+/*
+ * Falcom Xanadu demuxer
+ * Copyright (c) 2016 James Darnley
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "avformat.h"
+
+typedef struct FalcomXADemuxContext {
+const AVClass *class;
+unsigned frame_size;
+} FalcomXADemuxContext;
+
+static av_cold
+int falcom_xa_read_header(AVFormatContext *s)
+{
+int sample_rate, bit_depth, channels;
+AVStream *st;
+AVIOContext *pb = s->pb;
+
+avio_seek(pb, 22, SEEK_SET);
+channels = avio_rl16(pb);
+if (channels != 2)
+return AVERROR_INVALIDDATA;
+
+sample_rate = avio_rl32(pb);
+if (sample_rate != 44100)
+return AVERROR_INVALIDDATA;
+
+avio_seek(pb, 34, SEEK_SET);
+bit_depth = avio_rl16(pb);
+if (bit_depth != 16)
+return AVERROR_INVALIDDATA;
+
+avio_seek(pb, 44, SEEK_SET);
+
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+
+st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
+st->codecpar->codec_id = AV_CODEC_ID_ADPCM_MS;
+st->codecpar->sample_rate = sample_rate;
+st->codecpar->channels = channels;
+st->codecpar->block_align = 2048;
+
+return 0;
+}
+
+static
+int falcom_xa_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+FalcomXADemuxContext *ctx = s->priv_data;
+
+if (ctx->frame_size == 0) {
+unsigned tell = avio_tell(s->pb);
+unsigned size = avio_rl32(s->pb);
+av_log(ctx, AV_LOG_DEBUG, "read size %u (0x%x) at offset %u (0x%x)\n",
+size, size, tell, tell);
+if (size % 2048)
+return AVERROR_INVALIDDATA;
+ctx->frame_size = size;
+avio_skip(s->pb, 4); // unknown bytes
+}
+
+ctx->frame_size -= 2048;
+return av_get_packet(s->pb, pkt, 2048);
+}
+
+static const AVClass falcom_xa_demux_class = {
+.class_name = "Falcom Xanadu demuxer",
+.item_name = av_default_item_name,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+AVInputFormat ff_falcom_xa_demuxer = {
+.name = "falcom_xa",
+.long_name = NULL_IF_CONFIG_SMALL("Falcom Xanadu demuxer"),
+.priv_data_size = sizeof(FalcomXADemuxContext),
+.read_header= falcom_xa_read_header,
+.read_packet= falcom_xa_read_packet,
+.priv_class = &falcom_xa_demux_class,
+};
--
2.12.2
___
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 Sat, 15 Apr 2017 09:47:58 +0200 Zalewa PL wrote: > Hello, > > > The plan is that if ffserver is not fixed before the next bump, it will > > be removed. > > ffserver has been serving our purpose in a 24/7 fashion for about 7 > years now. It will probably be serving us for the foreseeable future, > whatever the community decides. I prefer to share any fix I make back > with the community because allowing everyone to build on top of better > software pays off. If the community drops the program, we most likely > won't, even if it means being stuck with a single version for years to > come. However, we still need to get it as stable as possible. If your company thinks ffserver is so important, you should probably invest work into it to fix it. > I also admit that I'm not versed in the codebase and whatever change I > made was based purely on valgrind's output. I understand that my patch > in its current state is not ideal and I probably should have attempted a > cleaner fix before submitting. I'll try to do that. > > Having stated this, let's get back to the technical topic: > > > This accesses plenty of internal fields. (Maybe did so before, but no > > matter.) > > > > So doing the freeing correctly (if even possible) would be better for > > the survival of ffserver. > > At first I was hoping that avformat_free_context() will do the job > nicely for me, but unfortunately there are some shared objects that get > destroyed in this call and ffserver eventually crashes. If you run such > ffserver build in valgrind, it will warn about "free'd memory" accesses. Which shared objects? > The problem seems to stem from the "COPY" done in unlayer_stream(). I > will try to reverse this "COPY" before avformat_free_context() and see > if it helps. > > Best regards, > Z. > ___ > 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] opus_pvq: add resynth support and band encoding cost function
On Sat, 15 Apr 2017 07:55:50 +0200 Carl Eugen Hoyos wrote: > 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? Well, are you joking? While it may seem so, you apparently aren't. > > 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. OK? > > 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? Is that some sort of trick question? I'm doing neither. But what _you_ do is defaming the entire Libav project (and possibly me), which is illegal and against the FFmpeg CoC. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Made minor changes to get the decklink avdevice code to build using Visual C++
On 4/15/2017 4:19 AM, Marton Balint wrote:
On Thu, 13 Apr 2017, Aaron Levinson wrote:
On 4/13/2017 1:23 PM, Hendrik Leppkes wrote:
[...]
From 00fdc9d15414a92a155eb7d1394bac3736dc9405 Mon Sep 17 00:00:00 2001
From: Aaron Levinson
Date: Thu, 13 Apr 2017 14:22:19 -0700
Subject: [PATCH] Made minor changes to get the decklink avdevice code
to build using Visual C++.
Maybe it just me, but as I mentioned earlier, I don't like too verbose
comments in the code, see below:
diff --git a/libavdevice/decklink_common.cpp
b/libavdevice/decklink_common.cpp
index f01fba9..523217c 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -19,6 +19,15 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA
*/
+// Moved inclusion of internal.h here in order to get it to build
successfully
+// when using Visual C++ to build--otherwise, compilation errors result
+// due to winsock.h (which is included indirectly by DeckLinkAPI.h and
+// DeckLinkAPI_i.c) conflicting with winsock2.h, which is included by
+// internal.h. If winsock2.h is included first, then the conflict is
resolved.
This can be as short as this:
/* Include internal.h first to avoid conflict of winsock.h (used by
* DeckLink) and winsock2.h (used by libavformat) in MSVC++ builds */
(for multiline comments I think /* */ is preferred)
Although since you do this in multiple headers, maybe it is enough if
you specify the reason in the commit message, and delete the comment
from here entirely.
I think it is a good idea to have a comment in the code, as then it is
front in center if someone in the future wonders why internal.h precedes
the other includes and decides to move it because it will look cleaner,
thereby breaking the MSVC build. Although, in that case, maybe it would
be preferable to have the same comment in each of the three places, as
opposed to just one.
A shorter comment is fine, and your example comment explains things well
enough, although I tend to think that more information is better than
less for comments in code. From my perspective, "used by DeckLink" is a
bit vague, since technically, DeckLinkAPI.h and DeckLinkAPI_i.c would be
generated by the user if the actual Blackmagic DeckLink SDK were used
(these files are not actually supplied with the Blackmagic DeckLink
SDK), which is how I got DeckLinkAPI.h and DeckLinkAPI_c.h when I built
ffmpeg. Well, DeckLinkAPI.h is included in the Linux header files in
the Blackmagic DeckLink SDK, but the _i.c file is not, and on Windows,
neither file is provided.
Regarding multi-line comments being wrapped in /* */ vs using // on each
line, it doesn't so much matter in this case, but I personally find //
more versatile because then it makes it easier to comment out blocks of
code. But, if that's the standard for the ffmpeg code base, then I'll
make that change.
@@ -262,8 +265,18 @@ static int64_t
get_pkt_pts(IDeckLinkVideoInputFrame *videoFrame,
res =
videoFrame->GetHardwareReferenceTimestamp(time_base.den, &bmd_pts,
&bmd_duration);
break;
case PTS_SRC_WALLCLOCK:
-pts = av_rescale_q(wallclock, AV_TIME_BASE_Q, time_base);
+{
+// doing the following rather than using AV_TIME_BASE_Q
because
+// AV_TIME_BASE_Q doesn't work when building with Visual C++
+// for C++ files (works for C files). When building C++
files,
+// it results in compiler error C4576. At least, this is
the case
+// with Visual C++ 2015.
And this is:
// MSVC does not support compound literals like AV_TIME_BASE_Q in C++ code
+AVRational timebase;
+timebase.num = 1;
+timebase.den = AV_TIME_BASE;
+pts = av_rescale_q(wallclock, timebase, time_base);
break;
+}
This whole block needs to be indented 1 column more I think.
I'll double-check later today to make sure that it is indented properly,
adjust the comment, and submit a new patch then.
Regards,
Marton
Thanks,
Aaron
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Added require fallback for libmfx in the case that pkg-config cannot find libmfx
On 4/15/2017 4:25 AM, Ricardo Constantino wrote:
> On 15 April 2017 at 02:51, Aaron Levinson wrote:
>
>> 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"; } }
>>
> Needs a '|| die "ERROR: libmfx not found";' before the last curly bracket
> or it won't complain about not finding libmfx if enabled.
Doesn't require() already do that? Here is the contents of require():
require(){
log require "$@"
name_version="$1"
headers="$2"
func="$3"
shift 3
check_lib "$headers" $func "$@" || die "ERROR: $name_version not found"
}
Aaron
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/6] avcodec/h264: change some labels to be macro-local
Hi, On Fri, Apr 14, 2017 at 9:46 PM, James Darnley wrote: > 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 So I've thought about it some more. I think I'd first need to understand what you're doing here and why. It seems to me that the issue you're trying to address is that when you look at disassembly (in e.g. a debugger or objdump), it goes from label to label (where function entry is also a label), and so every function-local label means disassembly is cut off as a block, right? (Each block then represents a jump target or loop or something like that.) And you don't like that, so you're getting rid of the labels, right? So, if all of this is correct, then I agree that the output of tools like debugger/objdump is irritating. In fact, it has irritated me forever in any codec's DSP functions. But it also seems like we're moving away from a de facto convention if we don't use dot-labels anymore. If we do it for h264_idct, we should do it everywhere (for consistency). Is that what people want? Maybe we should follow convention and fix objdump to include all dot labels in a block if a CLI option is provided? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] avfilter/vf_framerate: always request input if no output is provided in request_frame
On Wed, 12 Apr 2017, Nicolas George wrote:
Le tridi 23 germinal, an CCXXV, Marton Balint a écrit :
Note that the above code which I moved returns 0 if ff_request_frame returns
AVERROR_EOF. As far as I see, this can only happen a few times, not
infinitely, so I am not sure if this is an error or not, so I kept is as it
was before.
There are exactly three acceptable behaviours for request_frame() and
all the functions it calls:
* it pushes a frame and returns 0;
* it issues a ff_request_frame() on the input and returns 0;
* it returns EOF or an error.
If the "few times" correspond to frames pushed, then it is ok.
Otherwise, it is not. lavfi will not activate filters saying "hey, you
told me last time you had nothing to do, but just in case I am taking
news". A filter should never do nothing.
Well, then I guess the doc/filtering_design.txt is outdated, because
it uses term "making progress towards producing a frame" when returning 0
There is also an example code snippet there:
if (frames_queued) {
push_one_frame();
return 0;
}
input = input_where_a_frame_is_most_needed();
ret = ff_request_frame(input);
if (ret == AVERROR_EOF) {
process_eof_on_input();
} else if (ret < 0) {
return ret;
}
return 0;
Am I getting this right, process_eof_on_input() should be extended to
process_eof_on_input();
if (!frames_queued)
return AVERROR_EOF;
push_one_frame();
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec: add Mandsoft Screen Capture Codec decoder
Signed-off-by: Paul B Mahol
---
configure | 1 +
doc/general.texi| 1 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 ++
libavcodec/mscc.c | 220
libavformat/riff.c | 1 +
8 files changed, 233 insertions(+)
create mode 100644 libavcodec/mscc.c
diff --git a/configure b/configure
index 98f7828..1436acb 100755
--- a/configure
+++ b/configure
@@ -2488,6 +2488,7 @@ mpeg2video_encoder_select="aandcttables mpegvideoenc
h263dsp"
mpeg4_decoder_select="h263_decoder mpeg4video_parser"
mpeg4_encoder_select="h263_encoder"
msa1_decoder_select="mss34dsp"
+mscc_decoder_select="zlib"
msmpeg4v1_decoder_select="h263_decoder"
msmpeg4v2_decoder_select="h263_decoder"
msmpeg4v2_encoder_select="h263_encoder"
diff --git a/doc/general.texi b/doc/general.texi
index a02437b..72f02b1 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -789,6 +789,7 @@ following image formats are supported:
@tab Used in LucasArts games / SMUSH animations.
@item lossless MJPEG @tab X @tab X
@item MagicYUV Video @tab @tab X
+@item Mandsoft Screen Capture Codec @tab @tab X
@item Microsoft ATC Screen @tab @tab X
@tab Also known as Microsoft Screen 3.
@item Microsoft Expression Encoder Screen @tab @tab X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index c745454..cf5317d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -429,6 +429,7 @@ OBJS-$(CONFIG_MPEG4_MEDIACODEC_DECODER) += mediacodecdec.o
OBJS-$(CONFIG_MPEG4_OMX_ENCODER) += omx.o
OBJS-$(CONFIG_MPL2_DECODER)+= mpl2dec.o ass.o
OBJS-$(CONFIG_MSA1_DECODER)+= mss3.o
+OBJS-$(CONFIG_MSCC_DECODER)+= mscc.o
OBJS-$(CONFIG_MSMPEG4V1_DECODER) += msmpeg4dec.o msmpeg4.o msmpeg4data.o
OBJS-$(CONFIG_MSMPEG4V2_DECODER) += msmpeg4dec.o msmpeg4.o msmpeg4data.o
OBJS-$(CONFIG_MSMPEG4V2_ENCODER) += msmpeg4enc.o msmpeg4.o msmpeg4data.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 379bd6e..5a708b3 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -258,6 +258,7 @@ static void register_all(void)
REGISTER_DECODER(MPEG2_CRYSTALHD, mpeg2_crystalhd);
REGISTER_DECODER(MPEG2_QSV, mpeg2_qsv);
REGISTER_DECODER(MSA1, msa1);
+REGISTER_DECODER(MSCC, mscc);
REGISTER_DECODER(MSMPEG4V1, msmpeg4v1);
REGISTER_ENCDEC (MSMPEG4V2, msmpeg4v2);
REGISTER_ENCDEC (MSMPEG4V3, msmpeg4v3);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index ee13371..da9d9dc 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -443,6 +443,7 @@ enum AVCodecID {
AV_CODEC_ID_XPM,
AV_CODEC_ID_AV1,
AV_CODEC_ID_BITPACKED,
+AV_CODEC_ID_MSCC,
/* various PCM "codecs" */
AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the
start of audio codecs
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 7b2a1b9..e342db7 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1388,6 +1388,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("Bitpacked"),
.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
},
+{
+.id= AV_CODEC_ID_MSCC,
+.type = AVMEDIA_TYPE_VIDEO,
+.name = "mscc",
+.long_name = NULL_IF_CONFIG_SMALL("Mandsoft Screen Capture Codec"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+},
/* image codecs */
{
diff --git a/libavcodec/mscc.c b/libavcodec/mscc.c
new file mode 100644
index 000..6050056
--- /dev/null
+++ b/libavcodec/mscc.c
@@ -0,0 +1,220 @@
+/*
+ * Mandsoft Screen Capture Codec decoder
+ *
+ * Copyright (c) 2017 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+#include
+
+#include "avcodec.h"
+#include "bytestream.h"
+#include "internal.h"
+
+#include
+
+typedef struct MSCCContext {
+unsigned bpp;
+unsigned int decomp_size;
+uint8_t *decomp_buf;
Re: [FFmpeg-devel] Added require fallback for libmfx in the case that pkg-config cannot find libmfx
On 15 April 2017 at 02:51, Aaron Levinson wrote:
> 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"; } }
>
Needs a '|| die "ERROR: libmfx not found";' before the last curly bracket
or it won't complain about not finding libmfx if enabled.
> 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 mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Made minor changes to get the decklink avdevice code to build using Visual C++
On Thu, 13 Apr 2017, Aaron Levinson wrote:
On 4/13/2017 1:23 PM, Hendrik Leppkes wrote:
[...]
From 00fdc9d15414a92a155eb7d1394bac3736dc9405 Mon Sep 17 00:00:00 2001
From: Aaron Levinson
Date: Thu, 13 Apr 2017 14:22:19 -0700
Subject: [PATCH] Made minor changes to get the decklink avdevice code to build
using Visual C++.
Maybe it just me, but as I mentioned earlier, I don't like too verbose
comments in the code, see below:
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index f01fba9..523217c 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -19,6 +19,15 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+// Moved inclusion of internal.h here in order to get it to build successfully
+// when using Visual C++ to build--otherwise, compilation errors result
+// due to winsock.h (which is included indirectly by DeckLinkAPI.h and
+// DeckLinkAPI_i.c) conflicting with winsock2.h, which is included by
+// internal.h. If winsock2.h is included first, then the conflict is resolved.
This can be as short as this:
/* Include internal.h first to avoid conflict of winsock.h (used by
* DeckLink) and winsock2.h (used by libavformat) in MSVC++ builds */
(for multiline comments I think /* */ is preferred)
Although since you do this in multiple headers, maybe it is enough if you
specify the reason in the commit message, and delete the comment from
here entirely.
@@ -262,8 +265,18 @@ static int64_t get_pkt_pts(IDeckLinkVideoInputFrame
*videoFrame,
res = videoFrame->GetHardwareReferenceTimestamp(time_base.den,
&bmd_pts, &bmd_duration);
break;
case PTS_SRC_WALLCLOCK:
-pts = av_rescale_q(wallclock, AV_TIME_BASE_Q, time_base);
+{
+// doing the following rather than using AV_TIME_BASE_Q because
+// AV_TIME_BASE_Q doesn't work when building with Visual C++
+// for C++ files (works for C files). When building C++ files,
+// it results in compiler error C4576. At least, this is the case
+// with Visual C++ 2015.
And this is:
// MSVC does not support compound literals like AV_TIME_BASE_Q in C++ code
+AVRational timebase;
+timebase.num = 1;
+timebase.den = AV_TIME_BASE;
+pts = av_rescale_q(wallclock, timebase, time_base);
break;
+}
This whole block needs to be indented 1 column more I think.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Removed pthread dependency
On Thu, 13 Apr 2017, Aaron Levinson wrote: On 4/13/2017 3:40 PM, Marton Balint wrote: On Thu, 13 Apr 2017, Aaron Levinson wrote: On 4/13/2017 2:12 AM, Hendrik Leppkes wrote: On Thu, Apr 13, 2017 at 10:36 AM, Aaron Levinson wrote: Give it some time for the other changes to be reviewed by the people that actually know decklink itself, you can include that in any new versions of the patch then, no need to send one for that right now. - Hendrik Actually, the coding changes made to the decklink source files in this patch have pretty much nothing to do with decklink itself, and anyone with familiarity with semaphores and pthread could review those changes. In fact, all I really did was use already existing approaches for replacing a semaphore with the combination of a condition variable, mutex, and counter, and there are plenty of examples of how to do this on the Web. Yeah, the changes look fine, please send an updated patch, I will apply it after some final testing. Thanks, Marton Here's a new version of the patch with the pthreads dependency replaced with threads. Thanks, applied. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3 2/3] ffplay: convert to new decode API
On Fri, 7 Apr 2017, Marton Balint wrote: Signed-off-by: Marton Balint --- ffplay.c | 101 ++- 1 file changed, 54 insertions(+), 47 deletions(-) Pushed the rest of the series. Regards, Marton ___ 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
2017-04-15 1:48 GMT+02:00 James Almer : > 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. That's not how I remember it. We had a relatively high number of open regressions when 3.2 was released but I don't think we ever had such a high number of open regressions as now (neither at times of releases nor otherwise). > 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 Sorry, but I really wonder what this sentence is supposed to mean... 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
Michael Niedermayer wrote: >> + 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 ? No! Either a list: . . . or simply the text: . . . is correct, but *NOT* nesting into . ___ 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
James Almer wrote: >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. +1 And as for bug report/fixing there has been invented the k++ possibility in the i.j.k versioning schema... In the real world of audio-visual archives, witch I know best, it is indeed important to be able to tell to the users to keep updated with the last release. (BTW: They are often unable to deal with the HEAD.) The final goal should to be to have FFmpeg used widely, I guess. Best regards, Reto ___ 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.
Hello, The plan is that if ffserver is not fixed before the next bump, it will be removed. ffserver has been serving our purpose in a 24/7 fashion for about 7 years now. It will probably be serving us for the foreseeable future, whatever the community decides. I prefer to share any fix I make back with the community because allowing everyone to build on top of better software pays off. If the community drops the program, we most likely won't, even if it means being stuck with a single version for years to come. However, we still need to get it as stable as possible. I also admit that I'm not versed in the codebase and whatever change I made was based purely on valgrind's output. I understand that my patch in its current state is not ideal and I probably should have attempted a cleaner fix before submitting. I'll try to do that. Having stated this, let's get back to the technical topic: This accesses plenty of internal fields. (Maybe did so before, but no matter.) So doing the freeing correctly (if even possible) would be better for the survival of ffserver. At first I was hoping that avformat_free_context() will do the job nicely for me, but unfortunately there are some shared objects that get destroyed in this call and ffserver eventually crashes. If you run such ffserver build in valgrind, it will warn about "free'd memory" accesses. The problem seems to stem from the "COPY" done in unlayer_stream(). I will try to reverse this "COPY" before avformat_free_context() and see if it helps. Best regards, Z. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
