[issue1162] Possible MediaCoder GPL violation
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: @victorhooi: Could you post the link to the source code you found? -- substatus: - reproduced FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1162
[issue866] Baofeng Media Player violates FFmpeg's licenses
luis luiis...@gmail.com added the comment: HI,jason Garrett-Glaser.I think this rulemake sure your program is not using any GPL libraries(notably libx264)quiet very unreasonable.because a lot of soft use other GPL libraries if necessary.just for the ability that play media documents. -- assignedto: - Dark Shikari nosy: +Dark Shikari priority: normal - wish substatus: reproduced - reject type: - feature_request FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue866
[issue866] Baofeng Media Player violates FFmpeg's licenses
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: Fix Status etc. -- assignedto: Dark Shikari - nosy: -Dark Shikari priority: wish - normal substatus: reject - reproduced type: feature_request - FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue866
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment:
i used this:
-noframedrop -an -vf scale=1024:693
/home/gat/DIESEL/TEST_FP24/PF24_60Seconds.MTS
this works, and appears to be fairly fast on a pIII/700Mhz laptop.
It does seem like one has to feed in the minimum of screen size and
video frame size. Feeding in a large video frame size seems to screw up
things.
==
Breakpoint 3, alloc_picture (opaque=0xb7238020) at ffplay.c:1328
1328 vp-bmp = SDL_CreateYUVOverlay(vp-width, vp-height,
(gdb) n
1332 SDL_LockMutex(is-pictq_mutex);
(gdb) p *vp
$12 = {pts = 0, target_clock = 0, pos = 0, bmp = 0x8c53820, width = 1024,
height = 693, allocated = 0, pix_fmt = PIX_FMT_YUV420P, picref = 0x0}
(gdb) p *vp-bmp
$13 = {format = 842094169, w = 1024, h = 693, planes = 3, pitches = 0x8c304a8,
pixels = 0x8c55f08, hwfuncs = 0x86b4a40, hwdata = 0x8c3e6d0, hw_overlay = 1,
UnusedBits = 0}
(gdb) p vp-bmp-pitches[0]
$14 = 1024
(gdb) p vp-bmp-pitches[1]
$15 = 512
(gdb) p vp-bmp-pitches[2]
$16 = 512
(gdb) l
1327
1328 vp-bmp = SDL_CreateYUVOverlay(vp-width, vp-height,
1329 SDL_YV12_OVERLAY,
1330 screen);
1331
1332 SDL_LockMutex(is-pictq_mutex);
1333 vp-allocated = 1;
1334 SDL_CondSignal(is-pictq_cond);
1335 SDL_UnlockMutex(is-pictq_mutex);
1336 }
(gdb)
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2079
[issue2126] AVFORMAT leaks 1KB for every missing file.
Vitor vitor1...@gmail.com added the comment: Using vi...@vitor:~$ valgrind ffmpeg_g -i /tmp/unexisting_file /tmp/out.avi ==12603== Memcheck, a memory error detector ==12603== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==12603== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==12603== Command: ./ffmpeg_g -i /tmp/unexisting_file /tmp/out.avi ==12603== FFmpeg version SVN-r24456, Copyright (c) 2000-2010 the FFmpeg developers built on Jul 23 2010 11:58:11 with gcc 4.4.3 configuration: --cc='ccache gcc' --cpu='host' --samples='/home/vitor/ffmpeg/fate/fate-suite' libavutil 50.23. 0 / 50.23. 0 libavcore 0. 0. 0 / 0. 0. 0 libavcodec52.84. 0 / 52.84. 0 libavformat 52.76. 0 / 52.76. 0 libavdevice 52. 2. 0 / 52. 2. 0 libavfilter1.26. 1 / 1.26. 1 libswscale 0.11. 0 / 0.11. 0 /tmp/unexisting_file: No such file or directory ==12603== ==12603== HEAP SUMMARY: ==12603== in use at exit: 0 bytes in 0 blocks ==12603== total heap usage: 9 allocs, 9 frees, 41,869 bytes allocated ==12603== ==12603== All heap blocks were freed -- no leaks are possible ==12603== ==12603== For counts of detected and suppressed errors, rerun with: -v ==12603== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 29 from 8) So how does ffmpeg.c not leak mem? -Vitor FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2126
[issue2126] AVFORMAT leaks 1KB for every missing file.
Vitor vitor1...@gmail.com added the comment: Needs more info. -- substatus: new - needs_more_info FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2126
[issue2126] AVFORMAT leaks 1KB for every missing file.
Reimar Döffinger b...@reimardoeffinger.de added the comment: On Mon, Jul 26, 2010 at 03:11:10AM +, Pavel wrote: free allocated context on failure That not really enough at all. See av_close_input_stream. I think everything except s-iformat-read_close(s); should be done. Otherwise every demuxer must manually free chapters, metadata, index etc. if read_header() fails after reading them. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2126
[issue2126] AVFORMAT leaks 1KB for every missing file.
Pavel i-love-s...@yandex.ru added the comment: I use: int ret = av_open_input_file(format_ctx, invalidfile.png, NULL, 0, NULL); if invalidfile.png doesn't exist, then on return format_ctx is 0 and ret contains a error return (-2). At this point, I can't do anything anymore. The only way to fix it was to free context on error. I don't know internals of avio, but the next line after my patch, there is av_free(st); after that st-codec is leaked, so I addredd free just before that. valgrind ffmpeg_g -i /tmp/unexisting_file /tmp/out.avi : It doesn't necessarily use the same way to open files, and may go some other code path. I can't comment on ffmpeg cli FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2126
[issue2126] AVFORMAT leaks 1KB for every missing file.
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: I would like to repeat that this kind of bug-report is _very_ rude and definitely NOT welcome! (That is also true if it's a patch since the patch guidelines clearly ask for explanations.) valgrind ./ffmpeg_g -i no.png ==5489== Memcheck, a memory error detector ==5489== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==5489== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==5489== Command: ./ffmpeg_g -i no.png ==5489== FFmpeg version SVN-r24460, Copyright (c) 2000-2010 the FFmpeg developers built on Jul 26 2010 23:39:10 with gcc 4.4.4 configuration: cc='/usr/local/gcc-4.4.4/bin/gcc -m32' libavutil 50.23. 0 / 50.23. 0 libavcore 0. 0. 0 / 0. 0. 0 libavcodec52.84. 0 / 52.84. 0 libavformat 52.76. 0 / 52.76. 0 libavdevice 52. 2. 0 / 52. 2. 0 libavfilter1.26. 1 / 1.26. 1 libswscale 0.11. 0 / 0.11. 0 no.png: No such file or directory ==5489== ==5489== HEAP SUMMARY: ==5489== in use at exit: 940 bytes in 1 blocks ==5489== total heap usage: 12 allocs, 11 frees, 44,291 bytes allocated ==5489== ==5489== LEAK SUMMARY: ==5489==definitely lost: 940 bytes in 1 blocks ==5489==indirectly lost: 0 bytes in 0 blocks ==5489== possibly lost: 0 bytes in 0 blocks ==5489==still reachable: 0 bytes in 0 blocks ==5489== suppressed: 0 bytes in 0 blocks ==5489== Rerun with --leak-check=full to see details of leaked memory ==5489== ==5489== For counts of detected and suppressed errors, rerun with: -v ==5489== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 3) -- status: new - open substatus: needs_more_info - reproduced type: patch - bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2126
[issue2126] AVFORMAT leaks 1KB for every missing file.
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: ==19207== ==19207== HEAP SUMMARY: ==19207== in use at exit: 940 bytes in 1 blocks ==19207== total heap usage: 12 allocs, 11 frees, 44,291 bytes allocated ==19207== ==19207== 940 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==19207==at 0x4CA8E9E: memalign (in /usr/lib64/valgrind/vgpreload_memcheck-x86-linux.so) ==19207==by 0x4CA8EFB: posix_memalign (in /usr/lib64/valgrind/vgpreload_memcheck-x86-linux.so) ==19207==by 0x8472716: av_malloc (mem.c:83) ==19207==by 0x8296D4E: avcodec_alloc_context2 (options.c:471) ==19207==by 0x8296DA2: avcodec_alloc_context (options.c:485) ==19207==by 0x80FE37D: av_new_stream (utils.c:2514) ==19207==by 0x808DC76: img_read_header (img2.c:197) ==19207==by 0x80F78A6: av_open_input_stream (utils.c:452) ==19207==by 0x80F7D91: av_open_input_file (utils.c:606) ==19207==by 0x8054DAD: opt_input_file (ffmpeg.c:3174) ==19207==by 0x805828F: parse_options (cmdutils.c:179) ==19207==by 0x8057AF1: main (ffmpeg.c:4340) FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2126
[issue2127] compilation with --disable-optimizations fails on x86_32 for transpose4x4()
New submission from Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at: When trying to build ffmpeg with ./configure --disable-optimizations (with a 32 bit x86 compiler), compilation fails for transpose4x4() in libavcodec/x86/dsputil_mmx.c This being the only failing file (and disable-optimization being very useful when using valgrind) imo justifies a #if !HAVE_7REGS (or #if !HAVE_OPTIMIZATIONS) around a pure C implementation of transpose4x4 (or an asm implementation that needs less registers). cc -m32 -I. -I/home/cehoyos/Projects/FFmpeg -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DHAVE_AV_CONFIG_H -std=c99 -pthread -g -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=implicit-function-declaration -Werror=missing-prototypes -MMD -MF libavcodec/x86/dsputil_mmx.d -MT libavcodec/x86/dsputil_mmx.o -c -o libavcodec/x86/dsputil_mmx.o libavcodec/x86/dsputil_mmx.c ./libavutil/x86/bswap.h:32: warning: ‘av_bswap16’ defined but not used ./libavcodec/mathops.h:57: warning: ‘UMULH’ defined but not used ./libavcodec/get_bits.h:603: warning: ‘get_vlc2’ defined but not used libavcodec/x86/h264dsp_mmx.c:2080: warning: ‘avg_h264_qpel8or16_hv1_lowpass_3dnow’ defined but not used libavcodec/x86/h264dsp_mmx.c:2084: warning: ‘avg_h264_qpel8or16_hv1_lowpass_mmx2’ defined but not used libavcodec/x86/dsputil_mmx.c: In function ‘transpose4x4’: libavcodec/x86/dsputil_mmx.c:736: error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’ libavcodec/x86/dsputil_mmx.c:736: error: ‘asm’ operand has impossible constraints make: *** [libavcodec/x86/dsputil_mmx.o] Error 1 -- messages: 11410 priority: normal status: open substatus: open title: compilation with --disable-optimizations fails on x86_32 for transpose4x4() type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2127
[issue2116] Possible license violation, Edimax
Robert Lukassen robert.lukas...@gmail.com added the comment: The file IC-9000-020304-n.f is uploaded in the context of issue 2116. It contains the firmware for an IP camera (IC-9000) distributed by Edimax. This camera is probably a clone of the IC-602 camera distributed by StarVedia. The firmware file contains a gzipped ramdisk, starting at offset 0xcb98c continuing up to the end of the file (excluding some padding). After gunzipping, the resulting file can be mounted via a loop device as an ext2 filesystem. This contains a directory /ffmpeg holding an ffserver executable that is clearly modified. It can be shown that this firmware contains a modified binary derived from GPL'd ffmpeg/ffserver sources. While running this firmware, it can be demonstrated that the ffserver is active by visiting a specific link (stat.html). This produces the following result: FFServer Status Available Streams PathServed Conns bytesFormatBit rate kbits/sVideo kbits/s CodecAudio kbits/s CodecFeed test.ts 0 0 mpegts 1536 1536 mpeg4 0 feed1.ffm test2.ts 0 0 mpegts 256 256 mpeg4 0 feed2.ffm rtspvideo 0 0 rtp 256 256 mpeg4 0 feed2.ffm rtspmp2 0 25051Mrtp 1536 1536 mpeg4 0 feed1.ffm stat.html 1 0 - - - - index.html 0 0 - - - - Feed feed1.ffm Streamtypekbits/scodecParameters 0video1536mpeg4640x480, q=1-31, fps=30 Feed feed2.ffm Streamtypekbits/scodecParameters 0video256mpeg4320x240, q=1-31, fps=15 Connection Status Number of connections: 4 / 24 Bandwidth in use: 0k / 20480k #FileIPProtoStateTarget bits/secActual bits/secBytes transferred 1stat.html192.168.1.18HTTP/1.1 HTTP_WAIT_REQUEST0 0 0 2feed2.ffm(input)127.0.0.1HTTP/1.0 RECEIVE_DATA256k0 0 3feed1.ffm(input)127.0.0.1HTTP/1.0 RECEIVE_DATA1536k0 0 4(input)127.0.0.1RECEIVE_DATA0 2432 83288k Generated at Sun Jan 4 04:04:07 1970 FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2116
[issue2128] ffserver's RTSP doesn't work with VLC
New submission from PeterKim demo...@paran.com:
VLC / ffserver RTSP handshake have a problem,
ffserver / vlc / rtsp combination doesn't work.
- VLC client use
PLAY rtsp://192.168.229.132:5454/test1-
rtsp.mpg/ RTSP/1.0
- FFSERVER internal ...
rtsp://192.168.229.132:5454/test1-rtsp.mpg
note ... there is no / after .mpg
ffserver.c , find_rtp_session_with_url function ...
please change the code
// if(!strcmp(path, rtp_c-stream-filename)) {
-- original
if ( ! strncmp ( path, rtp_c-stream-filename,
strlen ( rtp_c-stream-filename))) { -- update
--
messages: 11413
priority: normal
status: new
substatus: new
title: ffserver's RTSP doesn't work with VLC
type: patch
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2128
