I am getting ready to make the Pd-extended 0.39.2 release branch. Which version of Gem should I include?
.hc
------------------------------------------------------------------------
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
I think the current CVS is a pretty good release. Jamie committed some changes yesterday for fairly advanced features which need testing, and I have some esoteric code not yet ready, but the rest of it seems pretty solid from my use.
Maybe Cyrille and some of the other people using the recent code will give their impressions.
cgc
On 11/2/06, Hans-Christoph Steiner hans@eds.org wrote:
I am getting ready to make the Pd-extended 0.39.2 release branch. Which version of Gem should I include?
The only thing that I have noticed is that the current HEAD doesn't build on Mac OS X 10.3. It was building fine until a couple weeks ago.
If you make a tag, then I can use that as the starting place for the Pd-extended branch.
.hc
On Nov 2, 2006, at 10:33 AM, chris clepper wrote:
I think the current CVS is a pretty good release. Jamie committed some changes yesterday for fairly advanced features which need testing, and I have some esoteric code not yet ready, but the rest of it seems pretty solid from my use.
Maybe Cyrille and some of the other people using the recent code will give their impressions.
cgc
On 11/2/06, Hans-Christoph Steiner hans@eds.org wrote:
I am getting ready to make the Pd-extended 0.39.2 release branch. Which version of Gem should I include?
------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
On 11/2/06, Hans-Christoph Steiner hans@eds.org wrote:
The only thing that I have noticed is that the current HEAD doesn't build on Mac OS X 10.3. It was building fine until a couple weeks ago.
The Altivec code? That is a mystery since I have built that on using Apple's GCC 3.3 on 10.4.
What is your plan for binaries? OSX 10.3 and 10.4 versions with/without Altivec? What about Windows i386 and i686 with and without SSE?
If you make a tag, then I can use that as the starting place for the
Pd-extended branch.
We will wait until the other two agree with the tag point and some people in the field confirming that something critical isn't horribly broken.
cgc
On Nov 2, 2006, at 10:49 AM, chris clepper wrote:
On 11/2/06, Hans-Christoph Steiner hans@eds.org wrote:
The only thing that I have noticed is that the current HEAD doesn't build on Mac OS X 10.3. It was building fine until a couple weeks ago.
The Altivec code? That is a mystery since I have built that on using Apple's GCC 3.3 on 10.4.
What is your plan for binaries? OSX 10.3 and 10.4 versions with/ without Altivec? What about Windows i386 and i686 with and without SSE?
I was planning on just one release per platform. In the long run, we could provide CPU-specific builds, but its too much work for me right now. If anyone wants to take that project on, I would gladly help. Basically, there needs to be a standardized method of specifying optimization flags. This is working the pd/src/makefile and externals/Makefile now, but things that aren't based on that don't get the flags (cyclone, zexy, Gem, pdp, pidip,...).
Most of what is involved is just having standard names for a Makefile variable for the optimization flags. Then the necessary variables can be easily overridden from the Makefile that calls the others. Check packages/*/Makefile for examples. Right now, that standard name is OPT_CFLAGS.
.hc
If you make a tag, then I can use that as the starting place for the Pd-extended branch.
We will wait until the other two agree with the tag point and some people in the field confirming that something critical isn't horribly broken.
cgc
------------------------------------------------------------------------
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
chris clepper a écrit :
I think the current CVS is a pretty good release. Jamie committed some changes yesterday for fairly advanced features which need testing, and I have some esoteric code not yet ready, but the rest of it seems pretty solid from my use.
Maybe Cyrille and some of the other people using the recent code will give their impressions.
i just compile the curent cvs. all my patch look like working perfectly. jamie multitexture test patch work, i did not try yet to use it with glsl.
i work very few with video, so i did not have fully tested movie , webcam etc.
gem is perfectly stable on my computer for what i 'm doing. so, curent cvs is the best GEM release ever for my use.
i'll try to make more test soon.
cyrille
cgc
On 11/2/06, Hans-Christoph Steiner hans@eds.org wrote:
I am getting ready to make the Pd-extended 0.39.2 release branch. Which version of Gem should I include?
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
second try, as yesterday my machine went down due to thermal issue...
cyrille henry wrote:
Maybe Cyrille and some of the other people using the recent code will give their impressions.
i just compile the curent cvs. all my patch look like working perfectly. jamie multitexture test patch work, i did not try yet to use it with glsl.
i work very few with video, so i did not have fully tested movie , webcam etc.
gem is perfectly stable on my computer for what i 'm doing. so, curent cvs is the best GEM release ever for my use.
i'll try to make more test soon.
great.
i have checked in some more code 3 days ago (1 day after jamies multitexture stuff). actually there are 3 different changes involved: 1. [pix_texture]: improved the texture sharing a lot; you can now connect the 2nd outlet of on [pix_texture] (with a valid texture) with the 2nd inlet of another [pix_texture] (without a texture) to share textures between various gemlists. i would like to use the same mechanism (sharing of more information than just the texture-id) in [pix_multitexture] too 2a. video4linux: i made the v4l-1 code work with my usb cam; however i have to check back with normal capture cards (hopefully i haven't re-introduced the bug cyrille noticed at the end of last year) 2b. video4linux2: at least i can now grab the image from a v4l2 device (i think that some things like changing channel won't work; and i know that some things, like changing resolution, don't work) 3. i added post(), error() and verbose() functions to the CPPExtern class, which automatically prepend the object's name to any posted message (and in the case of error() also use pd_error() so that the object is findable). this change means that in static class functions (e.g. callbacks) we have to either call pd's native post() with "::post()" or the object's post with "GetMyClass(data)->post()"; i hope that i have fixed all occurences of calls to unspecified post()s (at least it compiles on os-x and linux, but i might have missed some on w32-only code)
mfg.ar IOhannes
Hello,
IOhannes m zmoelnig a écrit :
second try, as yesterday my machine went down due to thermal issue...
cyrille henry wrote:
Maybe Cyrille and some of the other people using the recent code will give their impressions.
i just compile the curent cvs. all my patch look like working perfectly. jamie multitexture test patch work, i did not try yet to use it with glsl.
i work very few with video, so i did not have fully tested movie , webcam etc.
gem is perfectly stable on my computer for what i 'm doing. so, curent cvs is the best GEM release ever for my use.
i'll try to make more test soon.
great.
i have checked in some more code 3 days ago (1 day after jamies multitexture stuff). actually there are 3 different changes involved:
- [pix_texture]: improved the texture sharing a lot; you can now
connect the 2nd outlet of on [pix_texture] (with a valid texture) with the 2nd inlet of another [pix_texture] (without a texture) to share textures between various gemlists.
this is great and usefull. the exemple work perfectly.
i would like to use the same mechanism (sharing of more information than just the texture-id) in [pix_multitexture] too 2a. video4linux: i made the v4l-1 code work with my usb cam; however i have to check back with normal capture cards (hopefully i haven't re-introduced the bug cyrille noticed at the end of last year)
i pluged my 2 webcam and perform some test with pix_video : it is now very solid. i can plug, unplug cam, create, destroy gemwin, change between device etc without problem. so it's perfect i think. (i just have 1 small problem with my philips webcam that convert red to blue and blue to yellow, but that's not a gem specific problem).
2b. video4linux2: at least i can now grab the image from a v4l2 device (i think that some things like changing channel won't work; and i know that some things, like changing resolution, don't work)
i can't test this
- i added post(), error() and verbose() functions to the CPPExtern
class, which automatically prepend the object's name to any posted message (and in the case of error() also use pd_error() so that the object is findable). this change means that in static class functions (e.g. callbacks) we have to either call pd's native post() with "::post()" or the object's post with "GetMyClass(data)->post()"; i hope that i have fixed all occurences of calls to unspecified post()s (at least it compiles on os-x and linux, but i might have missed some on w32-only code)
ok, great.
i made some test with pix_film and pix_movie. both crash when loading some movie, but work with other files. depending on the movie, right inlet does not set curent frame, but increase frame position.
pix_record works, but crash easilly. it will crash if the file can not be created (already exist, or if the directory does not exist etc). it can also crash for other (unknown) reason.
there is still some things that i did not understand with pix_record: 1st : does it create only 20fps file? 2nd : after recording a 1024x768 movie, quick time and vlc read it correctly, but ubuntu see it as a 1024x384 movie. (i already see this with other tools, so it can be a ubuntu specific problem.) anyway, i found a better solution to record my work so i don't use pix_record.
every other stuff look perfect.
i've got on my wish list :
- better optimisation when reading a movie with "auto 1" (sequential reading.) if popssible (as Iohannes explain me on an other mail.) - a better primitive to draw 3d curve (it's on my todolist for years, i don't know what the best solution is : using the glu nurbs? doing everything from scratch? or find some other lib?) - a better suport (or exemple) of various buffer utilisation (stencil, accumulation) - multiples rendering windows (what is the curent developement state?)
I make all test with ubuntu dapper and nvidia binary drivers. i'll try again all of this with ubuntu edgy in 1 or 2 week.
Cyrille
mfg.ar IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
cyrille henry wrote:
- [pix_texture]: improved the texture sharing a lot; you can now
connect the 2nd outlet of on [pix_texture] (with a valid texture) with the 2nd inlet of another [pix_texture] (without a texture) to share textures between various gemlists.
this is great and usefull. the exemple work perfectly.
oh, i just noticed that i haven't updated the example-file. since my last changes, the use of [pix_coordinate] is not necessary any more (since this is handled by the more complex tex-id message); this also means that you can now switch between normalized and rectangle textures in the parent [pix_texture], and the childs will automatically adapt themselves.
i pluged my 2 webcam and perform some test with pix_video : it is now very solid. i can plug, unplug cam, create, destroy gemwin, change between device etc without problem.
wow
so it's perfect i think. (i just have 1 small problem with my philips webcam that convert red to blue and blue to yellow, but that's not a gem specific problem).
some drivers claim that they can do RGB while they really provide BGR only.
2b. video4linux2: at least i can now grab the image from a v4l2 device (i think that some things like changing channel won't work; and i know that some things, like changing resolution, don't work)
i can't test this
i guess it will be some time till v4l2 becomes standard in Gem.
i made some test with pix_film and pix_movie. both crash when loading some movie, but work with other files.
do you have any small crasher examples so i could give it a try? could you send me the printout of pd before it crashes?
depending on the movie, right inlet does not set curent frame, but increase frame position.
this should only be the case when using libmpeg1 for decoding mpeg-videos. libmpeg1 simply doesn't support seeking, so i don't know what to do. libmpeg3 can do seeking, but you have to create a toc-file first and load this one instead. e.g. "~> mpeg3toc alea.mpg alea.toc" and then load "alea.toc" into [pix_film]
pix_record works, but crash easilly. it will crash if the file can not be created (already exist, or if the directory does not exist etc). it can also crash for other (unknown) reason.
that is interesting and bad to hear. i know that [pix_record] is rather picky about the codecs (i am only able to use ~3 of 12 installed codecs without crashes).
there is still some things that i did not understand with pix_record: 1st : does it create only 20fps file?
right, 20fps is currently hardcoded. this should be changed sometime (in the meantime i guess that there are some tools where you can (re)set the framerate of an existing file)
2nd : after recording a 1024x768 movie, quick time and vlc read it correctly, but ubuntu see it as a 1024x384 movie. (i already see this with other tools, so it can be a ubuntu specific problem.)
you mean vlc on ubuntu cannot display it correctly or some ubuntu-specific player cannot do it?
anyway, i found a better solution to record my work so i don't use pix_record.
please share your ideas.
mfg.adr IOhannes
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
- [pix_texture]: improved the texture sharing a lot; you can now
connect the 2nd outlet of on [pix_texture] (with a valid texture) with the 2nd inlet of another [pix_texture] (without a texture) to share textures between various gemlists.
this is great and usefull. the exemple work perfectly.
oh, i just noticed that i haven't updated the example-file. since my last changes, the use of [pix_coordinate] is not necessary any more (since this is handled by the more complex tex-id message); this also means that you can now switch between normalized and rectangle textures in the parent [pix_texture], and the childs will automatically adapt themselves.
ok. cool.
[...]
i made some test with pix_film and pix_movie. both crash when loading some movie, but work with other files.
do you have any small crasher examples so i could give it a try?
you can find differents movie in
http://dr.pichon.free.fr/temp/
they all crash pix_movie on my computer.
could you send me the printout of pd before it crashes?
cyrille@nusmuk:~$ pd pd/Gem/help/pix_movie.pd quicktime_delete_vcodec_stub called <init> : Avifile RELEASE-0.7.44-060114-13:42-(Ubuntu <init> : Available CPU flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2 <init> : 4294.97 MHz Intel(R) Pentium(R) M processor 2.13GHz detected <reader> : Checking: /data/video/DF13214123.MOV GUID type 0 20000000-7466-7079-7174-202020050300 <ASF reader> : Object: error - object size: 538997849 <ASF reader> : Not ASF stream <ASX reader> : Not a redirector! <ASF network reader> : Not an URL <FF reader> : Format QuickTime/MPEG4 format streams:2 <FF reader> : S: 0 id:11000 bitrate:0 (8000000) samprate:44100 chn:2 framerate:0/1 wxh 0x0 0/1 <FF stream> : Starttime: 0 Duration: 27027027 <FF reader> : S: 1 id:5 bitrate:0 (8000000) samprate:0 chn:0 framerate:1/2997 wxh 320x230 0/1 <FF stream> : Starttime: 0 Duration: 27027027 <reader> : Initialized video stream (chunk tblsz: 0, fmtsz: 40) <FF reader> : readPacket() <FF reader> : stream:1 n:1 d:2997 p:156239 d:1068 dur:0 p:4200 <codec keeper> : Found 5 plugins (/usr/lib/avifile-0.7,A:22,V:27) <FFMPEG video decoder> : looking h263 <codec keeper> : Created video decoder: FF H263+ SEEKPOS 0 <FF reader> : readPacket() <FF reader> : stream:0 n:1 d:44100 p:1e8f0a d:158ff dur:0 p:88319 <FF reader> : readPacket() <FF reader> : stream:1 n:1 d:2997 p:1666e6 d:1130 dur:0 p:4400 <ffh263> : not using DR1 [h263 @ 0xb6c85ee4]warning: first frame is no keyframe pd_gui: pd process exited Erreur de segmentation
depending on the movie, right inlet does not set curent frame, but increase frame position.
this should only be the case when using libmpeg1 for decoding mpeg-videos. libmpeg1 simply doesn't support seeking, so i don't know what to do. libmpeg3 can do seeking, but you have to create a toc-file first and load this one instead. e.g. "~> mpeg3toc alea.mpg alea.toc" and then load "alea.toc" into [pix_film]
ok. that would be nice to put this on the help file.
btw : the last trick you told me about selecting a specifig codec when loading a movie is not on the help file.
pix_record works, but crash easilly. it will crash if the file can not be created (already exist, or if the directory does not exist etc). it can also crash for other (unknown) reason.
that is interesting and bad to hear. i know that [pix_record] is rather picky about the codecs (i am only able to use ~3 of 12 installed codecs without crashes).
ok
there is still some things that i did not understand with pix_record: 1st : does it create only 20fps file?
right, 20fps is currently hardcoded. this should be changed sometime (in the meantime i guess that there are some tools where you can (re)set the framerate of an existing file)
using an external tool to change framerate of a movie is not very user friendy...
2nd : after recording a 1024x768 movie, quick time and vlc read it correctly, but ubuntu see it as a 1024x384 movie. (i already see this with other tools, so it can be a ubuntu specific problem.)
you mean vlc on ubuntu cannot display it correctly or some ubuntu-specific player cannot do it?
vlc read it correctly. but the ubuntu player does not. right click + property on the file give a file dim of 1024x384. could you try to download this file :
http://dr.pichon.free.fr/temp2/
and tell me if it's a 4:3 movie?
anyway, i found a better solution to record my work so i don't use pix_record.
please share your ideas.
well. a standard computer can not display a complex scenne and record it to the HD with good quality (at least 50fps, 1024x768) in Real Time. so the solution is not to do it in real time!
i'm made very small abstraction that replace pd time related objects. So i replace all line, delay, pipe with _line, _delay, _pipe. this abstractions react exactly like the originals object, exept that they receive a time-scale-factor. so all the patch can be slow down by a 10 factor by exemple.
i also made a rec_play abstraction that record everything it receive in a qlist, and play everything later. this rec_play abstraction share the same time-scale-factor as _line etc.
so, i just record data generated by a live performance. i can play exactely the same stuff in real time to record sound. then play a second time with a 10 time slow down to record all images in full quality.
last, a few command line gives me a very big file with sound and images.
i nead some time to clean up everything in order to share a good example. do you think i should just send it to the list, or upload it somewhere in the cvs?
my problem now is : how to have a 1h good quality movie to fit in a 4.7Go DVD :-)
cyrille
mfg.adr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
cyrille henry wrote:
IOhannes m zmoelnig a écrit :
cyrille henry wrote: do you have any small crasher examples so i could give it a try?
you can find differents movie in
http://dr.pichon.free.fr/temp/
they all crash pix_movie on my computer.
one of them runs fine (DF13214123.MOV) here, 2 just produce nice noise (threads-vid-3.mov, sable.mp4). however, pdpod.avi crashes; this made me think of something and i checked back with the configure-output you sent a while ago, and lo and behold! it seems you are using libmpeg1. when found, this is used as a last resort (when all other available libs failed), because i was never able to make it stable (it often crashes when it is not able to open a file correctly). since you also have libmpeg3 installed, there is usually no need for libmpeg1; i would disable it entirely (with "--disable-mpeg")
this will stop Gem from crashing (but you still won't be able to get useful information from these files)
i don't want to disable libmpeg1 entirely (for people who don't have e.g. libmpeg3)
mfgasdr. IOhannes
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
IOhannes m zmoelnig a écrit :
cyrille henry wrote: do you have any small crasher examples so i could give it a try?
you can find differents movie in
http://dr.pichon.free.fr/temp/
they all crash pix_movie on my computer.
one of them runs fine (DF13214123.MOV) here, 2 just produce nice noise (threads-vid-3.mov, sable.mp4). however, pdpod.avi crashes; this made me think of something and i checked back with the configure-output you sent a while ago, and lo and behold! it seems you are using libmpeg1. when found, this is used as a last resort (when all other available libs failed), because i was never able to make it stable (it often crashes when it is not able to open a file correctly). since you also have libmpeg3 installed, there is usually no need for libmpeg1; i would disable it entirely (with "--disable-mpeg")
ok, i just unistall it. now : DF13214123.MOV still crash, and the other just don't load (so it's ok).
cyrille@nusmuk:~$ pd pd/Gem/help/pix_movie.pd quicktime_delete_vcodec_stub called <init> : Avifile RELEASE-0.7.44-060114-13:42-(Ubuntu <init> : Available CPU flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2 <init> : 4294.97 MHz Intel(R) Pentium(R) M processor 2.13GHz detected <reader> : Checking: /data/video/DF13214123.MOV GUID type 0 20000000-7466-7079-7174-202020050300 <ASF reader> : Object: error - object size: 538997849 <ASF reader> : Not ASF stream <ASX reader> : Not a redirector! <ASF network reader> : Not an URL <FF reader> : Format QuickTime/MPEG4 format streams:2 <FF reader> : S: 0 id:11000 bitrate:0 (8000000) samprate:44100 chn:2 framerate:0/1 wxh 0x0 0/1 <FF stream> : Starttime: 0 Duration: 27027027 <FF reader> : S: 1 id:5 bitrate:0 (8000000) samprate:0 chn:0 framerate:1/2997 wxh 320x230 0/1 <FF stream> : Starttime: 0 Duration: 27027027 <reader> : Initialized video stream (chunk tblsz: 0, fmtsz: 40) <FF reader> : readPacket() <FF reader> : stream:1 n:1 d:2997 p:156239 d:1068 dur:0 p:4200 <codec keeper> : Found 5 plugins (/usr/lib/avifile-0.7,A:22,V:27) <FFMPEG video decoder> : looking h263 <codec keeper> : Created video decoder: FF H263+ SEEKPOS 0 <FF reader> : readPacket() <FF reader> : stream:0 n:1 d:44100 p:1e8f0a d:158ff dur:0 p:88319 <FF reader> : readPacket() <FF reader> : stream:1 n:1 d:2997 p:1666e6 d:1130 dur:0 p:4400 <ffh263> : not using DR1 [h263 @ 0xb6d95ee4]warning: first frame is no keyframe pd_gui: pd process exited Erreur de segmentation
this will stop Gem from crashing (but you still won't be able to get useful information from these files)
i don't want to disable libmpeg1 entirely (for people who don't have e.g. libmpeg3)
ok
cyrille
mfgasdr. IOhannes
cyrille henry wrote:
this should only be the case when using libmpeg1 for decoding mpeg-videos. libmpeg1 simply doesn't support seeking, so i don't know what to do. libmpeg3 can do seeking, but you have to create a toc-file first and load this one instead. e.g. "~> mpeg3toc alea.mpg alea.toc" and then load "alea.toc" into [pix_film]
ok. that would be nice to put this on the help file.
actually you should get a number of warnings on the console (the "real" one, not pd's builtin console), telling you that you should create a toc with this command. it is not very generic (and it only started with a later version of libmpeg3), so i didn't put it into the help-file yet.
btw : the last trick you told me about selecting a specifig codec when loading a movie is not on the help file.
indeed, this is missing.
mfg.adsr. IOhannes
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
this should only be the case when using libmpeg1 for decoding mpeg-videos. libmpeg1 simply doesn't support seeking, so i don't know what to do. libmpeg3 can do seeking, but you have to create a toc-file first and load this one instead. e.g. "~> mpeg3toc alea.mpg alea.toc" and then load "alea.toc" into [pix_film]
ok. that would be nice to put this on the help file.
actually you should get a number of warnings on the console (the "real" one, not pd's builtin console),
ok. i'm wondering how many people still use this console...
cyrille
On Sun, 5 Nov 2006, cyrille henry wrote:
IOhannes m zmoelnig a écrit :
actually you should get a number of warnings on the console (the "real" one, not pd's builtin console),
ok. i'm wondering how many people still use this console...
It's getting problematic nowadays, because some important error messages appear only on stderr, which is discarded when students start the program from the applications menu (we're using ubuntu).
BTW, if the filename is wrong with [pix_image], where is the error message supposed to appear? I didn't see one.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Sun, 5 Nov 2006, cyrille henry wrote:
IOhannes m zmoelnig a écrit :
actually you should get a number of warnings on the console (the "real" one, not pd's builtin console),
ok. i'm wondering how many people still use this console...
It's getting problematic nowadays, because some important error messages appear only on stderr, which is discarded when students start the program from the applications menu (we're using ubuntu).
the problem is, that several libraries are writing libraries (library as in "libavifile", not as in "Gem") to the console by themselves. there is no way to catch these (well, except for redirecting the stderr); furthermore i don't even want them on the pd-console (since i cannot turn them off)
nevertheless, i strongly suggest that all pd-libs use post() instead of printf()
BTW, if the filename is wrong with [pix_image], where is the error message supposed to appear? I didn't see one.
it should definitely appear in the pd-console (with probably some additional information from the decoding libraries at the xterm)
mf.adsr. IOhannes
cyrille henry wrote:
you mean vlc on ubuntu cannot display it correctly or some ubuntu-specific player cannot do it?
vlc read it correctly. but the ubuntu player does not. right click + property on the file give a file dim of 1024x384. could you try to download this file :
http://dr.pichon.free.fr/temp2/
and tell me if it's a 4:3 movie?
hmm, i don't have ubuntu; i am using debian with kde; right-clicking in konqueror and selecting properties doesn't give me any video-related info. all players (vlc, mplayer, [pix_film], lqt-play) play it fine with 1024x768.
mg-.adr IOhannes
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
you mean vlc on ubuntu cannot display it correctly or some ubuntu-specific player cannot do it?
vlc read it correctly. but the ubuntu player does not. right click + property on the file give a file dim of 1024x384. could you try to download this file :
http://dr.pichon.free.fr/temp2/
and tell me if it's a 4:3 movie?
hmm, i don't have ubuntu; i am using debian with kde; right-clicking in konqueror and selecting properties doesn't give me any video-related info. all players (vlc, mplayer, [pix_film], lqt-play) play it fine with 1024x768.
ok. i don't know why ubuntu doesn't understand the corect size. but at least, it's not a gem problem.
cyrille
mg-.adr IOhannes
On Sun, 5 Nov 2006, IOhannes m zmoelnig wrote:
so it's perfect i think. (i just have 1 small problem with my philips webcam that convert red to blue and blue to yellow, but that's not a gem specific problem).
some drivers claim that they can do RGB while they really provide BGR only.
If blue changes to yellow, either it's a cyanish blue switch to an orangish yellow, or it's not a RGB<->BGR switch. I think that for some webcams, the neutral hueshift is 0, whereas on some others it's 32768, and that may be another possible source of confusion (?).
AFAIK, many drivers nowadays don't support RGB nor BGR, so the confusion would instead be between YUV and YVU, which looks like a RGB<->BGR confusion, but can't be fixed in exactly the same way.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
chris clepper -
cyrille henry -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard