okay, now I am confused....I placed the clips on the timeline via the Explorer window in Vegas..A simple drag and drop, that has always snapped all the clips together. I zoom in and I see this:

Now I tried the "Show unquarantined.." and I get this:

I see the red, but where is it coming from if I am dragging the clips to the timeline and they all snap together...This was working fine in 300 and previous version.

Thank you

Is the timeline set to a framerate that exactly matches these clips?

I get unquantized frames regularly when using phone video (Samsung S23 Ultra and previous Samsung phones as well) because phone video is invariably at NTSC frame rates (i.e. 24, 29.7, 30, 60 fps) and is also recorded in a variable frame rate (VFR) which means that in reality the frame rate recorded by the phone can vary considerably from the fps rate chosen in settings.

In the following image, the bottom video track shows the original VFR video from the phone - there's lots of unquantized frames. The top video track contains the same video events after they have been transcoded to 25 fps at a constant frame rate (CFR) in Vegas Pro 21 - there are no unquantized frames.

To see what unquantized means, zoom right in on the timeline to a few frames only and you'll see the the red frame edge does not sit on a frame line - it sits midway between the two frame lines (L & R) of the one frame.

In the above pic, the two markers show the beginning and end lines of just the one frame. The phone video ends midway in the frame. If rendered, this frame will likely render as black because the frame isn't fully occupied by the video image. To fix, it's just a matter of trimming the end of the video event to the LH frame line and then moving the following events up by one frame usually by using Ripple.

Enabling the quantize menu option does not change the position of any event on the timeline, all it does is identify unquantized frames.

From your MediaInfo report, I see that your video has been shot CFR so the unquantized frames may be caused, as alluded to earlier in this thread, by the project frame rate not being exactly the same as the media.

The unquantized frame issue is not new to Vegas Pro 21 build 314 by any means. I first encountered the unquantized frame (with one black frame in the render) issue back in 2013 in Vegas Pro 12 - and that was with video media that was the same CFR frame rate as the project. Prior to the last few Vegas Pro versions, enabling the unquantized frame display had to be done in Internal Preferences.

Please follow this post as a guide for providing comprehensive information to help troubleshoot problems like this. In particular:

What was the source of the files (what camera)? (B3)

Which decoder is Vegas using? (C2)

Is the timeline set to a framerate that exactly matches these clips?

No it does not and don't intent to. I shoot in 60fps and timeline is in 30fps.

The camera is a Panasonic HC-X1.

Remember that this has always worked for me, until V21 build 314 and that on the same timeline, I have other clips from a Sony A7iv (60fps) that work fine.
The template used was Magix AVC/AAC MP4.
I reverted back to build 300.

@Julius_ not everyone might be using your camera or have a sample of a couple of clips to test. If you can upload a couple of samples, others can test and see if the problem is present on their systems.

Is the timeline set to a framerate that exactly matches these clips?

No it does not and don't intent to. I shoot in 60fps and timeline is in 30fps.

The camera is a Panasonic HC-X1.

Remember that this has always worked for me, until V21 build 314 and that on the same timeline, I have other clips from a Sony A7iv (60fps) that work fine.
The template used was Magix AVC/AAC MP4.
I reverted back to build 300.

@Julius_ Did you pick a project framerate that is an exact multiple of the source clip (59.94 vs 60fps)?

I agree with Reyfox it would be very helpful to get sample clips to test if you can upload one or more to Google Drive, box, Dropbox, etc. There must be an issue with the decoder and this media.

Sure thing...

Here's a few clips...just place them on timeline and you can render it out or just do a SHIFT-B on a region.

https://www.dropbox.com/scl/fo/wh87t72jmvv2zzl4t38qm/ALsvprQqLuezXt-OSgzBwHM?rlkey=ts3p0loulvp7wz8ffs34tn256&st=ak7oh90j&dl=0

Thank you!!

@Julius_ dragging the clips to the timeline and rendering, yes, black frames at the end of each clip.

When in Options>Preferences>File I/O, and turning Hardware Decoder to Use, to OFF, it rendered correctly.

My hardware specs are in my Signature. I am using AMD's latest driver 24.5.1.

ADDED: I rendering in both 60 and 30P and the results were the same. No issues.

Screenshot of the CPU and GPU usage when I started rendering.

Hi, I too use a 30p project & regularly get unquantified frames, there's a difference between NV Encoder & Mainconcept 🤷‍♂️ I know how to trim the on the timeline & I know the OP has an AMD GPU, I'm just sharing for this post.

I didn't change the project throughout only the Encode Mode option.

Thank you for uploading the video events. Here is the timeline in Vegas Pro 21 with the project frame rate set at 59.94 fps:

No quantized frames

Here is the exact same timeline after the project properties is changed to 29.97 fps (no changes at all made to the timeline):

And here is a zoomed in down to one frame view of the first frame of the first video event:

The markers and width of the arrow is one frame only. In PAL frame rates, a 10 seconds video is 250 frames in length, but if that video event is not quantized, the length of that event may be something like 250.3 frames or 249.7 frames in length.

BTW, I got exactly the same result with importing those same video events into Vegas Pro 19.

And exactly the same thing in Sony Vegas Pro 12:

The 59.94 video on the timeline when the project properties have been changed to 29.97.

With this clips, I can repro the issue: in VP20 b411 it is possible to import the clips in the timeline without unquantitized frames showing up. But with VP21 b314, I see for the clip .... 6 always such an unquantifized frame at the end of the event.

Seems to be a decoding issue, since we had here a change in the decoder - from so4... to mxcompaundplug.dll

However, enabling the legacy AVC encoder does not resolve the issue (what means that we would go back so so4...) - but only on the first try. If one enables the legacy AVC encoder, and makes sure to import the events again, it is gone also in VP21 b314. See the second event part after the marker (was imported when the legacy AVC encoder was enabled - you find that in preferences files I/O):

And: I do not see that in VP20 b411.

@VEGASDerek

@Wolfgang S. Hi, If I'm understanding this post correctly is this the same thing your seeing with the OP's files?

I converted all these with Handbrake to Constant 30p & clicked Yes to match project to media but still have red unquantified frames

@Gid 

I have only used the original footage as it was uploaded. 

Converting it with Handbrake is a good idea for editing purposes. However, there's uncertainty in reproducing the issue here. It should work without conversion since the footage is HD and plays back well even on my laptop at full quality set the preview to best/full. Therefore, there's no reason to convert it.

I must state clearly that I do not understand why Dexcon has reached different conclusions. I cannot explain their findings.

@Wolfgang S. Thanks, yes the footage from my phone even tho it's variable plays without issue. I don't normally convert them. (I do convert some to Prores but that's just for when playing with fxs)

I converted these 4 as a test after reading this post to try to work out why even when I have converted media for whatever reason it loads with red unquantified frames, even rendering out of Vegas & then dragging back in some have these red ends, 🤷‍♂️

If you or anyone wants to try them you're more than welcome, test files - 4 x AVC UHD 30p folder size 128mb

Phone footage often has variable frame rates, which can cause issues. However, we have footage from a Panasonic camera that offers constant frame rates, eliminating the need for conversion. Given Panasonic's expertise in this field, it seems we should look for a solution elsewhere. And interestingly, we have a brand new decoder in VP21. A new decoder indeed...

The test footage is from which phone?

Indeed, the footage is intriguing! However, it has been converted using Handbrake, as indicated by Mediainfo.

Do you possess any original clips from the phone? That would be fantastic!

Moreover, even the Handbrake-converted footage exhibits the quantization issue with the new encoder. Yet, reverting to the older legacy encoder resolves the problem once more.

This also affects me if I put a batch of my Panasonic GH4 29.97fps UHD AVC+PCM clips on the timeline at once.

• VP21 b314
  • mxcompoundplug
    • Some unquantized ends, followed by tiny gap
    • Some quantized, single-frame gaps
    • Same result with and without hardware decoding
  • so4compoundplug
    • Some quantized, single-frame gaps
  • compoundplug
    • Some quantized, single-frame gaps
• VP20 b411
  • so4compoundplug
    • No unquantized ends
    • No gaps
  • compoundplug
    • No unquantized ends
    • No gaps

Feels to me like there might be more than 1 issue here. i.e. A math error when laying footage on the timeline, as well as mxcompoundplug not always quantizing the ends.

General comments about quantize and black frames (sorry if obvious; wasn't always obvious to me):

"Options -> Quantize to Frames -> [x] Enable quantize to frames" will position imported events at frame boundaries as defined by the project properties frame rate. Makes sense.

Events that are not an exact multiple of frames in length according to project properties will end seemingly in the middle of a frame. The following event will be aligned at the next frame boundary. That leaves a gap of less than a frame. I don't know what this *should* mean, but it results in black frames on render. Turning on "Options -> Quantize to Frames -> [x] Show unquantized frame boundaries" will show where this is likely to happen. Again, this is based on the timing of frame boundaries as determined by the project properties.

Any mismatch between an event length with its frame rate vs project properties and its frame rate will likely cause these gaps (i.e. frame length, thus event length, is determined by frame rate).

That is what will happen with mismatched frame rates when the event decoder calculates event lengths correctly, always did, and is not a bug (opinions may vary). Workarounds would be to match the project properties to all the events or turn off quantize to frames* before importing. A related issue could happen when modifying the project properties (frame rate) after importing events. Makes sense. Then things that were quantized might not be, and vice versa. Also, changing the selected decoder from a correct one to a buggy one** might change the quantization of end boundaries.

Another workaround would be to run a script that truncates the last partial frames of offending events, thus creating single frame gaps, and ripples all the events to close the gaps.

* Using the don't enable quantize to frames solution causes imported events to be joined in mid frame. This might cause a different glitch, whereby a frame rendered at that event boundary shows a blend of the two events. How that looks on playback might or might not be a problem. Changing project properties (frame rate) after importing could also cause this.

** Past versions of the different HEVC decoders actually resulted in different event lengths! I don't know about now.

@bvideo

this is all correct what you say - and that is why we try to adjust the project framerate to the framerate of the footage we edit. And why we enable quantize to frames.

As we see it in VP20 b411 for example, where everything is ok (as shown here by some of us).

I think the team has to review the findings from here. I have forewarded that to them.

@Wolfgang S. These are the 4 original untouched files, 3 from the Samsung S23 Ultra & 1 from a Gopro 11,

https://drive.google.com/drive/folders/1uMRSiewKSkyT_yNcPVy0-8I_liG0t3Py?usp=sharing

----------------

The orig ones in the link above are HEVC, the ones I sent earlier I had made a mistake & converted to AVC,

This is with the correctly converted to HEVC constant using Handbrake, same result with the quantified frames.

Thank you for the files. As anticipated, the original Samsung files exhibit variable frame rates. Here, both the new and the old decoders display unquantized frames. These files are HEVC, which means switching the encoder to the legacy AVC will not be effective, as this is not HEVC footage. In this case, one can only test the experimental HEVC encoder.

However, playback is smooth with both HEVC encoders, including for the GoPro file.

What reasons might there be to proceed with the conversion? Is it to address the variable frame rate issue?