possibly on windows, but the Mac libraries have to be loaded from the viddll.engine library so I don't think that will work.

I'm seeing dylib files with the same names. isn't it the same prinziple on Mac (xcode), linking the project with dynam. libraries and that's it? I did compile externals for Mac but I think I never had to deal with dylib files. I'm going to find that out

well, def let us know. maybe it works fine!

Some progress here: On Windows it works fine. It's all good if the ffmpeg dlls are somewhere in the search path, which is granted if the VIDDLL 1.1 Package is present.

On MacOs, after I successfully installed ffmpeg-devel package with MacPorts to get the header files, i'm adding the dylib files to the xcode project and the build succeeds. But when external gets loaded the dylibs can't be found : (for some reason it only reports the error for libavformat. I'm also using libavcodec and libavutil. I don't know if that means the other 2 dylibs have been opened successfully, I assume not)

Do you know where variable @loader_path is looked up or can be set to be the viddll support folder. It seems to look inside the mxo bundle for the dylibs. Do I maybe have to use dlopen() manually in the external? Would I even find the dylibs without hardcoded path? It seems the max.app folder is not in the search path opposed to Max 7 folder on Windows.

I really prefer a solution that refers to VIDDLLs dylibs. Don't want to bundle 30mb with an extenal, 30mb that are already present in every users Packages folder.

I edited the binary in the mxo bundle with install_name_tool. I replace the "@loader_path" parts with absolute paths to "/Applications/Max.app/Contents/Resources/C74/packages/VIDDLL/support/libname.dylib" and IT WORKS. really, could it be so simple? (after reading endless posts, saying you can't link to a dylib outside the app bundle i'm confused) Is it correct that the Max app path is a fixed thing on Mac and I can rely on this hardcoded path working on every Mac + Max?

Having all applications in the Application folder is something I never liked in OSX. So on my Macs, Max is not in the Application folder, nor in ~/Applications. And if you create standalones with you external, I guess it won't find the library.

Hmm ok thanks for the info. So the path is not reliable. You are right, creating a standalone is another problem where it makes no sense to link to Max app. For now I was hoping I can make it work crossplatform in Max4Live. At least I can be sure the Max app is somewhere on disk in this environment. But i'm kinda loosing hope it will work on Mac. If I pack the libs with mxo bundle i got a 33mb external. Is that a problem at all? O.

Omg, turns out every mxo knows the location of the Max binary at runtime and can navigate relative to this location. i'm setting the pathes like this: "@executable_path/../Resources/C74/packages/VIDDLL/support/libavcodec.dylib" i didn't noticed first but that's how they find the jitter and audio framework: @executable_path/../Frameworks/MaxAudioAPI.framework/Versions/A/MaxAudioAPI @executable_path/../Frameworks/JitterAPI.framework/Versions/A/JitterAPI

Any news on your experiments? I'm using ffmpeg via shell right now, looking for a more convenient way to reas and re-encode a stream directly in max. Since I'm here, another question, is there a way in max/jitter to play an open video file?(I mean a videofile that is still been encoded). I can open a ts file with jit movie it just lets me watch what has been recorded at the time i ve opened the file. I need to reopen the file everytime I want to so see a new part of the stream. cheers

I have a working prototype that decodes any file into a buffer~ like the "replace" message of buffer. I have not investigated into the video part of ffmpeg but that is probably what viddll and related jit externals do. I got a little bit lost and frustrated trying to implement a clever solution for handling big files, i mean files that exceeds buffers maximum size. Once i can finalize the last 5% of the external i'm happy to share it + source code. But, like i wrote above, it uses a thread to decode an audio stream to buffer~, no video involved.

Basically I think you can put any ffmpeg feature into in external. What helped a lot was to code the function in an executeable to debug and create a working example before moving it to an external. Even this first step was a lot of struggle as most examples on the web are outdated if you use latest libs.

seems really interesting. I'm looking forward to it, have fun and a nice week ;)

this requires Max 7.3.4

[beta download removed] scr included. If this works for everybody I'll put this to my site as a download. And HappyHalloween for all you guys ;)

very cool 11OLSEN, thanks much for sharing and congratulations on getting those libraries working for you!

Hi, 11Olsen. Great external. It's particularly useful when simultaneously dealing with audio and video/3D animation. I've done it in the past and there's some pauses in Jitter while audio is being read from disk. It really should be the standard behaviour of the loading process of buffer~ and other similar objects.

Yes, I want to do an audiofile-browser-like thing. And a seemless prelistening function of files is not possible with the blocking behaviour of the default objects.

I removed the beta version download. I fixed many bugs since then, some of them are critical.

Second, i noticed that when the osx external is frozen into a m4l device the "unable to load object bundle executable" - error is back. The frozen device state seems to isolate the externals from the max app ? Seems this is not finished yet. I have to dive into it again.

As long as the m4l-Editor is not opened, the @executable_path for externals links to the Live app. Where it finds the Max frameworks but of course not the viddll package. Ok didn't know that.

Maybe that changes with Live 10. For now I see no other way than using @loader_path and including the dylibs in the mxo bundle. sad

Here's version 1.0: http://www.11olsen.de/code/max-objects/11ffload All ffmpeg dependencies are included for now.