@poz_cumincode
Hello
(from Thailand)

Would be nice if FrameServer could
Send files from the Vegas Timeline directly to the Edit Share Connect software for use in the render farm.
Note: I am using Vegas Pro 19.

THANKS

Does this mean we have to pay twice for FS and HOS?  It's crazy.  We might as well use Voukoder which is much more powerful and free.  

@xcxz-a - I’m not sure you know the difference between the three? Where’s the twice? Please explain. Each has its “talents” and uses.

So debugmode fs is discontinued?

Or whats the difference between them?

@Grazie 

I know they are all about connecting Vegas Pro to FFmpeg. (What is FFmpeg?  The most powerful free! video encoder library in the world. )

Same purpose, Voukoder is free, and it links directly to Vegas render dialog (much more integrated), and Voukoder updates regularly to ensure the latest FFmpeg.    So why pay twice for FrameServer and HOS?

Voukoder is a good tool. However, it is limited, doesn't even have the essential zerolatency tuning. HOS is much more than another encoder, and you are kind of mixed up about Frameserver, which is currently disabled in VP19, so it is a moot point. Do you know that many of us have been using ffmpeg for two decades?

Here’s one example, FS serves Frames to HOS KwikPreview Preview and it is/was remarkable. Voukoder doesn’t do that. Voukoder, I use, is great.

A bit of explanation. The developer of the original DebugMode FrameServer (DMFS) which is currently used in HOS has abandoned its development and moved on to other things. Up until changes introduced in build 532, that version worked OK in Vegas. The core DMFS software was further developed by the addition of 10bit and virtual frameserving and is now being marketed as CuminCoder FrameServer (CCFS). At the moment, I am trying to work an arrangement with the CCFS developer for its inclusion in future versions of HOS.

Regarding Voukoder and HOS, if all one wants is a high quality render from Vegas, then Voukoder is the choice. Its free (at least for the time being) and it provides easy access to most encoder parameters while HOS requires the user to write his own command lines for use of advanced options. As others have pointed out, HOS does a lot more things than render. Of the 20 plus tools,only a few require use of FrameServing. Additionally, the use of frameserving enables access to the vast library of Avisynth filters.

@wwaag - Thank you 🙏.

Interesting...and affordable...

I understand what it does & will go ahead and get it..but I don't quite grok what I'm going to do with it...

More usage examples here (or somehwere else?) would be appreciated.

A solution looking for a problem, in my case I guess.

KwikPreview is one feature I used a lot while editing in every video. Hoping everything works out.

KwikPreview is one feature I used a lot while editing in every video. Hoping everything works out.

@Reyfox - "Yah bet your sweet bippy!" Reference? Rowan & Martin's Laugh-In, and yes, I am that old. Check out Goldie Hawn - hysterical.

@Grazie the "sock it to me girl"? I think everyone had a crush on her in her bikini!

@poz_cumincode I'm a little late but I just installed v4.21 in vp20 with mixed success. The new virtual avi thing works well on my 9900k system running win10, but only if the target is my c: drive. In which case it works quite smoothly piping output to ffmpeg. But if the target is the d: drive, the ccfs folder gets created but no signposts appear. On my 11900k system running win11, it also only works on c: but runs ffmpeg very slowly and ffmpeg generates no output.

I came up with a workaround, however, that works well on both of my systems. I unchecked the virtual box so the signpost file appears in the folder specified in the render screen... I usually render to d:\temp which is an ssd. So I set the render folder to d:\temp and name the output fs.avi ... I also place a text file named fs.avs in the d:\temp folder with this content:

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

Then use the avs file as an avisynth+ converter for ffmpeg...

Scheme works with ffmpeg v4. And v5 for hyper-rendered qsv. But just released v6 doesn't accept the avs trick.

@Howard-Vigorita Have you checked if the ffmpeg V6 you have got the avisynth library built-in?

I would also do the color space conversion in the avs script by adding the command

Convertto

with the matrix which suite your rendering parameters (for a x264 420 - 8bit use converttoYUV420(matrix="709:l")

Frameserving to RGB32 is useless unless you want to keep the alpha channel.

Have you checked if the ffmpeg V6 you have got the avisynth library built-in?

I would also do the color space conversion in the avs script by adding the command

Convertto

with the matrix which suite your rendering parameters (for a x264 420 - 8bit use converttoYUV420(matrix="709:l")

Frameserving to RGB32 is useless unless you want to keep the alpha channel.

@GJeffrey This is my 1st exposure to frameserver and avisynth... just trying to take advantage to ffmpeg support for Intel hyper-rendered qsv and see if I can get higher quality deliverables at the same time. Can't find a win x64 avisynth so I used 32-bit avisynth+ which might be the weakest link. I should be able to do HOS VRQ quality analysis before and after to measure that. Built-in ability to read the format without avisynth would not only eliminate it as a suspect but allow direct weighted measurements via ffmpeg itself. I used the voukoder ffmpeg6 Windows build which doesn't seem to read the format any differently than v4 or v5. Have not tried Gyan or bitN yet.

update: Gyan build has avisynth enabled and supports the avs file. But does not read the avi stream directly.

@Howard-Vigorita with the avisynth installer you linked you should have both 32 and 64bits version available.

To test the hyper boost encoding mode, I would use qsvenc instead of ffmpeg because it's always up to date and with a complete and clear documentation.

I've quickly tried the direct command line within the frame server and it doesn't work indeed (I am using ffmpeg V6) with both avs or avi as input. Running the exact same command line through a bat file works though (using avs as input, as you have seen ffmpeg doesn't read the frameserved avi file directly).

You could also built your own ffmpeg very easily with that tool and be able to include or remove any additional libraries fitting your needs.

@Howard-Vigorita +1 for use of Qsvencc64 rather FFmpeg. The author, Rigaya, is constantly updating apps for Intel, Nvidia, and AMD GPUs unlike FFmpeg which seems to be updated only sporadically. Additionally, he has added quite a few filters including such things as SuperRes. He is very responsive to user questions and requests, having implemented some of my feature requests for HOS. Additionally, Qsvencc64 also supports VP9 encoding in addition to AV1.

@GJeffrey Thanks, I haven't had a chance to try qsvenc yet but it looks promising. Been testing with the gyan ffmpeg6 build all day and it handles avs fine. But the avisynth+ quality analysis isn't that great. For instance, testing transcodes of a lossless clip I get these readings:

vp20 frameserver to ffmpeg via avisynth+ ......... psnr: 30.6098; ssim: .9483; vmaf: 42.5138
ffmpeg direct (same command as above) .......... psnr: 40.5807; ssim: .9682; vmaf: 72.3633
voukouder13/vp20 (abr 24M, bufsize 48M) ........ psnr: 38.1276; ssim: .9448; vmaf: 51.0709

Was also able to measure raw frameserver output without avisynth+:

vegas frameserver to HOS VRQ direct ...... psnr: 62.556; ssim: 0.9998; mse: 0.036

I'll try and get frameserver to talk to qsvenc and see how that goes.

EDIT: the voukouder abr specifying both buffsize & max bitrate to better match ffmpeg vbr:
voukouder13/vp20 (same as ffmpeg x265 vbr 24/48) .. psnr: 40.1377; ssim: .9623; vmaf: 64.2610

Also, juggling crf to approximate the vbr bitrate and file size:
voukouder13/vp20 (x265 crf=21.1 approx vbr rate) .... psnr: 40.1308; ssim: .9622; vmaf: 64.2479

Thanks, @wwaag. Your VRQ worked like a charm, btw. I had to run 2 vp20 instances both using ccfs. One to put up the signpost, and the other to import the signpost and compare it to the original clip with vrq. I didn't actually expect that to fly. Took a while, but it worked.

@Howard-Vigorita Your low PSNR result with the frameserver + avisynth shows that ffmpeg did not use the correct range when converting to YUV. There is no such information in the RGB frameserved file so ffmpeg has to guessand guess wrong That's the reason why I was suggesting you to add the convertto command in the avs script.

With ffmpeg direct, are you encoding your lossless file directly with ffmpeg, without Vegas involved?

@GJeffrey With converttoYUV420(matrix="709:l") I got... psnr: 30.6171; ssim: 9474; vmaf: 40.1038, not a tremendous difference but lower across the board. Did you say that's for 8-bit? Source clip is 10-bit video-range and my Vegas project is set to 32-bit float video-range. All the test renders are video-range w/o any color or other transformations except to specify pix_fmt. The ffmpeg command line I used for the 1st 3 measurements using the Gyan build is:

ffmpeg6g -i d:\temp\fs.avs -c:v libx265 -b:v 24M -minrate 24M -maxrate 48M -bufsize 48M -pix_fmt yuv420p10le -y d:\temp\fs.mkv

I'm testing mostly with vbr to eventually match to Magix default presets. Btw, will be trying qsvenc soon and compare with ffmpeg specifying its pix_fmt as p010le to match previous x265 renders.

And, yes, the ffmpeg direct inputs the reference hevc lossless clip without Vegas.