Announcing viddll (beta) video engine - call for testers
Hello dear Maxers. I'm very pleased to announce the public beta stage of the viddll video engine. VIDDLL is an interface and set of utilities for cross platform, high performance, random access video playback. I've been working closely with VIDDLL's developers to bring the viddll jitter engine adapter to life, and thanks to the magic of the Max 7.1 Package Manager, you can easily join in on the fun.
The viddll engine is probably of most interest to windows users, especially those looking for video playback in 64 bit mode, however all Jitter users should give it a try and see what it can do for you. VIDDLL utilizes the FFmpeg library for playback, and therefore is capable of playing a wide variety of files types and codecs (certainly many more than the avf engine). It even offers support for Hap encoded files (current Hap users will know this is a big win).
The package contains a launch patcher that explains the functionality of the new "cache_size" attribute and how that will affect playback. This attribute's functionality may change over time, and will eventually turn into a replacement for jit.movie's missing "loadram" feature (last seen in the 32 bit qt engine). Currently, the viddll engine only handles file playback, so jit.grab and jit.record are unaffected and will use the default video engine when instantiated with viddll selected as the video engine (avf for Mac and qt for Windows).
There is currently a limitation in which files with PCM encoded audio tracks will not playback the audio. This affects some factory content, such as crashtest.mov. This should be resolved in subsequent updates.
As mentioned, this is a beta release, and testers should adjust their expectations appropriately. Bugs and crash reports are appreciated, and can be posted here, or sent to me directly at robr@cycling74.com. Please be as specific as possible with the steps to reproduce, and the file and codec types in your reports. Please address any general questions to this forum thread and I'll do my best to answer them (although there will be some downtime over the holidays).
Happy holidays and happy patching!
Hey this is cool. Installed successfully. Thanks man.
smooth !
hahaha look at all those chickens going in and out and falling and un-falling at different speeds
I can't get any attributes from [jit.viddll.engine] with [attrui]. Is that expected? Should use of viddll be limited to [jit.movie @engine viddll]? Will setting my default engine via "; max video engine viddll" impact my ability to export images/video with other objects (at least, are there any known issues?)
hi metamax. yes the jit.*.engine externals are not intended to be instantiated in an object box. your max install already comes with qt and avf engine externals, this is simply adding a third engine external. the engine is loaded dynamically by jit.movie (or jit.playlist) based on the video engine preference or the @engine attribute argument.
there are no known issues with exporting when using viddll, but please let me know if you encounter something. viddll will not load as the engine for jit.record, so that will revert to the default engine when viddll is selected as the video engine.
Ok.. cool. Thanks Rob.
in case it isn't obvious, you can install viddll through the Max 7.1 Package Manager.
see here for more info on the package manage:
https://cycling74.com/articles/introducing-the-max-package-manager/
Hi Rob,
Thanks for viddll engine !
work fine with mp4 file, but it stop playing with 1080p hap file...
MacBook Pro (Retina, mi-2012), OSX 10.11.2, Max 7.1
Hey, maybe it's a bug maybe not, but jit.movie can't read a gif file when using the viddll engine (he can with avf, i just tested)
the return of loadram by means of cache_size is awesome! excited to see where this new engine goes and how it compares to avf. the inclusion of hap is equally awesome.
hi Francois, i can't reproduce problems with HAP files using a 4K file. it plays back as expected. however looking at your patch, i see you don't have @output_texture enabled. you really should enable that when playing back HD files. this is slightly different from the jit.gl.hap external, which only outputs textures and therefore doesn't have this attribute. you may also want to increase your @cache_size attribute when playing back these larger files. if you can't get it sorted out, i'd be happy to take a look at the exact file you're using if you can send it my way.
vichung, i'll hopefully have animated GIF support in a forthcoming update.
It seems that max71 win32 or x64 is not able to download your VIDDLL package.
The wheel keeps spinning. I quit max7, and when i relaunch it , it quits directly.
I have to manually trash the VIDDLL package folder that has been downloaded , for max to start.
Is there a conflict with..., something ive got to trash? (preferences?)
so no VIDDLL use at the moment. :(
I've given this a go on osx with max 7. It works so far!
I'm interested in playing video files without audio, setting the speed to zero and driving them with position information.
This works as is but are frames are only cached after they've been played? Can you give us a bit more info on how the cache works please?
Also do h264 mp4 files benefit from hardware acceleration/gpu compression?
I'll give it more of a test and report back. Thanks.
hi spa, i can't reproduce your problems installing the package on windows. i would try again, ensuring you have a stable internet connection (the package is relatively large due to library file sizes, ~70MB uncompressed). if you still are having difficulties, send a message to support.
hi gavspav, thanks for your feedback. currently frames are only cached as they are played, in the future version there will be the ability to specify which frames to preload. h264 hardware decompression is not currently in use. this is another thing we will investigate down the road.
Hi,
I've been working a little with this package this afternoon... it seems to be working really!
Just a quick question: does output_texture 1 work with the VIDDLL engine in max 64 bit? My understanding was that output_texture does not work in max 64 bit on windows 10 - but I was wondering if this has been enabled with the VIDDLL engine.
... I'm looking for a way to go directly to gpu on a windows box using max 64.
Thanks in advance!
Mac
hi Mac. output_texture should absolutely work with the viddll engine in Windows 64 bit.
Hi Rob
Even by applying your advices (@output_texture enabled, big @cache_size) the movie continue to stop playing after two seconds (less or more).
You can DL one off my hap file (230 Mb encoded with qt7.7) here :
https://wsi.li/S2bqGq9zpN1t/
Thanks again
Francois
thanks for the file link francois, i can reproduce your issues and will try and get it sorted out.
THANKYOU!!!! (weeps tears of joy)
Cannot wait to try as I was coding C++, OpenGL using the OpenCV ffmpeg-based stuff for video, and using lots of fbo/pbo and video recursion before noticed max is way easier for development, just wary of any drop off from maximum performance, throughput, how to minimize any timehog parts etc.
Should be able to test and stress test and compare:
- optimum way, linux/c++/opencv vs windows 7 (64) c++
- SSD vs hybrid drive
- windows 7 (64) c++ approach vs max
... to see what's doable in a live vision mixer and how the 2 different approaches.
PS Raise any bugs / joyous results and stats here? or...?
PPS Was this ffmpeg due to opencv or is viddll an entirely new creation?
hi keith. i look forward to hearing about your results. this thread is the best place to share any feedback.
viddll is a new library, unaffiliated with opencv.
Win7-64 latest max etc - installed viddll set engine to viddll restarted + opened video panel on the left - all my vids works also .movs (no previews for those though) but "track2.mov" viddll says "jit.movie: error loading file track2.mov"
which is - C:\Program Files\Cycling '74\Max 7\resources\media\jitter\track2.mov - 186,022 / 188,416 bytes on disk - the only file windows file explorer doesn't show a preview of. Right-clicking on the track2.mov in windows gives NO media info type size frames metadata but QuickTime Player and VLC play (vlc says...)
+Stream 0 - Type: Video - Codec: Motion JPEG Video (jpeg) - Language: English - Resolution: 320x256 - Display Resolution 320x240 - Frame Rate: 15.020863 - Decoded format: Planar 4:2:0 YUV full scale
The preview jpg of it is a black square but it does fade in (160x120 96dpi 24bpp)
hi keith. thanks for the report on this. unfortunately this file fails in the ffmpeg engine itself, so not much to be done on our end.
Cheers - this patch of simple jitter and gen crashes just with these 2 files. I think it was crashing before I went from op to gen thingy with inlets but I've had to do a lot of windows updates so I was ignoring things before that, trying to pin down which of my videos. Aside from the above only 2 of mine run into trouble, attached - patch pasted below incase I've newb'd.
Hi Rob,
did VIDDLL read h264 codec (Raspberry pi vids)?
Thanks Rob, hap codecs running great on El captian (mac book air, pro and mac mini) as well as windows 8 in 64bit Max.
Also a little thanks for the black magic integration. Really nice work.
"The viddll engine is probably of most interest to windows users, especially those looking for video playback in 64 bit mode"
Just curious if you could elaborate on this a bit more Rob. From the latter part I gather that VIDDLL helps you make use of RAM beyond 4GB, is that correct?
What other advantages would Windows users have, or else is it because Mac users have more advantages with native quicktime?
The "DLL" part really makes you think Windows, that's for sure.
Hi guys!
I suspect there's a memory leak while reading movies via: jit.movie @output_texture 1 @engine viddll
(Just "read sunflower.mp4" a few times while watching your memory usage). Dispose doesn't free memory.
I'm on windows 8 on max 7.2.1
Anybody can confirm and/or has a workaround?
Aside from that, Love the new engine!
Thanks!
hi hugo, thanks for the report. i can confirm this and will be working on a fix.
Do I need to install something besides VIDDLL from the Max 7 Package Manager?
Max 7.2.1 (demo mode) running on Windows 10 x64
Max crashes whenever I try to use jit.movie with the viddll engine.
Video files are .MOV with Apple PNG codec
hi ed, could you post a link to the movie file so i can check it out? how about the factory installed files (e.g. dishes.mov, chickens.mp4)?
Hello Rob,
First af all thanks a lot for the nice work.
Everything seems to work great with jit.movie and VIDDLL inside Max.
But once I install the package, a very strange thing occurs to me in Max for Live. When I run Max for Live, as soon as I drop any M4L device in the set, the whole Live goes crazy, doesn't play and the M4L devices don't work.
If I remove the VIDDLL folder from the Packages folder of Max and open again Live, everything works fine...
I have no idea what can be causing this conflict...
Thank you!
Pablo
The dishes, chickens and other factory installed videos play fine with the VIDDLL engine.
This one does crashes Max: https://vimeo.com/160668823
Really looking forward new developpements for Viddl!
Some other quirks that I noticed about Viddll:
- Video loops are not as smooth on certain files compared to QT, not sure why that is. The max supplied files are looping fine, but other files that loop well in VLC or Quictime player don't loop well with Viddl (tried different codecs)
- frame message doesn't seem reliable compared to QT, although frame_true works as expected.
Have a great one!
Hi again Rob,
I tried for the XXX time to reinstall the viddll package.
i retried today with 7.2.1, trashing the preferences and max 32 and 64 before.
everytime I download the package it works fine, than when i restart max, it crashes in 32 and 64. Max7 starts for a while than crash.
So i have to clean Max7 app and preferences and reinstall all...
I dont know what to do?
I see in your viddll_launcher patcher that you added a warning about changing the engine to qt BEFORE removing the VIDDLL package.
Back in January, i have perhaps removed the package without changing the engine.(the warning was not there?)
Could it possibly be that it is the cause that I'm unable to reinstall properly the package now?
Anyway, when max crash at starting, you have no way to change the engine back to qt ...
your only choice is to remove the package from the packages folder...
Do I have to remove some hidden files in windows???
Max7.1.2
Windows 10
hi,
i'm a new user to max, but a fairly experienced programmer. anyway, when i started to do the tutorials, i got to RGB Music and, on Windows 10 64bit, of course, the quicktime mov video didn't work. so i started googling around and found this package, which totally solved the problem BUT for some reason, after i made viddll the default video engine, whenever i start a tutorial video, when i hit play, the video doesn't work, but then if i click forward to the second track, and then hit back, it's now working from the first part of the tutorial video. odd. i was going to recommend that for 64 bit windows users, you put a little blurb about viddll at the beginning of the RGB Music lesson (as it's the first one using video) but with the little glitch i describe (which i assume is related to viddll since tutorial videos had no such hangup prior to switching the engine) i don't know if new users would be ok.
that said, if you're a new user, and you get to RGB Music on 64 bit windows, and you get no information about why you can't load videos.. well, that's deeply frustrating. so, either refer to this library (it's great!) or at least change the lesson so it has some graceful failure.
thanks
omar
Any improvements on this? I'm having the same problem as Francois, where files only play for a couple of seconds and then freeze the image. Also wondering if this is intended to work with spigot~? I really need a solution that can play files and output synced audio into MSP that is NOT the workaround of creating separate audio and video files.
hey everyone, thanks for all the feedback. fixes for most of these issues are coming very soon in the next update.
PEL: this issues should be fixed in the next update.
ED: PNG image sequences are not supported on windows, due to a library requirement for the decoder. hopefully the crashing is fixed.
HUGOBOX: some improvements in looping, and frame message fixes are in the next update
SPA: i'm really not sure what's causing your issues. please send a message to support if the update doesn't fix this.
LEO: playback stalling is hopefully fixed in the next update. spigot~ functionality is logged as a feature request.
ANDEUTUNG: the minimum Mac OS for viddll is 10.9, and this is erroneously not mentioned in the package manager
Hi Rob, yep i will send a message to support but I already know they will tell me to reinstall my whole Windows 10 system.
This is a no go for me given all the soft installed and Max is the "only" soft asking you to reinstall the whole system...
The issue clearly came from installing VIDDLL, so ive got little hope of an answer outside of you.
IS THERE some hidden or modified file installed that i should remove?
WHY do you state in RED to change the engine back to qt before removing viddll? What do you do if that happened? Does it corrupt Max for ever?
Thanks
"ED: PNG image sequences are not supported on windows, due to a library requirement for the decoder. hopefully the crashing is fixed."
That is unfortunate. Is there a different video format which supports alpha channel transparency that will work with VIDDLL?
SPA: this red warning is simply due to a bug in the Max Preferences window that won't allow you to change the pref if there aren't two options. it won't corrupt your system and should have nothing to do with the problems you are experiencing.
my recommendation is to wait for the soon to be announced update, and then try again. we can try and diagnose further then.
ED: Animation codec and Prores4444 both support alpha channel and should work with viddll. i recommend prores4444 if you also want compatibility with the Mac AVF engine, but otherwise, Animation is fine.
Rob,
Thanks for all your hard work on this!
Just to be clear, any method of getting audio into MSP would be great, it would be cool if it was handled internally instead of having to create the named contexts for spigot~, which I'm always "breaking" by opening two of the same named context.
Hi Rob, thanks for the following.
After installing and desinstaling max 7.2.2 32 and 64 a dozen of time, and having max crashing, max seems to catch viddll.
I have to select engine qt in preferences just after starting max. and then i could create a jit.movie object. if not (with default viddll) it will hang for ever..
What is actually very weird is that sometimes it will crash if i launch max by double-clicking a max patch file with a jit.movie in it.
Whitout triyng to create a jit.movie @engine viddll, max runs perfectly.
I join 2 crash logs about those issues, creating a jit.movie object and ... hanging max
ps: Weirdly, when i right click a max file in the finder and go into the contextual menu : open with ... it shows only Max(64-bit) but not 32-bit, even if it's also installed.
Are you planning a 'asyncread' like with qt. it's great to not have a 3d render stalling when reading a movie...
Am I wrong, output_texture does not work in Win64?
Sorry, output_texture does work in Win64
Well, its a nightmare.
viiddll started to crash again max 32 and 64. same logs error than the post before.
I dont get it. I use max 10 times with viddll and everything is fine, and suddenly. it starts to hang everytime i use a jit.movie @engine viddll.
Looking on forums, i read that the dbgcore.dll error comes perhaps from a software that was badly desinstall.
It s really weird that it does happen only with viddll...
hey guys, many thanks for all your testing and feedback. Viddll is now installed with the app, and i've moved the viddll discussion to a new thread:
https://cycling74.com/forums/viddll-video-engine-now-factory-and-the-default-on-windows/
SPA: please send a message to support, as they are better equipped to handle these types of situations
Hey Rob, I just updated to VidDLL 1.0.1 in Max 7.2.2 and I'm getting an error message when I try to load Hap files:
file not playable - possibly unsupported codec.
I've tested this across multiple machines (both MacBook Pro, 2014, Retina, quad i7, NVIDIA GeForce GT 750M). Has Hap functionality been disabled in the new version, or am I missing something?
THANKS!
SYRINX: sounds like you are using the default "avf" engine. make sure you set your Video Engine preference to "viddll"
My bad! Looks like I was still actually in 7.2.1. Sorry for the wasted bandwidth and thanks for the reply, Rob. Nothing to see here, folks...
Hi Rob,
I don't understand the use of "framecalc".
Using jit.gl.hap I appreciated very much the framereport attribute. It reports the current position of the playing file in frames.
Framereport on 'jit.movie @engine viddll' sends out "framecalc" and some floating numbers. What can I use this for? And is there a way of keeping track of the fileposition automatically or do I have to bang "getposition" constantly?
thanx!
the jit.movie framereport reference entry explains it's behavior. it simply reports the amount of time spend calculating each frame.
how that's useful, i can't really say but it's been there since the beginning days of jitter.
i've noted your feature request for current frame reporting. for now banging getposition is the required.
Hi,
As quicktime framework is almost obsolete on Mac OS, the rtsp streaming on qt engine is already broken. I am heavily relying in rtsp stream inputs in a project in maxmsp. So, is there anyway we can play rtsp or http live stream using VIDDLL ? or is there any plans such support for future.
check this thread: https://cycling74.com/forums/jitter-ip-camera-and-or-syphon
specifically Jesse's reply.
Hello,
I'm running into a problem using the viddll engine quite extensively in a long duration video project.
Basically, I want to read a lot of different video files for a long time.
After just over a 1000 video reads, the viddll engine crashes and is only posting the error message "jit.movie: error loading file".
After restarting max, everything runs fine again, until just over a 1000 reads...
Here a small patch to reproduce the error:
The same patch runs fine the in qt engine for a long time (I stopped at about 10'000 video re-reads) ...
I run into the same problem on Thinkpad W530 with Win7 and on a macMini with MacOsX 10.10.5.
Am I overlooking something?
Or could this be a bug?
hi Lukas.
there are some known memory usage problems with the viddll engine and multiple reads over a long period of time.
i would either use qt (or hap if possible) engine, or create a structure where you have the movie reader loaded in a separate app instance, which sends textures to your main instance via spout or syphon, and restarts itself periodically.
Hello Rob,
Thanks for the fast reply.
Qt is unfortuately not sufficently smooth enought for what I envisage (quickly alternating reads at 720p).
I'll try with hap or the restart solution.
Is there any hope that the memory usage problem will be fixed at some point in the future?
Apart from that, the viddll engine is really amazing in terms of performance and cross-platform ability.
Great work!
there's always hope, and it's on the top of my list. most i can say at this point
for random access playing of about 3 or 4 footages 4K, and considering that apparently annoying (frightening for stage option) memory usage problem, would you suggest viddll and hap ? hap only?
i would suggest testing extensively
I further investigated the multiple reads/out of memory problem with different video engines:
I had no luck with hap: "jit.movie @engine hap @texture 1" seems to run out of memory as well, stops and crashes at around 600-700 reread.
Strange enough: "jit.movie~ @engine qt" shows the same behavior like "jit.movie @engine viddll" and "jit.movie~ @engine viddll" and crashes at around 1000 rereads. Tested with max 7.3.3 on win7 and macOS Sierra.
The only option that worked for me out of the box for multiple rereads is "jit.movie @engine qt", but this is terribly lagy on the first view frames of playback (again strange "jit.movie~ @engine qt" is playing smoothly from the beginning). Same with max 7.3.3 on win7 and macOS Sierra.
I guess there are different things under the hood of jit.movie and jit.movie~...
So the only real solution for smooth playback and lots of rereads seems to be a periodically restarting program at the moment...
hey Lukas, jit.movie~ only supports viddll engine, so there's no way to override the engine for that object.
i've actually just pushed a viddll update to the Package Manager to version 1.0.9, which should fix the memory leak issues you were experiencing with jit.movie~.
please check it out and let us know if that fixes things for you.
Hello Rob,
Thanks for the update! Works great so far.
Tested it for several hours and about 30'000 reads without any problems.
Will test it more extensively soon...