I want to use Gem to capture still frames from a video stream. I was going to use pix_write . At the same time I want to turn those still frames into a movie and output them in a Gem window. Since pix_write captures the rendered output I assume I need 1 PD instance for the capture and 1 PD instance for the output. Related to this should I use pix_multiimage to output the frames or use a script to continually create a movie then use pix_film? In other words the output movie will continuously get longer as frames are captured from the video stream. I know I will need to allow time for loading, saving etc.
Thanks for any advice before I tackle this. I am using Linux.
Jim
On 12/08/2017 06:51 PM, Jim Ruxton wrote:
I want to use Gem to capture still frames from a video stream. I was going to use pix_write
don't. instead, use [pix_buffer].
all your other problems (mentioned in this mail) will magically disappear.
(to answer your subject question: no you don't need to instances of Pd/Gem for this; not even when using [pix_write]; but with [pix_buffer] it's going to be much easier)
fgamdsr IOhannes
Hi Jim,
just a quick reply: Perhaps pix_buffer is what you could use here? I see no need for two instances.
I want to use Gem to capture still frames from a video stream. I was going to use pix_write . At the same time I want to turn those still frames into a movie and output them in a Gem window. Since pix_write captures the rendered output I assume I need 1 PD instance for the capture and 1 PD instance for the output. Related to this should I use pix_multiimage to output the frames or use a script to continually create a movie then use pix_film? In other words the output movie will continuously get longer as frames are captured from the video stream. I know I will need to allow time for loading, saving etc.
Thanks for any advice before I tackle this. I am using Linux.
Jim
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Thanks a lot Peter pix_buffer works great for this. I'd like to find a way to retrieve everything if I lose power but I think I can do that by also pix_writing every frame.
Jim
On 2017-12-08 02:51 PM, Peter P. wrote:
Hi Jim,
just a quick reply: Perhaps pix_buffer is what you could use here? I see no need for two instances.
- Jim Ruxton jim.ruxton@gmail.com [2017-12-08 18:51]:
I want to use Gem to capture still frames from a video stream. I was going to use pix_write . At the same time I want to turn those still frames into a movie and output them in a Gem window. Since pix_write captures the rendered output I assume I need 1 PD instance for the capture and 1 PD instance for the output. Related to this should I use pix_multiimage to output the frames or use a script to continually create a movie then use pix_film? In other words the output movie will continuously get longer as frames are captured from the video stream. I know I will need to allow time for loading, saving etc.
Thanks for any advice before I tackle this. I am using Linux.
Jim
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 12/09/2017 05:25 AM, Jim Ruxton wrote:
Thanks a lot Peter pix_buffer works great for this. I'd like to find a way to retrieve everything if I lose power but I think I can do that by also pix_writing every frame.
hmm. i think that [pix_write] is a design failure in itself, and shouldn't be used if possible.
in any case, you can "save" images in a [pix_buffer].
mgsdf IOhannes
On 12/09/2017 05:25 AM, Jim Ruxton wrote:
Thanks a lot Peter pix_buffer works great for this. I'd like to find a way to retrieve everything if I lose power but I think I can do that by also pix_writing every frame.
hmm. i think that [pix_write] is a design failure in itself, and shouldn't be used if possible.
Just curious. Why is it a design failure, which alternatives should be used?
thanks,P
On 12/09/2017 03:02 PM, Peter P. wrote:
Just curious. Why is it a design failure,
it combines three unrelated things:
which alternatives should be used?
[pix_snap] + [pix_buffer] + [makefilename]
gfamrds IOhannes
On 12/09/2017 03:02 PM, Peter P. wrote:
Just curious. Why is it a design failure,
it combines three unrelated things:
- taking snapshots from the current framebuffer
- generating filenames
- saving pixes to disk
which alternatives should be used?
[pix_snap] + [pix_buffer] + [makefilename]
So [pix_write] cound become an abstraction that holds the above objects maybe.
On 12/10/2017 04:40 PM, Peter P. wrote:
[pix_snap] + [pix_buffer] + [makefilename]
So [pix_write] cound become an abstraction that holds the above objects maybe.
patches/PRs welcome.
Just curious, if [pix_write] would become an abstraction as described avove how would one do the encoding of still images saved from [pix_buffer] into a (compressed) video file without using external tools (ffmpeg, mencoder) then?
On 2017-12-11 10:19, Peter P. wrote:
- IOhannes m zmölnig zmoelnig@iem.at [2017-12-10 18:56]:
On 12/10/2017 04:40 PM, Peter P. wrote:
[pix_snap] + [pix_buffer] + [makefilename]
So [pix_write] cound become an abstraction that holds the above objects maybe.
patches/PRs welcome.
Just curious, if [pix_write] would become an abstraction as described avove how would one do the encoding of still images saved from [pix_buffer] into a (compressed) video file without using external tools (ffmpeg, mencoder) then?
price question: how would you do that with [pix_write] as a binary (as is now)?
fgamsdr IOhannes
On 2017-12-11 10:19, Peter P. wrote:
- IOhannes m zmölnig zmoelnig@iem.at [2017-12-10 18:56]:
On 12/10/2017 04:40 PM, Peter P. wrote:
[pix_snap] + [pix_buffer] + [makefilename]
So [pix_write] cound become an abstraction that holds the above objects maybe.
patches/PRs welcome.
Just curious, if [pix_write] would become an abstraction as described avove how would one do the encoding of still images saved from [pix_buffer] into a (compressed) video file without using external tools (ffmpeg, mencoder) then?
price question: how would you do that with [pix_write] as a binary (as is now)?
Sorry, mixed it up with [pix_record].