gcc -I/usr/src/ffmpegscript/ffmpeg/ test.c -L/usr/src/ffmpegscript/ffmpeg/
-l avformat
发件人: libav-user-boun...@ffmpeg.org [mailto:libav-user-boun...@ffmpeg.org]
代表 sangeeta chowdhary
发送时间: 2013年1月14日 16:00
收件人: This list is about using libavcodec, libavformat, libavutil,
libavdevice and libavfi
[root@node2 ffmpeginstaller.7.4]# gcc -I/usr/src/ffmpegscript/ffmpeg/
test.c -L/usr/src/ffmpegscript/ffmpeg/ -l avformat
/usr/bin/ld: cannot find -lavformat
collect2: ld returned 1 exit status
On Mon, Jan 14, 2013 at 1:34 PM, 吴立明 Joy Woo wrote:
> gcc -I/usr/src/ffmpegscript/ffmpeg/ test.c -L/us
Hi Team,
Which library I am missing ?
[root@node2 ffmpeginstaller.7.4]# gcc -I/usr/src/ffmpegscript/ffmpeg/
test.c -L/usr/src/ffmpegscript/mplayer/ffmpeg/libavformat/ -lavformat
-L/usr/src/ffmpegscript/mplayer/ffmpeg/libavcodec/ -lavcodec
-L/usr/src/ffmpegscript/mplayer/ffmpeg/libswscale/ -lswsca
put attach files into ffmpeg source dir or tests dir, run tst_gxx.sh
g++ -I.. -I. -D__STDC_CONSTANT_MACROS -c -o tst_gxx.o tst_gxx.cpp
tst_gxx.cpp: In function 'int main()':
tst_gxx.cpp:5:5: error: taking address of temporary array
make: *** [tst_gxx.o] Error 1
i think we can use a inline funct
put attach files into ffmpeg source dir or tests dir, run tst_gxx.sh
g++ -I.. -I. -D__STDC_CONSTANT_MACROS -c -o tst_gxx.o tst_gxx.cpp
tst_gxx.cpp: In function 'int main()':
tst_gxx.cpp:5:5: error: taking address of temporary array
make: *** [tst_gxx.o] Error 1
i think we can use a inline funct
On Jan 14, 2013, at 11:01, Wang Bin wrote:
> > g++ 4.7.2 fails to compile av_err2strI use av_err2str
> > in a c++ file, g++ 4.7.2 can not compile it. The error
> > message is "taking address of temporary array".
>
That's a surprising error for me ... the only physical explanation for a
variable
sangeeta chowdhary writes:
> swfdec.c:(.text+0xd5d): undefined reference to `inflateInit_'
Looks like -lz is missing.
> atrac3.c:(.text.unlikely+0xb9): undefined reference to `sin'
Looks like -lm is missing.
Carl Eugen
___
Libav-user mailing list
L
I have added lz and lm, still issues
[root@node2 ffmpeginstaller.7.4]# gcc -I/usr/src/ffmpegscript/ffmpeg/
test.c -lm -lz -L/usr/src/ffmpegscript/mplayer/ffmpeg/libavformat/
-lavformat -L/usr/src/ffmpegscript/mplayer/ffmpeg/libavcodec/ -lavcodec
-L/usr/src/ffmpegscript/mplayer/ffmpeg/libswscale/ -
On Mon, Jan 14, 2013 at 12:20 PM, "René J.V. Bertin"
wrote:
>
> On Jan 14, 2013, at 11:01, Wang Bin wrote:
>>
>> > g++ 4.7.2 fails to compile av_err2strI use av_err2str
>> > in a c++ file, g++ 4.7.2 can not compile it. The error
>> > message is "taking address of temporary array".
>
> That's a sur
On Jan 14, 2013, at 11:42, Alex Cohn wrote:
>> used later on. Semantics imposed by C++?
>>
>> R.
>
> An easy test proves that adding "-x c" to command line resolves the
> problem. So it is a C++ artifact.
As I feared.
Note that the OP's tst_gxx.cpp does a simple
av_err2str(AVERROR_BUG)
sangeeta chowdhary writes:
> libmp3lame.c:(.text+0x4f): undefined reference to `lame_encode_flush'
Looks as if -lmp3lame is missing.
Please do not top-post on this mailing list, it is considered
rude, and please force your mailer to "text-only".
Carl Eugen
___
On Mon, Jan 14, 2013 at 1:31 PM, "René J.V. Bertin" wrote:
> On Jan 14, 2013, at 11:42, Alex Cohn wrote:
>>> used later on. Semantics imposed by C++?
>>>
>>> R.
>>
>> An easy test proves that adding "-x c" to command line resolves the
>> problem. So it is a C++ artifact.
>
> As I feared.
>
> Note
On Jan 14, 2013, at 13:48, Alex Cohn wrote:
> ... but I believe that the solution is simple: this macro should not
> be used in C++, that's it! Whoever needs similar functionality in g++,
> may use
>
>#undef av_err2str
>#define av_err2str(errnum) \
>av_make_error_string((char*)__built
On Mon, Jan 14, 2013 at 2:59 PM, "René J.V. Bertin" wrote:
> On Jan 14, 2013, at 13:48, Alex Cohn wrote:
>
>> ... but I believe that the solution is simple: this macro should not
>> be used in C++, that's it! Whoever needs similar functionality in g++,
>> may use
>>
>>#undef av_err2str
>>#
> Alex Wrote:
>
> Note that in terms of allocations and encoder logic, you can use nv21 input
> instead of yuv420p. The resulting video will be crap, but the encoder should
> not > crash/fail, and you can expect to receive a movie file as output. You
> can even extract nv21 frames from this movi
On Mon, Jan 14, 2013 at 6:06 PM, David Longest
wrote:
>
> I just tried creating an AVFrame and setting the pixel format to
> PIX_FMT_YUV420P while still providing NV21 data. When passing this frame to
> avcodec_encode_video2, I will still get the crash unless I allocate the
> input packet's data f
Le quintidi 25 nivôse, an CCXXI, Alex Cohn a écrit :
> Yes, alloca() should be OK. Now that I think about it, that's right:
> it is compatible with C, too.
I am far from sure that alloca() exists in all supported C compilers.
> But Microsoft compiler only recognizes
On Jan 14, 2013, at 17:49, Nicolas George wrote:
>> But Microsoft compiler only recognizes
>> _alloca().
>
> There you are.
#ifdef _MSC_VER
# define alloca(n)_alloca(n)
#endif
>
> There is another problem with alloca(): the scope of the allocation is
Le quintidi 25 nivôse, an CCXXI, "René J.V. Bertin" a écrit :
> Are you sure? I was under the impression that
>
> n = 10;
> { char *foo = (char*) alloca(n); // char foo[n] in gcc :)
> // fill foo
> printf( "%s\n", foo );
> }
>
> is equivalent to
>
> { char foo[10];
> // fill fo
On Jan 14, 2013, at 19:14, Nicolas George wrote:
>
> I checked both in the man page (from gcc+glibc) and a test program: if you
> use alloca() inside a loop, it returns a new block each time, while a
> compound literal has always the same address. The man page says:
Ok. Note however that a changi
Hello,
I've been looking at the examples on how to use ffmpeg
and I found a few issues.
Fist of all there seems to be a memory leak in
doc/examples/demuxing.c (valgrind certainly tells me that).
Freeing the AVPacket seems to resolve that issue (see the patch
attached). Hope I didn't miss anythin
Angelo Haller writes:
> Fist of all there seems to be a memory leak in
> doc/examples/demuxing.c (valgrind certainly tells me that).
> Freeing the AVPacket seems to resolve that issue (see the patch
> attached).
Please send patches to ffmpeg-devel.
Carl Eugen
__
22 matches
Mail list logo
