[issue2004] libavutil/common.h needs stdint.h #define __STDC_CONSTANT_MACROS
Bill Morris mor...@ee.ccny.cuny.edu added the comment: If c++ is not a concern then I think that it would make sense to just add #include stdint.h to /usr/local/include/libavutil/common.h There are other files in ffmpeg have it included, so common.h should probably have it included as well. I can add the __STDC_CONSTANT_MACROS to the application. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2004
[issue2004] libavutil/common.h needs stdint.h #define __STDC_CONSTANT_MACROS
Reimar Döffinger b...@reimardoeffinger.de added the comment: On Sun, Jun 13, 2010 at 06:23:13AM +, Bill Morris wrote: If c++ is not a concern then I think that it would make sense to just add #include stdint.h to /usr/local/include/libavutil/common.h There are other files in ffmpeg have it included, so common.h should probably have it included as well. common.h includes inttypes.h, which is required to include stdint.h (I think even in a C++ context). Is a separate stdint.h include really required on your system? If yes, please give us details, because this then probably isn't the only places that would need to be adapted. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2004
[issue2004] libavutil/common.h needs stdint.h #define __STDC_CONSTANT_MACROS
Bill Morris mor...@ee.ccny.cuny.edu added the comment: Sorry, I missed that stdint.h was included there. I'll close the ticket. -- status: new - closed substatus: new - wont_fix FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2004
[issue2004] libavutil/common.h needs stdint.h #define __STDC_CONSTANT_MACROS
Mans Rullgard m...@mansr.com added the comment: Fix substatus. -- Måns Rullgård m...@mansr.com -- substatus: wont_fix - invalid FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2004
[issue1993] Conversion of quicktime reference files
Attila Kinali att...@kinali.ch added the comment: directory renamed to issue1993_quicktime-reference to match naming guidelines FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1993
[issue2005] FFplay displays random data for audio in mono files.
New submission from Ramiro Polla ram...@lisha.ufsc.br: ffplay any mono audio-only file, you will get the actual rdft of the only channel in pink, and green straight horizontal lines of random data for the other supposed channel. -- messages: 10792 priority: normal status: new substatus: new title: FFplay displays random data for audio in mono files. type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2005
[issue1957] video frame cut instead of scaled when cropping input
blindbunny ffmpegbugs.10.noonee...@spamgourmet.com added the comment: I'm seeing the very same problem. The command ffmpeg -i src.mkv -s 400x320 -vcodec libx264 -vpre hq -crf 20 -an -sn scaled.mkv -vframes 10 scales the input down to 400x320 as expected. But the command ffmpeg -i src.mkv -cropbottom 1 -s 400x320 -vcodec libx264 -vpre hq -crf 20 -an -sn scaled.mkv -vframes 10 crops the input to 400x320. This is with a subversion snapshot from 2010-05-13. You find the samples used/produced by the above commands in upload.ffmpeg.org/MPlayer/incoming/1957/ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1957
[issue1957] video frame cut instead of scaled when cropping input
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: Please confirm that this only happens with x264 and test --disable- libavfilter and provide complete, uncut output of your command line. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1957
