Wasn't expecting it. Glad it was not abandoned.

@john_dennis

I just ran the new downloaded version selecting all versions of Vegas and it worked OK--no error messages. I have no idea about whether it works with a trial Vegas version.

Thank You. I wasn't aware of this tool existence. Plus going to their mother site there are three very interesting free plugins.

What seems truly amazing is going to the forum cited and finding nets of non profit VIDEO plugins makers, even some with relevant musicians names attached... (Coldcut. Syzygy).
https://freeframe.sourceforge.net/participants.html

What one might do with such VEGAS extensions! Definitely worth investigating.

@wwaag I sent Satish a message.

Looks good. Was hoping for a 4k quality jump to ffmpeg-direct levels but it's pretty much the same as with v5...

Got a message from Satish. He fixed the issue and the installation on the Vegas Pro trial went to completion. Thank you!

I really appreciate the update.  Creating the signpost avi  works but virtual serving with Dokan does not. The DBFM folder is created with an avi for cached audio. But the virtual and virtualmirror folders are empty. Any ideas? Thanks.

@Howard-Vigorita

The problem is probably limitations in Vegas' "pipeline" - if I remember correctly. The problem will probably be solved when the new video engine is finished.

Jøran Toresen

@Scott-Young

Works OK here. Here's a screengrab of the virtual avi.

Having said that, I would not recommend using that option since it is very, very slow, compared with use of the signpost avi. The only use as I see it would be for apps that cannot read the signpost file directly. Even then, it's probably faster to render out a digital intermediate. This option was added to DMFS during the time it was under private development when it was called CuminCoder FrameServer (CCFS).

Thanks. The signpost avi was really slow so I thought that the virtual one might be faster. I'll stick with the intermediate file. Thanks again.

Much appreciation is extended to the developer of this venerable Vegas tool, Satish Kumar.

Me too! Well done “Sats”.

I used FS + ripbot a lot before, but know Voukoder is perfect.
Kudos to both devs!

The problem is probably limitations in Vegas' "pipeline" - if I remember correctly. The problem will probably be solved when the new video engine is finished.

@J-Toresen I agree it's probably a 4k pipeline bandwidth issue. But something MagicYUV figured out not only for vp22, but retroactively going back at least as far as vp19. See: https://www.vegascreativesoftware.info/us/forum/magicyuv-2-4-1-released--147264/#ca926592

There is nothing wrong with the frameserver. Objective metrics are higher than Vegas or Voukoder.

Whenever you want to keep a 10bits pipeline, you need to frameserve using V210 option and correctly convert your luma before encoding.

Test below with a 422-10bit Rec709 limited original file - project set to 32bits full - View transform off.

Rendering qsv hevc cbr 135mbps

@GJeffrey Have you tried CRF and CQB mode?

 

There is nothing wrong with the frameserver. Objective metrics are higher than Vegas or Voukoder.

Whenever you want to keep a 10bits pipeline, you need to frameserve using V210 option and correctly convert your luma before encoding.

Test below with a 422-10bit Rec709 limited original file - project set to 32bits full - View transform off.

Rendering qsv hevc cbr 135mbps

@GJeffrey I used the same ffmpeg script directly and with frameserver. I also used the v210 option with dmfs which does in fact give better results than other 3 options. And the same lossless reference in all cases. Luma conversion changed nothing suggesting it's not needed by my footage. 4:2:2 renders make no difference since my lossless reference comes off a sensor physically striped with only the elements used by 4:2:0. I included a retest with v5 to see if anything's changed since the last time we covered all this... it hasn't.

Note that the quality cap reveals itself only with 4k projects. HD projects seem to be fine. That pretty much proves to me that it's a pipeline bandwidth constraint. Voukoder coming through the same pipeline is similarly affected. MagicYUV, however, seems to be unaffected at 4k. That suggests that the constraint can be lifted if the other 3rd party developers seek support from Vegas developers. Which I encourage them to do because I strongly desire ffmpeg render quality and performance out of my Vegas projects without resorting to enormous MagicYUV intermediates.

@Howard-Vigorita

"I used the same ffmpeg script directly and with frameserver."

Could you post the ffmpeg script you are using? I presume that you are using the virtual avi from DMFS since the direct signpost avi can't be opened directly in ffmpeg, at least not for me? Thanks

@wwaag Here are the 2 command lines I used for the ffv1 renders... just the input and output names change for ffmpeg direct and dmfs renders. I move the # comment from one to the other to execute them from the same fs.ps1 powershell script file:

#ffmpeg7g -i 'D:\MISC\test ffmetrics\hevc-lossless-an.mov' -c:v ffv1 -level 3 -an -y 'd:\temp\ffmpeg7g_ffv1-10.avi'

ffmpeg7g -i 'd:\temp\fs.avs' -c:v ffv1 -level 3 -an -y 'd:\temp\dmfs_flv1-10.avi'

The fs.avs file I use has this single command line:

AviSource("D:\temp\fs.avi")

I also tried adding a ConvertToyuv420() command line to fs.avs but got identical render quality results so I left it out. I expect any needed conversions to increase quality metrics but nothing I tried did that. Explicit rate or timestamp tweaking in ffmpeg actually reduces quality metrics across the board. Doing that seems to create misalignment so I leave it alone.

I copy both fs.avs and fs.ps1 to my d:\temp folder on my ssd work drive and manually execute fs.ps1 from there after I kick off the dmfs in a Vegas project named fs.veg rendering by default to fs.avi in D:\temp. The lossless mov I used for reference/render source is the one linked my signature.