[PD] Capture Gem output: best practices?

[Peter P.]

* Max <abonnements at revolwear.com> [2017-09-17 20:16]:
> This is such a reoccurring question, I've always wanted to make a FAQ about
> this where we can point to. There are quite a few possibilities and it
> depends on the system and case which one is the best for you.
Thank you Max for responding here!
 
> A) inside GEM
> You can record the GEM window inside GEM with pix_record and pix_snap. This
> is the cleanest and cross platform solution, because it doesn't require
> additional soft- or hardware. You can also render things slower than
> realtime, while making sure to save every frame.
I tried this and it works kinda great! I attach a patch for others that
does pretty much that.

Here are a few questions to everyone that have just arisen:

I am not selecting a particular codec, perhaps the first
codec in the list
	codec 0 ffmpeg_mpg4 FFMPEG MPEG-4
is used as default?

It is cool that the resulting file (header) seems to know about the Gem
framerate, although I am recording with individual bangs rather than the
auto message. The codec seems to support 20 and 25 fps, but for example
not 22fps as it tells me then that
	[mpeg4 @ 0x55e50833bac0] removing common factors from framerate
	[mpeg4 @ 0x55e50833bac0] timebase 22727/500000 not supported by MPEG 4
	standard, the maximum admitted value for the timebase denominator is
	65535

I am doing this on Debian(testing) and having started Pd from an xterm I
am getting a line of
	[mpeg4 @ 0x55e50809b620] AVFrame.format is not set
	[mpeg4 @ 0x55e50809b620] AVFrame.width or height is not set
there for every frame that is written to disk.

In addition the helpfile for pix_record mentions a [dialog< message,
that has no effect (on my O.S) and is lacking the info that the codec
list and properties are given at the third outlet of [pix_record] and
that the default for the [auto< message seems to be "1".

Upon closing my patch I get the following red line in the Pd console:
	record: implementation forgot to call close() - please report a bug!

Creating a pix_snap object (in an empty patch) gives:
	GEM: Someone sent a bogus pointer to copy2Image

I hope this is not a bad thing! ;)

thank you all again!
Peter
-------------- next part --------------
#N canvas 721 118 544 614 10;
#X declare -lib Gem;
#X obj 8 6 declare -lib Gem;
#X msg 10 38 create \, 1;
#X obj 20 123 gemhead;
#X obj 20 279 teapot;
#X obj 207 417 pix_record;
#X msg 253 260 codeclist;
#X obj 271 439 print;
#X obj 20 251 rotateXYZ;
#X floatatom 38 221 5 0 0 0 - - -, f 5;
#X obj 267 364 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1
1;
#X floatatom 235 441 5 0 0 0 - - -, f 5;
#X msg 260 283 codec 0;
#X obj 168 192 t b b a;
#X msg 267 307 auto 0;
#X obj 207 234 pix_snap 0 0 500 500;
#X msg 267 384 record \$1;
#X obj 168 138 gemhead 51;
#X obj 38 198 random 360;
#X obj 38 173 metro 100;
#X obj 38 149 loadbang;
#X text 238 140 <- renders after everything else;
#X obj 10 73 gemwin 20;
#X msg 267 341 file /tmp/mymovie.mov \, auto 0;
#X text 68 74 <-20fps is Gem's default;
#X connect 1 0 21 0;
#X connect 2 0 7 0;
#X connect 4 1 10 0;
#X connect 4 2 6 0;
#X connect 5 0 4 0;
#X connect 7 0 3 0;
#X connect 8 0 7 1;
#X connect 8 0 7 2;
#X connect 8 0 7 3;
#X connect 9 0 15 0;
#X connect 11 0 4 0;
#X connect 12 0 4 0;
#X connect 12 1 14 0;
#X connect 12 2 14 0;
#X connect 13 0 4 0;
#X connect 14 0 4 0;
#X connect 15 0 4 0;
#X connect 16 0 12 0;
#X connect 17 0 8 0;
#X connect 18 0 17 0;
#X connect 19 0 18 0;
#X connect 22 0 4 0;