pix_film does not re-send still frames for subsequent pix_ objects.

[musger]

When loading a video file into pix_film and selecting a certain frame to display, modifications to [pix_invert] or [pix_contrast] will produce strange results unless the still frame is addressed again with a message into [pix_film's] right inlet. [pix_film]'s behavior displaying still frames should equal that of [pix_image]. See attached example patch.

pix_film_stillImage.pd.zip

[umlaeute]

this is actually a feature. see [pix_buf]'s help for a bit of explanation.

however, it should behave consistently with [pix_image].

[musger]

• umläute [email protected] [2017-11-20 14:21]:

this is actually a feature. see [pix_buf]'s help for a bit of explanation. Thank you! Are you referring to the sentence "All images use a pull system, so as long as nothing is modified in the pix "upstream", the pix_buf is still valid."?

Is this the reason subsequent pix transformations do not work?

however, it should behave consistently with [pix_image]. Yes.

[musger]

Could this be a duplicate of https://sourceforge.net/p/pd-gem/bugs/61/ ?

[umlaeute]

yes it is.

[musger]

Just saw that that sourceforge bug got reported in 2009 the first time. It seem this one is particularly tricky... Had this on multiple computers in parallel, and it is a quite reproducable bug.

[umlaeute]

it's easy to reproduce. the cause is known. a solution is not hard to implement.

but as the sf bug report says, it's unclear what the proper solution to the problem is. quoting the sf bug report:

• automatically copy the frame? (how much performance loss does it imply?)
• add an option to [pix_video] to automatically copy the frame (or not to)?
• leave it to the user to add a [pix_buf] (==[pix_separator]) object (no change involved on the code side)

the reason why it is not solved yet is simply performance. automatically copying the frame will incur a performance loss, even if you don't do any video processing (and just want to send the footage straight to a texture). the current architecture doesn't allow for CoW, so the pixels need to be copied before any FX touches them. pix_image does copy the frame before sending it out (so it can send out a fresh copy if some FX polluted the data), but that's because still images hardly ever change, so you typically don't have to perform the copy for each render cycle.

now, pix-based effects are becoming less and less important, as for any serious stuff you probably want to use a GPU shader anyhow - making any automatic copy even more useless.