[issue534] Cooliris License Violation
Diego Biurrun di...@biurrun.de added the comment: On Fri, Dec 19, 2008 at 01:45:38AM +, Andy Taylor wrote: Andy Taylor a...@cooliris.com added the comment: We've made the following addition to our EULA regarding reverse engineering to comply with section 6 of the LGPL: (i) Decompile, reverse engineer, disassemble, modify, rent, lease, loan, distribute, or create derivative works (as defined by the U.S. Copyright Act) or improvements (as defined by U.S. patent law) based upon the Cooliris Software or any portion thereof, unless this is strictly for personal use or to debug such modifications; That's better. You'll also notice that we now display an Open Source Software notice with full credit and a link to download the original FFmpeg source (revision 12758 with no code modifications) directly from our site. This is to comply with section 4 of the LGPL. Good. This should comply fully with the LGPL. Thank you for your time and diligence. I quickly looked at your EULA found at http://www.cooliris.com/legal/terms/ Without even bothering to read it fully I noticed two things: 1) You do not seem to have read it yourselves. Otherwise it would not have escaped your notice that some paragraphs are duplicated. 2) There is still a section that is incompatible with our copyrights: (ii) Incorporate the Cooliris Software or any portion thereof into any computer chip or the firmware of a computing device manufactured by or for you; You have no business forbidding people what to do with FFmpeg, which is a portion of your software. It took me less than five minutes to discover. While you are surely closer to compliance than before, more diligence is still needed. The holes are still quite obvious without even looking at the software itself. Diego __ FFmpeg issue tracker ffmpeg_iss...@live.polito.it https://roundup.mplayerhq.hu/roundup/ffmpeg/issue534 __
[issue757] invalid packet pts readed from mpeg4 stream
flicker greend...@mail.ru added the comment: may be it is buggy... like all ffmpeg library, and like all open source. But this patch solve my problem. I trying to read all packets from the stream and after that try to decode this packets. Don't ask me why, but i realy need this. When i reading packet all PTS==DTS, witch produce invalid order in reordered_opaque after decoding, but if i decode packets as soon as they readed, some PTS values in packets are AV_NOPTS_VALUE, and i can reconstruct reordered_opaque in right way at decoding step. In general, PTS value depends on avctx-has_b_frames, because it used in av_read_frame, right? Only avcodec_decode_video sets avctx-has_b_frames... and what if i never call avcodec_decode_video? All packets will be readed with invalid PTS? May be not extremly invalid, but different from case when i call avcodec_decode_video after reading evry packet. Why packet reading depends on codec processing?! I think it is not right. You choise is to use my patch or not to use. If you understend problem, you can make right (in you point of view) patch. So, mpeg1/mpeg2 stream parser sets avctx-has_b_frames in mpegvideo_extract_headers without any problems, can you tell me why mpeg4 parser can't do this? avcodec_decode_video of mpeg4 stream sets avctx-has_b_frames exacly in the same way like in my patch, am i right? AVI format store indexes at the end of file, and i can't cut usefull sample easy. -- substatus: needs_more_info - open __ FFmpeg issue tracker ffmpeg_iss...@live.polito.it https://roundup.mplayerhq.hu/roundup/ffmpeg/issue757 __
[issue757] invalid packet pts readed from mpeg4 stream
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: Please upload your uncut sample to ftp://ffmpeg.org/MPlayer/incoming/ -- status: new - open substatus: open - needs_more_info __ FFmpeg issue tracker ffmpeg_iss...@live.polito.it https://roundup.mplayerhq.hu/roundup/ffmpeg/issue757 __
[issue759] [svq3 @ 0xa70000]weird prediction
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: Did you test binary codec with an old version of mplayer? -vc qtsvq3 doesn't work for me for quite some time. However, reproduced with Quicktime and sample uploaded to issue759. -- substatus: open - reproduced __ FFmpeg issue tracker ffmpeg_iss...@live.polito.it https://roundup.mplayerhq.hu/roundup/ffmpeg/issue759 __
Re: [issue759] [svq3 @ 0xa70000]weird prediction
-demuxer mov -vc qtsvq3 binary codec is broken with extradata and demuxer lavf :(
[issue762] mp1 audio file plays too fast
New submission from Steven Zakulec spzaku...@gmail.com: From the uncommon audio codec list, the 2005_L23_CELTA__1-Villarreal_0___1-0_Baiano.avi file is MP1, and if you play it with FFplay the voices are distorted. If you play it with MPlayer and force libMAD, the voices sound normal. File can be found here: http://www.videosdelcelta.com/Videos/2005/2005_L23_CELTA__1- Output: ffplay -stats 2005_L23_CELTA__1-Villarreal_0___1-0_Baiano.avi FFplay version SVN-r16208, Copyright (c) 2003-2008 Fabrice Bellard, et al. configuration: --enable-gpl --enable-zlib --enable-bzlib --enable-libx264 --arch=i686 --enable- libavutil 49.12. 0 / 49.12. 0 libavcodec52. 7. 0 / 52. 7. 0 libavformat 52.23. 1 / 52.23. 1 libavdevice 52. 1. 0 / 52. 1. 0 libavfilter0. 1. 0 / 0. 1. 0 libswscale 0. 6. 1 / 0. 6. 1 libpostproc 51. 2. 0 / 51. 2. 0 built on Dec 17 2008 22:05:28, gcc: 4.2.4 (Ubuntu 4.2.4-1ubuntu3) [NULL @ 0x8911960]Invalid and inefficient vfw-avi packed B frames detected Input #0, avi, from '2005_L23_CELTA__1-Villarreal_0___1-0_Baiano.avi': Duration: 00:00:54.68, start: 0.00, bitrate: 788 kb/s Stream #0.0: Video: mpeg4, yuv420p, 512x384 [PAR 1:1 DAR 4:3], 25.00 tb(r) Stream #0.1: Audio: mp1, 11025 Hz, stereo, s16, 448 kb/s MPlayer output: mplayer -ac mad 2005_L23_CELTA__1-Villarreal_0___1-0_Baiano.avi MPlayer dev-SVN-r28162-4.2.4 (C) 2000-2008 MPlayer Team CPU: Intel(R) Core(TM)2 CPU T5300 @ 1.73GHz (Family: 6, Model: 15, Stepping: 2) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2 Warning unknown option option at line 2 Playing 2005_L23_CELTA__1-Villarreal_0___1-0_Baiano.avi. AVI file format detected. [aviheader] Video stream found, -vid 0 [aviheader] Audio stream found, -aid 1 VIDEO: [DX50] 512x384 24bpp 25.000 fps 769.8 kbps (94.0 kbyte/s) === Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4) === === Forced audio codec: mad Opening audio decoder: [libmad] libmad mpeg audio decoder AUDIO: 11025 Hz, 1 ch, s16le, 8.0 kbit/4.54% (ratio: 1000-22050) Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3) === AO: [oss] 11025Hz 1ch s16le (2 bytes per sample) Starting playback... -- messages: 3883 priority: normal status: new substatus: new title: mp1 audio file plays too fast type: bug __ FFmpeg issue tracker ffmpeg_iss...@live.polito.it https://roundup.mplayerhq.hu/roundup/ffmpeg/issue762 __
