[issue2114] GOP-based multithreading(h264 encoding performance boost of 78%)

Michael Niedermayer added the comment: Btw this can be implemented both in ffmpeg.c as well as a script calling ffmpeg. FFmpeg issue tracker

[issue2113] SWScale output junk converting YUV444 -> RGB565 using bilinear+full_chroma_int

Pavel added the comment: in short, "... it asserts at the end of yuv2rgbXinC_full". Before posting any bug reports, I obviously updated to latest svn. I took ffmpeg and made it compile with icl long time ago. I build ffmpeg with visual studio, and FFmpeg version SVN-r20069 is the last version th

[issue2113] SWScale output junk converting YUV444 -> RGB565 using bilinear+full_chroma_int

Vitor 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 produ

[issue2114] GOP-based multithreading(h264 encoding performance boost of 78%)

Carl Eugen Hoyos 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%) __

[issue2113] SWScale, does not convert from YUV444 to RGB565

Carl Eugen Hoyos 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). ___

[issue2113] SWScale, does not convert from YUV444 to RGB565

Pavel 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 w

[issue2113] SWScale, does not convert from YUV444 to RGB565

Pavel 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 w

[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52

Ernst Albrecht Köstlin 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 --- libav

[issue2114] GOP-based multithreading(h264 encoding performance boost of 78%)

Henk Schoneveld 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 encod

[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52

Ernst Albrecht Köstlin 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 _

[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52

Ernst Albrecht Köstlin 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

[issue2101] RockPlayer Android app in violation of license agreement

pinxue 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 l

[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52

Ernst Albrecht Köstlin 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

[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52

Reimar Döffinger added the comment: On Tue, Jul 20, 2010 at 06:19:18PM +, Mans Rullgard wrote: > > Mans Rullgard added the comment: > > Reimar Döffinger writes: > > > Reimar Döffinger added the comment: > > > > On Tue, Jul 20, 2010 at 06:12:22PM +, Ernst Albrecht Köstlin wrote: > >

[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52

Ernst Albrecht Köstlin added the comment: see my first posting on this -- substatus: needs_more_info -> analyzed FFmpeg issue tracker

[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52

Ernst Albrecht Köstlin added the comment: Anymore I could do on this? FFmpeg issue tracker

[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52

Ernst Albrecht Köstlin added the comment: Yes, your're right, for setting the stream pointers back to NULL this should do. FFmpeg issue tracker

[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52

Mans Rullgard added the comment: Reimar Döffinger writes: > Reimar Döffinger 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

[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52

Reimar Döffinger 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->st

[issue2003] (libavformat) 0x00e8cfac in av_open_input_stream () from /usr/lib/libavformat.so.52

Ernst Albrecht Köstlin 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 co

[issue2114] GOP-based multithreading(h264 encoding performance boost of 78%)

Michael Niedermayer 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 multithreadin

[issue1874] RTMP stream_open() url parsing is incorrect (enforced format)

alex 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,

[issue2114] GOP-based multithreading(h264 encoding performance boost of 78%)

Henk Schoneveld added the comment: Status is needs_more_info. What additional info is needed ? FFmpeg issue tracker

[issue2082] Crash in FFT-SSE code when playing mmst URI

Mans Rullgard added the comment: Michael Niedermayer 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 inval

[issue2104] ASS demuxer doesn't write UTF-8 BOM

Michael Niedermayer 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 se

[issue2115] Error when opening a mp3 file

Carl Eugen Hoyos added the comment: Is this reproducible with ffmpeg (the application)? -- status: new -> open substatus: new -> needs_more_info FFmpeg issue tracker ___

[issue2082] Crash in FFT-SSE code when playing mmst URI

Michael Niedermayer 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? [...] __

[issue2113] SWScale, does not convert from YUV444 to RGB565

Carl Eugen Hoyos added the comment: Complete, uncut output is still missing. FFmpeg issue tracker

[issue2113] SWScale, does not convert from YUV444 to RGB565

Pavel 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 quali

[issue2113] SWScale, does not convert from YUV444 to RGB565

Pavel 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 quali