Skip to content
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

Export sketch bug? Native libraries in different location relative to JARs #176

Closed
neilcsmith-net opened this issue Mar 2, 2021 · 6 comments

Comments

@neilcsmith-net
Copy link

Just helping someone on the forum with a bug using Video library and sketch export - https://discourse.processing.org/t/exporting-sketch-with-movie-is-blank/27983

This may be a bug in the Video library, but it's caused by the native GStreamer libraries being moved up in the relative hierarchy during sketch export - eg. contents of subfolder windows64 are moved up adjacent to the jar files. Should export be filtering by platform but keeping the relative locations of platform specific files? If current behaviour is expected behaviour, relative linking will fail so the Video library loading will need rewriting. I'm unclear whether it's a bug there or here.

Of course, the obvious (and preferred) fix would be to stop shipping bundled GStreamer libraries in the first place, at least in the way it's currently done.

@batlleadri
Copy link

Here you have the macosx solution!
contents

@benfry
Copy link
Owner

benfry commented Jun 14, 2021

Is the fix to move the video libraries into a subfolder called macosx inside the Java folder of the export? If so, then that's a bug in the video library.

@neilcsmith-net
Copy link
Author

neilcsmith-net commented Jun 14, 2021

@benfry it's likely a bug in Processing itself. I haven't debugged the process fully, but I'd guess the code that pulls everything up a level at https://github.com/processing/processing4/blob/master/app/src/processing/app/Library.java#L268 is probably the issue. Is there a reason that is there? Seems more likely to cause issues than not, as relative links get broken. Or is there another way that the Video library should be finding those relative links? Unfortunately, no-one seems to be maintaining it anyway (offer of help to anyone who takes it on is still open).

EDIT : I think that link might be a red herring. Sorry, told you I hadn't debugged 😄 Something in export is dropping the top folder name anyway, and probably shouldn't be.

@benfry
Copy link
Owner

benfry commented Jun 14, 2021

There should be no macosx folder in the export. If the Video Library is expecting that, and the fix is to add one, then it's a bug in the Video Library.

If Export to Application is including the macosx folder, then that's a Processing bug.

@neilcsmith-net
Copy link
Author

@benfry OK, in that case it's a bug in the Video library. Changing relative hierarchy of files in export seems a curious thing to do though!

Guess it's over to someone who wants to pick up the library, although probably better to stop shipping GStreamer inside it.

@benfry
Copy link
Owner

benfry commented Jun 14, 2021

It's not changing a relative hierarchy, it's copying platform-specific code from a subdirectory. This is how Libraries work.

GStreamer is shipped with the code so that it works out of the box. Not everyone knows how to install GStreamer themselves, which is the point of the video library since the very first release of Processing: to have video work without additional/hidden installation steps for the user.

@benfry benfry closed this as completed Jun 14, 2021
Repository owner locked as off-topic and limited conversation to collaborators Jun 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants