Gaps, NTSC

Robert Johnston wrote on 10/12/2023, 11:09 PM

I ran into this problem. This has to do only with 59.94 fps media being added to a 29.97 fps project timeline.

You can end up with gaps under these conditions:

  1. When dragging 2 or more selected media with 59.94 fps to the timeline, and
  2. the project is set to 29.97 fps, and
  3. no media is on the timeline to begin with, and
  4. you allow Vegas to base project video settings on first-added media.
  5. And when Quantitize to Frames is ON.

Result: Gaps between the added media.

To avoid having to correct for this:

  1. Drag only 1 media clip to timeline at first and allow project to be automatically set to 59.94 fps.
  2. Drag the rest of the clips to the timeline after that,

or

change project video settings to 59.94 fps before dragging any of those clips to timeline.

Last changed by Robert Johnston

Intel Core i7 10700K CPU @ 3.80GHz (to 4.65GHz), NVIDIA GeForce RTX 2060 SUPER 8GBytes. Memory 32 GBytes DDR4. Also Intel UHD Graphics 630. Mainboard: Dell Inc. PCI-Express 3.0 (8.0 GT/s) Comet Lake. Bench CPU Multi Thread: 5500.5 per CPU-Z.

Vegas Pro 21.0 (Build 108) with Mocha Vegas

Windows 11 not pro

Comments

jetdv wrote on 10/13/2023, 8:51 AM

@Robert Johnston, when adding my dash cam footage to the timeline (30p) into a default project (29.97), I drag the first clip to the timeline and then tell it to match the project settings to that clip. Then I select the rest of the clips and drag them in behind the first event now on the timeline. I, too, have found that the safest way.

If I do happen to forget, I either undo and do it again the correct way, or I just run a script to remove all gaps. If I'm doing it several times, I just leave the project alone, delete all of the events from the timeline (and clear the Project Media) and then I can drag all the clips for the next dashcam segment to the timeline with no issues as the project already matches.

But I can definitely duplicate your results.

john_dennis wrote on 10/13/2023, 8:58 AM

Though I've seen the behavior in the past, I've been unable to duplicate it this morning by following your instructions.

Howard-Vigorita wrote on 10/13/2023, 9:27 AM

@Robert Johnston It's a bug that's been reported for quite a while. Just checked on my laptop where I have vp 19, 20, and 21 installed and can duplicate on every one of them at a 29.97 frame rate. One workaround is to turn quantize off before dragging the clips onto the timeline, group them, turn quantize on again, and then move the group to a frame boundary.

Since most of my projects are multicam, I usually take a different approach. I join adjacent clips before bringing the footage into Vegas... doing that also minimizes the number of splits and slivers Vegas creates across tracks in multicam edit mode.

jetdv wrote on 10/13/2023, 9:56 AM

 

General
Complete name                            : C:\...\20231005070848_009054.MP4
Format                                   : MPEG-4
Format profile                           : Base Media / Version 2
Codec ID                                 : mp42 (isom/avc1/mp42)
File size                                : 181 MiB
Duration                                 : 1 min 0 s
Overall bit rate                         : 25.3 Mb/s
Encoded date                             : UTC 2023-10-05 07:09:48
Tagged date                              : UTC 2023-10-05 07:09:48

Video
ID                                       : 1
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main@L5@High
Codec ID                                 : hvc1
Codec ID/Info                            : High Efficiency Video Coding
Duration                                 : 1 min 0 s
Bit rate                                 : 24.6 Mb/s
Width                                    : 3 840 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 30.000 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Bits/(Pixel*Frame)                       : 0.099
Stream size                              : 176 MiB (97%)
Language                                 : English
Encoded date                             : UTC 2023-10-05 07:09:48
Tagged date                              : UTC 2023-10-05 07:09:48
Color range                              : Full
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709
Codec configuration box                  : hvcC

Audio
ID                                       : 2
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Codec ID                                 : mp4a-40-2
Duration                                 : 59 s 968 ms
Bit rate mode                            : Constant
Bit rate                                 : 64.0 kb/s
Channel(s)                               : 1 channel
Channel layout                           : C
Sampling rate                            : 16.0 kHz
Frame rate                               : 15.625 FPS (1024 SPF)
Compression mode                         : Lossy
Stream size                              : 469 KiB (0%)
Language                                 : English
Encoded date                             : UTC 2023-10-05 07:09:48
Tagged date                              : UTC 2023-10-05 07:09:48
mdhd_Duration                            : 59968

 

john_dennis wrote on 10/13/2023, 10:04 AM

I have a vague suspicion that the Ruler Time Format is implicated in this issue.

bvideo wrote on 10/13/2023, 10:59 AM

Quantizing to frames only happens at the first frame of each clip. When frame rates don't match, that leaves a fractional frame gap at the end of each clip* before the next clip, which will be added at a frame boundary due to quantizing. I don't know what it should mean when displaying a frame like the ones at the ends of those clips that have a partial frame gap, but evidently it usually displays and renders as a "black frame". The "bug", if any, is in not making a provision for resolving those gaps, which are otherwise just following the rules of quantizing. Note that there is a properties setting for "[ ] adjust source media to better match project or render settings". I wonder if that helps?

* in the case of the OP, where the source frame rate is exactly double the project frame rate, clips that have an even number of frames will not end in gaps.

john_dennis wrote on 10/13/2023, 11:52 AM

@bvideo said: "Quantizing to frames only happens at the first frame of each clip. When frame rates don't match, that leaves a fractional frame gap at the end of each clip* before the next clip, which will be added at a frame boundary due to quantizing."

Media Frame Rate Does Not Match Project Frame Rate

Media Frame Rate Matches Project Frame Rate

"The "bug", if any, is in not making a provision for resolving those gaps, which are otherwise just following the rules of quantizing."

Perhaps the "bug" is what we used to call in the fixin' bidness, a non-bug. How many times has anyone stopped the camera and not done some editing at a clip boundary?

jetdv wrote on 10/13/2023, 12:14 PM

@john_dennis I agree that the ruler format probably DOES come into play. But, I can drag the first one, choose Match, and then the rest drag in fine (yes, I'm sure they do match the ruler at that time).

However, If I drag a bunch in at first, and choose "Match", should it not also match at that time? Perhaps the timeline isn't "matching" until AFTER the clips have been added as events? Perhaps the "matching" should happen first and the the clips added as events?

john_dennis wrote on 10/13/2023, 12:45 PM

@jetdv said: "However, If I drag a bunch in at first, and choose "Match", should it not also match at that time? Perhaps the timeline isn't "matching" until AFTER the clips have been added as events? Perhaps the "matching" should happen first and the(n) the clips added as events?"

I have checked Project Properties immediately after the clips are added to the timeline and the frame rate and Ruler Time Format do match. I agree, when it happens could be key.

Likely adding 23.976p clips to a 29.97p timeline will create gaps per @bvideo's quantizing assertion and will always require cleanup.

bvideo wrote on 10/13/2023, 2:34 PM

@jetdv

However, If I drag a bunch in at first, and choose "Match", should it not also match at that time? Perhaps the timeline isn't "matching" until AFTER the clips have been added as events? Perhaps the "matching" should happen first and the the clips added as events?

Yes, it seems like this would fix this form of the problem - in other words, getting the project frame rate to be coerced soon enough to match the whole group. However, this may be a special case. Mixing frame rates in source files, whenever they are added, will foil this orderly process and will always let in gaps when quantizing.

Would it be so bad if quantizing also meant truncating fractional frames at the ends of events? What exactly does a fractional frame contribute to the whole sequence? What about a fractional frame followed by another event that is not quantized, but butted up against the fractional frame? How is that split frame actually rendered? Interlaced vs. not interlaced?

+

 

 

jetdv wrote on 10/13/2023, 3:38 PM

@bvideo, in my case, I'm not seeing any "fractional frames". There's just a 1 frame gap between events.

Robert Johnston wrote on 10/13/2023, 4:53 PM

@bvideo, @Howard-Vigorita, @john_dennis, @jetdv

I just realized that the source files were all produced in Topaz Video AI, mp4 avc. A few files I just created in Vegas at 59.94 do not have gaps when all dragged to the timeline under conditions stated. So, some source files will cause the gaps and others won't, as we all know. It was driving me nuts.

Intel Core i7 10700K CPU @ 3.80GHz (to 4.65GHz), NVIDIA GeForce RTX 2060 SUPER 8GBytes. Memory 32 GBytes DDR4. Also Intel UHD Graphics 630. Mainboard: Dell Inc. PCI-Express 3.0 (8.0 GT/s) Comet Lake. Bench CPU Multi Thread: 5500.5 per CPU-Z.

Vegas Pro 21.0 (Build 108) with Mocha Vegas

Windows 11 not pro

bvideo wrote on 10/13/2023, 9:19 PM

@jetdv

@bvideo, in my case, I'm not seeing any "fractional frames". There's just a 1 frame gap between events.

When one of these gaps happens to me, I always see a clip ending at a non-boundary. I've enabled Options | Quantize to Frames | Show Unquantized Event Edges to be sure I don't miss them. Sometimes I need to zoom all the way in to see that the clip end is not at a frame boundary.

I wonder if the sequence of setting the project frame rate by the first clip is doing the frame boundary calculations in a weird order. Maybe rounding for quantizing each clip start point first (based on original frame rate & the lengths of clips), then setting each clip length by the newly changed frame rate. So clip lengths get seemingly shortened by a frame, but they end on frame boundaries.

mark-y wrote on 10/15/2023, 8:57 PM

The thing I have noticed with some HEVC/h265 is that the last frame is not full length, causing an unquantized frame edge. Not necessarily a change in Vegas' behavior, although it bears deeper investigation.

john_dennis wrote on 10/15/2023, 9:15 PM

@mark-y said: "What does that mean?"

My Microsoft calculator says: 1/25=40ms. Duration_Last Frame:-80ms sounds like two frames to me.

mark-y wrote on 10/15/2023, 9:39 PM

I don't understand the negative sign. 80 ticks short of a Happy Meal?