[issue2114] GOP-based multithreading(h264 encoding performance boost of 78%)
Henk Schoneveld belca...@zonnet.nl added the comment: If my brains serve me well, all video codecs become multithreaded this way. Which brings audio-only files to mind. Do they have a GOP-like substitute? FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2114
[issue2116] Possible license violation, Edimax
New submission from Robert Lukassen robert.lukas...@gmail.com: The software in the Edimax IC-9000 IP camera (http://www.edimax.com/en/produce_detail.php?pd_id=336pl1_id=8pl2_id=80) is based on a number of open source projects licensed under LGPL and GPLv2 (some GPLv2 or later). While Edimax has made an archive with firmware source code available on their website, this can be shown not to correspond to the actual firmware used in their product and is incomplete. Analysis of the binary firmware image, as well as responses to selective HTTP queries to the actual product, show that this product is using both ffmpeg and ffserver which are licensed under the LGPL (or possibly, due to inclusion of one or more modules originally licensed under GPL, GPL). These ffmpeg and ffserver binaries can be shown to be modified. The published firmware source code does *not* include any source code of these ffmpeg and ffserver binaries, nor does it contain the modifications in that source code applied in that IC-9000 camera. The company has been responsive to my enquiries about this (this actually led to the publication of the firmware source code on their website), until I informed them of my analysis that this firmware source code does not correspond to the actual product firmware (and in fact seems to be a straight copy of the BSP for the main System-on-Chip (CPU) in their product, originally supplied by Faraday). It can further be shown that the ffmpeg and ffserver binaries have probably been produced by StarVedia (with Edimax being a distributor of re-labeled StarVedia products). The Edimax IC-9000 is clearly a clone of the IC-602 StarVedia product. -- messages: 11314 priority: normal status: new substatus: new title: Possible license violation, Edimax topic: (L)GPL violation FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2116
[issue2116] Possible license violation, Edimax
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: Could you upload the firmware image to a new directory issue2116 on ftp://ffmpeg.org/MPlayer/incoming/ (write-only)? -- status: new - open substatus: new - open FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2116
[issue2113] SWScale output junk converting YUV444 - RGB565 using bilinear+full_chroma_int
Vitor vitor1...@gmail.com added the comment: Attached patch should fix it. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2113 Index: libswscale/swscale.c === --- libswscale/swscale.c (revision 31758) +++ libswscale/swscale.c (working copy) @@ -974,6 +974,34 @@ } } break; +case PIX_FMT_RGB565: +YSCALE_YUV_2_RGBX_FULL_C(121, 0) +((uint16_t *)dest)[0] = B25 | ((G19) (127 5)) | +((R14) (63 11)); +dest+= step; +} +break; +case PIX_FMT_BGR565: +YSCALE_YUV_2_RGBX_FULL_C(121, 0) +((uint16_t *)dest)[0] = R25 | ((G19) (127 5)) | +((B14) (63 11)); +dest+= step; +} +break; +case PIX_FMT_BGR555: +YSCALE_YUV_2_RGBX_FULL_C(121, 0) +((uint16_t *)dest)[0] = R25 | ((G20) (63 5)) | +((B15) (63 10)); +dest+= 2; +} +break; +case PIX_FMT_RGB555: +YSCALE_YUV_2_RGBX_FULL_C(121, 0) +((uint16_t *)dest)[0] = B25 | ((G20) (63 5)) | +((R15) (63 10)); +dest+= 2; +} +break; default: assert(0); }
[issue2113] SWScale output junk converting YUV444 - RGB565 using bilinear+full_chroma_int
Vitor vitor1...@gmail.com added the comment:
New patch that also fix RGB48{BE,LE}.
RGB8, RGB4 and MONO{WHITE,BLACK} are still broken but I think it is better to
just error out saying that full_chroma_int is not supported for these outputs
(and it is not very meaningful anyway).
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2113
Index: libswscale/swscale.c
===
--- libswscale/swscale.c (revision 31758)
+++ libswscale/swscale.c (working copy)
@@ -974,6 +974,54 @@
}
}
break;
+case PIX_FMT_RGB565:
+YSCALE_YUV_2_RGBX_FULL_C(121, 0)
+((uint16_t *)dest)[0] = B25 | ((G19) (127 5)) |
+((R14) (63 11));
+dest+= step;
+}
+break;
+case PIX_FMT_BGR565:
+YSCALE_YUV_2_RGBX_FULL_C(121, 0)
+((uint16_t *)dest)[0] = R25 | ((G19) (127 5)) |
+((B14) (63 11));
+dest+= step;
+}
+break;
+case PIX_FMT_BGR555:
+YSCALE_YUV_2_RGBX_FULL_C(121, 0)
+((uint16_t *)dest)[0] = R25 | ((G20) (63 5)) |
+((B15) (63 10));
+dest+= 2;
+}
+break;
+case PIX_FMT_RGB555:
+YSCALE_YUV_2_RGBX_FULL_C(121, 0)
+((uint16_t *)dest)[0] = B25 | ((G20) (63 5)) |
+((R15) (63 10));
+dest+= 2;
+}
+break;
+case PIX_FMT_RGB48:
+YSCALE_YUV_2_RGBX_FULL_C(121, 0)
+((uint16_t *)dest)[0] = R14;
+((uint16_t *)dest)[1] = G14;
+((uint16_t *)dest)[2] = B14;
+dest+= step;
+}
+break;
+#if HAVE_BIGENDIAN
+case PIX_FMT_RGB48LE:
+#else
+case PIX_FMT_RGB48BE:
+#endif
+YSCALE_YUV_2_RGBX_FULL_C(121, 0)
+((uint16_t *)dest)[0] = av_bswap16(R14);
+((uint16_t *)dest)[1] = av_bswap16(G14);
+((uint16_t *)dest)[2] = av_bswap16(B14);
+dest+= step;
+}
+break;
default:
assert(0);
}
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: Further investigation by UGeorge determined that the root cause of this problem is that the coded video dimensions are larger than his desktop. This leads to a buffer overrun during an image copy into the YUV Overlay buffer. The bug is that ffplay.c assumes that the call to SDLCreateYUVOverlay() will always return the requested image buffer size, but evidence indicates that it does not. It won't create a buffer larger than the desktop. Fixed title and reopened this issue since it appears to be a valid report, and I didn't find an existing roundup issue for this situation. Issue1672 might be the same, but there's not enough information in that report to be sure. -- status: closed - open title: ffplay: munmap_chunk(): invalid pointer - ffplay: segfault if coded video WxH dimension larger than desktop FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment: do u just have the patchs so I can apply to my heavily modified DEBUG of ffmpeg/ffplay? -- title: ffplay: segfault if coded video WxH dimension larger than desktop - ffplay: segfault if coded video WxH dimension larger than desktop FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2114] GOP-based multithreading(h264 encoding performance boost of 78%)
Michael Niedermayer michae...@gmx.at added the comment: On Wed, Jul 21, 2010 at 07:50:20AM +, Henk Schoneveld wrote: If my brains serve me well, all video codecs become multithreaded this way. Which brings audio-only files to mind. Do they have a GOP-like substitute? each audio frame is its own gop more or less due to mdct one has to feed more audio in each gop encoder though to make them match properly when concatenated later [...] FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2114
[issue2113] SWScale output junk converting YUV444 - RGB565 using bilinear+full_chroma_int
Michael Niedermayer michae...@gmx.at added the comment:
On Wed, Jul 21, 2010 at 01:04:16PM +, Vitor wrote:
New patch that also fix RGB48{BE,LE}.
RGB8, RGB4 and MONO{WHITE,BLACK} are still broken but I think it is better to
just error out saying that full_chroma_int is not supported for these outputs
(and it is not very meaningful anyway).
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2113
swscale.c | 48
1 file changed, 48 insertions(+)
a2379da1fa0ebdd905f3cb89523c59f5372592ff sws_full_chroma_fix2.diff
Index: libswscale/swscale.c
===
--- libswscale/swscale.c (revision 31758)
+++ libswscale/swscale.c (working copy)
@@ -974,6 +974,54 @@
}
}
break;
+case PIX_FMT_RGB565:
+YSCALE_YUV_2_RGBX_FULL_C(121, 0)
+((uint16_t *)dest)[0] = B25 | ((G19) (127 5)) |
+((R14) (63 11));
+dest+= step;
+}
+break;
+case PIX_FMT_BGR565:
+YSCALE_YUV_2_RGBX_FULL_C(121, 0)
+((uint16_t *)dest)[0] = R25 | ((G19) (127 5)) |
+((B14) (63 11));
+dest+= step;
+}
+break;
+case PIX_FMT_BGR555:
+YSCALE_YUV_2_RGBX_FULL_C(121, 0)
+((uint16_t *)dest)[0] = R25 | ((G20) (63 5)) |
+((B15) (63 10));
+dest+= 2;
+}
+break;
+case PIX_FMT_RGB555:
+YSCALE_YUV_2_RGBX_FULL_C(121, 0)
+((uint16_t *)dest)[0] = B25 | ((G20) (63 5)) |
+((R15) (63 10));
+dest+= 2;
+}
+break;
missing dithering
+case PIX_FMT_RGB48:
+YSCALE_YUV_2_RGBX_FULL_C(121, 0)
+((uint16_t *)dest)[0] = R14;
+((uint16_t *)dest)[1] = G14;
+((uint16_t *)dest)[2] = B14;
+dest+= step;
+}
+break;
+#if HAVE_BIGENDIAN
+case PIX_FMT_RGB48LE:
+#else
+case PIX_FMT_RGB48BE:
+#endif
a _NME (not machine endian) #define in pixfmts.h would simplify this
also we might wish to implement such formats by bswaping the output
in a seperate pass to reduce code bloat
[...]
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2113
[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 07:20:24PM +, Ernst Albrecht Köstlin wrote: 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. And neither it is supposed to do, av_close_input_stream does all that. Actually it also calls ffm_close. So the whole fail: code just should be removed. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2003
[issue2101] RockPlayer Android app in violation of license agreement
Doug Stevenson dougn...@hyper-aware.com added the comment: It seems to me that if the instructions on FFmpeg's legal page are followed, then you are intentionally avoiding all issues with the LGPL license: http://www.ffmpeg.org/legal.html If you do this, you are making it easy for people to experiment with FFmpeg under Android, which in turn creates an environment where the open source community can feed improvements back into FFmpeg, which will indirectly improve RockPlayer. You only stand to gain from this kind of transparency. By holding back and dodging questions as has been done on the RockPlayer forums so far, it raises concerns about the spirit in which FFmpeg's LGPL license is being observed. I will point out that the first zip of source I obtained from the url that was posted above did not even contain the LGPL license file. Today it is present, and that's a start. I'll also point out that the included README is just plain wrong. It says to reference documentation in the doc directory, which does not exist. It also says to run ./configure, which does not exist. The INSTALL file is equally incorrect and mentions nothing about the end game of producing a ffmpeg.so which can be linked into Android applications. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2101
[issue2114] GOP-based multithreading(h264 encoding performance boost of 78%)
Henk Schoneveld belca...@zonnet.nl added the comment: Because of the impact on all encoding shouldn't it get a super-important status. I for myself wouldn't mind. ;) Which brings audio-only files to mind. Do they have a GOP-like substitute? each audio frame is its own gop more or less due to mdct one has to feed more audio in each gop encoder though to make them match properly when concatenated later [...] 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
[issue2117] MJPEG decoder crash
New submission from Pavel i-love-s...@yandex.ru:
Some damaged pictures crash MJPEG decoder from ffmpeg.
Latest svn (july 21) crashes. Output doesn't have any messages.
ffmpeg -i 1279729383-BLUE01.jpg -f image2 -vcodec bmp out.bmp
crashes inside
/* decode block and dequantize */
static int decode_block(MJpegDecodeContext *s, DCTELEM *block,
...
for(;;) {
UPDATE_CACHE(re, s-gb); // -- here
GET_VLC(code, re, s-gb, s-vlcs[1][ac_index].table, 9, 2)
File '1279729383-BLUE01.jpg' not attached - you can download it from
https://roundup.ffmpeg.org/file992.
--
files: 1279729383-BLUE01.jpg
messages: 11326
priority: normal
status: new
substatus: new
title: MJPEG decoder crash
type: bug
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2117
[issue2113] SWScale output junk converting YUV444 - RGB565 using bilinear+full_chroma_int
Vitor vitor1...@gmail.com added the comment:
On 07/21/2010 07:35 PM, Michael Niedermayer wrote:
Michael Niedermayermichae...@gmx.at added the comment:
On Wed, Jul 21, 2010 at 01:04:16PM +, Vitor wrote:
New patch that also fix RGB48{BE,LE}.
RGB8, RGB4 and MONO{WHITE,BLACK} are still broken but I think it is better to
just error out saying that full_chroma_int is not supported for these outputs
(and it is not very meaningful anyway).
[...]
+case PIX_FMT_RGB555:
+YSCALE_YUV_2_RGBX_FULL_C(121, 0)
+((uint16_t *)dest)[0] = B25 | ((G20) (63 5)) |
+((R15) (63 10));
+dest+= 2;
+}
+break;
missing dithering
True, but it probably will require more radical changes than the attached patch.
BTW, is there a reason why yuvj444p - rgb555 does dithering while yuvj420p -
rbg555 doesn't?
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2113
[issue2118] BUG tracker is unusably TOO slow.
New submission from Pavel i-love-s...@yandex.ru: reproducible with current svn of ffmpeg cli. Does the bug tracker try to fix the bugs itself and that's why the web interface is extremely unresponsive. Or is it to prevent some bug reporters from filling their reports (that one the other way to fix bugs as well) ... -- messages: 11329 priority: normal status: new substatus: new title: BUG tracker is unusably TOO slow. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2118
