VIDDLL video engine now factory and the default on Windows
Hey guys.
I'm happy to announce that as of the 7.2.2. update, the VIDDLL video engine is now a factory package. This means that it comes installed with the app, and will be the default video engine on Windows machines, replacing qt (Quicktime). The qt engine can still be used simply by changing the Video Engine preference.
Another exciting feature of 7.2.2 is the ability for us to provide updates to our factory packages via the Package Manager. So updates to viddll won't be tied to the Max app release schedule. You will be notified when updates are available by a yellow Package Manager icon in the upper left corner of the patch toolbar.
For now, I'll be posting to this thread to announce the updates and provide a list of fixes, features, etc.
Many thanks to everyone for providing feedback on viddll during the beta period.
The viddll 1.0.1 update is now available via the Package Manager.
This update addresses an issue with jit.grab not functioning properly on Windows machines with the viddll engine.
PLEASE NOTE: you must restart Max after installing the update for it to take effect (even though you are not currently asked to do so)
Hi Rob, I am in the middle of a months-long development where I am mixing 1080p video files, and I just tried switching everything to the VIDDLL engine... performance has improved greatly, it has basically stopped stuttering after I send a [frame $1] message. Hallelujah! Thanks so much for this amazing update.
one question: I was using the [ mxform 1. 0. 0. 0. -1. 0. 0. 0. 1.] message to jit.movie to get a "mirror image" effect, but mxform doesn't seem to work with the VIDDLL engine. Is there an equivalent you can suggest? And, in general, is there documentation of this stuff somewhere I can read? I'm not finding it...
Thanks again!
Never mind, now using [rect 0. 1. 1. 0.] on a jit.gl.slab. Pointers to documentation would be great, though, if it exists yet.
We're doing some development and since we are being forced by Quicktime for our windows builds to use VIDDLL, I'm wondering if the VIDDLL engine works with jit.record and/or jit.vcr?
The answer's no I'm afraid. jit.vcr still needs qt installed to work on a Windows machine.
Anyone know of a workaround or should we hang tight for a fix?
On a similar-ish note - i was trying to import the audio from a movie file into a buffer, and that no longer works - i suspect its also tied in with my removal of quicktime. Its not hugely pressing, but would also be great to get that working on VIDDLL too.
hey guys, jit.record/vcr/matrixset exportmovie and movie audio import to buffer~ are all on the list for future versions of viddll.
thanks for your feedback.
good to know Rob - are u able to give some idea of time frame?
@Rob on my mac side viddll is even superior to the avf engine, so thanks for this! I hope whenever the engine gets incorporated to [jit.record] it'll come with the HAP codec. Cheers.
Package not found in windows 10 max 64
Ok! I had not read that with 7.2.2 it was in max now. Sorry.
I'm testing a quite simple max patch on the win machine. I have a bunch of Prores video files (viddll engine) everything works as expected but there is no sound from the movies. Movies work properly in VLC. The same behaviour is repeated in help patches, but for example movies from Max folder (e.g. blading.mov) sound works as expected.
I guess it has to do with the choice of codec. ANy hints?
It works without any problems when I encoded files as mpeg4. I am just curious why there is no sound in PRORES?
Also, what is a recommended codec for windows (I am on OSX) - this is for an installations that will go to museum collection and I want to choose a codec that is most likely to last - files are SD resolution so codec doesn't have to be the most efficient one.
viddll currently has a limitation where it can't play PCM encoded audio files. however that is fixed for the next update (soon to be released).
for now, you can encode your audio tracks as AAC and should be fine.
codec depends on what you need. h264 is great for file size vs quality, at the expense of fast random seeking and reverse playback.
Thank you Rob. That sorted it :)
I'm not a Windows user and I was not sure if I was doing something wrong :)
As for the choice of codec, it's very simple "play till the end" system, so mpegs will be fine. My main concern is what will happen in 10-20 or more years when they try to make it work again. Will the codecs exist? As that is really difficult to predict :) , I inculded TIFF image sequences and WAVs of all the movies, so that they can always put them together if they need to.
But I'm sure MAX will be here forever :)
(I ocassionally run some nice Max 3.0 patches from mid 90's on a 25MHz Mac Powerbook... and most of them work on recent versions of Max)
hello viddllers, i've just posted an update to the Package Manager (1.1.2) which is recommended for all users.
fixes include:
- Fix crash or breakage when loading TIFF image files (would affect jit.gl.model factory files)
- Fix issue with audio playback in only one channel
in addition to the version 1.1.1 changes:
- Fix bug with cache_size and loadram
- Fix crash with certain multi-channel audio files
- Support for h265 / HEVC and webm vp8 / vp9 file codecs
- Various playback improvements
Great, thanks!
Some weirdness in Max 7.3.4, macOS 10.11.6:
- when selecting a jit.movie with @engine avf it gives me in max console a 'viddll.engine version 1.1.3', I assume viddll is selected as the engine?
- the package manager didn't show a yellow Package Manager icon in the upper left corner of the patch toolbar
Performance is good playing back a H264 1080p file in this setup though.