May 2015 - ffmpeg-devel - lists.ffmpeg.org

[PATCH] WebP native muxer bugfix: frames should have alpha blending off
by Urvang Joshi 14 Jul '15

14 Jul '15

All the frames that the native muxer gets are fully reconstructed frames, and they should not be alpha-blended with the previous frames. As per the WebP container spec https://developers.google.com/speed/webp/docs/riff_container#animation, ANMF chunk should specify blending method = do not blend (and disposal method = do not dispose). However, the native muxer was wrongly setting blending method = use alpha blending. This bug can be reproduced by converting a source with transparency (e.g. animated GIF with transparency) to an animated WebP, and viewing it with vwebp. --- libavformat/webpenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/webpenc.c b/libavformat/webpenc.c index 69270c6..1455cc7 100644 --- a/libavformat/webpenc.c +++ b/libavformat/webpenc.c @@ -137,7 +137,7 @@ static int flush(AVFormatContext *s, int trailer, int64_t pts) avio_wl24(s->pb, pts - w->last_pkt.pts); } else avio_wl24(s->pb, w->last_pkt.duration); - avio_w8(s->pb, 0); + avio_w8(s->pb, 2); // Do not dispose and do not blend. } avio_write(s->pb, w->last_pkt.data + skip, w->last_pkt.size - skip); av_free_packet(&w->last_pkt); -- 2.2.0.rc0.207.ga3a616c

3 7

[PATCH] oggparsedirac: check return value of init_get_bits
by Christopher Watkins 09 Jul '15

09 Jul '15

4 3

[PATCH] Support Ctrl+Break in ffmpeg.exe on Windows as if it was Ctrl+C
by Joe Wreschnig 30 Jun '15

30 Jun '15

On Windows, the Ctrl+Break key combination usually does what Ctrl+C does. It is more common for processes to send other processes Ctrl+Break rather than Ctrl+C, because sending Ctrl+C / SIGINT doesn't work if you started a child in a new process group. This patch makes ffmpeg.exe register what Windows calls a console control event handler, which allows it to intercept Ctrl+Break. It hands it off directly to the usual SIGINT/SIGTERM handler. The same function also processes closing the console window, mapping it to SIGTERM. Obviously, this is only enabled if compiling for a platform where SetConsoleCtrlHandler is available (i.e. modern Windows). (I've also submitted this as a ticket at https://ffmpeg.org/trac/ffmpeg/ticket/1463 but it was recommended I post it here also.)

5 17

[PATCH]lavf/img2: Only autodetect valid Quickdraw images
by Carl Eugen Hoyos 30 Jun '15

30 Jun '15

Hi! Attached patch improves the Quickdraw autodetection. Please comment, Carl Eugen

2 3

[PATCH 1/2] lavfi/ebur128: add support for smaller video sizes
by Marton Balint 27 Jun '15

27 Jun '15

Signed-off-by: Marton Balint <cus(a)passwd.hu> --- doc/filters.texi | 4 ++-- libavfilter/f_ebur128.c | 11 ++++++++--- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/doc/filters.texi b/doc/filters.texi index 53f4cb2..713989c 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -10146,8 +10146,8 @@ activated. Default is @code{0}. @item size Set the video size. This option is for video only. For the syntax of this -option, check the "Video size" section in the ffmpeg-utils manual. Default -and minimum resolution is @code{640x480}. +option, check the "Video size" section in the ffmpeg-utils manual. The default +resolution is @code{640x480}, the minimum is @code{480x102}. @item meter Set the EBU scale meter. Default is @code{9}. Common values are @code{9} and diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c index c18ae79..8780062 100644 --- a/libavfilter/f_ebur128.c +++ b/libavfilter/f_ebur128.c @@ -114,6 +114,7 @@ typedef struct { int scale_range; ///< the range of LU values according to the meter int y_zero_lu; ///< the y value (pixel position) for 0 LU int *y_line_ref; ///< y reference values for drawing the LU lines in the graph and the gauge + int line_step; ///< LU steps for drawn lines /* audio */ int nb_channels; ///< number of channels in the input @@ -257,9 +258,9 @@ static int config_video_output(AVFilterLink *outlink) AVFrame *outpicref; /* check if there is enough space to represent everything decently */ - if (ebur128->w < 640 || ebur128->h < 480) { + if (ebur128->w < 480 || ebur128->h < 102) { av_log(ctx, AV_LOG_ERROR, "Video size %dx%d is too small, " - "minimum size is 640x480\n", ebur128->w, ebur128->h); + "minimum size is 480x102\n", ebur128->w, ebur128->h); return AVERROR(EINVAL); } outlink->w = ebur128->w; @@ -285,6 +286,9 @@ static int config_video_output(AVFilterLink *outlink) ebur128->graph.w = ebur128->gauge.x - ebur128->graph.x - PAD; ebur128->graph.h = ebur128->gauge.h; + /* compute line step based on graph height and needed lines */ + ebur128->line_step = (ebur128->scale_range * 8 - 1) / (ebur128->graph.h) + 1; + /* graph and gauge share the LU-to-pixel code */ av_assert0(ebur128->graph.h == ebur128->gauge.h); @@ -309,8 +313,9 @@ static int config_video_output(AVFilterLink *outlink) for (i = ebur128->meter; i >= -ebur128->meter * 2; i--) { y = lu_to_y(ebur128, i); x = PAD + (i < 10 && i > -10) * 8; - ebur128->y_line_ref[y] = i; + ebur128->y_line_ref[y] = ((i % ebur128->line_step == 0) ? i : 0); y -= 4; // -4 to center vertically + if (i % ebur128->line_step == 0) drawtext(outpicref, x, y + ebur128->graph.y, FONT8, font_colors+3, "%c%d", i < 0 ? '-' : i > 0 ? '+' : ' ', FFABS(i)); } -- 2.1.2

4 6

[PATCH 1/2] api-flac-test: Fix stupid mistake
by Ludmila Glinskih 27 Jun '15

27 Jun '15

Was comparing 0 bytes in memcmp --- libavcodec/api-flac-test.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavcodec/api-flac-test.c b/libavcodec/api-flac-test.c index 5ca8e8f..1540da9 100644 --- a/libavcodec/api-flac-test.c +++ b/libavcodec/api-flac-test.c @@ -117,7 +117,6 @@ static int run_test(AVCodec *enc, AVCodec *dec, AVCodecContext *enc_ctx, AVFrame *in_frame, *out_frame; uint8_t *raw_in = NULL, *raw_out = NULL; int in_offset = 0, out_offset = 0; - int frame_data_size = 0; int result = 0; int got_output = 0; int i = 0; @@ -218,7 +217,7 @@ static int run_test(AVCodec *enc, AVCodec *dec, AVCodecContext *enc_ctx, av_free_packet(&enc_pkt); } - if (memcmp(raw_in, raw_out, frame_data_size * NUMBER_OF_FRAMES) != 0) + if (memcmp(raw_in, raw_out, out_frame->linesize[0] * NUMBER_OF_FRAMES) != 0) { av_log(NULL, AV_LOG_ERROR, "Output differs\n"); return 1; -- 1.9.1

3 5

Areas needing work
by Michael Niedermayer 21 Jun '15

21 Jun '15

Hi all There are various areas in the project that are not maintained as well as they should be, heres a certainly not comlpete list, dont hesitate to reply and add to it. If someone wants to pick something up and contribute that is VERY welcome * Post merge review&cleanup, changes merged from libav would benefit from people reviewing and MUCH MUCH more importantly also people actually caring about and taking responsibility not just dumping comments with the idea "someone" will fix it. Ideally each area would have a maintainer who takes care of it and keeps it in good nick. * fate clients we lack a armcc test, a real android test someone should take over haiku and sunos/solaris fate clients, my haiku VM just keeps crashing * our fate server lacks the ability to display a user specified release this makes the output look quite unwieldy Timothy was working on a rewrite * Paid maintainers a big problem is that we have areas in the codebase that have no maintainr or rather noone with sufficient time+will+abilty. It would help tremendiusly if maintainers could work full time on maintaining code instead of just a few hours in their free time * ffserver lacks a regression test code that is not tested will accumulate bugs. period there are people who use ffserver, they clearly like the lack of regression tests it seems as noone finds the need to look into changing that. * more people should help on https://trac.ffmpeg.org, like check that tickets contain all information needed to reproduce and ask the reporter to provide missing information, check if things are regressions, if they can be reproduced, bisect regressions or ask the reporter to bisect and help him if needed close tickets where there is not enough information to reproduce and the reporter doesnt react for months. ATM carl does all that and more but iam sure he wouldnt mind if more people would help him * Stipends and Sponsorship programs We do not have enough funds for basic things, for example OPW/Outreachy is twice a year and to participate we have to pay at least one stipend (about 6.5k USD). We participated in december 2014 and it allowed us to convert all remaining libmpcodecs filters to the native system. resulted in multiple new video filters and several block ciphers which are faster then all other tested implementations. For may 2015 we only way after the last minute managed to secure some funding so we are short of applicants now as for a long time ffmpeg was not listed as a participating org. * Decentralize Too many things are done and admined by me, iam doing security updates to the servers, doing the git merges, maintaining all releases, maintaining half the fate clients, submitting data to coverity and doing all the crap that noone else wants to do. Does the community care so little that they want me to be a single point of failure? We need people to take some of this over at least on the basis of a backup in case iam unavailable for whatever reason, and i think it should ideally be people who do not yet have their daily work shedule overflowing with ffmpeg work but better new volunteers. * Conferences / exhibitions, public stuff Theres a conference, linuxtag, fosdem, whatever, wherever in your local area and you think FFmpeg should be represented there ? Simple, go there and represent FFmpeg! unless you are too shy ... of course. FFmpeg is a large community of users and developers, the developers who managed the last stands/booths arent special, every FFmpeg developer and even Users who know ffmpeg a bit better who like can do this too. Also please add all conferences / exhibitions to https://trac.ffmpeg.org/wiki/Conferences You dont have time to help with any above or you prefer pretending that you dont, well, maybe you know someone else who could help with something, dont hesitate to ask them / forward this! please make sure to keep ffmpeg-devel in CC if you reply from ffmpeg-user -- 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

9 18

[RFC] DXVA2 decoding and FFmpeg
by Stefano Sabatini 16 Jun '15

16 Jun '15

Hi guys, I'm playing with DXVA2 hardware decoding on Windows, and these are my findings. DVXA2 decoding was enabled in avconv/ffmpeg through the commit: commit 35177ba77ff60a8b8839783f57e44bcc4214507a Author: Hendrik Leppkes <h.leppkes(a)gmail.com> Date: Tue Apr 22 15:22:53 2014 +0200 avconv: add support for DXVA2 decoding Signed-off-by: Anton Khirnov <anton(a)khirnov.net> DXVA2 decoding is enabled when a dxva2api.h header is found in the path. From my understanding the header is provided by VLC: http://download.videolan.org/pub/contrib/dxva2api.h (I suppose the header was created in order to make compilation work with MinGW). When compiling with MinGW from mingw.org I had to change the GetShellWindow call in the line: hr = IDirect3D9_CreateDevice(ctx->d3d9, adapter, D3DDEVTYPE_HAL, GetShellWindow(), D3DCREATE_SOFTWARE_VERTEXPROCESSING | D3DCREATE_MULTITHREADED | D3DCREATE_FPU_PRESERVE, &d3dpp, &ctx->d3d9device); to GetDesktopWindow in the ffmpeg_dxva2.c file. I applied the fix suggested here: http://ffmpeg.org/pipermail/libav-user/2014-December/007673.html Then I performed some tests with the command: ffmpeg -hwaccel dxva2 INPUT -threads 1 -f null - The -threads 1 option seems required or ffmpeg will fail with decoding errors. In the ffmpeg(1) manual I can read this big warning: Note that most acceleration methods are intended for playback and will not be faster than software decoding on modern CPUs. Additionally, ffmpeg will usually need to copy the decoded frames from the GPU memory into the system memory, resulting in further performance loss. This option is thus mainly useful for testing. I tested with several HW combinations, and I always find that pure software decoding is always several time faster than DXVA2 decoding. In some cases I got invalid output (same with VLC) which may be related to a problem in the graphics card or driver (a VIA VX900). On the other hand when testing with VLC I noticed better performances (in general, a significantly reduced usage of the CPU, usually of an order of 3), so I have to conclude that at least VLC is able to make good use of DXVA2 hardware acceleration. I'm aware that the need to copy GPU data back to the CPU memory as required by ffmpeg defeats the advantage (if any) of hardware decoding, especially given that multithreading decoding cannot be adopted with DXVA2. My questions are: There are some cases when DXVA2 (or in general HW decoding) can be used effectively in ffmpeg? Can you tell if there is something which could be improved in the current ffmpeg_dxva2.c implementation? (My guess is that this code is somehow based on the VLC code). Would it make sense to integrate DXVA2 decoding in ffplay.c, assuming it would be worth the effort, at least for testing/didactic purposes? Related resources: https://trac.ffmpeg.org/ticket/604 https://ffmpeg.org/pipermail/ffmpeg-user/2012-May/006600.html http://forum.doom9.org/showthread.php?t=170793 TIA for any comments. -- FFmpeg = Fostering and Fantastic Maxi Picky Erudite God

8 28

jpeg2000: unsupported marker 0xFF5F at pos 0x73
by Wolfgang Woehl 12 Jun '15

12 Jun '15

See fdfcde74_excerpt_000000-000023 (on ftp://upload.ffmpeg.org/MPlayer/incoming/ as suggested by ffplay). The dir contains a MXF (DCI specs) with 24 4K frames and a 1/4-sized proxy video of that segment. The source MXF is real-world and currently in distribution. It was apparently generated with a Clipster system and asdcp-info says http://pastebin.com/raw.php?i=FFnHrW6K about it. ffplay (3e0c78b as of today) says http://pastebin.com/raw.php?i=df5sJDth when trying to play the excerpt MXF and fails to generate frames -- essentially the same as for the source MXF. Yes, the console output is that garbled. Wolfgang

3 9

[PATCH] * mpegts demuxer should recognize private streams
by Wolfgang Lorenz 11 Jun '15

11 Jun '15

The patch addresses this problem: https://lists.ffmpeg.org/pipermail/libav-user/2014-September/007475.html What it does is this: * Except stream type 0x06 as a private stream. (AVMEDIA_TYPE_DATA, AV_CODEC_ID_NONE) (It was necessary to convince mpegts_set_stream_info(), that AV_CODEC_ID_NONE might be a valid codec id.) * Handle stream id 0xbd (private_stream_1). This stream uses PES headers, but needs no further parsing (as there is no codec defined). --- libavformat/mpegts.c | 39 ++++++++++++++++++++++++++------------- 1 file changed, 26 insertions(+), 13 deletions(-) diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c index aeb2335..4025bcf 100644 --- a/libavformat/mpegts.c +++ b/libavformat/mpegts.c @@ -689,6 +689,7 @@ static const StreamType ISO_types[] = { { 0x02, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_MPEG2VIDEO }, { 0x03, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_MP3 }, { 0x04, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_MP3 }, + { 0x06, AVMEDIA_TYPE_DATA, AV_CODEC_ID_NONE }, { 0x0f, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_AAC }, { 0x10, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_MPEG4 }, /* Makito encoder sets stream type 0x11 for AAC, @@ -756,13 +757,13 @@ static const StreamType DESC_types[] = { { 0 }, }; -static void mpegts_find_stream_type(AVStream *st, - uint32_t stream_type, - const StreamType *types) +static int mpegts_find_stream_type(AVStream *st, + uint32_t stream_type, + const StreamType *types) { if (avcodec_is_open(st->codec)) { av_log(NULL, AV_LOG_DEBUG, "cannot set stream info, codec is open\n"); - return; + return 0; } for (; types->stream_type; types++) @@ -770,8 +771,10 @@ static void mpegts_find_stream_type(AVStream *st, st->codec->codec_type = types->codec_type; st->codec->codec_id = types->codec_id; st->request_probe = 0; - return; + return 1; } + + return 0; } static int mpegts_set_stream_info(AVStream *st, PESContext *pes, @@ -779,6 +782,7 @@ static int mpegts_set_stream_info(AVStream *st, PESContext *pes, { int old_codec_type = st->codec->codec_type; int old_codec_id = st->codec->codec_id; + int new_codec_found; if (avcodec_is_open(st->codec)) { av_log(pes->stream, AV_LOG_DEBUG, "cannot set stream info, codec is open\n"); @@ -799,11 +803,12 @@ static int mpegts_set_stream_info(AVStream *st, PESContext *pes, st->codec->codec_tag = pes->stream_type; - mpegts_find_stream_type(st, pes->stream_type, ISO_types); + new_codec_found = mpegts_find_stream_type(st, pes->stream_type, ISO_types); if ((prog_reg_desc == AV_RL32("HDMV") || prog_reg_desc == AV_RL32("HDPR")) && - st->codec->codec_id == AV_CODEC_ID_NONE) { - mpegts_find_stream_type(st, pes->stream_type, HDMV_types); + st->codec->codec_id == AV_CODEC_ID_NONE && + !new_codec_found) { + new_codec_found = mpegts_find_stream_type(st, pes->stream_type, HDMV_types); if (pes->stream_type == 0x83) { // HDMV TrueHD streams also contain an AC3 coded version of the // audio track - add a second stream for this @@ -829,13 +834,19 @@ static int mpegts_set_stream_info(AVStream *st, PESContext *pes, sub_pes->sub_st = pes->sub_st = sub_st; } } - if (st->codec->codec_id == AV_CODEC_ID_NONE) - mpegts_find_stream_type(st, pes->stream_type, MISC_types); - if (st->codec->codec_id == AV_CODEC_ID_NONE) { + if (st->codec->codec_id == AV_CODEC_ID_NONE && + !new_codec_found) + new_codec_found = mpegts_find_stream_type(st, pes->stream_type, MISC_types); + if (st->codec->codec_id == AV_CODEC_ID_NONE && + !new_codec_found) { st->codec->codec_id = old_codec_id; st->codec->codec_type = old_codec_type; } - + if (new_codec_found && + st->codec->codec_id == AV_CODEC_ID_NONE && + st->codec->codec_type == AVMEDIA_TYPE_DATA) { + st->need_parsing = 0; + } return 0; } @@ -1036,7 +1047,9 @@ static int mpegts_push_data(MpegTSFilter *filter, code != 0x1ff && code != 0x1f2 && /* program_stream_directory, DSMCC_stream */ code != 0x1f8) { /* ITU-T Rec. H.222.1 type E stream */ pes->state = MPEGTS_PESHEADER; - if (pes->st->codec->codec_id == AV_CODEC_ID_NONE && !pes->st->request_probe) { + if (code == 0x1bd) { /* private_stream_1 */ + pes->st->need_parsing = 0; + } else if (pes->st->codec->codec_id == AV_CODEC_ID_NONE && !pes->st->request_probe) { av_log(pes->stream, AV_LOG_TRACE, "pid=%x stream_type=%x probing\n", pes->pid, -- 1.9.1

4 19