michelefiori

Hi friends, I need to have some details on video rendering with the GPU

1. when we use the texture option the video is loaded by 

2. when we use the loadram command is the video loaded into the computer's RAM?

3. if the two commands are used together what happens? how can you get better performance, especially with heavy formats (fullHD, 4K..etc)?

4. How does the asynchronous reading affect rendering in the GPU?

5. To use the loadram command I must first provide a substantial cache .. is the cache_size expressed in MB? Should I consider a cache_size at least as large as the file to be loaded?

1. when we use the texture option the video is loaded by Jit.movie directly from the hard disk in the GPU?
2. when we use the loadram command is the video loaded into the computer's RAM?
3. if the two commands are used together what happens? how can you get better performance, especially with heavy formats (fullHD, 4K..etc)?
4. How does the asynchronous reading affect rendering in the GPU?
5. To use the loadram command I must first provide a substantial cache .. is the cache_size  expressed in MB? Should I consider a cache_size at least as large as the file to be loaded?

Thanks!

Hi friends, I need to have some details on video rendering with the GPU
1. when we use the texture option the video is loaded by Jit.movie d

gpu-video-rendering

The answers below assume Max 8 and viddll engine, the only engine that supports loadram.

more or less. the frames are decoded by the CPU and uploaded directly to the GPU for playback.

the frames are decoded and stored in memory. they are uploaded to the GPU from this RAM cache when available, otherwise decoded from the movie file.

Codec and diskspeed come into play greatly with files of that size. Hap is a good choice requires large file sizes. h264 (or hevc, h265, other modern temporal compression codecs) are also good if straight forward playback with no random access or rate changing is needed. reading from SSD drive is usually recommended.

For viddll engine jit.movie, you should increase your @cache_size attribute to whatever works for your setup, but at least 1 (GB) for these ultraHD resolutions. Then simply enable @output_texture, and ensure the signal chain only goes through texture processing objects (jit.gl.slab, jit.gl.pix, vizzie modules) and then displayed with a jit.world. If the chain goes to any matrix objects, or a jit.pwindow the FPS will drop significantly.

If you have enough memory available, and the clip is short enough you can try to increase your cachesize (i'd say ~2 GB less than your total memory) and load the file into memory with loadram. as demonstrated in the jit.movie help patch (VIDDLL specific tab, loadram sub-patcher) the object will print out the dumpout how many seconds of the file it was able to load into memory.

Yes, described above. cache_size is GB. No, you must consider a cache_size as large as the 

 of the file to be loaded (typically much larger than the file itself).

1. when we use the texture option the video is loaded by Jit.movie directly from the hard disk in the GPU? 

2. when we use the loadram command is the video loaded into the computer's RAM? 

3. if the two commands are used together what happens? how can you get better performance, especially with heavy formats (fullHD, 4K..etc)? 

Codec and diskspeed come into play greatly with files of that size. Hap is a good choice requires large file sizes.  h264 (or hevc, h265, other modern temporal compression codecs) are also good if straight forward playback with no random access or rate changing is needed. reading from SSD drive is usually recommended. 

For viddll engine jit.movie, you should increase your @cache_size attribute to whatever works for your setup, but at least 1 (GB) for these ultraHD resolutions. Then simply enable @output_texture, and ensure the signal chain only goes through texture processing objects (jit.gl.slab, jit.gl.pix, vizzie modules) and then displayed with a jit.world. If the chain goes to any matrix objects, or a jit.pwindow the FPS will drop significantly. 

4. How does the asynchronous reading affect rendering in the GPU? 

5. To use the loadram command I must first provide a substantial cache .. is the cache_size  expressed in MB? Should I consider a cache_size at least as large as the file to be loaded? 

Yes, described above. cache_size is GB. No, you must consider a cache_size as large as the uncompressed frames of the file to be loaded (typically much larger than the file itself).

FWIW, most of the answers I've given here are found in the jit.movie reference page. In order to view the viddll-specific reference page, create a jit.movie object with viddll set as the video engine (the default on windows), or specify @engine viddll in the object box, and then right-click - Open jit.movie Reference

Thank you very much Rob, now everything is clearer ..

  in fact I got a better fluidity in the videos through the complete upload in the ram and the subsequent sending to the GPU, the problem is that the loading time on ram for a whole video is very long, and this makes it very difficult to use it in practice. Is there a way to upload directly to the GPU memory without intermediate steps?

Thanks again for clarity and congratulations for your work!

Great thread here. Some clarification on a couple points please.

1. If the video is uploaded to the GPU as a texture, are the frames then sitting in the video ram and thus loadram to the motherboard becomes unnecessary ? I would think we'd rather use the video ram.

2. Does a video loaded to RAM or the GPU maintain its codec or is it decoded into something we can jump around / play backwards without interframe compression ?

Great thread here. Some clarification on a couple points please. 

1. If the video is uploaded to the GPU as a texture,  are the frames then sitting in the video ram and thus loadram to the motherboard becomes unnecessary ? I would think we'd rather use the video ram. 

2. Does a video loaded to RAM or the GPU maintain its codec or is it decoded into something we can jump around / play backwards without interframe compression ?


1 - loadram preloads decoded frames to cpu memory. output_texture uploads the current frame to the GPU for display

2 - frames in the loadram cache are uncompressed

1 - loadram preloads decoded frames to cpu memory. output_texture uploads the current frame to the GPU for display 

2 - frames in the loadram cache are uncompressed 

As to point 2 - I am loadramming short temporal compression clips, HEVC 1080p 2 seconds, and playing backwards still doesn't work, even though at this point the video is uncompressed. Why is this the case ? If you load to ram the codec isn't used so why should this not work but mjpeg work fine ?

Hi again and thanks again to Rob Ramirez: I propose this problem: I am doing a project in which there are two jit.movie objects on which two videos are loaded to show alternately. The first goes in a loop and a signal comes to the end and when it ends the other starts on the second jit.movie. I used the loading of the first and last second of the videos with loadram to avoid the slowdown of the loop when it is resumed. The problem I encounter is that when I load on the second jit.movie the video that should be played at the end of the first one, during the loading I notice a slowdown in the rendering of the first video that is playing in the meantime.

Jit.Movie_problem_to_forum.maxpat

Hi again and thanks again to Rob Ramirez: I propose this problem: I am doing a project in which there are two jit.movie objects on which two videos are loaded to show alternately. The first goes in a loop and a signal comes to the end and when it ends the other starts on the second jit.movie. I used the loading of the first and last second of the videos with loadram to avoid the slowdown of the loop when it is resumed. The problem I encounter is that when I load on the second jit.movie the video that should be played at the end of the first one, during the loading I notice a slowdown in the rendering of the first video that is playing in the meantime.
Is there any way around this problem?

GPU Video rendering