hello,
chris clepper a écrit :
On 5/15/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
i used the gemhead to trigger the counter.
i just insert a delay 5 in order to to trig the counter between 2 frame. it look better. is it possible, or it's just because i'm fade up looking for the same movie everytime?
Maybe you were seeing some differences between the metro driven counter and the GEM render cycle? Keep in mind these objects use Pd's logical time which is in no way consistent with actual real world time.
i think we where just tired.
i'm still tring to find a solution. i don't have the computer with me anymore, so testing is not really easy.
if the hard drive is a limiting factor, maybe i can use someting faster to store the movie. a fast usbflash could be faster (osx monitor tells me that the i read the HD at maximum 4Mb/s, while fast flash usbstick can be read at 30 Mb/s).
the other solution i can imagine is to use the time object in order to get the time beween 2 frame, and compute the frame number i should get. this will not reduce the glitchs, but at last the velocity of the movy should be constant.
does anyone already tried one of this "solution"?
thanks for the help Cyrille
The 'rate' message exists because it allows Quicktime to do all of the timing for when to get frames. Pd's logical time cannot be used for this efficiently or accurately. pix_movie/film attempts to make the Quicktime timing work with Pd's time but it is not always effective.
chris clepper a écrit :
On 5/15/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
i used the gemhead to trigger the counter.
i just insert a delay 5 in order to to trig the counter between 2 frame. it look better. is it possible, or it's just because i'm fade up looking for the same movie everytime?
Maybe you were seeing some differences between the metro driven counter and the GEM render cycle? Keep in mind these objects use Pd's logical time which is in no way consistent with actual real world time.
The 'rate' message exists because it allows Quicktime to do all of the timing for when to get frames. Pd's logical time cannot be used for this efficiently or accurately. pix_movie/film attempts to make the Quicktime timing work with Pd's time but it is not always effective.
On 5/19/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
if the hard drive is a limiting factor, maybe i can use someting faster to store the movie. a fast usbflash could be faster (osx monitor tells me that the i read the HD at maximum 4Mb/s, while fast flash usbstick can be read at 30 Mb/s).
No matter how fast you played back the movie the hard disk only moved 4 MB per second? What about playing multiple movies or an uncompressed one?
That could be a hard disk problem. I have seen drives that get too hot only move about that speed. In my experience this was with large (100+ GB) transfers and the drive would move 40 MB/sec for the first few GB and then slow to 1/10 that speed. Stopping the transfer for ten minutes and letting the drive cool would resume the full speed transfer for a few minutes then slow down again.
chris clepper a écrit :
On 5/19/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
if the hard drive is a limiting factor, maybe i can use someting faster to store the movie. a fast usbflash could be faster (osx monitor tells me that the i read the HD at maximum 4Mb/s, while fast flash usbstick can be read at 30 Mb/s).
No matter how fast you played back the movie the hard disk only moved 4 MB per second?
that's what i remember
What about playing multiple movies or an uncompressed one?
i will try when i can.
That could be a hard disk problem. I have seen drives that get too hot only move about that speed. In my experience this was with large (100+ GB) transfers and the drive would move 40 MB/sec for the first few GB and then slow to 1/10 that speed.
hum, that could explain.
thanks
Cyrille
Stopping the transfer for ten minutes and letting the drive cool would resume the full speed transfer for a few minutes then slow down again.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hello,
finally, i put all movie in a fast usb flash, and it help to remove the biger problem.
then, an other problem came from the diferent rendering frequency of the gemwin (50fps) and the screen (60 or more). i now render the gemwin at 60fps, just like the screen, and the render frequency is lot's more stable. (so the video is lot's more smooth).
moreover, if i create a gemwin 200, i get a 60fps output (as openGL is sincronize to the screen) and the framerate is even more stable. unfortunatly, this halt the pd clock for audio synthesis and create audio drop at every frames.
thanks chris and everyone else for the help. it was really useful.
cyrille
cyrille henry a écrit :
chris clepper a écrit :
On 5/19/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
if the hard drive is a limiting factor, maybe i can use someting faster to store the movie. a fast usbflash could be faster (osx monitor tells me that the i read the HD at maximum 4Mb/s, while fast flash usbstick can be read at 30 Mb/s).
No matter how fast you played back the movie the hard disk only moved 4 MB per second?
that's what i remember
What about playing multiple movies or an uncompressed one?
i will try when i can.
That could be a hard disk problem. I have seen drives that get too hot only move about that speed. In my experience this was with large (100+ GB) transfers and the drive would move 40 MB/sec for the first few GB and then slow to 1/10 that speed.
hum, that could explain.
thanks
Cyrille
Stopping the transfer for ten minutes and letting the drive cool would resume the full speed transfer for a few minutes then slow down again.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 5/29/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
hello,
finally, i put all movie in a fast usb flash, and it help to remove the biger problem.
Which USB flash drive did you use? All of the ones I have used are much slower than hard drives.
then, an other problem came from the diferent rendering frequency of the gemwin (50fps) and the screen (60 or more). i now render the gemwin at 60fps, just like the screen, and the render frequency is lot's more stable. (so the video is lot's more smooth).
30 and 60 fps work best with LCD displays and projectors. Plasma and CRT have much fewer issues with the frame rate.
chris clepper a écrit :
On 5/29/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
hello,
finally, i put all movie in a fast usb flash, and it help to remove the biger problem.
Which USB flash drive did you use? All of the ones I have used are much slower than hard drives.
it's the corsair flash voyager GT. official reading speed is 34Mo/s.
then, an other problem came from the diferent rendering frequency of the gemwin (50fps) and the screen (60 or more). i now render the gemwin at 60fps, just like the screen, and the render frequency is lot's more stable. (so the video is lot's more smooth).
30 and 60 fps work best with LCD displays and projectors. Plasma and CRT have much fewer issues with the frame rate.
that's probably why i did not notice anything before connecting to the projector.
cyrille
On Sat, 2007-05-19 at 17:19 +0200, cyrille henry wrote:
hello,
chris clepper a écrit :
On 5/15/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
i used the gemhead to trigger the counter.
i just insert a delay 5 in order to to trig the counter between 2 frame. it look better. is it possible, or it's just because i'm fade up looking for the same movie everytime?
Maybe you were seeing some differences between the metro driven counter and the GEM render cycle? Keep in mind these objects use Pd's logical time which is in no way consistent with actual real world time.
i think we where just tired.
i'm still tring to find a solution. i don't have the computer with me anymore, so testing is not really easy.
if the hard drive is a limiting factor, maybe i can use someting faster to store the movie. a fast usbflash could be faster (osx monitor tells me that the i read the HD at maximum 4Mb/s, while fast flash usbstick can be read at 30 Mb/s).
the other solution i can imagine is to use the time object in order to get the time beween 2 frame, and compute the frame number i should get. this will not reduce the glitchs, but at last the velocity of the movy should be constant.
does anyone already tried one of this "solution"?
i still believe, the best solution would be to set the framerate to the movie's native framerate and then use a counter, that is triggered by [gemhead], to choose the frame. if cpu and hd are fast enough, you'll get a tight playback. if one or the other is too slow, this approach won't help, of course, and the movie is played back too slow. the question is, what does have more priority for you: playing every frame or keeping the original velocity.
roman
thanks for the help Cyrille
The 'rate' message exists because it allows Quicktime to do all of the timing for when to get frames. Pd's logical time cannot be used for this efficiently or accurately. pix_movie/film attempts to make the Quicktime timing work with Pd's time but it is not always effective.
chris clepper a écrit :
On 5/15/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
i used the gemhead to trigger the counter.
i just insert a delay 5 in order to to trig the counter between 2 frame. it look better. is it possible, or it's just because i'm fade up looking for the same movie everytime?
Maybe you were seeing some differences between the metro driven counter and the GEM render cycle? Keep in mind these objects use Pd's logical time which is in no way consistent with actual real world time.
The 'rate' message exists because it allows Quicktime to do all of the timing for when to get frames. Pd's logical time cannot be used for this efficiently or accurately. pix_movie/film attempts to make the Quicktime timing work with Pd's time but it is not always effective.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli a écrit :
On Sat, 2007-05-19 at 17:19 +0200, cyrille henry wrote:
hello,
chris clepper a écrit :
On 5/15/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
i used the gemhead to trigger the counter.
i just insert a delay 5 in order to to trig the counter between 2 frame. it look better. is it possible, or it's just because i'm fade up looking for the same movie everytime?
Maybe you were seeing some differences between the metro driven counter and the GEM render cycle? Keep in mind these objects use Pd's logical time which is in no way consistent with actual real world time.
i think we where just tired.
i'm still tring to find a solution. i don't have the computer with me anymore, so testing is not really easy.
if the hard drive is a limiting factor, maybe i can use someting faster to store the movie. a fast usbflash could be faster (osx monitor tells me that the i read the HD at maximum 4Mb/s, while fast flash usbstick can be read at 30 Mb/s).
the other solution i can imagine is to use the time object in order to get the time beween 2 frame, and compute the frame number i should get. this will not reduce the glitchs, but at last the velocity of the movy should be constant.
does anyone already tried one of this "solution"?
i still believe, the best solution would be to set the framerate to the movie's native framerate and then use a counter,
well, the movie playback framerate change. mostly for 1 to 10, but can go thrus 0.1 to 50 or 100 for short period of time
that is triggered by [gemhead], to choose the frame.
i already use some kind of counter to play the movie.
if cpu and hd are fast enough, you'll get a tight playback.
unfortunatly, i din't have a tight playback. specially when playback speed is high.
if one or the other is too slow, this approach won't help, of course, and the movie is played back too slow. the question is, what does have more priority for you: playing every frame or keeping the original velocity.
i don't play every frame (when playback speed is > 1). i don't keep the original velocity ether. i just whant something that look smooth, that's not the case mostly because time between every frame is not constant.
thanks Cyrille
roman
thanks for the help Cyrille
The 'rate' message exists because it allows Quicktime to do all of the timing for when to get frames. Pd's logical time cannot be used for this efficiently or accurately. pix_movie/film attempts to make the Quicktime timing work with Pd's time but it is not always effective.
chris clepper a écrit :
On 5/15/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
i used the gemhead to trigger the counter.
i just insert a delay 5 in order to to trig the counter between 2 frame. it look better. is it possible, or it's just because i'm fade up looking for the same movie everytime?
Maybe you were seeing some differences between the metro driven counter and the GEM render cycle? Keep in mind these objects use Pd's logical time which is in no way consistent with actual real world time.
The 'rate' message exists because it allows Quicktime to do all of the timing for when to get frames. Pd's logical time cannot be used for this efficiently or accurately. pix_movie/film attempts to make the Quicktime timing work with Pd's time but it is not always effective.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hi Cyrille,
Sounds like your skipping frames which is like seeking, and then any codec with inter-frame compression will suck, much harder for the machine to calculate each 10th frame.
Did you try photo-jpeg as suggested by others?
Try shark, I found it very useful to find stupid CPU usage issues that were related to quicktime and not Gem in the past, so give it a try and see what function is using the most CPU... could be a hint.
B.
cyrille henry wrote:
Roman Haefeli a écrit :
On Sat, 2007-05-19 at 17:19 +0200, cyrille henry wrote:
hello,
chris clepper a écrit :
On 5/15/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
i used the gemhead to trigger the counter.
i just insert a delay 5 in order to to trig the counter between 2 frame. it look better. is it possible, or it's just because i'm fade up looking for the same movie everytime?
Maybe you were seeing some differences between the metro driven counter and the GEM render cycle? Keep in mind these objects use Pd's logical time which is in no way consistent with actual real world time.
i think we where just tired.
i'm still tring to find a solution. i don't have the computer with me anymore, so testing is not really easy.
if the hard drive is a limiting factor, maybe i can use someting faster to store the movie. a fast usbflash could be faster (osx monitor tells me that the i read the HD at maximum 4Mb/s, while fast flash usbstick can be read at 30 Mb/s).
the other solution i can imagine is to use the time object in order to get the time beween 2 frame, and compute the frame number i should get. this will not reduce the glitchs, but at last the velocity of the movy should be constant.
does anyone already tried one of this "solution"?
i still believe, the best solution would be to set the framerate to the movie's native framerate and then use a counter,
well, the movie playback framerate change. mostly for 1 to 10, but can go thrus 0.1 to 50 or 100 for short period of time
that is triggered by [gemhead], to choose the frame.
i already use some kind of counter to play the movie.
if cpu and hd are fast enough, you'll get a tight playback.
unfortunatly, i din't have a tight playback. specially when playback speed is high.
if one or the other is too slow, this approach won't help, of course, and the movie is played back too slow. the question is, what does have more priority for you: playing every frame or keeping the original velocity.
i don't play every frame (when playback speed is > 1). i don't keep the original velocity ether. i just whant something that look smooth, that's not the case mostly because time between every frame is not constant.
thanks Cyrille
roman
thanks for the help Cyrille
The 'rate' message exists because it allows Quicktime to do all of the timing for when to get frames. Pd's logical time cannot be used for this efficiently or accurately. pix_movie/film attempts to make the Quicktime timing work with Pd's time but it is not always effective.
chris clepper a écrit :
On 5/15/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
i used the gemhead to trigger the counter.
i just insert a delay 5 in order to to trig the counter between 2 frame. it look better. is it possible, or it's just because i'm fade up looking for the same movie everytime?
Maybe you were seeing some differences between the metro driven counter and the GEM render cycle? Keep in mind these objects use Pd's logical time which is in no way consistent with actual real world time.
The 'rate' message exists because it allows Quicktime to do all of the timing for when to get frames. Pd's logical time cannot be used for this efficiently or accurately. pix_movie/film attempts to make the Quicktime timing work with Pd's time but it is not always effective.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-
B. Bogart -
chris clepper -
cyrille henry -
Roman Haefeli