Hmmm how about a PDP version using altivec. :)
A great framework for a number of things (like pix_trees?) :)
Ben
----- Original Message ----- From: /voldemars / d9 voldemars@parks.lv Date: Wednesday, January 8, 2003 9:20 pm Subject: [PD] Re: [PD-announce] PiDiP version 0.6.1 [ motion detection ]
on 09.01.03 03:52, Yves Degoyon at ydegoyon@free.fr wrote:
anyone's planning to port PiDiP for OSX use? point-to-point video communication sounds soo good.
/v
hi,
that's now PiDiP v0.6.1, i added the following objects :
pdp_mgrid : grid-based motion detection
it allows you to trigger some funny things whenever something moves in a region of the captured image ))
pdp_o/pdp_i : PD to PD streaming
it allows you to send your video processed data to a peer running PD ( linux ), so it's not really streaming, just point-to-point communication. it also requires a huge bandwidth, i'll optimize it soon.
- doing an object for MPG4 streaming is not that easy ...
enjoy !!
sevy/yves
PD-announce mailing list PD-announce@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-announce
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On Thursday, January 9, 2003, at 04:27 AM, bbogart@ryerson.ca wrote:
Hmmm how about a PDP version using altivec. :)
in the long run maybe :) the plan is to port the mmx stuff to c (c++) first and to add a general x-window output object (right now, only xv), so it at least works for all linux targets.
the prob for the mac pdp port is that it is pretty much tied to linux for the input output stuff right now. i don't know if libquicktime compiles for osx, this would sure make things easier.. for live video input/output on osx, i am pretty much in the dark. if someone has the drive and knowlegde to do the io for osx, i'd be more than happy to add altivec stuff :)
tom
Tom Schouten said this at Thu, 9 Jan 2003 13:26:08 +0100:
the prob for the mac pdp port is that it is pretty much tied to linux for the input output stuff right now. i don't know if libquicktime compiles for osx, this would sure make things easier.. for live video input/output on osx, i am pretty much in the dark. if someone has the drive and knowlegde to do the io for osx, i'd be more than happy to add altivec stuff :)
Hmm... Seems to me that libquicktime on Mac OS X should just be a compatibility layer, adapting lqt calls to real, native QuickTime calls. The lqt codecs wouldn't require much attention at all, then. Have any pointers to which API calls you would actually use?
Then again, why not a native QuickTime external, perhaps based on QuickTimeTcl (once it's more stable...)? http://hem.fyristorg.com/matben/qt/
adam
Hmm... Seems to me that libquicktime on Mac OS X should just be a compatibility layer, adapting lqt calls to real, native QuickTime calls. The lqt codecs wouldn't require much attention at all, then. Have any pointers to which API calls you would actually use?
for decoding, have a look at modules/pdp_qt.c in the tarball (http://zwizwa.fartit.com/pd/pdp/) the encoder object is in yves' pidip lib (http://ydegoyon.free.fr/) in modules/pdp_rec.c
Then again, why not a native QuickTime external, perhaps based on QuickTimeTcl (once it's more stable...)?
since it just decodes the video (and audio) for a specific frame, and converts to the internal format, a native object is probably easier indeed. conversion are in the pdp framework (system/pdp_llconv.c ; not entirely mmx free yet..)
tom
in the long run maybe :) the plan is to port the mmx stuff to c (c++) first and to add a general x-window output object (right now, only xv), so it at least works for all linux targets.
i'm afraid these are the strengths of PDP and that xv is much faster than a general X-window output. You don't have to remove xv, it's now in the official XFree86.
also, these are the reasons why i got into PDP and not in GEM, because it can run with a decent framerate on an ordinary machine, e.g. not hardware accelerated.
cheers,
sevy/yves
in the long run maybe :) the plan is to port the mmx stuff to c (c++) first and to add a general x-window output object (right now, only xv), so it at least works for all linux targets.
having all the code available as C or C++ will make it much easier for someone to port.
the prob for the mac pdp port is that it is pretty much tied to linux for the input output stuff right now. i don't know if libquicktime compiles for osx, this would sure make things easier.. for live video input/output on osx, i am pretty much in the dark. if someone has the drive and knowlegde to do the io for osx, i'd be more than happy to add altivec stuff :)
there is really no point in doing libquicktime on OSX since it has the real thing. libquicktime really has nothing in common with the mac quicktime api apart from reading the file format and decoding a very small percentage of the available quicktime codecs. it's quite easy to add quicktime video to an app, it's about 10 lines of code. plus, there are a ton of other goodies covered by quicktime.
so tom, how are your altivec skills? i'm going to dive back into it next week.
cgc
tom
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
having all the code available as C or C++ will make it much easier for someone to port.
i started working on separating the mmx stuff from the rest of the code. now a c/altivec port looks a bit more feasible.
there is really no point in doing libquicktime on OSX since it has the real thing <snip>
if you want to have a go, please do! i am preparing the code so at least the framework will run compile and run without mmx, with some modules doing nothing. so if you want to give it a try, let me know.
so tom, how are your altivec skills? i'm going to dive back into it next week.
ready to be tested :) i've never gotten to actually write ppc assembly though. but porting my mmx stuf to altivec seems not that hard. i think all mmx instructions have a mirror in altivec (and more). the only thing that would change is the vector size, the rest can be solved in the c glue code upstream..
tom