I only ever get that warning on one application I use from ASUS. If I click no, it never runs. Never seen that happen with another app though.
Regarding playback.
You shouldn't really need such a large audio buffer for this. Large audio buffers can be the cause of lag or stuttering. Not always, but could be a factor. You could also try changing your Import to CPU rather than nvidia, (That's a wild guess but maybe worth a try for this type of work).
Last but not least.
Even very fast SSDs have limits if the have to read and write a large file at the same time. I think (Although not completely sure) that whole file of 914MBs will have been loaded even though only a small portion has been selected. That's where I find lowering the audio buffer helps so less audio data gets loaded at a time.
When I do get stutters it is time to either create proxy files or use the Preview Render option although with the latter any alteration normally means that section has to be re-rendered. I would imagine any pre-rendering would happen quite quickly on your machine.
Ray.
Former user
wrote on 7/27/2022, 7:55 AM
@CubeAce I'll try changing the audio buffer, that's the default, & yep well aware of proxies & prerender, proxies often don't seem to make much difference &prerender can actually screw up the timeline, I tried both on this with no joy. It might be my pc tho, i'll have another go later.
PS, that media is an unedited screen capture, I know it's variable etc. but it looks just like any of my other files, this one plays ok but for whatever reason the Geforce screen captures do seem to need a bit more umph from the software to play, when i play them i can tell it's not as smooth or instant as one of my phone clips or an exported file 🤷♂️🤯
Then your audio default is different to mine, possibly down to the additional resources of your system but strange as it shouldn't need that amount unless you get to needing more than four independent sound tracks.
Other things that help are deleting unwanted sound tracks on other clips and not using full resolution clips for the individual 'boxes' if those clips are not going to be expanded to full frame and not importing clips that use HEVC.
Like I said, only use pre-rendering to check the flow of a section. Any alterations will not be seen unless that is done and not actually useful while putting sections together. I only use it to check a section I've just altered is playing back OK as it is faster on my machine than exporting a short clip.
[Edit]
That's why I use OBS. Great exports using H264 more effectively than any other bit of software I use. Why or how I've no idea but I'm not using default settings.
Not yet, need to have a look at it in more detail, however does that not still put the same load on the CPU/GPU as if the nested movie contents were in the timeline the nested movie was being added to?
I did some tests.
I have 2 movies, each is just a collage using Complex Geometry/Honeycomb. The combined movie has both twice as nested objects, each was shortened using Stretch, and there 3 short Glide transitions, and an audio file.
I have NVIDIA GeForce RTX3060 (GPU 1) for Processing and Export.
Playback of combined movie runs UHD Graphics 630 (GPU 0) up to 83% and GPU 1 to about 25% or less. There is stuttering.
Playback of the individual movies with the collages gives the same.
I applied Preview Rendering to one of the movies (Winter) and playback was the same, with stuttering. Most annoying.
I applied Preview Rendering to the combined movie and there was no stuttering of the nested movies, whereas the source movie itself stutters even after applying Preview Rendering. Both CPU 0 and 1 went to about 15%.
I exported each of the 2 movies to mxv and created an identical movie using them, with transitions and music. CPU 0 ran around 15%, CPU 1 around 20% with a couple of spikes to 29%, and, of course, no stuttering.
Summary:
Preview Rendering on the collage is useless.
Preview Rendering on the nested objects (collage movies) works well, smooth playback with lowest strain on CPUs.
Using mxv's gave smooth playback without Preview Rendering and had slightly more stress on CPU 1 (NVIDIA).
At some point, I will do more testing using nested objects, but it appears that just doing Preview Rendering on them works quite well. If they have to be changed at any point, I think it would be more efficient to using nesting rather than ex/im mxv files.
One very strange thing is that I tried applying the same collage in another movie and it would only take the first object, ignoring the other 4. I exported the movie containing only the 5 clips and the collage still wouldn't work properly. I created a new project, imported and trimmed the clips, and the collage worked fine.
John CB
Former user
wrote on 7/27/2022, 9:16 AM
@CubeAce Hi, yep reducing resolution of the clip would help although i would like to be able to zoom in on individual boxes, but i shouldn't have any problem with the 1 track + a couple of masks, what if i had a timeline with a few dozen clips n bits, it'd be a pain reducing each individually etc.
that screen capture i trimmed the ends where i started & stopped screen recording, exported as 4k AVC so i was using a fresh file,
this is how it goes with proxie, prerender etc. reducing audio buffer does seem to help a bit.
@browj2 yeah using SPR is no prob, I show that in the video above, , I have used this since 2004, but i think what Ray was meaning was using/importing smaller res images in the first place, rather than 4k & reducing them on the timeline,
I think that context is important here. If you're building a video wall, like my 28 image grid, each cell is about 274x270 (for 1920x1080), so the resolution does not need to be very high if the clip goes in just one cell, does it, unless you want to zoom way in on some very small detail? This is usually not the case. Of course, in Oz' example, there are some 4 cell videos, so you just have to make the calculation. In any event, I just import everything at the original resolution and go from there.
To get the grid, I created a grid itself and put this on the highest track, no chromakey. Thus you see the grid and you can change the colour. Of course, if you want the grid to be transparent right to the bottom to see what is on track 1, then this method does not work.
To create each of the masks, I created a grid in Xara with 28 cells and then just changed the colour of the cells from black to white, export to transparent png, repeat.
For 4 cells:
Once the cells are set up, it's easy to create the masks.
I can scroll easily enough but but playback is now having to be pre-rendered each time to check it is playing and the timing is as I want mine.
I know we are taking different approaches. Are you adding video clips?
I'm up to 15 individual video clips and 8 stills some of which are animated.
The video shown also pans across the whole screen and zooms in and out. Not sure how that bit will go yet.
Ray.
Former user
wrote on 7/28/2022, 4:23 PM
@browj2 No offence, I'm not 'making this hard' but you mention & everything you've been showing seems to be HD 1920 x 1080, in my comments & videos i've been working in 4k, I've mentioned it a few times, HD is really easy, 4k isn't hard tho either but i was puzzled why it didn't want to play one simple 4k file + 2 masks, I've worked out MEP doesn't seem to like 2 masks one on top of the other, as i showed in my vid, i swapped the masks around, so they're on top &/or below the media but still it wouldn't play right, not in 4k on my machine anyway, i haven't tried two masks on top of each other on HD 1920x1080,
this is 4k, 15 tracks, each media with just 1 mask, plays & exports no problem,
Here is what I wrote in the context of your Vegas presentation:
You seem to be making it too complicated. Simply use masks.
For your Parent/Child and applying an effect to the parent in Vegas, you can do the same in VPX by nesting as I showed. You apply the effect to the resultant object. Would you like a demo?
I see that you have now done this in MEP. That is what I was talking about, simply use masks.
The only difference between doing this in FHD and 4K is the resolution. The technique is the same.
The way masking works and as I show in one of my early tutorials, white shows what is on the track above (higher numbered track), black creates a hole in the track above, showing what is on the track below (lower numbered track). If there is a mask on the track below that one with black in the same area, then another hole is made, etc. You have it figured out in the video in your last post.
Track - Object
Video
Mask
Video
Mask
Video
Mask
...
You cannot have masks one above the other as you found. The mask affects the information from the next higher-numbered track; that track cannot also be a mask. To use the combined masks, you have to put the same top video clip (Video B) in between the masks, so:
Video A (background)
Mask b
Video B
Mask c
Video B
This also adds in flexibility to show different parts or the same part of Video B in the two squares.
MEP doesn't have nesting, so you have to do as John EB indicated, ex/im mxv file, in order to put effects on the combined video wall, like a transition to another video wall.
For whatever reason I have found in the past (and on this project) that using masks for whatever reason uses up much more of my computers resources than using any effect that effectively reducing the size of the object on screen (PiP).
Hence this time around I've been using such plugins. This has enable me to get up to 15 tracks of video clips and stills. All images and videos have been 4K or jpgs or png files of at least 12MBs in size for the stills and 100Mb/s 50fps for the video clips. After a while I do have to pre-render the sections I'm working on to see if the movement is correct for each clip but when editing the scrolling is smooth enough to not notice any problems.
The last bit of the project no-one yet seems to have tackled is the zooming in and around of the screen.
For that I may have to upscale the video to 8K and then re-run the finished video and zoom in and around using size, position, rotation, and exporting to HD to retain the perceived quality of the final export.
I am going to push this one minute video as far as I can to see the limits of my system to cope with this.
For some idea how far behind my nvidia 1650 Super is to Gids card, this one minute of video is taking one hour to process to 4K at the moment. That could double by the time I finish adding clips and stills.
OK, I understand now why you want to use a higher resolution project. You want to zoom in on the final result without losing any resolution. The original video given by Oz has some zooming in, but it is short and not very much so not much resolution would be lost. The video also has glide transitions between video walls, and the only way that I can think of to do this is to have separate files for each video wall, or nested objects if using VPX.
In my example using the collages, I did not doing any zooming in of the result of each collage, only glide transitions.
If the final result is to be 4K and you want to zoom in on the video wall itself without losing any resolution, then yes, you would have to use an 8K project. The objects in the initial projects do not need to be 8K as they will be zoomed out and normally not exceed their original 4K resolution. When done, export to mxv at 8K. Do the second video wall, export to mxv at 8K. Repeat for any more.
Open the final project as 4K, import each mxv to the timeline, add the effects to each object and add transitions. Don't zoom in further than 7680x4320 and you won't lose any resolution.
Nesting (VPX) would not work without losing some resolution if zooming in on the nested object was required.
Here is an illustration of how to do nesting in VPX. You simply created separate movies and then drag the movie from the Project Temp Folder onto the timeline in another movie. Effects can be applied to the nested objects.
How noticeable would a 10% zoom-in be over 1 second? In Oz' example, the action happens so fast and the zoom-in on a video wall not excessive, so I wouldn't worry about a slight loss of resolution; a purist would.