Rendering a region starts 1 frame before region

Little_Green_Dog wrote on 5/4/2024, 7:16 PM

Hi,

I need to render a bunch of regions from my timeline, but Vegas 21 is rendering each output clip with an extra frame at the head.

When I check the beginning of each region on the timeline, the first frame is correct, but the output clip starts with the last frame of the previous region. Curiously, the last frame for each clip is correct, so I'm getting footage that's 1 frame longer than it should be.

Here's my setup:

I'm an animator, and I used Vegas to set up my animatic. I'm using regions to render out each scene on the timeline as a clip that can be imported into our animation program to use as reference footage. This is why it's important for us to have exact frame accuracy.

To set the timeline regions, I used Vegasaur Markers to convert my markers to regions. To render, I tried Vegasaur's Quick Render batch script, the native Vegas batch script, the modified Vegas batch script by iEmby, and rendering with the regular Render As command, and I get the same extra frame result in the clips from each. I also tried different output formats, but I had no luck getting rid of the extra frame in every clip.

This isn't critical because we can offset the footage in the animation program and ignore the first frame, but it's still wrong.

I was just wondering if this is a known issue or if I missed an option in Vegas that renders the clips correctly.

Thanks in advance for any suggestions!

Comments

Dexcon wrote on 5/4/2024, 8:12 PM

Have you got 'Quantize to Frames' activated at the top of the Options context menu?

When activated, any frame that doesn't sit bang on a frame line on the timeline will be highlighted in red.

In the above screenshot, the LH edge of the audio event sits midway between two frame lines (arrowed). When this happens with a video event, rendering will render the entire first frame but render that whole frame as black.

Any unquantized video events need to be manually adjusted to a frame line. Unquantized audio events aren't so important in fixing unless one wants to do so.

Using ripple - especially when ripplining via an audio event - can sometimes cause all the video events affected by the ripple move to become unquantized. In that case, its a straightforward case of manually adjusting - with ripple activated - the first unquantized video event on to a frame line; all the following unquantized video events should then also hit a frame line and therefore become quantized.

Little_Green_Dog wrote on 5/5/2024, 9:01 AM

Hi, Dexcon! Thanks for replying.

Quantize To Frames was enabled, but I didn't check to see if I would get the correct results when it's disabled though. I don't really want to disable it, but I will check that later today and follow up. Thanks for suggesting this.

Regardless, this still means there's a 1 frame offset (extension, actually) between playing a region on the timeline and rendering a clip of that region. Every region exported (14 shots total) has this unwanted extra frame at the head of the clip.

Dexcon wrote on 5/5/2024, 9:09 AM

... but I didn't check to see if I would get the correct results when it's disabled though

It needs to be enabled, not disabled. Disabling loses the identification of unquantized events.

Robert Johnston wrote on 5/5/2024, 1:20 PM

@Dexcon, @Little_Green_Dog,

I can confirm that Vegas 21 300 is including the frame before the loop region when rendering to Magix AVC. I used Solid Color generated media orange and blue. I can see the one orange frame at the head followed by all blue frames being played back in VLC. Very obvious. And Quantize to Frames was enabled.

Robert Johnston wrote on 5/5/2024, 1:30 PM

Wait a minute. After appending more generated Solid Colors to the timeline and extending the loop region, the orange color was no longer at the head when rendered.

Little_Green_Dog wrote on 5/5/2024, 1:33 PM

It needs to be enabled, not disabled. Disabling loses the identification of unquantized events.

Oh, yes, I understood what you meant. I was just saying I was seeing the error with it enabled (it's on by default here,) but I hadn't checked to see if I got a different result when it was disabled. (It doesn't make any difference.)

@Robert Johnston, thanks for confirming this! Is there a place where this bug can be reported?

Little_Green_Dog wrote on 5/5/2024, 1:39 PM

Wait a minute. After appending more generated Solid Colors to the timeline and extending the loop region, the orange color was no longer at the head when rendered.

That's so weird, but this may confirm something else I was seeing: occasionally, rendering a region seemed to work correctly, but when I repeated the render, it was adding the extra frame again.

I was overwriting my test results and hadn't saved the 'good' one, but now I don't think I'm going nuts.

Little_Green_Dog wrote on 5/5/2024, 8:19 PM

I did more testing this afternoon, and it's consistently rendering the extra offset frame at the beginning.

I made sure every region started on a whole frame and every scene was snapped to the frame. Quantize on, of course, frame rates between project and output synced. I guess I'll contact tech support and submit a report about it as soon as I'm able to.

Little_Green_Dog wrote on 7/2/2024, 8:26 PM

Just a followup: I'm finally getting around to looking at this issue again.

We started another animated short here this week, and our shot exports from the animatic each still have the extra frame at the head when rendering Regions from the Vega timeline.

For clarity, here's our workflow:

1. Mark each shot's start point in the animatic's edit.

2. Use Vegasaur Markers tool to convert the shot Markers to Regions.

3. Use Vegasaur QuickRender to batch export the Regions as individual ProRes 422 clips.

4. The animators use these clips in our animation program as reference footage.

This process has worked correctly in the past, but now, each clip has an additional frame from the previous shot at its head. Curiously, each clip does end on the correct frame; it's only the first frame that's wrong.

In our last animation production, we compensated for this error by trimming the head of the clip in our animation program.

In our current animation production, I tried something different: I went through the Vegas timeline shot-by-shot and trimmed each region to drop the first frame of each shot. When I exported the edited regions from Vegas, we got the correct shot lengths for every shot (in other words, the first frame that was edited to be dropped from a region was included in the exported region, and no unwanted frame was included.)

Here's a screenshot of what the regions look like to get the correct export from Vegas...

Notice there is a one-frame gap between the region markers for every shot (the orange space.) This was necessary to get the correct duration for each shot (i.e., no gap).

Even though I'm using third-party scripts from Vegasaur to render the regions, the 1-frame error occurs even when I export the regions manually from Vegas using no script. So the fault is not with the scripts. I also tried different movie formats and still get the unwanted extra frame in our clips. The only way to get the correct durations is to 'lie' to Vegas about what we want from it. 🐱

I'm not sure when exporting Regions broke in Vegas because our last in-house animated short (before the previous one) was made a few years ago, and the Vegas workflow described above worked fine for us back then.

As suggested, I'll make a proper report to Magix later this week. I just wanted to mention my solution here in case anyone else encounters this problem. It's not an ideal solution because it defeats part of our automated process, but it gets the job done for now.

mark-y wrote on 7/2/2024, 8:49 PM

Quantize To Frames was enabled, but I didn't check to see if I would get the correct results when it's disabled though. I don't really want to disable it, but I will check that later today and follow up. Thanks for suggesting this.

In order for the media to be correctly quantized, "Quantize to Frames" must be active before adding any media to the timeline, as in a fresh project.

Turning "Quantize to Frames" on and off after having added some media to the timeline does absolutely nothing, whether or not they were quantized or not when added. This is important to understand, because clicking the switch doesn't fix anything.

There are scripts to perform QTF after the fact, or the best way to learn is to start with a fresh project, properly configured and begin adding your media.

Little_Green_Dog wrote on 7/4/2024, 11:50 AM

Thanks, but I don't think that's it. Quantize to Frames was on before I started the first project. I only switched it on and off after someone suggested it. I just checked for our current project and it's same there: Quantize to Frames is on by default. The current project was started fresh and not a repurposing of the previous project.

To be clear, there is no video footage in this project at this time, so I don't it's a frame rate problem. This is an animatic and there are only still images from the storyboard placed on the timeline, and every shot lines up perfectly on the frame markers. Also, this one-frame extension occurs with every shot exported as a movie clip.

I need to check again, but when this happened the last time, it seemed to happen only when rendering to a movie file (I tried ProRes 422 and H.265), and it did not occur when I rendered to an image sequence of a region. That was a couple of months ago, so I'll look again to be sure as soon as I'm able to.

It's very puzzling. As mentioned previously, we never had this problem with an older version of Vegas.

Little_Green_Dog wrote on 7/4/2024, 12:00 PM

Hmm...after writing the above, I thought of something: Maybe this occurs only with the animatic? We normally export shot regions only for the animatic, which are always made of still images unless a shot needs something pre-animated.

I never if this error occurred with rendered video footage on the timeline. We don't need to do that, but I'll check if it makes any difference.