ffmpeg now part of Max?


    Aug 17 2017 | 2:46 pm
    I just wrote an external using libav that requires the shared ffmpeg dll's. I noticed it keeps working even after removing the additional libs from the search path. So i did a search and it turned out the viddll package comes with this files. Does that mean we can write cool ffmpeg externals without having to provide the shared libraries. Is it the same on the Mac?

    • Aug 17 2017 | 4:09 pm
      possibly on windows, but the Mac libraries have to be loaded from the viddll.engine library so I don't think that will work.
    • Aug 17 2017 | 7:18 pm
      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
    • Aug 18 2017 | 5:14 pm
      well, def let us know. maybe it works fine!
    • Sep 20 2017 | 1:28 pm
      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)
      11ffload~: unable to load object bundle executable 2017-09-20 15:59:52.917 Max[727:707] Error loading /Users/admin/Desktop/max-sdk-7.1.0/externals/11ffload~.mxo/Contents/MacOS/11ffload~: dlopen(/Users/admin/Desktop/max-sdk-7.1.0/externals/11ffload~.mxo/Contents/MacOS/11ffload~, 262): Library not loaded: @loader_path/libavformat.57.dylib Referenced from: /Users/admin/Desktop/max-sdk-7.1.0/externals/11ffload~.mxo/Contents/MacOS/11ffload~ Reason: image not found
      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.
    • Sep 21 2017 | 10:45 am
      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?
    • Sep 22 2017 | 12:40 pm
      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.
    • Sep 22 2017 | 1:22 pm
      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.
    • Sep 22 2017 | 7:26 pm
      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
    • Oct 15 2017 | 12:43 pm
      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
    • Oct 15 2017 | 4:26 pm
      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.
    • Oct 16 2017 | 10:00 pm
      seems really interesting. I'm looking forward to it, have fun and a nice week ;)