I've noticed that [pix_record] will continue to record frames even if the [gemhead] object attached to it is switched off. Is this a bug?
I've attached a sample patch, where I'm attempting to take a snapshot from a camera and save it to a video
#N canvas 1660 101 564 374 10; #X obj 281 40 gemwin; #X obj 39 118 gemhead; #X obj 39 148 pix_video; #X obj 39 177 pix_texture; #X obj 39 205 rectangle 4 3; #X obj 39 88 metro 10; #X obj 39 59 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1 ; #X msg 281 10 buffer 1 , create , 1; #X msg 189 165 record $1; #X obj 189 143 tgl 15 0 empty empty empty 17 7 0 10 -257985 -1 -1 0 1; #X msg 137 44 0; #X obj 39 28 loadbang; #X obj 39 285 pix_record; #X floatatom 67 315 5 0 0 0 - - -; #X obj 67 334 change; #X msg 189 205 1; #X msg 189 105 file ./test.mov; #X text 292 104 1- open file; #X text 292 164 2- start record; #X text 292 204 3- capture frame; #X text 422 164 4- stop record; #X text 182 284 Despite rendering not being on , the pix record object continues to record until it is turned off. A bug?; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 4 0 12 0; #X connect 5 0 1 0; #X connect 6 0 5 0; #X connect 7 0 0 0; #X connect 8 0 12 0; #X connect 9 0 8 0; #X connect 10 0 6 0; #X connect 11 0 6 0; #X connect 12 1 13 0; #X connect 13 0 14 0; #X connect 14 0 10 0; #X connect 15 0 6 0; #X connect 16 0 12 0;
--
antonio@hellocatfood.com http://www.hellocatfood.com ============================
On 12/26/2012 15:08, Antonio Roberts wrote:
I've noticed that [pix_record] will continue to record frames even if the [gemhead] object attached to it is switched off. Is this a bug?
the way to turn off recording is by sending a "record 0" message to [pix_record], or - if you want to add single frames to a movie, to not use "auto 0" mode and manually "bang" the frames you want to record.
I've attached a sample patch, where I'm attempting to take a snapshot from a camera and save it to a video
even more interesting would be the OS and Gem-version your are using. (but the above still is a valid answer)
fgamdsr IOhannes
the way to turn off recording is by sending a "record 0" message to [pix_record], or - if you want to add single frames to a movie, to not use "auto 0" mode and manually "bang" the frames you want to record.
Try out the example patch that's included in the last message. After record is started it uses a bang to turn on the gemhead and to capture one frame, and then turns it off again. However, the time between the two frame captures is still recorded even if the gemhead is turned off e.g. the 20 seconds between two bangs will still be recorded even if rendering is stopped
Also, stopping recording writes the movie file, and restarting recording will overwrite the previous file.
even more interesting would be the OS and Gem-version your are using. (but the above still is a valid answer)
I'm using pd-extended 0.43.4~cvs20121225-1 on Ubuntu 12.04
On 26 December 2012 19:36, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 12/26/2012 15:08, Antonio Roberts wrote:
I've noticed that [pix_record] will continue to record frames even if the [gemhead] object attached to it is switched off. Is this a bug?
the way to turn off recording is by sending a "record 0" message to [pix_record], or - if you want to add single frames to a movie, to not use "auto 0" mode and manually "bang" the frames you want to record.
I've attached a sample patch, where I'm attempting to take a snapshot from a camera and save it to a video
even more interesting would be the OS and Gem-version your are using. (but the above still is a valid answer)
fgamdsr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 12/27/2012 01:33, Antonio Roberts wrote:
record is started it uses a bang to turn on the gemhead and to capture
i'm talking abot [bang(ing [pix_record], which is something different than [bang(ing [gemhead].
one frame, and then turns it off again. However, the time between the two frame captures is still recorded even if the gemhead is turned off e.g. the 20 seconds between two bangs will still be recorded even if rendering is stopped
i cannot check your example right now, but this can totally be desired behaviour. e.g. if your container supports variable framerates and you record two frames that are 20 seconds appart, you might end up with a 20sec video containing of 2 frames. (afair, you might be able to override the framerate (depending on the backend/container you are using).
Also, stopping recording writes the movie file, and restarting recording will overwrite the previous file.
yes. i was mainly pointing to the various ways to control [pix_record]. please check "auto" mode and manual frame progression in the help-patch.
even more interesting would be the OS and Gem-version your are using. (but the above still is a valid answer)
I'm using pd-extended 0.43.4~cvs20121225-1 on Ubuntu 12.04
thanks. since i'm not tracking PdX versions (and even less snapshot versions of PdX!), it is usually helpful to provide the Gem-version as well. (something like "0.93.3"; it should be displayed at startup - when Gem is loaded - though you might have to raise the verbosity of the pd-console)
fgmasdr IOhannes
i cannot check your example right now, but this can totally be desired behaviour. e.g. if your container supports variable framerates and you record two frames that are 20 seconds appart, you might end up with a 20sec video containing of 2 frames. (afair, you might be able to override the framerate (depending on the backend/container you are using).
This 20 seconds between frames is what I'm ending up with and I believe that it is a bug. As far as I understand, pix objects need a [gemhead] in order to function. If it is not present or is turned off then it shouldn't operate. What I'm finding is that once recording is turned on and then afterwards the gemhead is turned off, when it is turned back on and a frame captured the time between the two bangs is still recorded.
Is this a problem/feature of Gem or the codec used?
since i'm not tracking PdX versions (and even less snapshot versions of PdX!), it is usually helpful to provide the Gem-version as well. (something like "0.93.3"; it should be displayed at startup - when Gem is loaded - though you might have to raise the verbosity of the pd-console)
I'm using Gem 0.93.3
Thanks
Antonio
On 27 December 2012 18:57, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 12/27/2012 01:33, Antonio Roberts wrote:
record is started it uses a bang to turn on the gemhead and to capture
i'm talking abot [bang(ing [pix_record], which is something different than [bang(ing [gemhead].
one frame, and then turns it off again. However, the time between the two frame captures is still recorded even if the gemhead is turned off e.g. the 20 seconds between two bangs will still be recorded even if rendering is stopped
i cannot check your example right now, but this can totally be desired behaviour. e.g. if your container supports variable framerates and you record two frames that are 20 seconds appart, you might end up with a 20sec video containing of 2 frames. (afair, you might be able to override the framerate (depending on the backend/container you are using).
Also, stopping recording writes the movie file, and restarting recording will overwrite the previous file.
yes. i was mainly pointing to the various ways to control [pix_record]. please check "auto" mode and manual frame progression in the help-patch.
even more interesting would be the OS and Gem-version your are using. (but the above still is a valid answer)
I'm using pd-extended 0.43.4~cvs20121225-1 on Ubuntu 12.04
thanks. since i'm not tracking PdX versions (and even less snapshot versions of PdX!), it is usually helpful to provide the Gem-version as well. (something like "0.93.3"; it should be displayed at startup - when Gem is loaded - though you might have to raise the verbosity of the pd-console)
fgmasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 12/28/2012 02:18, Antonio Roberts wrote:
i cannot check your example right now, but this can totally be desired behaviour. e.g. if your container supports variable framerates and you record two frames that are 20 seconds appart, you might end up with a 20sec video containing of 2 frames. (afair, you might be able to override the framerate (depending on the backend/container you are using).
This 20 seconds between frames is what I'm ending up with and I believe that it is a bug.
hmm, with "this" is assume you mean that you really get a frame duration of 20 seconds (that is, your framerate is 0.05). if so, then the behaviour is definitely not a bug, as you record two frames and that are 20 seconds apart and you also get that. switching off the [gemhead] will not push new frames into your [pix_record], but it will not halt a "local time" (this is never what [gemhead] does).
i understand that this behaviour is not what you want, but the way to fix it is:
- either manually force the framerate to a constant value when writing
the file (it might well be (haven't checked yet) that you actually cannot force the framerate to a given value, which indeed could be considered a bug)
- or ignore the framerate when playing back the file
- or fix the framerate once the file is written (but before you want to
play it back).
As far as I understand, pix objects need a [gemhead] in order to function. If it is not present or is turned off then it shouldn't operate. What I'm finding is that once recording is turned on and then afterwards the gemhead is turned off, when it is turned back on and a frame captured the time between the two bangs is still recorded.
for the sake of completeness: there's a small chance of a problem with data caching. [pix_record] will not write new frames if it doesn't receive a render-trigger (usually originating from [gemhead]). but once you turn it on again it might write pixel data that originates from before turning on the [gemhead].
fadmsr IOhannes
switching off the [gemhead] will not push new frames into your [pix_record], but it will not halt a "local time" (this is never what [gemhead] does).
Ah, I see now! Although this is expected behaviour, I still think it'd be useful to be able to pause recording (at least in this scenario)
- either manually force the framerate to a constant value when writing the
file (it might well be (haven't checked yet) that you actually cannot force the framerate to a given value, which indeed could be considered a bug)
I've checked the help file and options and of pix_record and there doesn't appear to be any options to set the frame rate. Please correct me if I'm wrong!
I did a bit of further investigating and it appears that the framerate for the videos created by my patch/pix_record are craziliy high! Here's the sample video that I used http://dl.dropbox.com/u/350846/test.mov I ran the following command to get some information from the file mplayer -vo null -ao null -frames 0 -identify test.mov
The important part of that information is that the fps is 1000000.000. Something isn't right there...
On 28 December 2012 17:34, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 12/28/2012 02:18, Antonio Roberts wrote:
i cannot check your example right now, but this can totally be desired behaviour. e.g. if your container supports variable framerates and you record two frames that are 20 seconds appart, you might end up with a 20sec video containing of 2 frames. (afair, you might be able to override the framerate (depending on the backend/container you are using).
This 20 seconds between frames is what I'm ending up with and I believe that it is a bug.
hmm, with "this" is assume you mean that you really get a frame duration of 20 seconds (that is, your framerate is 0.05). if so, then the behaviour is definitely not a bug, as you record two frames and that are 20 seconds apart and you also get that. switching off the [gemhead] will not push new frames into your [pix_record], but it will not halt a "local time" (this is never what [gemhead] does).
i understand that this behaviour is not what you want, but the way to fix it is:
- either manually force the framerate to a constant value when writing the
file (it might well be (haven't checked yet) that you actually cannot force the framerate to a given value, which indeed could be considered a bug)
- or ignore the framerate when playing back the file
- or fix the framerate once the file is written (but before you want to play
it back).
As far as I understand, pix objects need a [gemhead] in order to function. If it is not present or is turned off then it shouldn't operate. What I'm finding is that once recording is turned on and then afterwards the gemhead is turned off, when it is turned back on and a frame captured the time between the two bangs is still recorded.
for the sake of completeness: there's a small chance of a problem with data caching. [pix_record] will not write new frames if it doesn't receive a render-trigger (usually originating from [gemhead]). but once you turn it on again it might write pixel data that originates from before turning on the [gemhead].
fadmsr
IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 12/29/2012 16:20, Antonio Roberts wrote:
switching off the [gemhead] will not push new frames into your [pix_record], but it will not halt a "local time" (this is never what [gemhead] does).
Ah, I see now! Although this is expected behaviour, I still think it'd be useful to be able to pause recording (at least in this scenario)
bien sur.
- either manually force the framerate to a constant value when writing the
file (it might well be (haven't checked yet) that you actually cannot force the framerate to a given value, which indeed could be considered a bug)
I've checked the help file and options and of pix_record and there doesn't appear to be any options to set the frame rate. Please correct me if I'm wrong!
aye, it's a bit undocumented :-( [*]
like with [pix_video], you can set a number of properties specific to the used backend/codec. when selecting a specific codec, you should get a list of supported properties for the selected setting on the info-outlet of [pix_record] (that's the 3rd outlet).
e.g. slecting [codec mjpa( gives me available properties "framerate", "jpeg_quality" and "jpeg_usefloat". you can then set these properties using a "set" message: [set framerate 20( should give create a film with a fixed framerate of 20fps, whereas [set jpeg_quality 15( will give you low quality jpeg compression.
I did a bit of further investigating and it appears that the framerate for the videos created by my patch/pix_record are craziliy high! Here's the sample video that I used http://dl.dropbox.com/u/350846/test.mov I ran the following command to get some information from the file mplayer -vo null -ao null -frames 0 -identify test.mov
The important part of that information is that the fps is 1000000.000. Something isn't right there...
hmm, i get: $ qtinfo test.mov | grep rate rate 0.608175 [1000000:1644263] not constant
which sounds plausible to me. might be, that mplayer doesn't report the correct framerate (only the numerator, not the denominator)
mfgasdr IOhannes
[*] patches contributing to the docs are welcome.
like with [pix_video], you can set a number of properties specific to the used backend/codec. when selecting a specific codec, you should get a list of supported properties for the selected setting on the info-outlet of [pix_record] (that's the 3rd outlet).
And now it seems I've encountered an actual bug!
I've tried several different codecs (25 and 1 exhaustively) and it appears that I can't change the settings of them. No matter what framerate I set I still get a framerate of 20 (or whatever the original video was (I think)). Before finally diagnosing this as a bug, is there a specific order to how the messages should be sent? This is my order, using the pix_record help file:
1 - create the gem window 2 - open the video file 3 - Choose the codec 4 - change the options of the codec (via set) 5 - open a location to save the file 6 - record 7 - set auto record [auto 1(
Is this right?
Thanks
Antonio
On 29 December 2012 19:41, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 12/29/2012 16:20, Antonio Roberts wrote:
switching off the [gemhead] will not push new frames into your [pix_record], but it will not halt a "local time" (this is never what [gemhead] does).
Ah, I see now! Although this is expected behaviour, I still think it'd be useful to be able to pause recording (at least in this scenario)
bien sur.
- either manually force the framerate to a constant value when writing
the file (it might well be (haven't checked yet) that you actually cannot force the framerate to a given value, which indeed could be considered a bug)
I've checked the help file and options and of pix_record and there doesn't appear to be any options to set the frame rate. Please correct me if I'm wrong!
aye, it's a bit undocumented :-( [*]
like with [pix_video], you can set a number of properties specific to the used backend/codec. when selecting a specific codec, you should get a list of supported properties for the selected setting on the info-outlet of [pix_record] (that's the 3rd outlet).
e.g. slecting [codec mjpa( gives me available properties "framerate", "jpeg_quality" and "jpeg_usefloat". you can then set these properties using a "set" message: [set framerate 20( should give create a film with a fixed framerate of 20fps, whereas [set jpeg_quality 15( will give you low quality jpeg compression.
I did a bit of further investigating and it appears that the framerate for the videos created by my patch/pix_record are craziliy high! Here's the sample video that I used http://dl.dropbox.com/u/350846/test.mov I ran the following command to get some information from the file mplayer -vo null -ao null -frames 0 -identify test.mov
The important part of that information is that the fps is 1000000.000. Something isn't right there...
hmm, i get: $ qtinfo test.mov | grep rate rate 0.608175 [1000000:1644263] not constant
which sounds plausible to me. might be, that mplayer doesn't report the correct framerate (only the numerator, not the denominator)
mfgasdr IOhannes
[*] patches contributing to the docs are welcome.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
No matter what framerate I set I still get a framerate of 20 (or whatever the original video was (I think)).
of course. you need to bang [pix_record] in the desired framerate. with "auto 1", it will always record in your current gem framerate, which is 20fps.
cheers, marian
Before finally diagnosing this as a bug, is there a specific order to how the messages should be sent? This is my order, using the pix_record help file:
1 - create the gem window 2 - open the video file 3 - Choose the codec 4 - change the options of the codec (via set) 5 - open a location to save the file 6 - record 7 - set auto record [auto 1(
Is this right?
Thanks
Antonio
On 29 December 2012 19:41, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 12/29/2012 16:20, Antonio Roberts wrote:
switching off the [gemhead] will not push new frames into your [pix_record], but it will not halt a "local time" (this is never what [gemhead] does).
Ah, I see now! Although this is expected behaviour, I still think it'd be useful to be able to pause recording (at least in this scenario)
bien sur.
- either manually force the framerate to a constant value when writing
the file (it might well be (haven't checked yet) that you actually cannot force the framerate to a given value, which indeed could be considered a bug)
I've checked the help file and options and of pix_record and there doesn't appear to be any options to set the frame rate. Please correct me if I'm wrong!
aye, it's a bit undocumented :-( [*]
like with [pix_video], you can set a number of properties specific to the used backend/codec. when selecting a specific codec, you should get a list of supported properties for the selected setting on the info-outlet of [pix_record] (that's the 3rd outlet).
e.g. slecting [codec mjpa( gives me available properties "framerate", "jpeg_quality" and "jpeg_usefloat". you can then set these properties using a "set" message: [set framerate 20( should give create a film with a fixed framerate of 20fps, whereas [set jpeg_quality 15( will give you low quality jpeg compression.
I did a bit of further investigating and it appears that the framerate for the videos created by my patch/pix_record are craziliy high! Here's the sample video that I used http://dl.dropbox.com/u/350846/test.mov I ran the following command to get some information from the file mplayer -vo null -ao null -frames 0 -identify test.mov
The important part of that information is that the fps is 1000000.000. Something isn't right there...
hmm, i get: $ qtinfo test.mov | grep rate rate 0.608175 [1000000:1644263] not constant
which sounds plausible to me. might be, that mplayer doesn't report the correct framerate (only the numerator, not the denominator)
mfgasdr IOhannes
[*] patches contributing to the docs are welcome.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
of course. you need to bang [pix_record] in the desired framerate. with "auto 1", it will always record in your current gem framerate, which is 20fps.
Thanks!
And with that I think I've identified the actual bug here. I still can't override that framerate by changing the option in the codec setting
On 30 December 2012 01:11, Marian Weger mail@marianweger.com wrote:
No matter what framerate I set I still get a framerate of 20 (or whatever the original video was (I think)).
of course. you need to bang [pix_record] in the desired framerate. with "auto 1", it will always record in your current gem framerate, which is 20fps.
cheers, marian
Before finally diagnosing this as a bug, is there a specific order to how the messages should be sent? This is my order, using the pix_record help file:
1 - create the gem window 2 - open the video file 3 - Choose the codec 4 - change the options of the codec (via set) 5 - open a location to save the file 6 - record 7 - set auto record [auto 1(
Is this right?
Thanks
Antonio
On 29 December 2012 19:41, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 12/29/2012 16:20, Antonio Roberts wrote:
switching off the [gemhead] will not push new frames into your [pix_record], but it will not halt a "local time" (this is never what [gemhead] does).
Ah, I see now! Although this is expected behaviour, I still think it'd be useful to be able to pause recording (at least in this scenario)
bien sur.
- either manually force the framerate to a constant value when writing
the file (it might well be (haven't checked yet) that you actually cannot force the framerate to a given value, which indeed could be considered a bug)
I've checked the help file and options and of pix_record and there doesn't appear to be any options to set the frame rate. Please correct me if I'm wrong!
aye, it's a bit undocumented :-( [*]
like with [pix_video], you can set a number of properties specific to the used backend/codec. when selecting a specific codec, you should get a list of supported properties for the selected setting on the info-outlet of [pix_record] (that's the 3rd outlet).
e.g. slecting [codec mjpa( gives me available properties "framerate", "jpeg_quality" and "jpeg_usefloat". you can then set these properties using a "set" message: [set framerate 20( should give create a film with a fixed framerate of 20fps, whereas [set jpeg_quality 15( will give you low quality jpeg compression.
I did a bit of further investigating and it appears that the framerate for the videos created by my patch/pix_record are craziliy high! Here's the sample video that I used http://dl.dropbox.com/u/350846/test.mov I ran the following command to get some information from the file mplayer -vo null -ao null -frames 0 -identify test.mov
The important part of that information is that the fps is 1000000.000. Something isn't right there...
hmm, i get: $ qtinfo test.mov | grep rate rate 0.608175 [1000000:1644263] not constant
which sounds plausible to me. might be, that mplayer doesn't report the correct framerate (only the numerator, not the denominator)
mfgasdr IOhannes
[*] patches contributing to the docs are welcome.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 12/30/2012 15:16, Antonio Roberts wrote:
And with that I think I've identified the actual bug here. I still can't override that framerate by changing the option in the codec setting
yes, indeed you found a bug here.
it seems that currently there is no real way to set any property (including "framerate") with [pix_record]. the "set" message is misdirected at setting the filename (just like "filename").
i have just pushed a fix for that to Gem's repository.
fgamdsr IOhannes
-
Antonio Roberts -
IOhannes m zmölnig -
Marian Weger