Ok, fair enough.  Just out of curiosity to compare quality (its really a very rough and ready method) I used VP15 on my old i7 4790k and GTX 580 re: Cuda HW acc.  I've updated the results of my main post on page 2.

As for the duplicate frame issue, using Nvenc HW encoding, all I know is that on my system using 29.97fps source clips, a total of four, it happens every time once the clips are not vfr.

@bitman

I am not sure the Nvenc renders are the same for all cards:

You're absolutely right. I meant within a series. The new hardware looks much better.

@Former user

Hi @wwaag I'm confused, I assumed from your previous posting that you were able to “fix” this issue by using HOS. Perhaps you hadn’t yet done the test that you just now did?

That's correct. I assumed there was a problem from other posts. To "humor you", I did fresh renders. Here are the results which are really surprising to me.

I thought that the Vegas and HOS renders would be of equal quality, but apparently not. The bitrate for the Vegas render was 24.1 Mb/s. For HOS, it was 24.7 Mb/s. Perhaps someone could confirm these findings.

wwaag

BTW. The flash image at the end of the Vegas playback is a result of the missing final frame in that render, thus revealing the original image.

Edit: Uploaded new demo with preview at Full(Best) rather than Preview(Auto).

@wwaag Your posts are becoming contradictory. Your last post, just above this clearly shows the issue where the “difference” is showing through, its very likely caused by the duplicate frame at 2s;28thf.

In your post previous to this one you say you cannot find a duplicate frame. The duplicate frame causes this issue, not whether HOS is better than Vegas render.

I can understand your need to bring up HOS, but strictly speaking its irrelevant to the issue at hand, notwithstanding that it may eleminate the issue in software, it still remains an issue if you don’t use HOS.

Perhaps @bitman is right that the newer generation RTX cards don’t have the issue.

@Former user

Your posts are becoming contradictory.

You're absolutely right. Things keep getting "curiouser and curiouser". First, I re-opened the project from which I made the recording. This time, everything was OK--completely black with nothing showing through (In the interim, I had disabled the SO4compound.dll and then re-enabled it.) Second, I re-rendered the original file with no timecode FX. This time, there was indeed a duplicate frame at 2:28. I then imported that rendered file into V14 and the duplicate frame disappeared. Third, I rendered the clip in V15 with NVENC and everything was OK--no duplicate frame or nothing showing through when compositing mode set to difference. The only problem was missing audio in the last three frames. Just speculation, but my suspicion is that the file is being rendered correctly, but there is a problem in its decoding when returned to the timeline.

The fact that it seems to work OK in HOS only shows that the hardware is OK, and the problem lies in software. It seems unlikely that the newer generation of cards will solve the problem, but perhaps it would. Sounds like a justification to spend some money and find out!

@wwaag Just a thought, is it possible that you might not have been using an Nvenc encoder when you got no duplicate frame? that could explain the discrepancy.

I found that disabling the SO4 .. .dll simply moves the duplicate frame further on to a non fixed location.

One thing to watch out for is also that applying the compositing difference simply sometimes doesn’t work. When I used VP15 to test Cuda for quality, not Nvenc, I had to save the project, close and reopen Vegas, then it worked.

So some facts at last that can be extracted from this debris,

1) The duplicate frame does occur using your Gtx 1050 Ti.

2) The duplicate frame does occur using my Gtx 1080.

3) It can be fixed with software.

Perhaps the software interface to/within the RTX is different and so works.

Thanks for taking the time.

@wwaag

@Former user Just speculation, but my suspicion is that the file is being rendered correctly, but there is a problem in its decoding when returned to the timeline.

 

You maybe on to something, the decoding hw (NVDEC) in the new Nvidea series is also different:

TU104 die actually contains two NVDEC units, a first for any GPU. They are only enabled on the Quadro and Tesla versions. (So I presume the consumer version will only have one NVDEC unit enabled).

So much for establishing the facts. @wwaag @bitman

I did the following. I used the original BruceUSA clip, “source” rendered it out “output” using Nvenc codec, brought it “output “ back in directly under the “source” clip.

Doing the usual difference test clearly shows a duplicate frame at 2s;28f. in the “output “.

I then opened a new project with the “output” clip only. It has no duplicate frame.

I found that with the 2 clips as above on the timeline, removing the source clip and the output clip, then adding again the output clip only, will cause it to have or have not a duplicate frame display depending on whether you elect to say yes or not to the prompt to allow Vegas to automatically set project properties.

If you say yes then no duplicate frame issue arises with the output Nvenc rendered file.

This does point to some difference within Vegas when setting the project properties for the two files and somehow an incompatibility arises when it involves the Nvenc rendered file.

Another way of stating the issue is that it depends on which clip you use to set the project properties to.

If 1) you set the project properties to an already Nvenc rendered output file theres no problem, if 2) you set the project properties to the origional BruceUSA clip then the duplicate frame issue arises.

If you do 1) theres no new issue with the BruceUSA clip.

Since this thread started by discussing the quality merits of VCE and I don't think I can progress the duplicate frame issue beyond my last post, I'm reposting my summary of different codecs tested against the original BruceUSA's clip

Lower is better ...

VCE = 19.3 (Avg. of 3) … no preview visible, this is BruceUSA's piece. Data rate 24.5.

Nvenc = 17 (Avg. of 3) ... when no preview is visible.  Data rate 27.4.

CPU = 20.6 (Avg. of 3) … no preview visible. Data rate 25.6.

QSV = 20.3 (Avg. of 3) … no preview visible. Data rate 27.6.

Cineform = 12.66 (Avg. of 3) … no preview visible. Data rate 369.

XAVC-I = 9.33  (Avg. of 3) … no preview visible. Data rate 276.

ffmpeg = 27.66 (Avg. of 3) … no preview visible. Data rate 29.5.

used ffmpeg -i I.mp4 -c:v libx264 -crf 23 -profile:v high -level 4.2 -preset slow -b:a 256k f.mp4

I tested using VP15, i7 4790k,  GTX 580 and Cuda as HW Acc for both these 2 extra tests ...

Cuda = 23 (Avg. of 3) … no preview visible. Data rate 28.2.

CPU = 17.66 (Avg. of 3) … no preview visible. Data rate 36.9

—————————————————————————————————————————

I used @wwaag 's new app to generate the following two charts, the first is a fairly high data rate selection of outputs (without VCE) compared to an “original” Xavc-I file, which was itself generated from a collection of “General Purpose“ video clips.

The second is sourced from the “BruceUSA” origional clip

In the chart below I used a slightly higher data rate than the Vce clip so bear that in mind when comparing. The app clearly shows the limitations of the differencing approach that I had used with only 3 points of comparison, as against 850😀. Thanks wwaag.

The chart below also includes a second VCE 3.1 comparison with a higher data rate.

Since this thread started by discussing the quality merits of VCE and I don't think I can progress the duplicate frame issue beyond my last post, I'm reposting my summary of different codecs tested against the original BruceUSA's clip

Lower is better ...

VCE = 19.3 (Avg. of 3) … no preview visible, this is BruceUSA's piece. Data rate 24.5.

Nvenc = 17 (Avg. of 3) ... when no preview is visible.  Data rate 27.4.

CPU = 20.6 (Avg. of 3) … no preview visible. Data rate 25.6.

QSV = 20.3 (Avg. of 3) … no preview visible. Data rate 27.6.

Cineform = 12.66 (Avg. of 3) … no preview visible. Data rate 369.

XAVC-I = 9.33  (Avg. of 3) … no preview visible. Data rate 276.

ffmpeg = 27.66 (Avg. of 3) … no preview visible. Data rate 29.5.

used ffmpeg -i I.mp4 -c:v libx264 -crf 23 -profile:v high -level 4.2 -preset slow -b:a 256k f.mp4

 

I tested using VP15, i7 4790k,  GTX 580 and Cuda as HW Acc for both these 2 extra tests ...

Cuda = 23 (Avg. of 3) … no preview visible. Data rate 28.2.

CPU = 17.66 (Avg. of 3) … no preview visible. Data rate 36.9

JN. Thanks for taking the times for all of this tests. Wow AMD VCE beat them all.

Anytime @BruceUSA take care, Happy New Year.

JN. Same to you. :)

Another way of stating the issue is that it depends on which clip you use to set the project properties to.

If 1) you set the project properties to an already Nvenc rendered output file theres no problem, if 2) you set the project properties to the origional BruceUSA clip then the duplicate frame issue arises.

If you do 1) theres no new issue with the BruceUSA clip.

@Former user The original BruceUSA clip has a MediaInfo frame rate of "29.970 (30000/1001) FPS" and the VP16 project frame rate (after matching to it) becomes "29.970 (NTSC)". Is that the same as the NVENC-rendered clip?

I've just checked in Mediainfo the Nvenc rendered clip and the “frame rate” is 29.97 (30000/1001)

I had looked at the properties in VP yesterday for any difference but there the same.

But in Mediainfo the Nvenc frame rate mode is variable. The origional clips frame rate mode is constant.

I'll post a screen grab shortly.

I've just checked in Mediainfo, its reported as variable, maybe this could be key to whats happening.

     Origional                  Nvenc                    VCE                      QSV

Nvenc render template used

So I rendered out a clip from the original using the Nvenc and QSV encoder, (I cannot test VCE), using all 6 frame rates available, 5 newly tested.

The Mediainfo reports either constant or variable frame rate mode ...

Nvenc encode                QSV encode               VCE encode

24 ……….  V                             C  

29.976 … V                             C                                 C

59.94 ….  V                             C 

23.976 … C                             C

25 ……….. C                             C

50 ……….. C                             C

It would be interesting to process the NVENC file with an ffmpeg command like this, which should make it constant frame rate, and see if the repeat frame remains:

ffmpeg -i input.mp4 -r 29.970 output.mp4

Hi @NickHope justed tested using your ffmpeg suggestion, no change, the duplicate frame issue is still there. When I use the project “match media video settings” and choose the rendered file it goes away, same as before.

The frame rate mode is indeed constant as per Mediainfo for this newly generated clip.

Hi @NickHope I looked up -r, sets frame rate, but up to now i’ve only had the issue with Nvenc encoded 29.97fps files.

I assume that when I ran the ffmpeg command line you gave that it would have only used cpu? yet I had no issue with a cpu generated file from within VP up to now. The plot thickens.

Maybe this ffmpeg -r documentation explains it. ... ”As an output option, duplicate or drop input frames to achieve constant output frame rate fps.”

@Former user The ffmpeg suggestion was just to post-process the NVENC file to force it to a constant frame rate. I wouldn't expect it to use anything other than CPU.

If you are saying that the duplicate frame is still there after matching project settings to the post-ffmpeg CFR file, then that implies that Vegas conforms the VFR NVENC file to CFR in the same way that ffmpeg line does. i.e. By duplicating or dropping input frames.

Can you please share the NVENC-rendered file? I think there are other ways to convert VFR to CFR by quantizing frame boundaries rather than dropping/doubling frames. The mp4box references in this thread might lead to one such way.

@NickHope “If you are saying that the duplicate frame is still there after matching project settings to the post-ffmpeg CFR file,“

For clarity ... with a small project consisting of 2 clips, the original BruceUsa clip and the newly rendered ffmpeg clip ...

The ffmpeg rendered file displays the duplicate frame if the project properties are set to the BruceUsa origional file. To have the ffmpeg rendered file not display the duplicate frame its simply a case of setting the project properties to the ffmpeg rendered clip, it just goes away, and theres no duplicate frame in the Bruceusa clip, which never had it anyway, so no apparent downside to setting project properties to the clip that has (more accurate to say it displays a duplicate frame since there may be no duplicate frame) a duplicate frame.

I'll post a link shortly.

https://www.dropbox.com/sh/n87nuob476yzjd4/AABu-u9KpVTH5YzQRvnlB3Qoa?dl=0

So up till now the only issue was with the Nvenc rendered clip, but it now also shows with the ffmpeg rendered clip, equivalent to a CPU render. This probably happens for the reason given in the ffmpeg documentation for the -r switch, see my previous post just above. I mention this only because it might be a pointer as to what’s happening internally with VP's interpretation of both clips on the timeline.

Maybe this is what happens ... when the project properties are set to the Nvenc clip by VP nothing needs to be done, its left as as, VP displays no duplicate frame. And the other clip, in this case the original clip doesn’t need to be conformed to fit the project properties so its left as is.

When the project properties are set to a different clip by VP then VP has to massage the Nvenc clip to have it better fit the existing project properties and it does this by dropping a frame in the Nvenc rendered clip and truncating the last frame.

If this is the case then its debatable whether VP is interpreting the Nvenc clip correctly or not, or whether there’s something in the Nvenc's clip metadata thats off.

Thank you for the samples.

This is such a strange problem, since the frame rate of a project matched to the NVENC-rendered file is shown as 29.970 fps, the same as a standard 29.970 fps project. Very difficult to work out exactly what is happening. I think somehow the "maximum frame rate" of 30.000 (reported in MediaInfo) may be finding its way into the decoding calculations made by Vegas. Or something (metadata, Vegas project properties, or codec) is working to too few (or too many) decimal places. Or Vegas is wrongly treating a fraction of a frame as a full frame in its calculation.

But I think the fundamental bug is that the NVENC-rendered file is tagged as VFR in its metadata when it is really CFR.

Anyway, let's try and settle on a definition of the issue. Anyone disagree with this?...

In a 29.970 fps project, the 87th frame of a "long" 29.970 fps NVENC-rendered AVC file is repeated, unless the project properties are matched to an NVENC-rendered file.

It would be useful to replace "long" with a precise threshold number.

As a workaround, NVENC-rendered files can be post-processed with this mp4box batch file, which sets it to CFR without adding or dropping frames. It converts every file in the folder in which it resides and gives is a "_fixed" suffix. Name it something with a .bat file extension and just double-click it.

@echo off & setLocal EnableDelayedExpansion

REM Extract h264 and aac streams
for %%a in (*.mp4) do mp4box "%%a" -raw 1 -raw 2

REM Remove "_track1" from the h264 filename
for /f "tokens=* delims= " %%a in ('dir /b *.h264') do (
set F=%%~Na
set F=!F:~0,-7!
move /y "%%a" "!F!%%~Xa"
)

REM Remove "_track2" from the aac filename
for /f "tokens=* delims= " %%a in ('dir /b *.aac') do (
set F=%%~Na
set F=!F:~0,-7!
move /y "%%a" "!F!%%~Xa"
)

REM Mux with 29.970 frame rate
for %%a in (*.h264) do mp4box -add "%%~na.h264:fps=29.970" -add "%%~na.aac" -new "%%~na_fixed.mp4"

REM Clear up the streams
del *.h264
del *.aac

pause