Re: [FFmpeg-devel] [PATCH] avcodec/tak: reset filter buffers
On 2/21/15, James Almer wrote: > On 21/02/15 3:47 PM, Paul B Mahol wrote: >> On 2/21/15, James Almer wrote: >>> On 21/02/15 8:49 AM, Paul B Mahol wrote: Have you measured performance drop before and after? >>> >>> filter_order 8 in decorrelate() >>> >>> Before >>> 903 decicycles in scalarproduct, 8388364 runs, 244 skips >>> After >>> 858 decicycles in scalarproduct, 8388215 runs, 393 skips >>> >>> >>> filter_order 24 in decode_subframe() >>> >>> Before >>> 993 decicycles in scalarproduct, 16776849 runs, 367 skips >>> After >>> 887 decicycles in scalarproduct, 16776783 runs, 433 skips >>> >> >> But what about other filter orders? > > filter order 12 in decode_subframe() > > Before > 963 decicycles in scalarproduct, 8388426 runs, 182 skips > After > 873 decicycles in scalarproduct, 8388410 runs, 198 skips > > > filter_order 8 in decode_subframe() > > Before > 900 decicycles in scalarproduct, 4194020 runs, 284 skips > After > 858 decicycles in scalarproduct, 4194198 runs, 106 skips > > > filter order 4 in decode_subframe() > > Before > 827 decicycles in scalarproduct, 1048561 runs, 15 skips > After > 876 decicycles in scalarproduct, 1048556 runs, 20 skips > > > Seems like only filter_order 4 is slower. I could leave the C code for that > one > case if you prefer. I'm more afraid of overhead that memset() does. Feel free to apply patch. > ___ > 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] avcodec/tak: reset filter buffers
Hi, 2015-02-22 13:13 GMT+01:00 Paul B Mahol : > I'm more afraid of overhead that memset() does. A single AVZERO128U (or whatever that is called) might do it. wmalossless could use the same, but for both tak and it, I bet that's mostly setup, ie quite less called. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/rtsp: punch holes again after pause
On Sun, Feb 22, 2015 at 07:59:55AM +0100, Gilles Chanteperdrix wrote: > When a client behind a NAT issues a pause command, and stay paused for a > long time, the router may stop the RTP/RTCP port redirection. Resend the > hole punching packets after each PLAY command to cause the router to > restart the port redirection in that case. > > Signed-off-by: Gilles Chanteperdrix > --- > libavformat/rtspdec.c | 4 > 1 file changed, 4 insertions(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter:vf_thumbnail.c: Fix bug in buffer handling for RGB width
On Wed, Feb 18, 2015 at 06:20:54PM -0800, Chris Kennedy wrote: > More details attached, debug level and gdb backtrace. Hopefully this > helps, and I will work on getting a file I can share showing the issue. > > Thanks > [...] > ffmpeg -nostdin -nostats -analyzeduration 774552000 -threads 1 -i input.avi > -threads 1 -vsync 0 -q:v 0 -an -vf trim=300:776,fps=fps=29.97,thumbnail=178 > video%02d.jpg > Returned: [Parsed_thumbnail_2 @ 0x2f4cac0] frame id #128 > (pts_time=351.785118) selected from a set of 178 images > WIP, backtrace and full debug ready, I am going to hunt now for the issue and > try to fix it: > Starting program: /opt/ffmpeg/ffmpeg -nostdin -nostats -analyzeduration > 774552000 -threads 1 -i input.avi -threads 1 -vsync 0 -q:v 0 -an -vf > trim=300:776,fps=fps=29.97,thumbnail=178 -loglevel debug video%02d.jpg > [Thread debugging using libthread_db enabled] > ffmpeg version n2.5.1-22-g26e5e17 Copyright (c) 2000-2014 the FFmpeg > developers > built on Feb 17 2015 15:59:56 with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-11) > configuration: --prefix=/usr --disable-outdev=sdl --disable-ffplay > --disable-ffserver --enable-gpl --enable-nonfree --disable-shared > --disable-optimizations --disable-stripping --enable-debug=3 --enable-static > --disable-mmx --disable-mmxext --disable-ssse3 --extra-cflags='-O0 > -fno-inline' Weird configuration... You can just use ffmpeg_g. And use runtime -cpuflags instead of disabling ASM at configure. > libavutil 54. 15.100 / 54. 15.100 > libavcodec 56. 13.100 / 56. 13.100 > libavformat 56. 15.102 / 56. 15.102 > libavdevice 56. 3.100 / 56. 3.100 > libavfilter 5. 2.103 / 5. 2.103 > libswscale 3. 1.101 / 3. 1.101 > libswresample 1. 1.100 / 1. 1.100 > libpostproc 53. 3.100 / 53. 3.100 > Splitting the commandline. > Reading option '-nostdin' ... matched as option 'stdin' (enable or disable > interaction on standard input) with argument 0. > Reading option '-nostats' ... matched as option 'stats' (print progress > report during encoding) with argument 0. > Reading option '-analyzeduration' ... matched as AVOption 'analyzeduration' > with argument '774552000'. > Reading option '-threads' ... matched as AVOption 'threads' with argument '1'. > Reading option '-i' ... matched as input file with argument 'input.avi'. > Reading option '-threads' ... matched as AVOption 'threads' with argument '1'. > Reading option '-vsync' ... matched as option 'vsync' (video sync method) > with argument '0'. > Reading option '-q:v' ... matched as option 'q' (use fixed quality scale > (VBR)) with argument '0'. > Reading option '-an' ... matched as option 'an' (disable audio) with argument > '1'. > Reading option '-vf' ... matched as option 'vf' (set video filters) with > argument 'trim=300:776,fps=fps=29.97,thumbnail=178'. > Reading option '-loglevel' ... matched as option 'loglevel' (set logging > level) with argument 'debug'. > Reading option 'video%02d.jpg' ... matched as output file. > Finished splitting the commandline. > Parsing a group of options: global . > Applying option nostdin (enable or disable interaction on standard input) > with argument 0. > Applying option nostats (print progress report during encoding) with argument > 0. > Applying option vsync (video sync method) with argument 0. > Applying option loglevel (set logging level) with argument debug. > Successfully parsed a group of options. > Parsing a group of options: input file input.avi. > Successfully parsed a group of options. > Opening an input file: input.avi. > [avi @ 0x1c8d9b0] Format avi probed with size=2048 and score=100 > [avi @ 0x1c8e330] use odml:1 > [avi @ 0x1c8d9b0] Before avformat_find_stream_info() pos: 9986 bytes > read:1906544 seeks:4 > [avi @ 0x1c8d9b0] All info found > rfps: 29.67 0.013653 > Last message repeated 1 times > rfps: 29.75 0.007182 > Last message repeated 1 times > rfps: 29.83 0.002772 > Last message repeated 1 times > rfps: 29.916667 0.000422 > Last message repeated 1 times > rfps: 30.00 0.000133 > Last message repeated 1 times > rfps: 60.00 0.000533 > Last message repeated 1 times > rfps: 120.00 0.002132 > Last message repeated 1 times > rfps: 240.00 0.008528 > Last message repeated 1 times > rfps: 29.970030 0.00 > rfps: 59.940060 0.00 > [avi @ 0x1c8d9b0] After avformat_find_stream_info() pos: 334549 bytes > read:2201456 seeks:4 frames:97 > Input #0, avi, from 'input.avi': > Metadata: > encoder : Lavf52.62.0 > Duration: 00:25:49.10, start: 0.00, bitrate: 1644 kb/s > Stream #0:0, 41, 1001/3: Video: mpeg4 (Simple Profile) (XVID / > 0x44495658), yuv420p(left), 624x480 [SAR 1:1 DAR 13:10], 1/3, 1439 kb/s, > 29.97 fps, 29.97 tbr, 29.97 tbn, 30k tbc > Stream #0:1, 56, 3/125: Audio: mp3 (U[0][0][0] / 0x0055), 48000 Hz, stereo, > s16p, 192 kb/s > Successfully opened the file. > Parsing a group of options: output file video%02d.jpg. > Applying option q:v (use fixed quality scale (VBR)) with argument 0. > Applying option an (di
Re: [FFmpeg-devel] [PATCH] avcodec/tak: reset filter buffers
On 22/02/15 9:22 AM, Christophe Gisquet wrote: > Hi, > > 2015-02-22 13:13 GMT+01:00 Paul B Mahol : >> I'm more afraid of overhead that memset() does. > > A single AVZERO128U (or whatever that is called) might do it. That's a good idea. Although there are no AV_ZEROU macros so we'll have to add them. > > wmalossless could use the same, but for both tak and it, I bet that's > mostly setup, ie quite less called. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/tak: reset filter buffers
On 22/02/15 9:13 AM, Paul B Mahol wrote: > On 2/21/15, James Almer wrote: >> On 21/02/15 3:47 PM, Paul B Mahol wrote: >>> On 2/21/15, James Almer wrote: On 21/02/15 8:49 AM, Paul B Mahol wrote: > Have you measured performance drop before and after? filter_order 8 in decorrelate() Before 903 decicycles in scalarproduct, 8388364 runs, 244 skips After 858 decicycles in scalarproduct, 8388215 runs, 393 skips filter_order 24 in decode_subframe() Before 993 decicycles in scalarproduct, 16776849 runs, 367 skips After 887 decicycles in scalarproduct, 16776783 runs, 433 skips >>> >>> But what about other filter orders? >> >> filter order 12 in decode_subframe() >> >> Before >> 963 decicycles in scalarproduct, 8388426 runs, 182 skips >> After >> 873 decicycles in scalarproduct, 8388410 runs, 198 skips >> >> >> filter_order 8 in decode_subframe() >> >> Before >> 900 decicycles in scalarproduct, 4194020 runs, 284 skips >> After >> 858 decicycles in scalarproduct, 4194198 runs, 106 skips >> >> >> filter order 4 in decode_subframe() >> >> Before >> 827 decicycles in scalarproduct, 1048561 runs, 15 skips >> After >> 876 decicycles in scalarproduct, 1048556 runs, 20 skips >> >> >> Seems like only filter_order 4 is slower. I could leave the C code for that >> one >> case if you prefer. > > I'm more afraid of overhead that memset() does. > > Feel free to apply patch. Pushed a version Christophe wrote some time ago that uses AV_ZERO instead of memset(), so that should not be a problem now. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/tak: remove unnecessary calls to emms_c()
On 21/02/15 9:18 AM, Paul B Mahol wrote: > On 2/21/15, James Almer wrote: >> It's already called by scalarproduct_int16 if required. >> >> Signed-off-by: James Almer >> --- >> libavcodec/takdec.c | 3 --- >> 1 file changed, 3 deletions(-) >> >> diff --git a/libavcodec/takdec.c b/libavcodec/takdec.c >> index 0f808e0..77170b5 100644 >> --- a/libavcodec/takdec.c >> +++ b/libavcodec/takdec.c >> @@ -480,8 +480,6 @@ static int decode_subframe(TAKDecContext *s, int32_t >> *decoded, >> memcpy(s->residues, &s->residues[y], 2 * filter_order); >> } >> >> -emms_c(); >> - >> return 0; >> } >> >> @@ -641,7 +639,6 @@ static int decorrelate(TAKDecContext *s, int c1, int c2, >> int length) >> memcpy(s->residues, &s->residues[tmp], 2 * filter_order); >> } >> >> -emms_c(); >> break; >> } >> } >> -- >> 2.3.0 > > Should be OK if no crashes happens. The new version of the previous patch i applied uses AV_ZERO128, which may use mmx code, so better keep these in place. Patch dropped. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/tak: clarify the size of residues buffer
On 21/02/15 9:32 AM, Paul B Mahol wrote:
> On 2/21/15, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> At least this is what i interpreted 544 meant. This patch can be discarded
>> otherwise.
>>
>> libavcodec/takdec.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/takdec.c b/libavcodec/takdec.c
>> index 77170b5..059fdaa 100644
>> --- a/libavcodec/takdec.c
>> +++ b/libavcodec/takdec.c
>> @@ -69,7 +69,7 @@ typedef struct TAKDecContext {
>>
>> int8_t coding_mode[128];
>> DECLARE_ALIGNED(16, int16_t, filter)[MAX_PREDICTORS];
>> -DECLARE_ALIGNED(16, int16_t, residues)[544];
>> +DECLARE_ALIGNED(16, int16_t, residues)[MAX_PREDICTORS * 2 +
>> FF_INPUT_BUFFER_PADDING_SIZE];
>> } TAKDecContext;
>>
>> static const int8_t mc_dmodes[] = { 1, 3, 4, 6, };
>> --
>> 2.3.0
>
> AFAIK If FF_INPUT_BUFFER_PADDING_SIZE changes decoder will no longer work.
Ok, in that case lets drop this patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] avcodec/a64multienc: use av_frame_ref instead of copying the frame
Hi,
using the a64multienc encoder currently results in a crash due to a
double free.
This seems to be broken since [1].
Attached patch fixes this.
Best regards,
Andreas
1:
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=13e9cc9ce0646ba8e31d837b5e6372ec80fa7a73
>From 78b5bdd67c72fbb316c3050d0809a3012ff04c4a Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Sun, 22 Feb 2015 20:43:30 +0100
Subject: [PATCH 1/4] avcodec/a64multienc: use av_frame_ref instead of copying
the frame
This fixes freeing the frame buffer twice on cleanup leading to a crash.
---
libavcodec/a64multienc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/a64multienc.c b/libavcodec/a64multienc.c
index 6438c27..dfb4414 100644
--- a/libavcodec/a64multienc.c
+++ b/libavcodec/a64multienc.c
@@ -317,7 +317,9 @@ static int a64multi_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
} else {
/* fill up mc_meta_charset with data until lifetime exceeds */
if (c->mc_frame_counter < c->mc_lifetime) {
-*p = *pict;
+ret = av_frame_ref(p, pict);
+if (ret < 0)
+return ret;
p->pict_type = AV_PICTURE_TYPE_I;
p->key_frame = 1;
to_meta_with_crop(avctx, p, meta + 32000 * c->mc_frame_counter);
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] avcodec/a64multienc: don't set incorrect packet size
Hi,
increasing the packet size without enlarging the packet buffer can't be
correct...
This seems to be broken since [1].
Best regards,
Andreas
1:
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=7340008f18dc7d1557efbf5a331c9452913f7f61
>From c1bc01a84654df6a0e9ec4ea62f95920bfb80e32 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Sun, 22 Feb 2015 20:45:19 +0100
Subject: [PATCH 2/4] avcodec/a64multienc: don't set incorrect packet size
This fixes invalid reads of the packet buffer in av_dup_packet.
---
libavcodec/a64multienc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavcodec/a64multienc.c b/libavcodec/a64multienc.c
index dfb4414..35080af 100644
--- a/libavcodec/a64multienc.c
+++ b/libavcodec/a64multienc.c
@@ -371,14 +371,12 @@ static int a64multi_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
}
/* advance pointers */
buf += screen_size;
-req_size += screen_size;
/* compress and copy colram to buf */
if (c->mc_use_5col) {
a64_compress_colram(buf, charmap, colram);
/* advance pointers */
buf += colram_size;
-req_size += colram_size;
}
/* advance to next charmap */
@@ -395,7 +393,6 @@ static int a64multi_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
pkt->pts = pkt->dts = c->next_pts;
c->next_pts = AV_NOPTS_VALUE;
-pkt->size = req_size;
pkt->flags |= AV_PKT_FLAG_KEY;
*got_packet = !!req_size;
}
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] avcodec/a64multienc: fix use of uninitialised values in, to_meta_with_crop
Hi,
this patch fixes another case of using uninitialized values.
Best regards,
Andreas
>From 469ebfec4f33b807d7e27abfc38d8f392481b792 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Sun, 22 Feb 2015 20:48:38 +0100
Subject: [PATCH 4/4] avcodec/a64multienc: fix use of uninitialized values in
to_meta_with_crop
Averaging over 2 pixels doesn't work correctly for the last pixel, because the
rest of the buffer is not initialized.
---
libavcodec/a64multienc.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavcodec/a64multienc.c b/libavcodec/a64multienc.c
index 31b97c0..dbf1d1f 100644
--- a/libavcodec/a64multienc.c
+++ b/libavcodec/a64multienc.c
@@ -78,9 +78,13 @@ static void to_meta_with_crop(AVCodecContext *avctx, AVFrame *p, int *dest)
for (y = blocky; y < blocky + 8 && y < C64YRES; y++) {
for (x = blockx; x < blockx + 8 && x < C64XRES; x += 2) {
if(x < width && y < height) {
-/* build average over 2 pixels */
-luma = (src[(x + 0 + y * p->linesize[0])] +
-src[(x + 1 + y * p->linesize[0])]) / 2;
+if (x + 1 < width) {
+/* build average over 2 pixels */
+luma = (src[(x + 0 + y * p->linesize[0])] +
+src[(x + 1 + y * p->linesize[0])]) / 2;
+} else {
+luma = src[(x + y * p->linesize[0])];
+}
/* write blocks as linear data now so they are suitable for elbg */
dest[0] = luma;
}
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] avcodec/a64multienc: initialize mc_meta_charset to zero
Hi, without this patch valgrind complains loudly about 'Conditional jump or move depends on uninitialised value(s)' in avpriv_do_elbg. (This patch applies to libav after cherry-picking [1].) Best regards, Andreas 1: https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=e4c180c05ac9aed33c16ee6e89581a9f2f7b890f >From 12e0e8db0a132be6bfef7268550b200955289749 Mon Sep 17 00:00:00 2001 From: Andreas Cadhalpun Date: Sun, 22 Feb 2015 20:47:50 +0100 Subject: [PATCH 3/4] avcodec/a64multienc: initialize mc_meta_charset to zero This fixes the use of uninitialized values in avpriv_do_elbg. --- libavcodec/a64multienc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/a64multienc.c b/libavcodec/a64multienc.c index 35080af..31b97c0 100644 --- a/libavcodec/a64multienc.c +++ b/libavcodec/a64multienc.c @@ -220,7 +220,7 @@ static av_cold int a64multi_encode_init(AVCodecContext *avctx) a64_palette[mc_colors[a]][2] * 0.11; } -if (!(c->mc_meta_charset = av_malloc_array(c->mc_lifetime, 32000 * sizeof(int))) || +if (!(c->mc_meta_charset = av_mallocz_array(c->mc_lifetime, 32000 * sizeof(int))) || !(c->mc_best_cb = av_malloc(CHARSET_CHARS * 32 * sizeof(int))) || !(c->mc_charmap = av_mallocz_array(c->mc_lifetime, 1000 * sizeof(int))) || !(c->mc_colram= av_mallocz(CHARSET_CHARS * sizeof(uint8_t))) || -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 1/4] avcodec/a64multienc: use av_frame_ref instead of copying the frame
On 22.02.2015 23:23, Luca Barbato wrote: On 22/02/15 21:56, Andreas Cadhalpun wrote: using the a64multienc encoder currently results in a crash due to a double free. This seems to be broken since [1]. I would expect that an unref would be needed somewhere, do we have a fate test for it? The unref 'av_frame_free(&avctx->coded_frame)' was already added as part of commit 13e9cc9. This is exactly what causes the crash. I doubt that there is a fate test for this, because that would have revealed the crash. For testing purposes you can use: avconv -y -i ./tests/reference.pnm -c:v a64multi -f avi /dev/null Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] MPEG-4 audio/video file generation API
Dear ffmpeg coderz, I work for Laoviland Experience, a digital innovation start-up based in Montpellier, France. We develop creative software for inspiration and automation of graphical creations.(see our website www.laoviland.com for additional info). We are searching for specific technical skills for our tool that generates movies from visual routes on digital paintings. What we need is to integrate inside our soft an API that would be able to create and write a movie file in standard MP4 format (MPEG-4 Part 14) with a video track (AVC) and an audio track (AAC). The input of that solution would be the video frames, the sound samples and some movie parameters (bit rate, resolution, and so on). The output would be the MP4 video file. Presently, we can make a video (using the CImg library) but without any sound muxed, unless we use an external tool (like ffmpeg), but that's not what we want. We want to integrate each and every step of the creation right in our soft, getting only one standalone executable, statically compiled under Linux, Windows and MacOS (we use the Qt 5 framework). In our researchs on the existing solutions, we found the ffmpeg library and this mailing list. Several libraries exist to fit our needs, but none is thoroughly documented, and as we need that feature in a short term and our manpower is limited, I launch this call to anyone who could match the interests and skills to achieve such a mission. Feel free to contact me back (me or my director, jt.tchou...@laoviland.com), for any additional information. Best regards, __ Boris JAULMES Junior software developer Laoviland Experience ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] MPEG-4 audio/video file generation API
On 22 February 2015 at 23:08, Boris Jaulmes wrote: > Dear ffmpeg coderz, Yes the "coderz" got your email the first time. I am sure all the ffmpeg rockstar devs will be emailing you soon. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] avcodec/a64multienc: don't set incorrect packet size
On Sun, Feb 22, 2015 at 09:58:09PM +0100, Andreas Cadhalpun wrote: > Hi, > > increasing the packet size without enlarging the packet buffer can't > be correct... > This seems to be broken since [1]. > > Best regards, > Andreas > > 1: > https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=7340008f18dc7d1557efbf5a331c9452913f7f61 > a64multienc.c |3 --- > 1 file changed, 3 deletions(-) > c55a02cc996cda0747e83d2ecc07c6c40c986f03 > 0002-avcodec-a64multienc-don-t-set-incorrect-packet-size.patch > From c1bc01a84654df6a0e9ec4ea62f95920bfb80e32 Mon Sep 17 00:00:00 2001 > From: Andreas Cadhalpun > Date: Sun, 22 Feb 2015 20:45:19 +0100 > Subject: [PATCH 2/4] avcodec/a64multienc: don't set incorrect packet size > > This fixes invalid reads of the packet buffer in av_dup_packet. This leaves the packet size wrong for mc_use_5col = 0 The quoted commit broke the size calculation quite completely ill try to fix it [...] -- 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. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Clarify documentation for fade duration
Hi!
I believe attached patch improves the fade documentation.
Please comment, Carl Eugen
diff --git a/doc/filters.texi b/doc/filters.texi
index 191b52f..d394aec 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4503,7 +4503,8 @@ The number of seconds for which the fade effect has to
last. At the end of the
fade-in effect the output video will have the same intensity as the input
video,
at the end of the fade-out transition the output video will be filled with the
selected @option{color}.
-If both duration and nb_frames are specified, duration is used. Default is 0.
+If both duration and nb_frames are specified, duration is used. Default is 0
+(nb_frames is used by default).
@item color, c
Specify the color of the fade. Default is "black".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/a64multienc: use av_frame_ref instead of copying the frame
On Sun, Feb 22, 2015 at 09:56:52PM +0100, Andreas Cadhalpun wrote:
> Hi,
>
> using the a64multienc encoder currently results in a crash due to a
> double free.
> This seems to be broken since [1].
>
> Attached patch fixes this.
>
> Best regards,
> Andreas
>
> 1:
> https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=13e9cc9ce0646ba8e31d837b5e6372ec80fa7a73
> a64multienc.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
> e8ab47bcbf64c450f707b490b3f4f569dbe8af4f
> 0001-avcodec-a64multienc-use-av_frame_ref-instead-of-copy.patch
> From 78b5bdd67c72fbb316c3050d0809a3012ff04c4a Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun
> Date: Sun, 22 Feb 2015 20:43:30 +0100
> Subject: [PATCH 1/4] avcodec/a64multienc: use av_frame_ref instead of copying
> the frame
>
> This fixes freeing the frame buffer twice on cleanup leading to a crash.
> ---
> libavcodec/a64multienc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/a64multienc.c b/libavcodec/a64multienc.c
> index 6438c27..dfb4414 100644
> --- a/libavcodec/a64multienc.c
> +++ b/libavcodec/a64multienc.c
> @@ -317,7 +317,9 @@ static int a64multi_encode_frame(AVCodecContext *avctx,
> AVPacket *pkt,
> } else {
> /* fill up mc_meta_charset with data until lifetime exceeds */
> if (c->mc_frame_counter < c->mc_lifetime) {
> -*p = *pict;
> +ret = av_frame_ref(p, pict);
> +if (ret < 0)
> +return ret;
I suspect this leaves a memleak, ill push it anyway as it allows
regression testing the more complex subsequent fix
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/a64multienc: fix use of uninitialised values in, to_meta_with_crop
On Sun, Feb 22, 2015 at 09:58:54PM +0100, Andreas Cadhalpun wrote: > Hi, > > this patch fixes another case of using uninitialized values. > > Best regards, > Andreas > a64multienc.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > 839c039050a554b3cee5fb98b0168c87632f4c90 > 0004-avcodec-a64multienc-fix-use-of-uninitialized-values-.patch > From 469ebfec4f33b807d7e27abfc38d8f392481b792 Mon Sep 17 00:00:00 2001 > From: Andreas Cadhalpun > Date: Sun, 22 Feb 2015 20:48:38 +0100 > Subject: [PATCH 4/4] avcodec/a64multienc: fix use of uninitialized values in > to_meta_with_crop > > Averaging over 2 pixels doesn't work correctly for the last pixel, because the > rest of the buffer is not initialized. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avcodec/a64multienc: initialize mc_meta_charset to zero
On Sun, Feb 22, 2015 at 09:58:39PM +0100, Andreas Cadhalpun wrote: > Hi, > > without this patch valgrind complains loudly about 'Conditional jump > or move depends on uninitialised value(s)' in avpriv_do_elbg. > > (This patch applies to libav after cherry-picking [1].) > > Best regards, > Andreas > > > 1: > https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=e4c180c05ac9aed33c16ee6e89581a9f2f7b890f > a64multienc.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > 6b68722a0e9f27f7ec4267a6222744114f81c879 > 0003-avcodec-a64multienc-initialize-mc_meta_charset-to-ze.patch > From 12e0e8db0a132be6bfef7268550b200955289749 Mon Sep 17 00:00:00 2001 > From: Andreas Cadhalpun > Date: Sun, 22 Feb 2015 20:47:50 +0100 > Subject: [PATCH 3/4] avcodec/a64multienc: initialize mc_meta_charset to zero > > This fixes the use of uninitialized values in avpriv_do_elbg. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Fix invalid memory accesses using the fade filter
Hi!
Attached patch fixes a crash with the following command line:
$ ffmpeg -loop 1 -i fate-suite/lena.pnm -vf format=yuva420p,fade -f null -
Please comment, Carl Eugen
diff --git a/libavfilter/vf_fade.c b/libavfilter/vf_fade.c
index 80ce75d..5d012af 100644
--- a/libavfilter/vf_fade.c
+++ b/libavfilter/vf_fade.c
@@ -203,7 +203,10 @@ static int filter_slice_luma(AVFilterContext *ctx, void
*arg, int jobnr,
for (i = slice_start; i < slice_end; i++) {
uint8_t *p = frame->data[0] + i * frame->linesize[0];
+int width = av_pix_fmt_desc_get(frame->format)->flags &
AV_PIX_FMT_FLAG_PLANAR ?
+frame->width :
+frame->width * s->bpp;
-for (j = 0; j < frame->width * s->bpp; j++) {
+for (j = 0; j < width; j++) {
/* s->factor is using 16 lower-order bits for decimal
* places. 32768 = 1 << 15, it is an integer representation
* of 0.5 and is for rounding. */
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
