Well, in fact I'm not actually trying to encode or decode. I'm trying to open a saved video to process it frame by frame. Is there another way to do this with opencv and without ffmpeg?
I have just followed every step in the page you linked with the same result. Executing the following, I get the output: # pkg-config --libs ffmpeg -L/opt/ffmpeg/lib -lavcodec -lavdevice -lavformat -lavutil Thanks and regards. Jose -------- Original Message -------- Subject: Re: Porting OpenCV to DM6446 Date: Mon, 30 Jun 2008 22:39:15 +0200 From: Andre Gaschler <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: Davinci-linux-open-source@linux.davincidsp.com Hi Jose, sorry, I have not used opencv for video encoding and decoding yet on the davinci. (Isn't that what the DSP is for? ;-) There are many general explanations on installing opencv+ffmpeg, though: http://freeshells.ch/~phoenix/ocv.htm Does the configure script ignore ./configure --with-ffmpeg ?? What does pkg-config --libs ffmpeg say? best regards Andre [EMAIL PROTECTED] schrieb: > Hi Andre. > > I finally did the easy way. I patched the function by removing its content. > > Now I'm trying to open an avi file by using cvCaptureFromFile, but it > doesn't seem to work. I traced it and found out that no HAVE_VFW, XINE, > FFMPEG or QUICKTIME were defined because no one of them was installed on > the target. So I tried to install FFMPEG on it, and did it successfully. > > But when I executed again the opencv's configure script to recompile the > library with ffmpeg support, I realize that ffmpeg wasn't detected. > > I was able to let configure to know about the presence of the ffmpeg > includes directory, so it generated the following output: > > checking ffmpeg/avcodec.h usability... yes > checking ffmpeg/avcodec.h presence... yes > checking for ffmpeg/avcodec.h... yes > > But finally, in the HighGUI configuration summary, the result was the same: > > Use ffmpeg: no > > I don't know what I'm doing wrong or even if there is a simpler solution > to open an avi file with opencv... > > > Thanks in advance and best regards. > Jose > > > -------- Original Message -------- > Subject: Re: Porting OpenCV to DM6446 > Date: Tue, 20 May 2008 13:30:45 +0200 > From: Andre Gaschler <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > CC: Davinci-linux-open-source@linux.davincidsp.com > > > Hi Jose, > > > I also stuck at that point. I am sure that the error is due to the old > compiler version of the arm-gcc. What you can most easily do is using an > older version of opencv or > simply remove the contents of the function icvPyrSegmentation (of course > keeping a "return CV_OK"). Fortunately, this is the only function in the > compile process that doesnt work and most algorithms do not need it. > If you really want to solve the problem, I would recommend to > - get a new compiler toolchain, which involves compiling gcc and takes a > lot of time if one has never done it before (who knows, maybe its enough > to download the newest version from ti.com??) important: the davinci > architecture is not arm-linux but arm_v5t_le- ! > - or write a patch for this opencv funtion (you never know, can be easy > or impossible) > Both takes some time so I have not tried so far, because my face > recognition algorithms do not need the function at all. > > I am most interested in how you solve the problem - especially when you > get a new gcc working it would be great to hear how that is done! > > > By the way, I am still working on porting some opencv functions to the > DSP. I have integrated the bigphysarea patch into the montavista kernel > and rewritten CMEM to dynamically allocate physical memory. And, dsplink > messages are working now. But, of course, it will take some time to > implement it properly. Hopefully, matrix multiplication or at least > convolution on the real opencv matrix structures will work in a two or > three weeks. > > > > -- Andre > > > > [EMAIL PROTECTED] wrote: > >> Hi Andre, >> >> I'm trying to complete the first step you mentioned, i.e. "make (i) Opencv >> work on the ARM-montavista-linux (which I did quite quickly)". >> >> When I try to compile the OpenCV sources, I get the following error >> compiling cv/src/cvpyrsegmentation.cpp >> >> if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. >> -I. -I../.. -I. -I../../cv/include -I../../cxcore/include -I../.. >> -DNDEBUG -Wall -fno-rtti -pipe -O3 -fomit-frame-pointer -MT >> cvpyrsegmentation.lo -MD -MP -MF ".deps/cvpyrsegmentation.Tpo" -c -o >> cvpyrsegmentation.lo cvpyrsegmentation.cpp; \ >> then mv -f ".deps/cvpyrsegmentation.Tpo" ".deps/cvpyrsegmentation.Plo"; >> else rm -f ".deps/cvpyrsegmentation.Tpo"; exit 1; fi >> g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I. -I../../cv/include >> -I../../cxcore/include -I../.. -DNDEBUG -Wall -fno-rtti -pipe -O3 >> -fomit-frame-pointer -MT cvpyrsegmentation.lo -MD -MP -MF >> .deps/cvpyrsegmentation.Tpo -c cvpyrsegmentation.cpp -fPIC -DPIC -o >> .libs/cvpyrsegmentation.o >> cvpyrsegmentation.cpp: In function `CvStatus >> icvPyrSegmentation8uC3R(uchar*, int, uchar*, int, CvSize, CvFilter, >> CvSeq**, CvMemStorage*, int, int, int)': >> cvpyrsegmentation.cpp:1021: internal compiler error: in >> verify_local_live_at_start, at flow.c:546 >> Please submit a full bug report, >> with preprocessed source if appropriate. >> Send email to MontaVista Software, Inc. for instructions. >> make[3]: *** [cvpyrsegmentation.lo] Error 1 >> make[3]: Leaving directory `/home/opencv/tmp/opencv-1.0.0/cv/src' >> make[2]: *** [all-recursive] Error 1 >> make[2]: Leaving directory `/home/opencv/tmp/opencv-1.0.0/cv' >> make[1]: *** [all-recursive] Error 1 >> make: *** [all] Error 2 >> make[1]: Leaving directory `/home/opencv/tmp/opencv-1.0.0' >> >> >> Do you know something about it? >> >> Thanks in advance and regards. >> Jose >> >> >> >> -------- Original Message -------- >> Subject: Porting OpenCV to DM6446 >> Date: Fri, 09 May 2008 13:08:32 +0200 >> From: Andre Gaschler <[EMAIL PROTECTED]> >> To: davinci-linux-open-source@linux.davincidsp.com >> >> >> Hello, >> >> in the previous weeks I have been working on porting OpenCV to the >> DM6446. The main target is to make (i) Opencv work on the >> ARM-montavista-linux (which I did quite quickly) (ii) Opencv use some >> DSP power, namely for those very basic matrix operations. If anybody >> does not know Opencv, its basically a computer vision C library >> originally made for i86. It both provides basic math and matrix >> operations and very newly researched computer vision algorithms. >> >> For now, my main target is to allocate opencv matrix data in common >> memory of the DM6446 and rewrite and encapsulate i.e. the matrix >> multiplication function of opencv so it calls a procedure on DSP side >> (pointers to the matrices by-reference). So, basically I only need (i) >> remote procedure calls and (ii) nice access to common memory. >> >> For the former, I am experimenting with DSPLINK that seems to serve nice >> remote procedure calls. Do you think it is right not to use the Codec >> Engine. What Ive heard CE is specialized on stream processind and >> DSPLINK with its modules PROC and NOTIFY/MSGQ is more appropriate for >> "normal" RPCs. >> >> For the latter, I cannot really agree with the tools TI provides. I >> tested DSPLINK POOL, that only serves fixed size pools that have to be >> determines at boot/compile time. The same goes for CMEM (which DSPLINK >> uses I think(?)). The memory pools are a good idea for DSP algorithms >> with fixed worst-case memory requirements. But not for usual computer >> vision algorithms that firstly use *lots* of structures you are not >> going to allocate pools for and secondly, do not have fixed requirements >> in general. >> My most important questions are >> - do think its a good idea in general to port opencv to the DM6446 >> - is there *anything* that can *dynamically* allocate memory (not in >> pre-defined pools) so both ARM and DSP can work on it without copying??? >> >> Ive got the impression since the DSP does not have a memory management >> unit it has got to work on (huge) chunks of continuous physical memory. >> Because if there is no means for dynamically allocate continuous >> physical memory I will write a linux kernel module for that (that >> replaces CMEM). >> >> Andre >> _______________________________________________ >> Davinci-linux-open-source mailing list >> Davinci-linux-open-source@linux.davincidsp.com >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source >> >> > > _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
