Joris Strijbos

I am working on a video player patch. But the output varies in choppy playback. It's supposed to run a LED wall and we are using quite big files of approx. 4 GB. 

I have been looking into different modes of jit.movie and experiment with metro speed, but the problem seems to come and go over time. The framerate stays at 60fps.

Also I want to output two of the same screens, and I don't know if that has something to do with the problem, maybe someone has a more efficient way of doing this?

I am on a windows 10 pro computer, with a i7-8700 CPU intel core, 3,19 GHz and 64gb RAM. And working on Max 8.

number

toggle

random

counter

metro

message

attrui

jit.gl.videoplane

comment

jit.fpsgui

loadbang

jit.window

jit.gl.render

qmetro

playbar

umenu

prepend

inlet

outlet

jit.movie

I am working on a video player patch. But the output varies in choppy playback. It's supposed to run a LED wall and we are using quite big files of approx. 4 GB. 

I have been looking into different modes of jit.movie and experiment with metro speed, but the problem seems to come and go over time. The framerate stays at 60fps. 

I am on a windows 10 pro computer, with a i7-8700 CPU intel core, 3,19 GHz and 64gb RAM.  And working on Max 8. 

Hi Guys, 
I am working on a video player patch. But the output varies in choppy playback. It's supposed to run a LED wall and we are using q

jit-movie-playback-choppy

you could try ping-ponging between two jit.movie objects, and using loadram to load each movie into memory prior to playing. depends on how large and the length of the movie files if it will fit into memory. you would then set up your patch so the menu triggers the loadram of the jit.movie not currently playing.

otherwise, I don't see anything wrong with your patch. what codec are you using? what dimensions are the files? does the stuttering happen with simple playback? with seeking? with reading a new file?

you could try ping-ponging between two jit.movie objects, and using loadram to load each movie into memory prior to playing. depends on how large and the length of the movie files if it will fit into memory. you would then set up your patch so the menu triggers the loadram of the jit.movie not currently playing. 

The codecs differ in the video files, they are JPG for the ones made in Jitter on a PC and ProRes422 for the ones made in Jitter on a MAC. The frame rates were recorded realtime and vary per file from 23 FPS to 54 FPS (most of them are around 30 FPS though). Also the bitrates vary per file from 60.000 - 220.000 kbps.We're thinking it's best to render them all to 30FPS in the same codec (perhaps we should also limit the datarate the same for each video?) to avoid this choppy playback, but it's hard to figure out which codec is the best suited for playing back video on MAX on a PC.

We are thinking about using ProRes422 under the Quicktime format or at least a codec that allows for least compression and quality loss.But we'll play the videos on a patch running a PC/windows, so perhaps another codec will work better in MAX then? Do you have advise on this?Our resolution is 4272 x 256, an unusual one, it's for a LED wall. 

As for the patch I am making a mixer between two jit.movie objects because in the end we want to fade two videos. Here there are two kind of bugs. One is the stuttering of the video which is being played, the stuttering happens with simple playback and varies also in the same files each time when played. This is also happening when I only use one jit.movie, like in the patch I posted before. I kind of solved this by putting my metro on 4 which resulted in a smoother playback, even when the fps stayed on 60, but sometimes stuttering still occurs.

The other one is when I am playing a video in one channel, and load a video in the other. The playback stops for a second and then continues. Here I changed the cache size from 60GB before (which is slightly under the RAM, since we thought to use all the memory that is available to avoid a crash to 0.8gb (default of the cache object is 0.1 gb) and this hiccup stopped, but the stuttering becomes heavier. 

Total size of all the videofiles is now 60GB and memory is 64GB. I would also like to see if it's ok to use more videos, but then we're exceeding the RAM memory. Is this something that will give more problems in max in video playback over time (crash, stuttering etc)? 

The loadram message is not really clear to me, do I just send that to the jit.movie once? Or every time I load a video? 

Thanks for thinking along!

The codecs differ in the video files, they are JPG for the ones made in Jitter on a PC and ProRes422 for the ones made in Jitter on a MAC. The frame rates were recorded realtime and vary per file from 23 FPS to 54 FPS (most of them are around 30 FPS though). Also the bitrates vary per file from 60.000 - 220.000 kbps.We're thinking it's best to render them all to 30FPS in the same codec (perhaps we should also limit the datarate the same for each video?) to avoid this choppy playback, but it's hard to figure out which codec is the best suited for playing back video on MAX on a PC.

We are thinking about using ProRes422 under the Quicktime format or at least a codec that allows for least compression and quality loss.But we'll play the videos on a patch running a PC/windows, so perhaps another codec will work better in MAX then? Do you have advise on this?Our resolution is 4272 x 256, an unusual one, it's for a LED wall. 

As for the patch I am making a mixer between two jit.movie objects because in the end we want to fade two videos. Here there are two kind of bugs. One is the stuttering of the video which is being played, the stuttering happens with simple playback and varies also in the same files each time when played. This is also happening when I only use one jit.movie, like in the patch I posted before. I kind of solved this by putting my metro on 4 which resulted in a smoother playback, even when the fps stayed on 60, but sometimes stuttering still occurs.

The other one is when I am playing a video in one channel, and load a video in the other. The playback stops for a second and then continues. Here I changed the cache size from 60GB before (which is slightly under the RAM, since we thought to use all the memory that is available to avoid a crash to 0.8gb (default of the cache object is 0.1 gb) and this hiccup stopped, but the stuttering becomes heavier. 

Total size of all the videofiles is now 60GB and memory is 64GB. I would also like to see if it's ok to use more videos, but then we're exceeding the RAM memory. Is this something that will give more problems in max in video playback over time (crash, stuttering etc)? 

The loadram message is not really clear to me, do I just send that to the jit.movie once? Or every time I load a video? 


All the best, Joris

hi Joris, for such an odd resolution you will have to just test and see what works best. for large files disk speed becomes a major factor, so SSD drives are generally recommended. Hap is worth investigating as well. The viddll engine supports hap file playback, but you should also install the Hap package from the Package Manager and run some comparisons with the hap engine (which decodes hap via a directshow instead of ffmpeg).

lastly, you may want to investigate splitting your app up into separate patches that run on separate instances of Max (simply copy the Max 8 exe folder and rename it), in order to better utilize the CPU cores on your machine. Some standard practices for this involve separating the audio and UI processing from the video processing, or splitting the video processing into 1 or more players and renderers, e.g. 1 or more patch reads movie files and outputs the frames, and the other patch running in a separate Max process mixes, effects, and displays the frames. To do this you use the Spout package to send textures between instances of Max, and udpsend / udpreceive to send messages.

loadram is used once, after the movie file is read. a standard practice is to read the file, and use the file read notification to trigger the loadram, then use the loadram notification to start playback (and trigger a crossfade or whatever process needs to happen).

@cache_size of 64 simply means allow that particular jit.movie object to a maximum of 64 GBs of memory to cache frames, either via loadram or simply from the frame decoder thread when playback is started. if the uncompressed size of the movie is less than 64, then only that amount will be used. if it's greater, then only the 64gbs most recent frames will be stored in the cache.

lastly, you may want to investigate splitting your app up into separate patches that run on separate instances of Max (simply copy the Max 8 exe folder and rename it), in order to better utilize the CPU cores on your machine. Some standard practices for this involve separating the audio and UI processing from the video processing, or splitting the video processing into 1 or more  players and renderers, e.g.  1 or more patch reads movie files and outputs the frames, and the other patch running in a separate Max process mixes, effects, and displays the frames. To do this you use the Spout package to send textures between instances of Max, and udpsend / udpreceive to send messages.

Hi Rob, many thanks for all your pointers, we made progress but still encounter crashes and have been testing different parameters to eliminate causes. we'll post our findings when more is clear.

Jit.movie playback choppy