Re: [FFmpeg-devel] [PATCH] add dumpwave filter
Hi, While Waveform.js converts old SoundCloud PNGs, wavesurer.js is using Web Audio API which is limited/not supported by all browsers > On 10 Jan 2018, at 08:51, Дмитрий Гуменюк wrote: > > There is no rush on this. Could you please do a code review so I can see how > to do things properly? >> On 10 Jan 2018, at 08:43, Kyle Swanson wrote: >> >> Hi, >> >> On Tue, Jan 9, 2018 at 3:49 PM, wrote: >>> From: Dmytro Humeniuk >>> >>> Signed-off-by: Dmytro Humeniuk >>> --- >>> Changelog | 1 + >>> doc/filters.texi | 23 >>> libavfilter/Makefile | 1 + >>> libavfilter/af_dumpwave.c | 285 >> + >>> libavfilter/allfilters.c | 1 + >>> libavfilter/version.h | 4 +- >>> tests/fate/filter-audio.mak| 5 + >>> tests/ref/fate/filter-dumpwave | 1 + >>> 8 files changed, 319 insertions(+), 2 deletions(-) >>> create mode 100644 libavfilter/af_dumpwave.c >>> create mode 100644 tests/ref/fate/filter-dumpwave >> >> I could see this possibly being a useful filter, but I'm confused about >> where the JSON schema came from. The two JS libraries that do this type of >> thing (waveform.js, and wavesurer.js) both just load waveform data as an >> array of floats. If we're going to add something like this to libavfilter >> it should be as generic and extensible as possible. I'm not wild about the >> string stuff, and the big sample format switch isn't necessary. I could do >> a code review, but it might just be faster if I rewrite it and send another >> patch. Is that OK with you? >> >> Thanks, >> Kyle >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > smime.p7s Description: S/MIME cryptographic signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Don't overwrite previously setup dimensions for all codecs
Currently a hacky way is used for some specific codecs such as
H264/VP6F/DXV.
Replace with a more generic way(an evolution based on a history commit
9de9b828ef005dec37052548c195a6b4f18fc701 but reverted somehow) to handle these
cases.
Signed-off-by: Zhong Li
---
libavcodec/utils.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 4d736d2..3f3f3db 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -684,16 +684,12 @@ int attribute_align_arg avcodec_open2(AVCodecContext
*avctx, const AVCodec *code
goto free_and_end;
}
-// only call ff_set_dimensions() for non H.264/VP6F/DXV codecs so as not
to overwrite previously setup dimensions
-if (!(avctx->coded_width && avctx->coded_height && avctx->width &&
avctx->height &&
- (avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id ==
AV_CODEC_ID_VP6F || avctx->codec_id == AV_CODEC_ID_DXV))) {
-if (avctx->coded_width && avctx->coded_height)
+if (avctx->coded_width && avctx->coded_height && !avctx->width &&
!avctx->height)
ret = ff_set_dimensions(avctx, avctx->coded_width,
avctx->coded_height);
-else if (avctx->width && avctx->height)
+else if (avctx->width && avctx->height && !avctx->coded_width &&
!avctx->coded_height)
ret = ff_set_dimensions(avctx, avctx->width, avctx->height);
if (ret < 0)
goto free_and_end;
-}
if ((avctx->coded_width || avctx->coded_height || avctx->width ||
avctx->height)
&& ( av_image_check_size2(avctx->coded_width, avctx->coded_height,
avctx->max_pixels, AV_PIX_FMT_NONE, 0, avctx) < 0
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add dumpwave filter.
On 08.01.2018 01:36, dmitry.gumen...@gmail.com wrote: From: Dmytro Humeniuk Signed-off-by: Dmytro Humeniuk --- Changelog | 1 + libavfilter/Makefile | 1 + libavfilter/af_dumpwave.c | 273 + libavfilter/allfilters.c | 1 + libavfilter/version.h | 4 +- tests/fate/filter-audio.mak| 5 + tests/ref/fate/filter-dumpwave | 1 + 7 files changed, 284 insertions(+), 2 deletions(-) create mode 100644 libavfilter/af_dumpwave.c create mode 100644 tests/ref/fate/filter-dumpwave [...] As far as I can see the filter reads audio and writes an envelope curve using JSON data format. The JSON data is then rendered into an image outside of FFmpeg. In my opinion it would be better to allow connecting the filter with other filters by directly rendering the image within FFmpeg. So the filter should have a generic video output instead of the JSON output. This would be similar to the existing "showvolume" filter. If you just want to get the raw envelope data from FFmpeg I suggest to take a look at the "write_peak" option of the WAV muxer. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add dumpwave filter.
On 10.01.2018 09:11, Дмитрий Гуменюк wrote: Hi, In my opinion JSON is more flexible, so envelope can be rendered in web app or mobile app This filter is useful when you’d like to generate visual representation of audio while doing transcode I see, but my point is: If you do the image rendering external anyway, why not use an existing envelope dumping format? Or alternatively connect the rendering application via the av* library interface in C? Filters into the codebase should be as generic as possible to allow re-usage by other filters. On 10 Jan 2018, at 09:00, Tobias Rapp wrote: On 08.01.2018 01:36, dmitry.gumen...@gmail.com wrote: From: Dmytro Humeniuk Signed-off-by: Dmytro Humeniuk --- Changelog | 1 + libavfilter/Makefile | 1 + libavfilter/af_dumpwave.c | 273 + libavfilter/allfilters.c | 1 + libavfilter/version.h | 4 +- tests/fate/filter-audio.mak| 5 + tests/ref/fate/filter-dumpwave | 1 + 7 files changed, 284 insertions(+), 2 deletions(-) create mode 100644 libavfilter/af_dumpwave.c create mode 100644 tests/ref/fate/filter-dumpwave [...] As far as I can see the filter reads audio and writes an envelope curve using JSON data format. The JSON data is then rendered into an image outside of FFmpeg. In my opinion it would be better to allow connecting the filter with other filters by directly rendering the image within FFmpeg. So the filter should have a generic video output instead of the JSON output. This would be similar to the existing "showvolume" filter. If you just want to get the raw envelope data from FFmpeg I suggest to take a look at the "write_peak" option of the WAV muxer. Regards, Tobias BTW: Top-posting is unpopular on this list. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] examples/qsvdec: remove the deprecated field refcounted_frames
It was just useful for deprecated API (avcodec_decode_video2), but useless for new decode APIs (avcodec_send_packet/avcodec_receive_frame). Signed-off-by: Zhong Li --- doc/examples/qsvdec.c | 1 - 1 file changed, 1 deletion(-) diff --git a/doc/examples/qsvdec.c b/doc/examples/qsvdec.c index 46e6ddc..cede615 100644 --- a/doc/examples/qsvdec.c +++ b/doc/examples/qsvdec.c @@ -210,7 +210,6 @@ int main(int argc, char **argv) video_st->codecpar->extradata_size); decoder_ctx->extradata_size = video_st->codecpar->extradata_size; } -decoder_ctx->refcounted_frames = 1; decoder_ctx->opaque = &decode; decoder_ctx->get_format = get_format; -- 1.8.3.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] examples/qsvdec: remove the deprecated field refcounted_frames
On Wed, 10 Jan 2018 16:39:16 +0800 Zhong Li wrote: > It was just useful for deprecated API (avcodec_decode_video2), > but useless for new decode APIs (avcodec_send_packet/avcodec_receive_frame). > > Signed-off-by: Zhong Li > --- > doc/examples/qsvdec.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/doc/examples/qsvdec.c b/doc/examples/qsvdec.c > index 46e6ddc..cede615 100644 > --- a/doc/examples/qsvdec.c > +++ b/doc/examples/qsvdec.c > @@ -210,7 +210,6 @@ int main(int argc, char **argv) > video_st->codecpar->extradata_size); > decoder_ctx->extradata_size = video_st->codecpar->extradata_size; > } > -decoder_ctx->refcounted_frames = 1; > > decoder_ctx->opaque = &decode; > decoder_ctx->get_format = get_format; LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Don't overwrite previously setup dimensions for all codecs
On Wed, Jan 10, 2018 at 9:10 AM, Zhong Li wrote: > Currently a hacky way is used for some specific codecs such as > H264/VP6F/DXV. > Replace with a more generic way(an evolution based on a history commit > 9de9b828ef005dec37052548c195a6b4f18fc701 but reverted somehow) to handle > these cases. > What does this actually fix or change? That should preferably be documented in the commit message. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add dumpwave filter
> wavesurer.js - Web Audio API I mean its would be hard to do the same for large files https://developer.mozilla.org/en-US/docs/Web/API/BaseAudioContext/decodeAudioData > On 10 Jan 2018, at 09:04, Дмитрий Гуменюк wrote: > > Hi, > While Waveform.js converts old SoundCloud PNGs, wavesurer.js is using Web > Audio API which is limited/not supported by all browsers > >> On 10 Jan 2018, at 08:51, Дмитрий Гуменюк wrote: >> >> There is no rush on this. Could you please do a code review so I can see how >> to do things properly? >>> On 10 Jan 2018, at 08:43, Kyle Swanson wrote: >>> >>> Hi, >>> >>> On Tue, Jan 9, 2018 at 3:49 PM, wrote: From: Dmytro Humeniuk Signed-off-by: Dmytro Humeniuk --- Changelog | 1 + doc/filters.texi | 23 libavfilter/Makefile | 1 + libavfilter/af_dumpwave.c | 285 >>> + libavfilter/allfilters.c | 1 + libavfilter/version.h | 4 +- tests/fate/filter-audio.mak| 5 + tests/ref/fate/filter-dumpwave | 1 + 8 files changed, 319 insertions(+), 2 deletions(-) create mode 100644 libavfilter/af_dumpwave.c create mode 100644 tests/ref/fate/filter-dumpwave >>> >>> I could see this possibly being a useful filter, but I'm confused about >>> where the JSON schema came from. The two JS libraries that do this type of >>> thing (waveform.js, and wavesurer.js) both just load waveform data as an >>> array of floats. If we're going to add something like this to libavfilter >>> it should be as generic and extensible as possible. I'm not wild about the >>> string stuff, and the big sample format switch isn't necessary. I could do >>> a code review, but it might just be faster if I rewrite it and send another >>> patch. Is that OK with you? >>> >>> Thanks, >>> Kyle >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > smime.p7s Description: S/MIME cryptographic signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add dumpwave filter
Same JSON schema used by SoundCloud > On 10 Jan 2018, at 10:16, Дмитрий Гуменюк wrote: > >> wavesurer.js - Web Audio API > I mean its would be hard to do the same for large files > https://developer.mozilla.org/en-US/docs/Web/API/BaseAudioContext/decodeAudioData > >> On 10 Jan 2018, at 09:04, Дмитрий Гуменюк wrote: >> >> Hi, >> While Waveform.js converts old SoundCloud PNGs, wavesurer.js is using Web >> Audio API which is limited/not supported by all browsers >> >>> On 10 Jan 2018, at 08:51, Дмитрий Гуменюк wrote: >>> >>> There is no rush on this. Could you please do a code review so I can see >>> how to do things properly? On 10 Jan 2018, at 08:43, Kyle Swanson wrote: Hi, On Tue, Jan 9, 2018 at 3:49 PM, wrote: > From: Dmytro Humeniuk > > Signed-off-by: Dmytro Humeniuk > --- > Changelog | 1 + > doc/filters.texi | 23 > libavfilter/Makefile | 1 + > libavfilter/af_dumpwave.c | 285 + > libavfilter/allfilters.c | 1 + > libavfilter/version.h | 4 +- > tests/fate/filter-audio.mak| 5 + > tests/ref/fate/filter-dumpwave | 1 + > 8 files changed, 319 insertions(+), 2 deletions(-) > create mode 100644 libavfilter/af_dumpwave.c > create mode 100644 tests/ref/fate/filter-dumpwave I could see this possibly being a useful filter, but I'm confused about where the JSON schema came from. The two JS libraries that do this type of thing (waveform.js, and wavesurer.js) both just load waveform data as an array of floats. If we're going to add something like this to libavfilter it should be as generic and extensible as possible. I'm not wild about the string stuff, and the big sample format switch isn't necessary. I could do a code review, but it might just be faster if I rewrite it and send another patch. Is that OK with you? Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >> > smime.p7s Description: S/MIME cryptographic signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add dumpwave filter.
On 10.01.2018 09:34, Дмитрий Гуменюк wrote: There is no existing dumping format for RMS. How to make it generic? Some of my applications use the following pattern to dump audio envelope data during transcoding: ffmpeg -i input-file -f [...] output-file \ -f wav -write_peak only peak-file The data format of "peak-file" follows EBU Tech 3285 Supplement 3 (BWF Peak Envelope Chunk). Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add dumpwave filter.
On Wed, Jan 10, 2018 at 08:58:05 +0100, dmitry.gumen...@gmail.com wrote:
> +@table @option
> +@item d
> +Dimensions @code{WxH}.
> +@code{W} - number of data values in json, values will be scaled according to
> @code{H}.
> +The default value is @var{640x480}
> +
> +@item s
> +Samples count per value per channel
In most other filters/filtersources, s+size is used for dimensions,
d+duration for time, and n for an amount/number of frames/samples or
so. Might be a good idea to align with this. And use aliases (i.e.
implement both "s" and "size").
> +static const AVOption dumpwave_options[] = {
> +{ "d", "set width and height", OFFSET(w), AV_OPT_TYPE_IMAGE_SIZE, {.str
> = "640x480"}, 0, 0, FLAGS },
> +{ "s", "set number of samples per value per channel", OFFSET(s),
> AV_OPT_TYPE_INT64, {.i64 = 0}, 0, INT64_MAX, FLAGS },
> +{ "json", "set json dump file", OFFSET(json), AV_OPT_TYPE_STRING, { .str
> = NULL }, 0, 0, FLAGS },
> +{ NULL }
[...]
> +static av_cold int init(AVFilterContext *ctx)
> +{
> +DumpWaveContext *dumpwave = ctx->priv;
> +if(!dumpwave->s) {
> +dumpwave->is_disabled = 1;
> +av_log(ctx, AV_LOG_ERROR, "Invalid samples per value config\n");
> +}
> +return 0;
I don't like the idea of having to provide the "s" parameter. Is there
really no useful default?
And now, if s=0, what does the filter do? Just sit around? Couldn't it
fail instead?
Apart from that:
"if (" is the bracket style ffmpeg uses.
> +if (dumpwave->json && !(dump_fp = av_fopen_utf8(dumpwave->json,
> "w")))
> +av_log(ctx, AV_LOG_WARNING, "Flushing dump failed\n");
I would appreciate evaluation of errno and printing the appropriate
string (using av_strerror(), I believe).
> +switch (inlink->format) {
> +case AV_SAMPLE_FMT_DBLP:
As Kyle hinted: Can this not force a conversion (implicit insertion of
aformat filter) to e.g. double by only supporting this format, and
reducing this switch to one or two cases? (The filter's output isn't
really meant for transparent reuse anyway? af_volumedetect e.g. also
supports only one, meaning its output can be a different format than
its input.) It's also really hard to go through and later to maintain.
It the big switch/case remains, one or two code macros would be
appropriate.
> +for (i = 0; i < buf->nb_samples; i++) {
> +for (c = 0; c < channels; c++, src++)
> +calc_db_rms(dumpwave, *src);
> +}}
I believe the curly brackets need to be placed differently.
> +.description = NULL_IF_CONFIG_SMALL("Dumps RMS amplitude to JSON
> file"),
Imperative, i.e. "Dump RMS ...".
> +FATE_AFILTER-$(call FILTERDEMDEC, DUMPWAVE, WAV, PCM_S16LE) +=
> fate-filter-dumpwave
> +fate-filter-dumpwave: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
> +fate-filter-dumpwave: CMD = ffmpeg -i $(SRC) -af
> dumpwave=d=1800x140:s=147:json=$(TARGET_PATH)/tests/data/fate/filter-dumpwave.out
> -f null - && cat $(TARGET_PATH)/tests/data/fate/filter-dumpwave.out
> +
If you need to implement all formats, you might want to test them all.
Just a thought.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] added reitnerlace filter
Hello, From the messages regarding the new reinterlace filter, based on your arguments and guidance, I came out with the following solution. Modify tinterlace filter so that it would behave like that: /if GONGIG_GPL is defined:/ / use curent titnerlace code with asm opts/ /else:/ / use the new reitnerlace filter, without asm opts/ After that I'll make sure that the new tinterlace gets compiled in ffmpeg without /--enable-gpl/ and /--enable-nonfree/. However, if one decides to use old tinterlace code with asm opts, he can use those configure flags. That being said, can the new tinterlace be released under LGPL? It is important for me to confirm once again this, to avoid writing new code that will have no future life. On 28.12.2017 17:30, Nicolas George wrote: Vasile Toncu (2017-12-28): Is submision to an older version possible? No. Branches are only maintained for bugs. New development only happens on Git head. Regards, ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 1/4] avformat/libopenmpt: Fix mixed code and declarations
Signed-off-by: Jörn Heusipp
---
libavformat/libopenmpt.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c
index af6eb1a..2e22290 100644
--- a/libavformat/libopenmpt.c
+++ b/libavformat/libopenmpt.c
@@ -72,13 +72,14 @@ static int read_header_openmpt(AVFormatContext *s)
{
AVStream *st;
OpenMPTContext *openmpt = s->priv_data;
-int64_t size = avio_size(s->pb);
-if (size <= 0)
-return AVERROR_INVALIDDATA;
-char *buf = av_malloc(size);
+int64_t size;
+char *buf;
int ret;
-
+size = avio_size(s->pb);
+if (size <= 0)
+return AVERROR_INVALIDDATA;
+buf = av_malloc(size);
if (!buf)
return AVERROR(ENOMEM);
size = avio_read(s->pb, buf, size);
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 0/4] libopenmpt 0.3 updates
Compared to the previous patch versions, only part 4 has been changed (based on the comments received so far). I also ran more performance tests. FFmpeg is configured via './configure --enable-libopenmpt --enable-libmodplug' in all tests. probetest failures with current libopenmpt 0.3.5-pre.0 (r9426): testing size=1 testing size=2 testing size=4 testing size=8 Failure of vqf probing code with score=50 type=3 p=C2A size=8 Failure of mov,mp4,m4a,3gp,3g2,mj2 probing code with score=50 type=3 p=FD1 size=8 Failure of 3dostr probing code with score=66 type=3 p=E2 size=8 Failure of mov,mp4,m4a,3gp,3g2,mj2 probing code with score=100 type=3 p=75 size=8 testing size=16 Failure of musx probing code with score=40 type=3 p=A6A size=16 Failure of alias_pix probing code with score=51 type=0 p=CBA size=16 testing size=32 testing size=64 Failure of mpc8 probing code with score=49 type=3 p=85A size=64 testing size=128 testing size=256 testing size=512 testing size=1024 testing size=2048 Failure of libopenmpt probing code with score=76 type=0 p=FED size=2048 testing size=4096 testing size=8192 testing size=16384 testing size=32768 testing size=65536 AMD A4-5000, Ubuntu 14.04, x86-64, GCC 4.8.2, libopenmpt 0.3.5-pre.0 (r9426): probetest performance: 1425530947 cycles, aa 25976883912 cycles, aac 25507211169 cycles, ac3 1042217662 cycles, acm 1632550096 cycles, act 1847361076 cycles, adp 3215025217 cycles, ads 1751119560 cycles, adx 1422549077 cycles, aea 1661030689 cycles, aiff 1664388004 cycles, aix 2876754979 cycles, amr 16213648221 cycles,amrnb 10357400286 cycles,amrwb 1518874168 cycles, anm 1848774401 cycles, apc 1025286732 cycles, ape 1999052278 cycles, apng 18252897495 cycles, aqtitle 2771276135 cycles, asf 2138272095 cycles,asf_o 16758768236 cycles, ass 1810499177 cycles, ast 1597035448 cycles, au 1629356130 cycles, avi 1664911494 cycles, avr 1421498186 cycles, avs 1504496122 cycles, bethsoftvid 1494735429 cycles, bfi 2543270309 cycles, bink 272403 cycles, bit 1500579804 cycles,bfstm 1087554907 cycles,brstm 1587938487 cycles, boa 1715001029 cycles, c93 1063478621 cycles, caf 7724800501 cycles,cavsvideo 1825737620 cycles, cdxl 1181800422 cycles, cine 3250419221 cycles, concat 078869 cycles,dcstr 1512175182 cycles, dfa 1403369419 cycles,dirac 1555052671 cycles,dnxhd 2044301070 cycles, dsf 1164145857 cycles, dsicin 1617975398 cycles, dss 31075115518 cycles, dts 1512886188 cycles,dtshd 15304698997 cycles, dv 12154318089 cycles, dvbsub 1641827312 cycles, dvbtxt 1799178653 cycles, dxa 2122493980 cycles, ea 1412999215 cycles, ea_cdata 19832626428 cycles, eac3 1469702273 cycles, epaf 3151846641 cycles, ffmetadata 3846803597 cycles, fits 2382096387 cycles, flac 1938351100 cycles, flic 1750595032 cycles, flv 1034144158 cycles, live_flv 1419146038 cycles, 4xm 2298304236 cycles, frm 2332352309 cycles, fsb 1753160137 cycles, gdv 1164270006 cycles, genh 4115033986 cycles, gif 2162805981 cycles, gsm 2425065785 cycles, gxf 22958299155 cycles, h261 22259377736 cycles, h263 21565315903 cycles, h264 14131416451 cycles, hevc 2294216465 cycles, hls,applehttp 2026125838 cycles, hnm 1599698430 cycles, ico 2130406935 cycles,idcin 1936330153 cycles, idf 1721541470 cycles, iff 2700087066 cycles, ilbc 1603579794 cycles,alias_pix 2559447550 cycles, brender_pix 1736901491 cycles,ingenient 13309369249 cycles, ipmovie 2020584923 cycles,ircam 2157010519 cycles, iss 1326703719 cycles, iv8 1373300900 cycles, ivf 3415745402 cycles, ivr 28777360214 cycles, jacosub 1683261092 cycles, jv 1796897802 cycles,lmlm4 27908164305 cycles, loas 2783000204 cycles, lrc 1698706136 cycles, lvf 2283438621 cycles, lxf 21187997513 cycles, m4v 1761691177 cycles, matroska,webm 1810514534 cycles,mgsts 13885029990 cycles, microdvd 17194619859 cycles,mjpeg 14864883485 cycles, mjpeg_2000 20581718455 cycles, mlp 1465609046 cycles, mlv 2130473395 cycles, mm 1381846427 cycles, mmf 2189640745 cycles, mov,mp4,m4a,3gp,3g2,mj2 33954117497
[FFmpeg-devel] [PATCH v2 3/4] avformat/libopenmpt: Update file extensions list for libopenmpt 0.3
Signed-off-by: Jörn Heusipp
---
libavformat/libopenmpt.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c
index 30c3d6e..5efbdc4 100644
--- a/libavformat/libopenmpt.c
+++ b/libavformat/libopenmpt.c
@@ -234,5 +234,9 @@ AVInputFormat ff_libopenmpt_demuxer = {
.read_close = read_close_openmpt,
.read_seek = read_seek_openmpt,
.priv_class = &class_openmpt,
-.extensions =
"669,amf,ams,dbm,digi,dmf,dsm,far,gdm,imf,it,j2b,m15,mdl,med,mmcmp,mms,mo3,mod,mptm,mt2,mtm,nst,okt,plm,ppm,psm,pt36,ptm,s3m,sfx,sfx2,stk,stm,ult,umx,wow,xm,xpk",
+#if OPENMPT_API_VERSION_AT_LEAST(0,3,0)
+.extensions =
"669,amf,ams,dbm,digi,dmf,dsm,dtm,far,gdm,ice,imf,it,j2b,m15,mdl,med,mmcmp,mms,mo3,mod,mptm,mt2,mtm,nst,okt,plm,ppm,psm,pt36,ptm,s3m,sfx,sfx2,st26,stk,stm,stp,ult,umx,wow,xm,xpk",
+#else
+.extensions =
"669,amf,ams,dbm,digi,dmf,dsm,far,gdm,ice,imf,it,j2b,m15,mdl,med,mmcmp,mms,mo3,mod,mptm,mt2,mtm,nst,okt,plm,ppm,psm,pt36,ptm,s3m,sfx,sfx2,st26,stk,stm,ult,umx,wow,xm,xpk",
+#endif
};
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 4/4] avformat/libopenmpt: Probe file format from file data if possible
When building with libopenmpt 0.3, use the libopenmpt file header
probing functions for probing. libopenmpt probing functions are
allocation-free and designed to be as fast as possible.
For libopenmpt 0.2, or when libopenmpt 0.3 file header probing cannot
probe successfully due to too small probe buffer, test the filename
against the file extensions supported by the libopenmpt library that
is actually linked, instead of relying on a hard-coded file extension
list. File extension testing is also allocation-free and designed to
be fast in libopenmpt. Avoiding a hard-coded file extension list is
useful because later libopenmpt versions will likely add support for
more module file formats.
libopenmpt file header probing is tested regularly against the FATE
suite and other diverse file collections by libopenmpt upstream in
order to avoid false positives.
FATE passes with './configure --enable-libopenmpt' as well as with
'./configure --enable-libopenmpt --enable-libmodplug'.
libopenmpt probing adds about 5%..10% cpu time (depending on precise
usage pattern and host CPU and compiler version used for libopenmpt)
compared to all current internal FFmpeg probing functions combined in
tools/probetest for all of its module formats combined (currently 41
modules formats in libopenmpt 0.3.4 and 234 file formats in FFmpeg).
Signed-off-by: Jörn Heusipp
---
libavformat/libopenmpt.c | 57
1 file changed, 57 insertions(+)
diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c
index 5efbdc4..42b78fb 100644
--- a/libavformat/libopenmpt.c
+++ b/libavformat/libopenmpt.c
@@ -218,6 +218,62 @@ static int read_seek_openmpt(AVFormatContext *s, int
stream_idx, int64_t ts, int
return 0;
}
+static int probe_openmpt_extension(AVProbeData *p)
+{
+const char *ext;
+if (p->filename) {
+ext = strrchr(p->filename, '.');
+if (ext && strlen(ext + 1) > 0) {
+ext++; /* skip '.' */
+if (openmpt_is_extension_supported(ext) == 1)
+return AVPROBE_SCORE_EXTENSION;
+}
+}
+return 0;
+}
+
+static int read_probe_openmpt(AVProbeData *p)
+{
+#if OPENMPT_API_VERSION_AT_LEAST(0,3,0)
+int probe_result;
+if (p->buf && p->buf_size > 0) {
+probe_result = openmpt_probe_file_header_without_filesize(
+ OPENMPT_PROBE_FILE_HEADER_FLAGS_DEFAULT,
+ p->buf, p->buf_size,
+ &openmpt_logfunc, NULL, NULL, NULL, NULL, NULL);
+if (probe_result == OPENMPT_PROBE_FILE_HEADER_RESULT_SUCCESS) {
+/* As probing here relies on code external to FFmpeg, do not return
+ * AVPROBE_SCORE_MAX in order to reduce the impact in the rare
+ * cases of false positives.
+ */
+return AVPROBE_SCORE_MIME + 1;
+} else if (probe_result ==
OPENMPT_PROBE_FILE_HEADER_RESULT_WANTMOREDATA) {
+if (probe_openmpt_extension(p) > 0) {
+return AVPROBE_SCORE_EXTENSION;
+} else {
+if (p->buf_size >=
openmpt_probe_file_header_get_recommended_size()) {
+/* We have already received the recommended amount of data
+ * and still cannot decide. Return a rather low score.
+ */
+return AVPROBE_SCORE_RETRY / 2;
+} else {
+/* The file extension is unknown and we have very few data
+ * bytes available. libopenmpt cannot decide anything here,
+ * and returning any score > 0 would result in successfull
+ * probing of random data.
+ */
+return 0;
+}
+}
+} else if (probe_result == OPENMPT_PROBE_FILE_HEADER_RESULT_FAILURE) {
+return 0;
+}
+}
+#endif
+/* for older libopenmpt, fall back to file extension probing */
+return probe_openmpt_extension(p);
+}
+
static const AVClass class_openmpt = {
.class_name = "libopenmpt",
.item_name = av_default_item_name,
@@ -229,6 +285,7 @@ AVInputFormat ff_libopenmpt_demuxer = {
.name = "libopenmpt",
.long_name = NULL_IF_CONFIG_SMALL("Tracker formats (libopenmpt)"),
.priv_data_size = sizeof(OpenMPTContext),
+.read_probe = read_probe_openmpt,
.read_header= read_header_openmpt,
.read_packet= read_packet_openmpt,
.read_close = read_close_openmpt,
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 2/4] avformat/libopenmpt: Update to libopenmpt 0.3 API
libopenmpt 0.3 deprecates openmpt_module_create_from_memory() and
provides a replacement function openmpt_module_create_from_memory2().
Detecting libopenmpt 0.3 can be done at build time via the API
version macros provided by libopenmpt. libopenmpt 0.2 did not provide
all required macros, however libopenmpt documents the required #define
shims that can be safely added for libopenmpt 0.2.
Using openmpt_module_create_from_memory2() instead of
openmpt_module_create_from_memory() avoids the deprecation warning
when building ffmpeg with libopenmpt 0.3.
openmpt_module_create_from_memory2() provides more fine-grained error
reporting and in particular allows distinguishing out-of-memory from
input file parsing errors. Return appropriate ffmpeg errors
accordingly.
libopenmpt 0.3 is ABI and API compatible with applications built
against libopenmpt 0.2. Building ffmpeg with libopenmpt 0.2 is still
supported.
Signed-off-by: Jörn Heusipp
---
libavformat/libopenmpt.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c
index 2e22290..30c3d6e 100644
--- a/libavformat/libopenmpt.c
+++ b/libavformat/libopenmpt.c
@@ -21,6 +21,14 @@
#include
#include
+#include
+/* Shims to support libopenmpt < 0.3.0 (as documented by libopenmpt) */
+#if !defined(OPENMPT_API_VERSION_MAKE)
+#define OPENMPT_API_VERSION_MAKE(major, minor, patch)
(((major)<<24)|((minor)<<16)|((patch)<<0))
+#endif
+#if !defined(OPENMPT_API_VERSION_AT_LEAST)
+#define OPENMPT_API_VERSION_AT_LEAST(major, minor, patch) (OPENMPT_API_VERSION
>= OPENMPT_API_VERSION_MAKE((major), (minor), (patch)))
+#endif
#include "libavutil/avstring.h"
#include "libavutil/opt.h"
@@ -74,6 +82,9 @@ static int read_header_openmpt(AVFormatContext *s)
OpenMPTContext *openmpt = s->priv_data;
int64_t size;
char *buf;
+#if OPENMPT_API_VERSION_AT_LEAST(0,3,0)
+int error;
+#endif
int ret;
size = avio_size(s->pb);
@@ -89,10 +100,24 @@ static int read_header_openmpt(AVFormatContext *s)
return size;
}
+#if OPENMPT_API_VERSION_AT_LEAST(0,3,0)
+error = OPENMPT_ERROR_OK;
+openmpt->module = openmpt_module_create_from_memory2(buf, size,
openmpt_logfunc, s, NULL, NULL, &error, NULL, NULL);
+av_freep(&buf);
+if (!openmpt->module) {
+if (error == OPENMPT_ERROR_OUT_OF_MEMORY)
+return AVERROR(ENOMEM);
+else if (error >= OPENMPT_ERROR_GENERAL)
+return AVERROR_INVALIDDATA;
+else
+return AVERROR_UNKNOWN;
+}
+#else
openmpt->module = openmpt_module_create_from_memory(buf, size,
openmpt_logfunc, s, NULL);
av_freep(&buf);
if (!openmpt->module)
return AVERROR_INVALIDDATA;
+#endif
openmpt->channels = av_get_channel_layout_nb_channels(openmpt->layout);
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] added reitnerlace filter
On 1/10/18, Vasile Toncu wrote: > Hello, > > From the messages regarding the new reinterlace filter, based on your > arguments and guidance, I came out with the following solution. > > Modify tinterlace filter so that it would behave like that: > > /if GONGIG_GPL is defined:/ > > /use curent titnerlace code with asm opts/ > > /else:/ > > /use the new reitnerlace filter, without asm opts/ > > After that I'll make sure that the new tinterlace gets compiled in > ffmpeg without /--enable-gpl/ and /--enable-nonfree/. However, if one > decides to use old tinterlace code with asm opts, he can use those > configure flags. > > That being said, can the new tinterlace be released under LGPL? It is > important for me to confirm once again this, to avoid writing new code > that will have no future life. No such duplicatated funcionality is allowed in codebase. As previously being said, just rewrite tinterlace filter in LGPL and add shim for GPL asm parts. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 4/4] avformat/libopenmpt: Probe file format from file data if possible
2018-01-10 12:18 GMT+01:00 Jörn Heusipp :
> When building with libopenmpt 0.3, use the libopenmpt file header
> probing functions for probing. libopenmpt probing functions are
> allocation-free and designed to be as fast as possible.
>
> For libopenmpt 0.2, or when libopenmpt 0.3 file header probing cannot
> probe successfully due to too small probe buffer, test the filename
> against the file extensions supported by the libopenmpt library that
> is actually linked, instead of relying on a hard-coded file extension
> list. File extension testing is also allocation-free and designed to
> be fast in libopenmpt. Avoiding a hard-coded file extension list is
> useful because later libopenmpt versions will likely add support for
> more module file formats.
>
> libopenmpt file header probing is tested regularly against the FATE
> suite and other diverse file collections by libopenmpt upstream in
> order to avoid false positives.
>
> FATE passes with './configure --enable-libopenmpt' as well as with
> './configure --enable-libopenmpt --enable-libmodplug'.
>
> libopenmpt probing adds about 5%..10% cpu time (depending on precise
> usage pattern and host CPU and compiler version used for libopenmpt)
> compared to all current internal FFmpeg probing functions combined in
> tools/probetest for all of its module formats combined (currently 41
> modules formats in libopenmpt 0.3.4 and 234 file formats in FFmpeg).
>
> Signed-off-by: Jörn Heusipp
> ---
> libavformat/libopenmpt.c | 57
>
> 1 file changed, 57 insertions(+)
>
> diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c
> index 5efbdc4..42b78fb 100644
> --- a/libavformat/libopenmpt.c
> +++ b/libavformat/libopenmpt.c
> @@ -218,6 +218,62 @@ static int read_seek_openmpt(AVFormatContext *s, int
> stream_idx, int64_t ts, int
> return 0;
> }
>
> +static int probe_openmpt_extension(AVProbeData *p)
> +{
> +const char *ext;
> +if (p->filename) {
> +ext = strrchr(p->filename, '.');
> +if (ext && strlen(ext + 1) > 0) {
> +ext++; /* skip '.' */
> +if (openmpt_is_extension_supported(ext) == 1)
> +return AVPROBE_SCORE_EXTENSION;
> +}
> +}
> +return 0;
> +}
> +
> +static int read_probe_openmpt(AVProbeData *p)
> +{
> +#if OPENMPT_API_VERSION_AT_LEAST(0,3,0)
> +int probe_result;
> +if (p->buf && p->buf_size > 0) {
> +probe_result = openmpt_probe_file_header_without_filesize(
> + OPENMPT_PROBE_FILE_HEADER_FLAGS_DEFAULT,
> + p->buf, p->buf_size,
> + &openmpt_logfunc, NULL, NULL, NULL, NULL, NULL);
> +if (probe_result == OPENMPT_PROBE_FILE_HEADER_RESULT_SUCCESS) {
> +/* As probing here relies on code external to FFmpeg, do not
> return
> + * AVPROBE_SCORE_MAX in order to reduce the impact in the rare
> + * cases of false positives.
> + */
> +return AVPROBE_SCORE_MIME + 1;
> +} else if (probe_result ==
> OPENMPT_PROBE_FILE_HEADER_RESULT_WANTMOREDATA) {
> +if (probe_openmpt_extension(p) > 0) {
> +return AVPROBE_SCORE_EXTENSION;
I don't think this is a good idea because it means that a high score is
reported for WANTMOREDATA.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] added reitnerlace filter
2018-01-10 11:57 GMT+01:00 Vasile Toncu : > From the messages regarding the new reinterlace filter, based on your > arguments and guidance, I came out with the following solution. > > Modify tinterlace filter so that it would behave like that: > >/if GONGIG_GPL is defined:/ > >/use curent titnerlace code with asm opts/ > >/else:/ > >/use the new reitnerlace filter, without asm opts/ I believe the relevant question is if it is technically possible to use the existing asm optimizations for the existing tinterlace filter in your new reinterlace filter. If it is technically possible, then the asm optimizations are used if FFmpeg was compiled with --enable-gpl and are not used if --enable-gpl was not passed to configure. In both cases, an interlace filter exist. Above solution seems worse than adding a new filter for license reasons, something not all developers are opposed to. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 4/4] avformat/libopenmpt: Probe file format from file data if possible
On 01/10/2018 12:55 PM, Carl Eugen Hoyos wrote:
2018-01-10 12:18 GMT+01:00 Jörn Heusipp :
When building with libopenmpt 0.3, use the libopenmpt file header
probing functions for probing. libopenmpt probing functions are
allocation-free and designed to be as fast as possible.
For libopenmpt 0.2, or when libopenmpt 0.3 file header probing cannot
probe successfully due to too small probe buffer, test the filename
against the file extensions supported by the libopenmpt library that
is actually linked, instead of relying on a hard-coded file extension
list. File extension testing is also allocation-free and designed to
be fast in libopenmpt. Avoiding a hard-coded file extension list is
useful because later libopenmpt versions will likely add support for
more module file formats.
libopenmpt file header probing is tested regularly against the FATE
suite and other diverse file collections by libopenmpt upstream in
order to avoid false positives.
FATE passes with './configure --enable-libopenmpt' as well as with
'./configure --enable-libopenmpt --enable-libmodplug'.
libopenmpt probing adds about 5%..10% cpu time (depending on precise
usage pattern and host CPU and compiler version used for libopenmpt)
compared to all current internal FFmpeg probing functions combined in
tools/probetest for all of its module formats combined (currently 41
modules formats in libopenmpt 0.3.4 and 234 file formats in FFmpeg).
Signed-off-by: Jörn Heusipp
---
libavformat/libopenmpt.c | 57
1 file changed, 57 insertions(+)
diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c
index 5efbdc4..42b78fb 100644
--- a/libavformat/libopenmpt.c
+++ b/libavformat/libopenmpt.c
@@ -218,6 +218,62 @@ static int read_seek_openmpt(AVFormatContext *s, int
stream_idx, int64_t ts, int
return 0;
}
+static int probe_openmpt_extension(AVProbeData *p)
+{
+const char *ext;
+if (p->filename) {
+ext = strrchr(p->filename, '.');
+if (ext && strlen(ext + 1) > 0) {
+ext++; /* skip '.' */
+if (openmpt_is_extension_supported(ext) == 1)
+return AVPROBE_SCORE_EXTENSION;
+}
+}
+return 0;
+}
+
+static int read_probe_openmpt(AVProbeData *p)
+{
+#if OPENMPT_API_VERSION_AT_LEAST(0,3,0)
+int probe_result;
+if (p->buf && p->buf_size > 0) {
+probe_result = openmpt_probe_file_header_without_filesize(
+ OPENMPT_PROBE_FILE_HEADER_FLAGS_DEFAULT,
+ p->buf, p->buf_size,
+ &openmpt_logfunc, NULL, NULL, NULL, NULL, NULL);
+if (probe_result == OPENMPT_PROBE_FILE_HEADER_RESULT_SUCCESS) {
+/* As probing here relies on code external to FFmpeg, do not return
+ * AVPROBE_SCORE_MAX in order to reduce the impact in the rare
+ * cases of false positives.
+ */
+return AVPROBE_SCORE_MIME + 1;
+} else if (probe_result ==
OPENMPT_PROBE_FILE_HEADER_RESULT_WANTMOREDATA) {
+if (probe_openmpt_extension(p) > 0) {
+return AVPROBE_SCORE_EXTENSION;
I don't think this is a good idea because it means that a high score is
reported for WANTMOREDATA.
That is what the first patch did also, however much more convoluted and
not easy to spot.
In any case, I agree, that does not appear like that good of an idea.
Will change to AVPROBE_SCORE_RETRY with the next iteration of the patch.
Regards,
Jörn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/11] libavdevice/decklink: Add support for EIA-708 output over SDI
On Mon, Jan 08, 2018 at 20:16:48 -0500, Devin Heitmueller wrote:
> +if (ctx->supports_vanc == 0 ||
> ctx->dlo->DoesSupportVideoMode(ctx->bmd_mode, ctx->raw_format,
In other places you (or the DeckLink code) use
if (!ctx->supports_vanc || [...]
which I believe is preferred.
> +if (ctx->supports_vanc == 0)
Same here.
> +if (ret != 0)
> +return AVERROR(ENOMEM);
Same here.
> +ret = klvanc_set_framerate_EIA_708B(pkt, ctx->bmd_tb_num,
> ctx->bmd_tb_den);
> +if (ret != 0) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid framerate specified:
> %lld/%lld\n",
Same here, and others.
> +for (size_t i = 0; i < cc_count; i++) {
Declare i outside the clause.
> +for (int i = 0; i < vanc_lines.num_lines; i++) {
Same here.
> +if (line == NULL)
if (!line)
These comments apply to several of the other patches as well.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/11] libavdevice/decklink: Add support for EIA-708 output over SDI
On Wed, Jan 10, 2018 at 14:29:43 +0100, Moritz Barsnick wrote:
> > +for (size_t i = 0; i < cc_count; i++) {
> Declare i outside the clause.
> > +for (int i = 0; i < vanc_lines.num_lines; i++) {
> Same here.
Sorry, this rule may not apply to C++ files, as it's part of all C++
standards and all compilers should support it. Others may know more.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/11] libavdevice/decklink: Add support for EIA-708 output over SDI
Hello Moritz,
> On Wed, Jan 10, 2018 at 14:29:43 +0100, Moritz Barsnick wrote:
>>> +for (size_t i = 0; i < cc_count; i++) {
>> Declare i outside the clause.
>>> +for (int i = 0; i < vanc_lines.num_lines; i++) {
>> Same here.
>
> Sorry, this rule may not apply to C++ files, as it's part of all C++
> standards and all compilers should support it. Others may know more.
For loop declaration has been part of the C standard since C99. I’m not
against changing it if required, but I’ve already revised the patch series
multiple times and would prefer that demands for such stylistic cleanup either
be pointed out in the first review or I can submit such changes as subsequent
patches.
If the patch needs to be revised for some good technical reason, I will
incorporate these changes.
Devin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Don't overwrite previously setup dimensions for all codecs
2018-01-10 9:10 GMT+01:00 Zhong Li : > Currently a hacky way is used for some specific codecs such as > H264/VP6F/DXV. > Replace with a more generic way(an evolution based on a history commit > 9de9b828ef005dec37052548c195a6b4f18fc701 but reverted somehow) This commit was never part of FFmpeg. > to handle these cases. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/11] libavdevice/decklink: Add support for EIA-708 output over SDI
On Wed, Jan 10, 2018 at 09:11:35 -0500, Devin Heitmueller wrote: > For loop declaration has been part of the C standard since C99. I'm just quoting other similar discussions on this list. This has been a topic several (hundred? ;-)) times the last few months. It peaked in this discussion which was apparently never closed: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/219405.html > I’m not against changing it if required, but I’ve already revised the > patch series multiple times and would prefer that demands for such > stylistic cleanup either be pointed out in the first review or I can > submit such changes as subsequent patches. I don't care, I'm justing pointing it out, as others don't seem to care (enough/anymore/and were more concentrated on the technical aspects) or have missed it. Comments of these sorts have come before (elsewhere of course). Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add dumpwave filter
Hi,
For this to be a part of libavfilter the output needs to be more generic
than the just the Soundcloud format. If we want this to be generally useful
it should probably just output an array of floats between 0.0 and 1.0. The
consumer of this data (JS library, or whatever) can use this in whatever
way it wants. If you send another patch, just reply to this thread because
that makes it easier to follow (sending a patch as an attachment is OK).
Here are some critiques:
+typedef struct DumpWaveContext {
> +const AVClass *class; /**< class for AVOptions */
> +int w; /**< number of data values in json */
> +int h; /**< values will be scaled according to
> provided */
> +int is_disabled;/**< disable filter in case it's
> misconfigured */
> +int i; /**< index of value */
> +char *json; /**< path to json */
> +char *str; /**< comma separated values */, wha
> +double *values; /**< scaling factors */
> +int64_t s; /**< samples per value per channel */
> +int64_t n; /**< current number of samples counted */
> +int64_t max_samples;/**< samples per value */
> +double sum; /**< sum of the squared samples per value */
> +} DumpWaveContext;
Use more descriptive variable names for your struct members. They don't
have to be just one letter.
> +{ "d", "set width and height", OFFSET(w), AV_OPT_TYPE_IMAGE_SIZE,
> {.str = "640x480"}, 0, 0, FLAGS },
Get rid of this. We shouldn't care how this data is used/rendered. Our only
job should be to output an array of floats.
> +{ "s", "set number of samples per value per channel", OFFSET(s),
> AV_OPT_TYPE_INT64, {.i64 = 0}, 0, INT64_MAX, FLAGS },
Maybe you can call this frame_size? 0 is not a useful value here, it
shouldn't be the lower bound or the default value.
> +static av_cold int init(AVFilterContext *ctx)
> +{
> +DumpWaveContext *dumpwave = ctx->priv;
> +if(!dumpwave->s) {
The filter should just fail if it's not configured correctly. You'll get
this behavior for free with better default values.
> +static int config_output(AVFilterLink *outlink)
> +{
> +AVFilterContext *ctx = outlink->src;
> +DumpWaveContext *dumpwave = ctx->priv;
> +const int width = dumpwave->w;
> +dumpwave->values = av_realloc(NULL, width * sizeof(double));
> +dumpwave->str = av_realloc(NULL, width * sizeof(int));
You don't need a giant buffer to hold the entire string. Just keep a file
open a write to it every frame. Maybe we could just write if to stdout
instead?
> +
> +/**
> + * Converts sample to dB and calculates root mean squared value
> + */
> +static inline void dbRms(DumpWaveContext *dumpwave, double smpl)
>
Just call this RMS and spit something out between 0.0 and 1.0. Avoid
camelcase for function names.
>
> +switch (inlink->format) {
> +case AV_SAMPLE_FMT_DBLP:
> +for (c = 0; c < channels; c++) {
> +const double *src = (const double *)buf->extended_data[c];
> +
> +for (i = 0; i < buf->nb_samples; i++, src++)
> +dbRms(dumpwave, *src);
> +}
> +break;
> +case AV_SAMPLE_FMT_DBL: {
> +const double *src = (const double *)buf->extended_data[0];
> +
> +for (i = 0; i < buf->nb_samples; i++) {
> +for (c = 0; c < channels; c++, src++)
> +dbRms(dumpwave, *src);
> +}}
> +break;
> +case AV_SAMPLE_FMT_FLTP:
> +for (c = 0; c < channels; c++) {
> +const float *src = (const float *)buf->extended_data[c];
> +
> +for (i = 0; i < buf->nb_samples; i++, src++)
> +dbRms(dumpwave, *src);
> +}
> +break;
> +case AV_SAMPLE_FMT_FLT: {
> +const float *src = (const float *)buf->extended_data[0];
> +
> +for (i = 0; i < buf->nb_samples; i++) {
> +for (c = 0; c < channels; c++, src++)
> +dbRms(dumpwave, *src);
> +}}
> +break;
> +case AV_SAMPLE_FMT_S64P:
> +for (c = 0; c < channels; c++) {
> +const int64_t *src = (const int64_t
> *)buf->extended_data[c];
> +
> +for (i = 0; i < buf->nb_samples; i++, src++)
> +dbRms(dumpwave, *src / (double)INT64_MAX);
> +}
> +break;
> +case AV_SAMPLE_FMT_S64: {
> +const int64_t *src = (const int64_t *)buf->extended_data[0];
> +
> +for (i = 0; i < buf->nb_samples; i++) {
> +for (c = 0; c < channels; c++, src++)
> +dbRms(dumpwave, *src / (double)INT64_MAX);
> +}}
> +break;
> +case AV_SAMPLE_FMT_S32P:
> +for (c = 0; c < channels; c++) {
> +const int32_t *src = (const int32
Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: Increase support for common encryption.
On Tue, Jan 09, 2018 at 10:25:12AM -0800, Jacob Trimble wrote:
> On Mon, Jan 8, 2018 at 5:19 PM, Carl Eugen Hoyos wrote:
> > 2018-01-08 23:16 GMT+01:00 Jacob Trimble
> > :
> >>> You can't remove API just like that without a deprecation period.
> >>> Add a new av_aes_ctr_set_full_iv() function, and either leave
> >>> av_aes_ctr_set_iv() alone or deprecate it if it effectively becomes
> >>> superfluous after adding the new function.
> >>>
> >>> Also, this patch needs to be split in three. One for the aes_crt
> >>> changes, one for the encryption_info changes, and one for mov changes,
> >>> with a minor libavutil version bump for the former two, and the
> >>> corresponding APIChanges entry.
> >>> Alternatively, you could also squash the new encryption_info API from
> >>> this patch into the one that actually introduces the entire feature.
> >>
> >> Whoops, I thought that was internal-only. Done and split into its own
> >> change.
> >>
> >> On Sat, Jan 6, 2018 at 7:30 AM, Carl Eugen Hoyos
> >> wrote:
> >>> 2018-01-05 20:49 GMT+01:00 Jacob Trimble
> >>> :
> >>>
> +if (!frag_stream_info->encryption_index) {
> +frag_stream_info->encryption_index =
> av_mallocz(sizeof(MOVEncryptionIndex));
> >>>
> >>> sizeof(variable), please.
> >
> > Do you disagree?
> > I have no strong opinion, but I thought it makes the code more robust...
>
> I did it most other places, but forgot it here. Done.
>
> >
> >>> [...]
> >>>
> +sample_count = avio_rb32(pb);
> +
> +encryption_index->encrypted_samples =
> av_mallocz_array(sizeof(AVEncryptionInfo*), sample_count);
> >>>
> >>> This should be avoided if possible, see below.
> >>>
> +if (!encryption_index->encrypted_samples) {
> return AVERROR(ENOMEM);
> }
> +encryption_index->nb_encrypted_samples = sample_count;
>
> -return av_aes_ctr_init(sc->cenc.aes_ctr, c->decryption_key);
> +for (i = 0; i < sample_count; i++) {
> >>>
> >>> Please check here for eof...
> >>>
> +ret = mov_read_sample_encryption_info(c, pb, sc,
> &encryption_index->encrypted_samples[i], use_subsamples);
> >>>
> >>> ... and insert a realloc here to avoid the large allocation above, see
> >>> 1112ba01.
> >>
> >> Done.
> >
> >> +if (use_subsamples) {
> >> +subsample_count = avio_rb16(pb);
> >> +for (i = 0; i < subsample_count && !pb->eof_reached; i++) {
> >> +unsigned int min_subsamples = FFMIN(FFMAX(i, 1024 * 1024),
> >> subsample_count);
> >> +subsamples = av_fast_realloc((*sample)->subsamples,
> >> &alloc_size,
> >> + min_subsamples *
> >> sizeof(*subsamples));
> >
> > The reason I did not comment on this block in the last mail is that
> > iiuc, the maximum allocation here is INT16_MAX * 8 which seems
> > acceptable (and there cannot be a realloc with the chosen initial
> > limit).
>
> Ok, changed back.
>
> >
> >> +sample_count = avio_rb32(pb);
> >
> > You have to check here...
> >
> > +for (i = 0; i < sample_count && !pb->eof_reached; i++) {
> > +unsigned int min_samples = FFMIN(FFMAX(i, 1024 * 1024),
> > sample_count);
> > +encrypted_samples =
> > av_fast_realloc(encryption_index->encrypted_samples, &alloc_size,
> >
> > +min_samples *
> > sizeof(*encrypted_samples));
> >
> > ... if this product could overflow for the final reallocation, see 1112ba01.
>
> Done
>
> >
> > Thank you, Carl Eugen
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> libavformat/isom.h | 20 -
> libavformat/mov.c | 432
> ++---
> tests/fate/mov.mak |8
> tests/ref/fate/mov-frag-encrypted | 57
> tests/ref/fate/mov-tenc-only-encrypted | 57
> 5 files changed, 422 insertions(+), 152 deletions(-)
> 21ec6d9850961f491553278e64042530cecaacbe
> 0001-avformat-mov-Increase-support-for-v3.patch
> From e8261628e11347a8aa1b61de04c53cc1174cdae3 Mon Sep 17 00:00:00 2001
> From: Jacob Trimble
> Date: Wed, 6 Dec 2017 16:17:54 -0800
> Subject: [PATCH 1/3] avformat/mov: Increase support for common encryption.
This causes a crash:
=
==4012==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020eb78
at pc 0x00a944aa bp 0x7ffcd481ce70 sp 0x7ffcd481ce68
READ of size 8 at 0x6020eb78 thread T0
#0 0xa944a9 in mov_free_encryption_index ffmpeg/libavformat/mov.c:6615:20
#1 0xa6fb2b in mov_read_close ffmpeg/libavformat/mov.c:6693:13
#2 0xa6d96f in mov_read_header ffmpeg/libavformat/mov.c:6867:13
#3 0xc4a6ed in avformat_open_input ffmpeg/libavformat/utils.c:613:20
#4 0x4db356 in open_input_file ffmpeg/fftools/ffmpeg_opt.c:1
Re: [FFmpeg-devel] [PATCH] avformat/aiffdec: AIFF fix in case of ANNO
On Wed, Jan 10, 2018 at 09:03:00AM +0200, Eduard Sinelnikov wrote: > Yes, the problem found from playing the file AIFF file you can download it > from: https://www.datafilehost.com/d/60337fcd thanks, i will apply the patch [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC 2018
On Tue, Jan 09, 2018 at 07:27:28PM +0100, Thilo Borgmann wrote: > Hi folks, > > yet again, the registration for Google Summer of Code 2018 has opened. > > Like in the previous years, we've setup an ideas page in our wiki: > https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2018 Would there be interrest in a project to write a QR code / barcode search & decode filter ? If yes, i may be intgerrested to mentor that. [...] -- 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: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/codecs: Add missing documentation for hwaccel_flags.
Ping? any comments? On 2018/1/2 13:59, Jun Zhao wrote: ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/codecs: Add missing documentation for hwaccel_flags.
On Tue, 2 Jan 2018 13:59:12 +0800
Jun Zhao wrote:
> From e030510864c28d4b17c8d1eb09ab00f274bf5dcc Mon Sep 17 00:00:00 2001
> From: Jun Zhao
> Date: Tue, 2 Jan 2018 13:55:29 +0800
> Subject: [PATCH] doc/codecs: Add missing documentation for hwaccel_flags.
>
> document the hwaccel_flags option for decoding.
>
> Signed-off-by: Jun Zhao
> ---
> doc/codecs.texi | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/doc/codecs.texi b/doc/codecs.texi
> index 7e20374334..190f03b293 100644
> --- a/doc/codecs.texi
> +++ b/doc/codecs.texi
> @@ -1254,6 +1254,33 @@ ffprobe -dump_separator "
> Maximum number of pixels per image. This value can be used to avoid out of
> memory failures due to large images.
>
> +@item hwaccel_flags @var{flags} (@emph{decoding,video})
> +Set hardware accelerated decoding flags. (if active)
> +
> +Possible values:
> +@table @samp
> +@item ignore_level
> +Ignore level, should be used for decoding even if the codec level used is
> unknown
> +or higher than the maximum supported level reported by the hardware driver.
> +
> +It's generally a good idea to pass this flag unless you have a specific
> +reason not to, as hardware tends to under-report supported levels.
> +@item allow_high_depth
> +Allow to output YUV pixel formats with a different chroma sampling than 4:2:0
> +and/or other than 8 bits per component
> +@item allow_profile_mismatch
This applies only to the legacy vdpau API. (The doxygen should probably
be updated about this.)
I'm not sure why stuff like this should be anywhere outside the doxygen
in the header files?
> +Attempt to decode anyway if hardware accelerated decoder's supported
> profiles do not
> +exactly match the stream.
> +
> +For example, this can be used to try to decode baseline profile H.264
> +streams in hardware - it will often succeed, because many streams marked
> +as baseline profile actually conform to constrained baseline profile.
> +
> +Warning: If the stream is actually not supported then the behaviour is
> +undefined, and may include returning entirely incorrect output
> +while indicating success.
> +@end table
> +
> @item apply_cropping @var{bool} (@emph{decoding,video})
> Enable cropping if cropping parameters are multiples of the required
> alignment for the left and top parameters. If the alignment is not met the
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vidstab: set bytesPerPixel only for packed formats.
On Wed, Jan 10, 2018 at 10:26:58AM +0530, Gyan Doshi wrote: > > > On 1/4/2018 5:25 PM, Gyan Doshi wrote: > > > >On 12/29/2017 8:38 AM, Michael Niedermayer wrote: > >>On Thu, Dec 28, 2017 at 12:50:00PM -0900, Lou Logan wrote: > >>>On Thu, Dec 28, 2017, at 11:51 AM, Michael Niedermayer wrote: > > who maintains vf_vidstabtransform.c ? > >>> > >>>Realistically, nobody. Ideally, should have been Georg Martius who is > >>>the original author of the filter and also of vid.stab itself. > >>>Consider CCing him at "martius at mis.mpg.de" or "georg.martius at > >>>web.de". > >> > >>ok, cc added > >> > >>Georg, do you want to maintain vf_vidstabtransform.c ? > >> > >>If not, who wants to maintain vf_vidstabtransform.c ? > >> > >>If noone then iam not sure who will test or apply this, i think many > >>dont have the dependancy installed ... > > > >I assume the author hasn't gotten back yet. Can anyone else test and apply > >this? > > Anyone? If noone else cares about maintaining this ... then there is one radical but simple solution ... post a patch that adds you to MAINTAINERs for the file. Anyone could object yes, but then that person should at least review and apply the vf_vidstabtransform.c patch [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vidstab: set bytesPerPixel only for packed formats.
On Thu, 11 Jan 2018 01:46:56 +0100 Michael Niedermayer wrote: > On Wed, Jan 10, 2018 at 10:26:58AM +0530, Gyan Doshi wrote: > > > > > > On 1/4/2018 5:25 PM, Gyan Doshi wrote: > > > > > >On 12/29/2017 8:38 AM, Michael Niedermayer wrote: > > >>On Thu, Dec 28, 2017 at 12:50:00PM -0900, Lou Logan wrote: > > >>>On Thu, Dec 28, 2017, at 11:51 AM, Michael Niedermayer wrote: > > > > who maintains vf_vidstabtransform.c ? > > >>> > > >>>Realistically, nobody. Ideally, should have been Georg Martius who is > > >>>the original author of the filter and also of vid.stab itself. > > >>>Consider CCing him at "martius at mis.mpg.de" or "georg.martius at > > >>>web.de". > > >> > > >>ok, cc added > > >> > > >>Georg, do you want to maintain vf_vidstabtransform.c ? > > >> > > >>If not, who wants to maintain vf_vidstabtransform.c ? > > >> > > >>If noone then iam not sure who will test or apply this, i think many > > >>dont have the dependancy installed ... > > > > > >I assume the author hasn't gotten back yet. Can anyone else test and apply > > >this? > > > > Anyone? > > If noone else cares about maintaining this ... > then there is one radical but simple solution ... > post a patch that adds you to MAINTAINERs for the file. > > Anyone could object yes, but then that person should at least review and apply > the vf_vidstabtransform.c patch Our development policy allows applying patches in absence of the maintainer. That said, our MAINTAINERs file is 100% useless. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC 2018
On Wed, Jan 10, 2018, at 3:30 PM, Michael Niedermayer wrote: > > Would there be interrest in a project to write a QR code / barcode > search & decode filter ? I've personally never scanned a QR code, but maybe I'm an outlier. Seems more like an OpenCV project to me. While we are throwing ideas around how about a documentation project? Instead of manually (not) updating the man files like we do now, automatically create and sync the majority, or at least the available options, from the built-in documentation with the ability to manually add additional information, examples, explanations, etc. I didn't think about how to implement something like this but I think Timothy Gu (CC-ing him) may have had some thoughts if I recall correctly (which I may not). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: Increase support for common encryption.
On Wed, Jan 10, 2018 at 1:51 PM, Michael Niedermayer
wrote:
> [...]
>
> This causes a crash:
>
> =
> ==4012==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x6020eb78 at pc 0x00a944aa bp 0x7ffcd481ce70 sp 0x7ffcd481ce68
> READ of size 8 at 0x6020eb78 thread T0
> #0 0xa944a9 in mov_free_encryption_index ffmpeg/libavformat/mov.c:6615:20
> #1 0xa6fb2b in mov_read_close ffmpeg/libavformat/mov.c:6693:13
> #2 0xa6d96f in mov_read_header ffmpeg/libavformat/mov.c:6867:13
> #3 0xc4a6ed in avformat_open_input ffmpeg/libavformat/utils.c:613:20
> #4 0x4db356 in open_input_file ffmpeg/fftools/ffmpeg_opt.c:1069:11
> #5 0x4da0e7 in open_files ffmpeg/fftools/ffmpeg_opt.c:3202:15
> #6 0x4d9d98 in ffmpeg_parse_options ffmpeg/fftools/ffmpeg_opt.c:3242:11
> #7 0x50e98c in main ffmpeg/fftools/ffmpeg.c:4813:11
> #8 0x7f9cf833cf44 in __libc_start_main
> /build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:287
> #9 0x420da5 in _start (ffmpeg/ffmpeg_g+0x420da5)
>
> 0x6020eb78 is located 4 bytes to the right of 4-byte region
> [0x6020eb70,0x6020eb74)
> allocated by thread T0 here:
> #0 0x4b126e in realloc (ffmpeg/ffmpeg_g+0x4b126e)
> #1 0x218bbfe in av_strdup ffmpeg/libavutil/mem.c:256:15
> #2 0x215eec1 in av_dict_set ffmpeg/libavutil/dict.c:87:22
> #3 0x215f6e2 in av_dict_set_int ffmpeg/libavutil/dict.c:153:12
> #4 0xa7644c in mov_read_ftyp ffmpeg/libavformat/mov.c:1109:5
> #5 0xa6b153 in mov_read_default ffmpeg/libavformat/mov.c:6327:23
> #6 0xa6c543 in mov_read_header ffmpeg/libavformat/mov.c:6865:20
> #7 0xc4a6ed in avformat_open_input ffmpeg/libavformat/utils.c:613:20
> #8 0x4db356 in open_input_file ffmpeg/fftools/ffmpeg_opt.c:1069:11
> #9 0x4da0e7 in open_files ffmpeg/fftools/ffmpeg_opt.c:3202:15
> #10 0x4d9d98 in ffmpeg_parse_options ffmpeg/fftools/ffmpeg_opt.c:3242:11
> #11 0x50e98c in main ffmpeg/fftools/ffmpeg.c:4813:11
> #12 0x7f9cf833cf44 in __libc_start_main
> /build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:287
>
> The input file should be here:
> https://bugs.chromium.org/p/chromium/issues/attachment?aid=177545
Fixed.
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many things microsoft did are stupid, but not doing something just because
> microsoft did it is even more stupid. If everything ms did were stupid they
> would be bankrupt already.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
From 5f6411a92569d13524485627fa68e62e8fd63e50 Mon Sep 17 00:00:00 2001
From: Jacob Trimble
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH] avformat/mov: Increase support for common encryption.
- Parse schm atom to get different encryption schemes.
- Allow senc atom to appear in track fragments.
- Allow 16-byte IVs.
- Allow constant IVs (specified in tenc).
- Allow only tenc to specify encryption (i.e. no senc/saiz/saio).
- Use sample descriptor to detect clear fragments.
This doesn't support:
- Different sample descriptor holding different encryption info.
- Only first sample descriptor can be encrypted.
- Encrypted sample groups (i.e. seig).
- Non-'cenc' encryption scheme when using -decryption_key.
This removes support for saio/saiz atoms, but it was incorrect before.
A follow-up change will add correct support for those.
Signed-off-by: Jacob Trimble
---
libavformat/isom.h | 20 +-
libavformat/mov.c | 432 ++---
tests/fate/mov.mak | 8 +
tests/ref/fate/mov-frag-encrypted | 57 +
tests/ref/fate/mov-tenc-only-encrypted | 57 +
5 files changed, 422 insertions(+), 152 deletions(-)
create mode 100644 tests/ref/fate/mov-frag-encrypted
create mode 100644 tests/ref/fate/mov-tenc-only-encrypted
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 65676fb0f5..3794b1f0fd 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -27,6 +27,7 @@
#include
#include
+#include "libavutil/encryption_info.h"
#include "libavutil/mastering_display_metadata.h"
#include "libavutil/spherical.h"
#include "libavutil/stereo3d.h"
@@ -108,12 +109,20 @@ typedef struct MOVSbgp {
unsigned int index;
} MOVSbgp;
+typedef struct MOVEncryptionIndex {
+// Individual encrypted samples. If there are no elements, then the default
+// settings will be used.
+unsigned int nb_encrypted_samples;
+AVEncryptionInfo **encrypted_samples;
+} MOVEncryptionIndex;
+
typedef struct MOVFragmentStreamInfo {
int id;
int64_t sidx_pts;
int64_t first_tfra_pts;
int64_t tfdt_dts;
int index_entry;
+MOVEncryptionIndex *encryption_index;
} MOVFragmentStreamInfo;
typedef struct MOVFragmentIndexItem {
@@ -214,15 +223,10 @@ typedef struct MOVStreamCo
Re: [FFmpeg-devel] [PATCH] doc/codecs: Add missing documentation for hwaccel_flags.
On 2018/1/11 8:45, wm4 wrote:
> On Tue, 2 Jan 2018 13:59:12 +0800
> Jun Zhao wrote:
>
>> From e030510864c28d4b17c8d1eb09ab00f274bf5dcc Mon Sep 17 00:00:00 2001
>> From: Jun Zhao
>> Date: Tue, 2 Jan 2018 13:55:29 +0800
>> Subject: [PATCH] doc/codecs: Add missing documentation for hwaccel_flags.
>>
>> document the hwaccel_flags option for decoding.
>>
>> Signed-off-by: Jun Zhao
>> ---
>> doc/codecs.texi | 27 +++
>> 1 file changed, 27 insertions(+)
>>
>> diff --git a/doc/codecs.texi b/doc/codecs.texi
>> index 7e20374334..190f03b293 100644
>> --- a/doc/codecs.texi
>> +++ b/doc/codecs.texi
>> @@ -1254,6 +1254,33 @@ ffprobe -dump_separator "
>> Maximum number of pixels per image. This value can be used to avoid out of
>> memory failures due to large images.
>>
>> +@item hwaccel_flags @var{flags} (@emph{decoding,video})
>> +Set hardware accelerated decoding flags. (if active)
>> +
>> +Possible values:
>> +@table @samp
>> +@item ignore_level
>> +Ignore level, should be used for decoding even if the codec level used is
>> unknown
>> +or higher than the maximum supported level reported by the hardware driver.
>> +
>> +It's generally a good idea to pass this flag unless you have a specific
>> +reason not to, as hardware tends to under-report supported levels.
>> +@item allow_high_depth
>> +Allow to output YUV pixel formats with a different chroma sampling than
>> 4:2:0
>> +and/or other than 8 bits per component
>> +@item allow_profile_mismatch
> This applies only to the legacy vdpau API. (The doxygen should probably
> be updated about this.)
I think VA-API decoder used the allow_profile_mismatch.
>
> I'm not sure why stuff like this should be anywhere outside the doxygen
> in the header files?
Now ffmpeg have a hwaccel_flags option, but this option didn't have a
docs in manpage,
so I think we can document this first.
>> +Attempt to decode anyway if hardware accelerated decoder's supported
>> profiles do not
>> +exactly match the stream.
>> +
>> +For example, this can be used to try to decode baseline profile H.264
>> +streams in hardware - it will often succeed, because many streams marked
>> +as baseline profile actually conform to constrained baseline profile.
>> +
>> +Warning: If the stream is actually not supported then the behaviour is
>> +undefined, and may include returning entirely incorrect output
>> +while indicating success.
>> +@end table
>> +
>> @item apply_cropping @var{bool} (@emph{decoding,video})
>> Enable cropping if cropping parameters are multiples of the required
>> alignment for the left and top parameters. If the alignment is not met the
> ___
> 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] doc/codecs: Add missing documentation for hwaccel_flags.
On Thu, 11 Jan 2018 09:11:08 +0800
Jun Zhao wrote:
> On 2018/1/11 8:45, wm4 wrote:
> > On Tue, 2 Jan 2018 13:59:12 +0800
> > Jun Zhao wrote:
> >
> >> From e030510864c28d4b17c8d1eb09ab00f274bf5dcc Mon Sep 17 00:00:00 2001
> >> From: Jun Zhao
> >> Date: Tue, 2 Jan 2018 13:55:29 +0800
> >> Subject: [PATCH] doc/codecs: Add missing documentation for hwaccel_flags.
> >>
> >> document the hwaccel_flags option for decoding.
> >>
> >> Signed-off-by: Jun Zhao
> >> ---
> >> doc/codecs.texi | 27 +++
> >> 1 file changed, 27 insertions(+)
> >>
> >> diff --git a/doc/codecs.texi b/doc/codecs.texi
> >> index 7e20374334..190f03b293 100644
> >> --- a/doc/codecs.texi
> >> +++ b/doc/codecs.texi
> >> @@ -1254,6 +1254,33 @@ ffprobe -dump_separator "
> >> Maximum number of pixels per image. This value can be used to avoid out of
> >> memory failures due to large images.
> >>
> >> +@item hwaccel_flags @var{flags} (@emph{decoding,video})
> >> +Set hardware accelerated decoding flags. (if active)
> >> +
> >> +Possible values:
> >> +@table @samp
> >> +@item ignore_level
> >> +Ignore level, should be used for decoding even if the codec level used is
> >> unknown
> >> +or higher than the maximum supported level reported by the hardware
> >> driver.
> >> +
> >> +It's generally a good idea to pass this flag unless you have a specific
> >> +reason not to, as hardware tends to under-report supported levels.
> >> +@item allow_high_depth
> >> +Allow to output YUV pixel formats with a different chroma sampling than
> >> 4:2:0
> >> +and/or other than 8 bits per component
> >> +@item allow_profile_mismatch
> > This applies only to the legacy vdpau API. (The doxygen should probably
> > be updated about this.)
> I think VA-API decoder used the allow_profile_mismatch.
I meant the allow_high_depth flag.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] http: cosmetics: reformat reconnect check for better readability
The condition was a bit too long, and most editors will break the line
and turn it into an unreadable mess. Move out some of the conditions.
This should not change the behavior.
---
libavformat/http.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 4806b1e59b..f1208fb123 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -1448,12 +1448,18 @@ static int http_read_stream(URLContext *h, uint8_t
*buf, int size)
return http_buf_read_compressed(h, buf, size);
#endif /* CONFIG_ZLIB */
read_ret = http_buf_read(h, buf, size);
-while ((read_ret < 0 && s->reconnect&& (!h->is_streamed
|| s->reconnect_streamed) && s->filesize > 0 && s->off < s->filesize)
-|| (read_ret == AVERROR_EOF && s->reconnect_at_eof && (!h->is_streamed
|| s->reconnect_streamed))) {
+while (read_ret < 0) {
uint64_t target = h->is_streamed ? 0 : s->off;
if (read_ret == AVERROR_EXIT)
-return read_ret;
+break;
+
+if (h->is_streamed && !s->reconnect_streamed)
+break;
+
+if (!(s->reconnect && s->filesize > 0 && s->off < s->filesize) &&
+!(s->reconnect_at_eof && read_ret == AVERROR_EOF))
+break;
if (reconnect_delay > s->reconnect_delay_max)
return AVERROR(EIO);
--
2.15.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/codecs: Add missing documentation for hwaccel_flags.
On 2018/1/11 9:26, wm4 wrote:
> On Thu, 11 Jan 2018 09:11:08 +0800
> Jun Zhao wrote:
>
>> On 2018/1/11 8:45, wm4 wrote:
>>> On Tue, 2 Jan 2018 13:59:12 +0800
>>> Jun Zhao wrote:
>>>
From e030510864c28d4b17c8d1eb09ab00f274bf5dcc Mon Sep 17 00:00:00 2001
From: Jun Zhao
Date: Tue, 2 Jan 2018 13:55:29 +0800
Subject: [PATCH] doc/codecs: Add missing documentation for hwaccel_flags.
document the hwaccel_flags option for decoding.
Signed-off-by: Jun Zhao
---
doc/codecs.texi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/doc/codecs.texi b/doc/codecs.texi
index 7e20374334..190f03b293 100644
--- a/doc/codecs.texi
+++ b/doc/codecs.texi
@@ -1254,6 +1254,33 @@ ffprobe -dump_separator "
Maximum number of pixels per image. This value can be used to avoid out of
memory failures due to large images.
+@item hwaccel_flags @var{flags} (@emph{decoding,video})
+Set hardware accelerated decoding flags. (if active)
+
+Possible values:
+@table @samp
+@item ignore_level
+Ignore level, should be used for decoding even if the codec level used is
unknown
+or higher than the maximum supported level reported by the hardware
driver.
+
+It's generally a good idea to pass this flag unless you have a specific
+reason not to, as hardware tends to under-report supported levels.
+@item allow_high_depth
+Allow to output YUV pixel formats with a different chroma sampling than
4:2:0
+and/or other than 8 bits per component
+@item allow_profile_mismatch
>>> This applies only to the legacy vdpau API. (The doxygen should probably
>>> be updated about this.)
>> I think VA-API decoder used the allow_profile_mismatch.
> I meant the allow_high_depth flag.
Got it， thanks the clarify.
> ___
> 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] Don't overwrite previously setup dimensions for all codecs
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Wednesday, January 10, 2018 10:18 PM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH] Don't overwrite previously setup
> dimensions for all codecs
>
> 2018-01-10 9:10 GMT+01:00 Zhong Li :
> > Currently a hacky way is used for some specific codecs such as
> > H264/VP6F/DXV.
>
> > Replace with a more generic way(an evolution based on a history commit
> > 9de9b828ef005dec37052548c195a6b4f18fc701 but reverted somehow)
>
> This commit was never part of FFmpeg.
IIUC, This commit was merged from Libav, checking the commit log of
cf7d3846fc865df47bd64f7d4d10bbedf9e3a17b:
Merge commit '9de9b828ef005dec37052548c195a6b4f18fc701'
* commit '9de9b828ef005dec37052548c195a6b4f18fc701':
lavc: don't overwrite display dimensions with coded dimensions.
lavc: extend / update the [coded_]{width,height} doxy
Conflicts:
libavcodec/avcodec.h
libavcodec/utils.c
The change to the w/h handling is not merged as it breaks lowres
Merged-by: Michael Niedermayer
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Don't overwrite previously setup dimensions for all codecs
On Thu, 11 Jan 2018 02:01:38 +
"Li, Zhong" wrote:
> IIUC, This commit was merged from Libav, checking the commit log of
> cf7d3846fc865df47bd64f7d4d10bbedf9e3a17b:
Yeah, but...
> Merge commit '9de9b828ef005dec37052548c195a6b4f18fc701'
>
> * commit '9de9b828ef005dec37052548c195a6b4f18fc701':
> lavc: don't overwrite display dimensions with coded dimensions.
> lavc: extend / update the [coded_]{width,height} doxy
>
> Conflicts:
> libavcodec/avcodec.h
> libavcodec/utils.c
>
> The change to the w/h handling is not merged as it breaks lowres
>
> Merged-by: Michael Niedermayer
This says this specific part was skipped. Apparently it broke lowres,
an obscure feature that probably nobody uses and that Libav removed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf/tcp.c: Free allocated client URLContext in case of error.
On Tue, Apr 11, 2017 at 08:05:02PM +0200, Stephan Holljes wrote:
> ---
>
> This version is rebased on Simon's tcp return fix.
>
> libavformat/tcp.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/tcp.c b/libavformat/tcp.c
> index 07b4ed9..f1a597d 100644
> --- a/libavformat/tcp.c
> +++ b/libavformat/tcp.c
> @@ -203,8 +203,10 @@ static int tcp_accept(URLContext *s, URLContext **c)
> return ret;
> cc = (*c)->priv_data;
> ret = ff_accept(sc->fd, sc->listen_timeout, s);
> -if (ret < 0)
> +if (ret < 0) {
> +ffurl_close(*c);
this should be ffurl_closep() to clear the freed pointer
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC 2018
2018-01-11 2:10 GMT+01:00 Lou Logan : > On Wed, Jan 10, 2018, at 3:30 PM, Michael Niedermayer wrote: >> >> Would there be interrest in a project to write a QR code / barcode >> search & decode filter ? > > I've personally never scanned a QR code, but maybe I'm an outlier. > Seems more like an OpenCV project to me. Any (audio-, video-, image-related) project that has mentor and student sounds interesting to me. > While we are throwing ideas around how about a documentation project? Were the GSoC rules concerning documentation projects changed? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Don't overwrite previously setup dimensions for all codecs
> > IIUC, This commit was merged from Libav, checking the commit log of
> cf7d3846fc865df47bd64f7d4d10bbedf9e3a17b:
>
> Yeah, but...
>
> > Merge commit '9de9b828ef005dec37052548c195a6b4f18fc701'
> >
> > * commit '9de9b828ef005dec37052548c195a6b4f18fc701':
> > lavc: don't overwrite display dimensions with coded dimensions.
> > lavc: extend / update the [coded_]{width,height} doxy
> >
> > Conflicts:
> > libavcodec/avcodec.h
> > libavcodec/utils.c
> >
> > The change to the w/h handling is not merged as it breaks lowres
> >
> > Merged-by: Michael Niedermayer
>
> This says this specific part was skipped. Apparently it broke lowres, an
> obscure feature that probably nobody uses and that Libav removed.
Yup... 9de9b82 was not merged as a whole.
I guess I am not the only one person who is confused why w/h are overwritten by
coded_w/coded_h here
(https://ffmpeg.org/pipermail/ffmpeg-devel/2013-March/140142.html )
For "lowres", is it still broken for H264/VP6F/DXV by current code?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Don't overwrite previously setup dimensions for all codecs
On Thu, 11 Jan 2018 05:34:07 +
"Li, Zhong" wrote:
> > > IIUC, This commit was merged from Libav, checking the commit log of
> > cf7d3846fc865df47bd64f7d4d10bbedf9e3a17b:
> >
> > Yeah, but...
> >
> > > Merge commit '9de9b828ef005dec37052548c195a6b4f18fc701'
> > >
> > > * commit '9de9b828ef005dec37052548c195a6b4f18fc701':
> > > lavc: don't overwrite display dimensions with coded dimensions.
> > > lavc: extend / update the [coded_]{width,height} doxy
> > >
> > > Conflicts:
> > > libavcodec/avcodec.h
> > > libavcodec/utils.c
> > >
> > > The change to the w/h handling is not merged as it breaks lowres
> > >
> > > Merged-by: Michael Niedermayer
> >
> > This says this specific part was skipped. Apparently it broke lowres, an
> > obscure feature that probably nobody uses and that Libav removed.
>
> Yup... 9de9b82 was not merged as a whole.
> I guess I am not the only one person who is confused why w/h are overwritten
> by coded_w/coded_h here
> (https://ffmpeg.org/pipermail/ffmpeg-devel/2013-March/140142.html )
> For "lowres", is it still broken for H264/VP6F/DXV by current code?
I don't know (from the mail above this might be more an API problem?),
but I'd prefer your patch over the current situation as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Don't overwrite previously setup dimensions for all codecs
2018-01-11 3:01 GMT+01:00 Li, Zhong : >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of Carl Eugen Hoyos >> Sent: Wednesday, January 10, 2018 10:18 PM >> To: FFmpeg development discussions and patches >> >> Subject: Re: [FFmpeg-devel] [PATCH] Don't overwrite previously setup >> dimensions for all codecs >> >> 2018-01-10 9:10 GMT+01:00 Zhong Li : >> > Currently a hacky way is used for some specific codecs such as >> > H264/VP6F/DXV. >> >> > Replace with a more generic way(an evolution based on a history commit >> > 9de9b828ef005dec37052548c195a6b4f18fc701 but reverted somehow) >> >> This commit was never part of FFmpeg. > > IIUC, This commit was merged from Libav But not the part you referenced in your original mail here. Would you like to also comment on Hendrik's question? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vidstab: set bytesPerPixel only for packed formats.
On 1/11/2018 6:16 AM, Michael Niedermayer wrote: Georg, do you want to maintain vf_vidstabtransform.c ? If not, who wants to maintain vf_vidstabtransform.c ? If noone then iam not sure who will test or apply this, i think many dont have the dependancy installed ... I assume the author hasn't gotten back yet. Can anyone else test and apply this? Anyone? If noone else cares about maintaining this ... then there is one radical but simple solution ... post a patch that adds you to MAINTAINERs for the file. Anyone could object yes, but then that person should at least review and apply the vf_vidstabtransform.c patch I have no interest or business maintaining the library wrappers. In the commit history for these files, I see Paul Mahol, Clément Bœsch and you as committers among those active. Timothy Gu has signed off as well, but I don't know if he's active. So, someone among the above could take a look? Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC 2018
On Wed, Jan 10, 2018, at 7:31 PM, Carl Eugen Hoyos wrote: > > Were the GSoC rules concerning documentation projects changed? I don't know. I haven't memorized the rules and haven't looked at them for several years. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] example/vaapi_transcode: Add a VA-API transcode example.
From b76a2f790814df326d7d93c54b14b3c8e74ab759 Mon Sep 17 00:00:00 2001
From: Jun Zhao
Date: Thu, 11 Jan 2018 15:00:30 +0800
Subject: [PATCH 2/2] example/vaapi_transcode: Add a VA-API transcode example.
Add VA-API transcoding example, useage like:
./vaapi_transcode input_stream h264_vaapi output_stream
Signed-off-by: Jun Zhao
Signed-off-by: Liu, Kaixuan
---
configure | 2 +
doc/examples/Makefile | 1 +
doc/examples/vaapi_transcode.c | 256 +
3 files changed, 259 insertions(+)
create mode 100644 doc/examples/vaapi_transcode.c
diff --git a/configure b/configure
index b8985ba542..6d08c0fbbb 100755
--- a/configure
+++ b/configure
@@ -1526,6 +1526,7 @@ EXAMPLE_LIST="
transcode_aac_example
transcoding_example
vaapi_encode_example
+vaapi_transcode_example
"
EXTERNAL_AUTODETECT_LIBRARY_LIST="
@@ -3319,6 +3320,7 @@ scaling_video_example_deps="avutil swscale"
transcode_aac_example_deps="avcodec avformat swresample"
transcoding_example_deps="avfilter avcodec avformat avutil"
vaapi_encode_example_deps="avcodec avutil"
+vaapi_transcode_example_deps="avcodec avformat avutil"
# EXTRALIBS_LIST
cpu_init_extralibs="pthreads_extralibs"
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index da5af36532..928ff306b3 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -20,6 +20,7 @@ EXAMPLES-$(CONFIG_SCALING_VIDEO_EXAMPLE) += scaling_video
EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += transcode_aac
EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE) += transcoding
EXAMPLES-$(CONFIG_VAAPI_ENCODE_EXAMPLE) += vaapi_encode
+EXAMPLES-$(CONFIG_VAAPI_TRANSCODE_EXAMPLE) += vaapi_transcode
EXAMPLES := $(EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)$(EXESUF))
EXAMPLES_G := $(EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)_g$(EXESUF))
diff --git a/doc/examples/vaapi_transcode.c b/doc/examples/vaapi_transcode.c
new file mode 100644
index 00..b92a387f2f
--- /dev/null
+++ b/doc/examples/vaapi_transcode.c
@@ -0,0 +1,256 @@
+/*
+ * Video Acceleration API (video transcoding) transcode sample
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * Intel VAAPI-accelerated transcoding example.
+ *
+ * @example vaapi_transcode.c
+ * This example shows how to do VAAPI-accelerated transcoding.
+ * Usage: vaapi_transcode input_stream h264_vaapi output_stream
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static AVFormatContext *ifmt_ctx = NULL;
+static AVBufferRef *hw_device_ctx = NULL;
+static AVCodecContext *decoder_ctx = NULL, *encoder_ctx = NULL;
+static int video_stream = -1;
+static FILE *fout;
+static int initialized = 0;
+
+static enum AVPixelFormat get_vaapi_format(AVCodecContext *ctx,
+ const enum AVPixelFormat *pix_fmts)
+{
+const enum AVPixelFormat *p;
+
+for (p = pix_fmts; *p != -1; p++) {
+if (*p == AV_PIX_FMT_VAAPI)
+return *p;
+}
+
+fprintf(stderr, "Failed to get vaapi pix format\n");
+return AV_PIX_FMT_NONE;
+}
+
+static int open_input_file(const char *filename)
+{
+int ret;
+AVCodec *decoder = NULL;
+AVStream *video = NULL;
+
+if ((ret = avformat_open_input(&ifmt_ctx, filename, NULL, NULL)) < 0) {
+fprintf(stderr, "Cannot open input file '%s', Error code: %s\n",
+filename, av_err2str(ret));
+return ret;
+}
+
+if ((ret = avformat_find_stream_info(ifmt_ctx, NULL)) < 0) {
+fprintf(stderr, "Cannot find input stream information. Error code:
%s\n",
+av_err2str(ret));
+return ret;
+}
+
+ret = av_find_best_stream(ifmt_ctx, AVMEDIA_TYPE_VIDEO, -1, -1, &decoder,
0);
+if (ret < 0) {
+fprintf(stderr, "Cannot find a video stream in the input file.\
+Error code: %s\n", av_err2str(ret));
+return ret;
+}
+video_stream = ret;
+
+if (!(decoder_ctx = avcodec_alloc_context3(decoder)))
+return AVERROR(ENOMEM);
+
+video = ifmt_ctx->streams[video_stream];
+if ((ret = avcodec_parameters_to_context(decoder_ctx, video->codecpar)) <
0) {
+fprintf(stderr, "avcodec_parameters_to_context error. Error code:
[FFmpeg-devel] [PATCH 1/2] examples/vaapi_encode: Remove redundancy check when free context.
From ef424745ce8d425859e9ca16dd9aca72297ed90a Mon Sep 17 00:00:00 2001 From: Jun Zhao Date: Thu, 11 Jan 2018 13:21:58 +0800 Subject: [PATCH 1/2] examples/vaapi_encode: Remove redundancy check when free context. avcodec_free_context have handle NULL pointer case, so caller doesn't need to check the NULL before call this function. Signe-off-by: Jun Zhao --- doc/examples/vaapi_encode.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/doc/examples/vaapi_encode.c b/doc/examples/vaapi_encode.c index f66a4a7c48..6425b1c98c 100644 --- a/doc/examples/vaapi_encode.c +++ b/doc/examples/vaapi_encode.c @@ -217,8 +217,7 @@ close: fclose(fout); av_frame_free(&sw_frame); av_frame_free(&hw_frame); -if (avctx) -avcodec_free_context(&avctx); +avcodec_free_context(&avctx); av_buffer_unref(&hw_device_ctx); return err; -- 2.14.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
