best video codec / video engine on windows 10 + moving from max 6 to max 7

Hi Christian.
your patch is outdated. please see the patch below for the modern way of playing HD videos in Jitter. The most important thing is to enable output_texture 1 on the jit.movie.

For a preview window, notice the use of @shared 1 on the jit.world and jit.pwindow in order to create a shared context to display the texture in both windows.

when using the viddll engine, you should adjust the cache_size attribute appropriately for your specific movie file and available memory. this allows the frames to be cached into memory, thereby making random file seeking very fast. you can also preload the frames in memory using the "loadram" message. the jit.movie help file explains this feature in the the "VIDDLL" tab.

1-Should I stick to the jit.qt.movie object or switch to the new jit.movie object ?

they are the same, jit.qt.movie is simply an alias for jit.movie to support legacy patches.

2- Use the qt engine or the new viddll engine ?

use viddll. the quicktime library is deprecated and not recommended on windows due to security vulnerabilities

3- What would be the best video codec to use in each case ?

depends on your needs. h264 is a good place to start.

4- Could I use the max 64 bit version ?

yes. viddll engine is supported on both platforms with both architectures.

Hi Rob -
Along the same line of questioning, could you enumerate the advantages & disadvantages of viddll vs avf on OS X? Is one generally preferred over the other? I've been going back and forth between them, and I'm not sure I've noticed a lot of difference. I guess jit.movie~ tilts the scale in favor of viddll, but are there other factors we should be considering? Thanks.

>What would be the best video codec to use in each case ?

>>depends on your needs. h264 is a good place to start.

I've been under the impression for a good while that h264 was a time-based compression, which means that it's not going to be a great choice in any situation where you're not playing the video forward and normal speed. Has h264 been changed in some way that would change my long-held assumption?

Thanks in advance for your wisdom, Rob....

Hello Rob, thanks a lot for your response ! Your exemple is very easy to understand and is working well. I see the effort been done to simplify the patching in regrouping different boxes. That is really satisfiying.

I encoded the video in QT with H.264 codec and the result is fluid, also when going backwards.
I will inquire further but this seems to make the job very well. Thanks.

Ah just a remark, your patch is working on max 7 32 bits but on the 64 bit version, it doesn't play the video (black screen), event the video you included as exemple. Any idea how to fix that ?
Thanks,
Christian

hey guys,

the short answer is, test on your setup for your particular needs. my recommendations are based on my own anecdotal observations, but may be entirely unsuitable for specific uses cases and hardware setups. this is why we spent the time to make switching video engines so easy.

the medium answer:

disadvantages of viddll vs avf

the avf engine does a great job with the codecs it supports, h264 and prores in particular, especially with output_texture enabled. it uses the apple hardware decoder and seems to handle random seeking very well with HD and UHD content, and has a smaller memory footprint per loaded file compared to viddll.

viddll however, allows you to pre-load the files into RAM cache (loadram), supports many more codec and format types, is cross platform and cross architecture, supports synchronous frame seeking, supports jit.movie~, and the (beta) asyncread behavior seems to work better at loading without stalling the renderer than avf.

Has h264 been changed in some way

AVF and h264 seems to handle random seeking fine, but reverse playback and fast rate changes, not so much. however it entirely depends on things like the size of the file, bitrate, and number of keyframes, and what you are doing with the file. for any use with jitter, it's recommended to export with keyframes every frame.

viddll allows you to load the file into memory (assuming sufficient memory is available) and therefore once it's decoded in memory, decoding speed of particular codecs in forward or reverse or random seeking is irrelevant.

the long answer, i need to write up an article on all this stuff, and plan to do so in the near future.

@christian, no idea. i would restart, make sure you have the proper latest version installed, make sure viddll is selected as the video engine, and make sure there are no errors or warnings in the max console.

I've tested a lot codecs in the last couple of weeks, and as ROB said, it depends on your engine and what do you wanna do with it. I have an 5 year old Macbook Pro, and i need every single frame i can get from my graphics. First of all think about your resolution and keyframes. Do you really need 2K or full HD? In my case i figured out that in some cases avf is a bit faster than viddl, but, viddll is way more flexible. I decided to just go on h264 even though HAP is faster and less CPU/GPU hungry if you are load movies vere (very) fast. (for example)

But this maybe all changes when apple supports native h265 hardware-playback on the new upcomming macbooks (so sign yet in macOS sierra)

cheers
markus

Hi Rob,

I'm finding the cache_size / loadram combination is not seemingly working as expected with h.264 on longer 4k videos of about 10 minutes in length, Win 10.

In fact, just now I got a crash, after playing around with this a bit in the example patch provided above, in 32bit mode (probably the cache_size request of 2GB was beyond what could be allocated in 32bit mode?). This machine has 16GB RAM, but I expect can only use 4GB of it in 32bit applications.

Prior to the crash, setting the cache_size and then triggering a loadram message would report an extremely small range from the notification, from 0. to some small quantity 0.n.

Finally after playing around with the value I got it to report a loaded range from 0. to 6.n, but that was the point when setting the slider feeding "position" caused the crash.

Trying once again in 7.3, 64bit, it seems that loadram message will only want to load small amounts of the video to ram, the largest I've been able to get is about 50 seconds, and this was for exorbitantly large cache_size settings (i.e. 16GB). Playing around with this a lot is seeming to make Max very unresponsive... in fact it is making the entire OS very unresponsive (loadram messages after extremely high cache_size attribute settings, up to the max 512 allowed)

I guess this feature wasn't designed for loading relatively long video clips, of minutes in length, to RAM?

Edit to add more:

Just realizing now the main problem was almost certainly a poor encode on the video I was testing with, nothing to do with Max.

The only thing on the Max side that threw me for a loop was the notification the jit.movie would output after receiving a loadram message.

For example, with a video that behaves properly, if the resolution is lower, it will notify a larger range read into memory (I was seeing more than 70 seconds loaded, but 20 minute long videos behaved as though the whole video was loaded to RAM, or possibly disk-based reading is just that much quicker..). Responsiveness seems excellent for cuing the position around, either way.

For higher resolution videos approaching 4K, it seems to have more trouble, or at least the loadram message reports back only 5-6 seconds loaded. None of this seems to have anything to do with the length of the videos.