New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
musger opened this Issue Nov 19, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@musger

musger commented Nov 19, 2017

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 comment has been minimized.

Owner

umlaeute commented Nov 20, 2017

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

however, it should behave consistently with [pix_image].

@umlaeute umlaeute added the bug label Nov 20, 2017

@musger

This comment has been minimized.

musger commented Nov 20, 2017

@musger

This comment has been minimized.

musger commented Nov 25, 2017

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

@umlaeute

This comment has been minimized.

Owner

umlaeute commented Dec 5, 2017

yes it is.

@musger

This comment has been minimized.

musger commented Dec 5, 2017

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

This comment has been minimized.

Owner

umlaeute commented Dec 6, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment