[issue2113] SWScale, does not convert from YUV444 to RGB565
Pavel i-love-s...@yandex.ru added the comment: To reproduce that error with ffmpeg cli, you need the following params ffmpeg attachedimage.jpg -f image2 -vcodec bmp -pix_fmt rgb565 img565.bmp -sws_flags bilinear+full_chroma_int (swscale full_chroma_int is the one required parameter for hq pics, otherwise high quality pics will look bad). The other catch is that if you have avfilter compiled in then you don't get that error. I don't know what avfilter does and how it works, but the problem only happens with regular libswscale when converting from yuv444 to rgb565 with SWS_FULL_CHR_H_INT. And the only way to reproduce it with ffmpeg cli it to compile without avfilt support, or simply do it in c code directly. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2113
[issue2113] SWScale, does not convert from YUV444 to RGB565
Pavel i-love-s...@yandex.ru added the comment: To reproduce that error with ffmpeg cli, you need the following params ffmpeg attachedimage.jpg -f image2 -vcodec bmp -pix_fmt rgb565 img565.bmp -sws_flags bilinear+full_chroma_int (swscale full_chroma_int is the one required parameter for hq pics, otherwise high quality pics will look bad). The other catch is that if you have avfilter compiled in then you don't get that error. I don't know what avfilter does and how it works, but the problem only happens with regular libswscale when converting from yuv444 to rgb565 with SWS_FULL_CHR_H_INT. And the only way to reproduce it with ffmpeg cli it to compile without avfilt support, or simply do it in c code directly. -- status: closed - open FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2113
[issue2082] Crash in FFT-SSE code when playing mmst URI
Michael Niedermayer michae...@gmx.at added the comment: On Wed, Jul 14, 2010 at 11:07:09PM +, Ronald S. Bultje wrote: A make clean fixed it. -- status: new - closed substatus: new - invalid Do we consider bugs in the compilation dependancies to be invalid? [...] FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2082
[issue2115] Error when opening a mp3 file
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: Is this reproducible with ffmpeg (the application)? -- status: new - open substatus: new - needs_more_info FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2115
[issue2104] ASS demuxer doesn't write UTF-8 BOM
Michael Niedermayer michae...@gmx.at added the comment: On Sat, Jul 17, 2010 at 02:49:00PM +, fmm wrote: Though this is probably a lost cause, of about 201 .ASS files found randomly in Google from different places, 193 had a BOM, and the rest, sending a patch would probably increase your chances to see this changed [...] FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2104
[issue2082] Crash in FFT-SSE code when playing mmst URI
Mans Rullgard m...@mansr.com added the comment: Michael Niedermayer iss...@roundup.ffmpeg.org writes: On Wed, Jul 14, 2010 at 11:07:09PM +, Ronald S. Bultje wrote: A make clean fixed it. -- status: new - closed substatus: new - invalid Do we consider bugs in the compilation dependancies to be invalid? Unless someone provides me with exact steps to reproduce the problem, I will not look at it. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2082
[issue1874] RTMP stream_open() url parsing is incorrect (enforced format)
alex zimin.a...@gmail.com added the comment: Looks like filename portion will be properly handled, if the following two lines are updated in rtmpproto.c file Line 839 FROM: char *p = strchr(path + 1, '/'); TO: char *p = strrchr(path + 1, '/'); Line 845 FROM: fname = strchr(p + 1, '/'); TO: fname = strrchr(p + 1, '/'); Difference is finding last slash '/' vs. first one. Filename should be the last part of the path, after the last '/'. I will try to compile ffmpeg from source in the next few days to see, if it solves the issue. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1874
[issue2114] GOP-based multithreading(h264 encoding performance boost of 78%)
Michael Niedermayer michae...@gmx.at added the comment: On Tue, Jul 20, 2010 at 03:41:35PM +, Henk Schoneveld wrote: Status is needs_more_info. What additional info is needed ? A patch ;) [...] -- title: GOP-based multithreading(h264 encoding performance boost of 78%) - GOP-based multithreading(h264 encoding performance boost of 78%) FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2114
[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52
Ernst Albrecht Köstlin m...@alks.org added the comment:
I ran also ran into this issue.
I tracked it down (based on git-1135538) and found the reason for this
behaviour:
When starting ffserver and for some reason the /tmp/feed1.ffm as defined in the
default config file (doc/ffserver.conf) appears to be corrupted the stream
creation done in libavformat/ffmdec.c is rolled back (label fail in
ffm_read_header), shortly after this transaction the crash appears because of
bad pointer values for the streams *not* created. Those due to that when the
above mentioned roll back is done the previously assigned pointers the
AVFormatContext arent set back to NULL along with the number of streams not
being set back to 0, which will lead the freeing already freed memory.
Anyhow to cut this short I add a patch. To this posting, as Im not really into
gits sync capabilities I leave it to the experts to merge this somehow into the
tree.
Happy hacking
/a
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2003
--- libavformat/ffmdec.c 2010-07-20 20:06:00.0 +0200
+++ libavformat/ffmdec_patched.c 2010-07-20 20:07:02.0 +0200
@@ -385,8 +385,10 @@
st = s-streams[i];
if (st) {
av_free(st);
+s-streams[i] = NULL;
}
}
+s-nb_streams = 0;
return -1;
}
[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52
Reimar Döffinger b...@reimardoeffinger.de added the comment:
On Tue, Jul 20, 2010 at 06:12:22PM +, Ernst Albrecht Köstlin wrote:
--- libavformat/ffmdec.c 2010-07-20 20:06:00.0 +0200
+++ libavformat/ffmdec_patched.c 2010-07-20 20:07:02.0 +0200
@@ -385,8 +385,10 @@
st = s-streams[i];
if (st) {
av_free(st);
+s-streams[i] = NULL;
}
Shouldn't that whole block just be
av_freep(s-streams[i]);
?
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2003
[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52
Mans Rullgard m...@mansr.com added the comment:
Reimar Döffinger iss...@roundup.ffmpeg.org writes:
Reimar Döffinger b...@reimardoeffinger.de added the comment:
On Tue, Jul 20, 2010 at 06:12:22PM +, Ernst Albrecht Köstlin wrote:
--- libavformat/ffmdec.c 2010-07-20 20:06:00.0 +0200
+++ libavformat/ffmdec_patched.c 2010-07-20 20:07:02.0 +0200
@@ -385,8 +385,10 @@
st = s-streams[i];
if (st) {
av_free(st);
+s-streams[i] = NULL;
}
Shouldn't that whole block just be
av_freep(s-streams[i]);
?
Looks like it should.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2003
[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52
Ernst Albrecht Köstlin m...@alks.org added the comment: Yes, your're right, for setting the stream pointers back to NULL this should do. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2003
[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52
Ernst Albrecht Köstlin m...@alks.org added the comment: Anymore I could do on this? FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2003
[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52
Ernst Albrecht Köstlin m...@alks.org added the comment: see my first posting on this -- substatus: needs_more_info - analyzed FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2003
[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52
Reimar Döffinger b...@reimardoeffinger.de added the comment:
On Tue, Jul 20, 2010 at 06:19:18PM +, Mans Rullgard wrote:
Mans Rullgard m...@mansr.com added the comment:
Reimar Döffinger iss...@roundup.ffmpeg.org writes:
Reimar Döffinger b...@reimardoeffinger.de added the comment:
On Tue, Jul 20, 2010 at 06:12:22PM +, Ernst Albrecht Köstlin wrote:
--- libavformat/ffmdec.c 2010-07-20 20:06:00.0 +0200
+++ libavformat/ffmdec_patched.c 2010-07-20 20:07:02.0 +0200
@@ -385,8 +385,10 @@
st = s-streams[i];
if (st) {
av_free(st);
+s-streams[i] = NULL;
}
Shouldn't that whole block just be
av_freep(s-streams[i]);
?
Looks like it should.
On second though, that whole code seems like complete
nonsense to me.
First, FFmpeg should free the streams on error,
if it doesn't we probably have a lot of memleaks.
So that would make just removing all this a proper
solution.
However, then we'd have a memleak due to rc_eq not being freed.
Below, completely untested patch might actually be correct I think:
Index: libavformat/ffmdec.c
===
--- libavformat/ffmdec.c(revision 24368)
+++ libavformat/ffmdec.c(working copy)
@@ -251,6 +251,7 @@
url_fseek(pb, ptr, SEEK_SET);
}
+static int ffm_close(AVFormatContext *s);
static int ffm_read_header(AVFormatContext *s, AVFormatParameters *ap)
{
@@ -381,12 +382,7 @@
ffm-first_packet = 1;
return 0;
fail:
-for(i=0;is-nb_streams;i++) {
-st = s-streams[i];
-if (st) {
-av_free(st);
-}
-}
+ffm_close(s);
return -1;
}
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2003
[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52
Ernst Albrecht Köstlin m...@alks.org added the comment:
Doing so won't free the already allocated structures AVFormatContext's stream
array entries are pointing to, neither would it set AVFormatContext's nb_stream
to 0.
So Id propose the following:
--- libavformat/ffmdec.c2010-07-20 21:19:05.0 +0200
+++ libavformat/ffmdec_patched.c2010-07-20 21:18:48.0 +0200
@@ -251,6 +251,7 @@
url_fseek(pb, ptr, SEEK_SET);
}
+static int ffm_close(AVFormatContext *);
static int ffm_read_header(AVFormatContext *s, AVFormatParameters *ap)
{
@@ -381,12 +382,11 @@
ffm-first_packet = 1;
return 0;
fail:
+ffm_close(s);
for(i=0;is-nb_streams;i++) {
-st = s-streams[i];
-if (st) {
-av_free(st);
-}
+av_freep(s-streams[i]);
}
+s-nb_streams = 0;
return -1;
}
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2003
[issue2101] RockPlayer Android app in violation of license agreement
pinxue pin...@gmail.com added the comment: Hi beafdefx or Doug Stevenson, creator of Act 1 Video Player for Android, I just found we have long email thread discussion in same day when this case is filed, so that I guess you already have the link to download this source code package at that day. PS, I have locked the thread (http://www.diffthink.com/forum/viewtopic.php?f=2t=34) which you keep posting every day in recent. Let's take here as a central place for discussion. We have tried our best to comply the LGPL license. But as the legal text is always formal and complex, it is always possible we haven't done it good enough, we are glad to improve if it is the case. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2101
[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52
Ernst Albrecht Köstlin m...@alks.org added the comment:
Ok, so I digged deeper and found this is still not all. AVStream's member codec
also need to be freed.
So this should do it:
--- libavformat/ffmdec.c2010-07-20 21:51:58.0 +0200
+++ libavformat/ffmdec_patched.c2010-07-20 21:49:54.0 +0200
@@ -251,6 +251,7 @@
url_fseek(pb, ptr, SEEK_SET);
}
+static int ffm_close(AVFormatContext *);
static int ffm_read_header(AVFormatContext *s, AVFormatParameters *ap)
{
@@ -381,12 +382,13 @@
ffm-first_packet = 1;
return 0;
fail:
+ffm_close(s);
for(i=0;is-nb_streams;i++) {
-st = s-streams[i];
-if (st) {
-av_free(st);
-}
+if (s-streams[i])
+av_freep(s-streams[i]-codec);
+av_freep(s-streams[i]);
}
+s-nb_streams = 0;
return -1;
}
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2003
[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52
Ernst Albrecht Köstlin m...@alks.org added the comment: All this then could go into some new av_delete_stream function in libavformat/utils.c, as there a av_new_stream already avaiable. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2003
[issue2114] GOP-based multithreading(h264 encoding performance boost of 78%)
Henk Schoneveld belca...@zonnet.nl added the comment: If I were smart enough I would have done that directly, I issued a feature_request, Real man provide patches ;) [...] -- title: GOP-based multithreading(h264 encoding performance boost of 78%) - GOP-based multithreading(h264 encoding performance boost of 78%) FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2114 -- title: GOP-based multithreading(h264 encoding performance boost of 78%) - GOP-based multithreading(h264 encoding performance boost of 78%) FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2114
[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52
Ernst Albrecht Köstlin m...@alks.org added the comment:
So what about this? The same as before but all AVStream related clean up moved
to the new function av_delete_stream, as far as it was setup by
av_new_stream. The codec-rc_eq stuff still needs to be cleaned up by calling
ffm_close.
Grz
/a
--- libavformat/avformat.h 2010-07-20 22:20:14.0 +0200
+++ libavformat/avformat_patched.h 2010-07-20 22:20:00.0 +0200
@@ -1086,6 +1086,7 @@
* @param id file-format-dependent stream ID
*/
AVStream *av_new_stream(AVFormatContext *s, int id);
+void av_delete_stream(AVStream ** st);
AVProgram *av_new_program(AVFormatContext *s, int id);
/**
--- libavformat/utils.c 2010-07-20 22:19:33.0 +0200
+++ libavformat/utils_patched.c 2010-07-20 22:21:19.0 +0200
@@ -2497,6 +2497,13 @@
url_fclose(pb);
}
+void av_delete_stream(AVStream ** st)
+{
+if (*st)
+av_freep(((*st)-codec));
+av_freep(st);
+}
+
AVStream *av_new_stream(AVFormatContext *s, int id)
{
AVStream *st;
--- libavformat/ffmdec.c2010-07-20 22:25:46.0 +0200
+++ libavformat/ffmdec_patched.c2010-07-20 22:20:38.0 +0200
@@ -251,6 +251,7 @@
url_fseek(pb, ptr, SEEK_SET);
}
+static int ffm_close(AVFormatContext *);
static int ffm_read_header(AVFormatContext *s, AVFormatParameters *ap)
{
@@ -381,12 +382,11 @@
ffm-first_packet = 1;
return 0;
fail:
+ffm_close(s);
for(i=0;is-nb_streams;i++) {
-st = s-streams[i];
-if (st) {
-av_free(st);
-}
+av_delete_stream(s-streams[i]);
}
+s-nb_streams = 0;
return -1;
}
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2003
[issue2113] SWScale, does not convert from YUV444 to RGB565
Pavel i-love-s...@yandex.ru added the comment: There is no output. It asserts without any messages (in debug build it doesn't show everything below Stream mapping). In release build here's the output (no need to comment about unsupported compiler, simply check if you get the same results with realse ffmpeg compiled without avfilt. Attached is the results of release build): \ffmpeg\binffmpeg -i img.jpg -f image2 -vcodec bmp -pix_fmt rgb565 img565.bmp -sws_flags bilinear+full_chroma_int FFmpeg version SVN-r20069, Copyright (c) 2000-2010 the FFmpeg developers built on Jul 20 2010 05:08:31 with icl 1110 configuration: icl v.1110 build libavutil 50.22. 0 / 50.22. 0 libavcodec52.84. 0 / 52.84. 0 libavformat 52.75. 0 / 52.75. 0 libavdevice 52. 2. 0 / 52. 2. 0 libswscale 0.11. 0 / 0.11. 0 Stream mapping: Stream #0.0 - #0.0 Press [q] to stop encoding frame=1 fps= 0 q=0.0 Lsize= -0kB time=0.04 bitrate= -4.4kbits/s video:14kB audio:0kB global headers:0kB muxing overhead -100.153610% FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2113
[issue2113] SWScale, does not convert from YUV444 to RGB565
Pavel i-love-s...@yandex.ru added the comment: There is no output. It asserts without any messages (in debug build it doesn't show everything below Stream mapping). In release build here's the output (no need to comment about unsupported compiler, simply check if you get the same results with realse ffmpeg compiled without avfilt. Attached is the results of release build): \ffmpeg\binffmpeg -i img.jpg -f image2 -vcodec bmp -pix_fmt rgb565 img565.bmp -sws_flags bilinear+full_chroma_int FFmpeg version SVN-r20069, Copyright (c) 2000-2010 the FFmpeg developers built on Jul 20 2010 05:08:31 with icl 1110 configuration: icl v.1110 build libavutil 50.22. 0 / 50.22. 0 libavcodec52.84. 0 / 52.84. 0 libavformat 52.75. 0 / 52.75. 0 libavdevice 52. 2. 0 / 52. 2. 0 libswscale 0.11. 0 / 0.11. 0 Stream mapping: Stream #0.0 - #0.0 Press [q] to stop encoding frame=1 fps= 0 q=0.0 Lsize= -0kB time=0.04 bitrate= -4.4kbits/s video:14kB audio:0kB global headers:0kB muxing overhead -100.153610% FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2113 attachment: img565.bmp
[issue2113] SWScale, does not convert from YUV444 to RGB565
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: Sorry for being so unclear before: Only latest svn is being accepted on this bug tracker (and being the one who made icc compiling possible, I _strongly_ suggest using a released version of gcc when reporting problems). FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2113
[issue2114] GOP-based multithreading(h264 encoding performance boost of 78%)
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: Fix Status. -- priority: normal - wish substatus: needs_more_info - open title: GOP-based multithreading(h264 encoding performance boost of 78%) - GOP-based multithreading(h264 encoding performance boost of 78%) FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2114
[issue2113] SWScale output junk converting YUV444 - RGB565 using bilinear+full_chroma_int
Vitor vitor1...@gmail.com added the comment: Reproducible with r24373 compiled with gcc 4.4.3 (produces a solid black image). Bug disappears if I remove full_chroma_int flag. Valgrind complains of reading uninitialized memory, and it is indeed not a false positive, since passing --malloc-fill=0xff to valgrind produces a solid white pic while --malloc-fill=0x00 produces a solid black pic. vi...@vitor:~$ ffmpeg -i /tmp/121652-pavel1.jpg -f image2 -vcodec bmp -pix_fmt rgb565 /tmp/img565.bmp -sws_flags bilinear+full_chroma_int FFmpeg version SVN-r24373, Copyright (c) 2000-2010 the FFmpeg developers built on Jul 20 2010 22:16:37 with gcc 4.4.3 configuration: --cc='ccache gcc' --cpu=host libavutil 50.22. 0 / 50.22. 0 libavcodec52.84. 0 / 52.84. 0 libavformat 52.76. 0 / 52.76. 0 libavdevice 52. 2. 0 / 52. 2. 0 libavfilter1.25. 1 / 1.25. 1 libswscale 0.11. 0 / 0.11. 0 Input #0, image2, from '/tmp/img.jpg': Duration: 00:00:00.04, start: 0.00, bitrate: N/A Stream #0.0: Video: mjpeg, yuvj444p, 65x108 [PAR 72:72 DAR 65:108], 25 tbr, 25 tbn, 25 tbc [ffmpeg_output @ 0x8dac580] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out' [scale @ 0x8dabca0] w:65 h:108 fmt:yuvj444p - w:65 h:108 fmt:rgb565le flags:0x2002 Output #0, image2, to '/tmp/img565.bmp': Metadata: encoder : Lavf52.76.0 Stream #0.0: Video: bmp, rgb565le, 65x108 [PAR 1:1 DAR 65:108], q=2-31, 200 kb/s, 90k tbn, 25 tbc Stream mapping: Stream #0.0 - #0.0 Press [q] to stop encoding frame=1 fps= 0 q=0.0 Lsize= -0kB time=0.04 bitrate= -4.4kbits/s video:14kB audio:0kB global headers:0kB muxing overhead -100.153610% ==11973== Memcheck, a memory error detector ==11973== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==11973== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==11973== Command: ffmpeg_g -i /tmp/121652-pavel1.jpg -f image2 -vcodec bmp -pix_fmt rgb565 /tmp/img565.bmp -sws_flags bilinear+full_chroma_int ==11973== FFmpeg version SVN-r24373, Copyright (c) 2000-2010 the FFmpeg developers built on Jul 20 2010 22:16:37 with gcc 4.4.3 configuration: --cc='ccache gcc' --cpu=host libavutil 50.22. 0 / 50.22. 0 libavcodec52.84. 0 / 52.84. 0 libavformat 52.76. 0 / 52.76. 0 libavdevice 52. 2. 0 / 52. 2. 0 libavfilter1.25. 1 / 1.25. 1 libswscale 0.11. 0 / 0.11. 0 Input #0, image2, from '/tmp/img.jpg': Duration: 00:00:00.04, start: 0.00, bitrate: N/A Stream #0.0: Video: mjpeg, yuvj444p, 65x108 [PAR 72:72 DAR 65:108], 25 tbr, 25 tbn, 25 tbc [ffmpeg_output @ 0x436a0d0] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out' [scale @ 0x436a780] w:65 h:108 fmt:yuvj444p - w:65 h:108 fmt:rgb565le flags:0x2002 Output #0, image2, to '/tmp/img565.bmp': Metadata: encoder : Lavf52.76.0 Stream #0.0: Video: bmp, rgb565le, 65x108 [PAR 1:1 DAR 65:108], q=2-31, 200 kb/s, 90k tbn, 25 tbc Stream mapping: Stream #0.0 - #0.0 Press [q] to stop encoding ==11973== Syscall param write(buf) points to uninitialised byte(s) ==11973==at 0x4184EB3: __write_nocancel (syscall-template.S:82) ==11973==by 0x809B601: put_flush_packet (aviobuf.c:95) ==11973==by 0x80B47B9: img_write_packet (img2.c:402) ==11973==by 0x8120A19: av_interleaved_write_frame (utils.c:2967) ==11973==by 0x4386173: ??? ==11973== Address 0x43f1452 is 66 bytes inside a block of size 32,768 alloc'd ==11973==at 0x4024106: memalign (vg_replace_malloc.c:581) ==11973==by 0x4024163: posix_memalign (vg_replace_malloc.c:709) ==11973==by 0x854A2C0: av_malloc (mem.c:83) ==11973==by 0x809B078: url_fdopen (aviobuf.c:587) ==11973==by 0x809B1B9: url_fopen (aviobuf.c:695) ==11973==by 0x80B45B1: img_write_packet (img2.c:354) ==11973==by 0x8120A19: av_interleaved_write_frame (utils.c:2967) ==11973==by 0x4386173: ??? ==11973== frame=1 fps= 0 q=0.0 Lsize= -0kB time=0.04 bitrate= -4.4kbits/s video:14kB audio:0kB global headers:0kB muxing overhead -100.153610% ==11973== ==11973== HEAP SUMMARY: ==11973== in use at exit: 0 bytes in 0 blocks ==11973== total heap usage: 307 allocs, 307 frees, 1,016,157 bytes allocated ==11973== ==11973== All heap blocks were freed -- no leaks are possible ==11973== ==11973== For counts of detected and suppressed errors, rerun with: -v ==11973== Use --track-origins=yes to see where uninitialised values come from ==11973== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 29 from 8) -- substatus: needs_more_info - reproduced title: SWScale, does not convert from YUV444 to RGB565 - SWScale output junk converting YUV444 - RGB565 using bilinear+full_chroma_int FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2113
[issue2114] GOP-based multithreading(h264 encoding performance boost of 78%)
Michael Niedermayer michae...@gmx.at added the comment: Btw this can be implemented both in ffmpeg.c as well as a script calling ffmpeg. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2114
