Version 6 should not have been marked as RTM

thebeardedllama

New member
I have been using VideoRedo for years now and can't even remember the last time it crashed.

I *paid* to upgrade to v6 yesterday and since the upgrade I have had to taskmanager->endprocess more than 10 times...

The gulf between v5 and v6 is incredible.

V6 should not have been released as it's clearly still in beta. Also you're releasing a new version in 2019 with no 64bit support?
 

hydra3333

Member
it works for me.

not sure why you say it doesn't work for you (no logs or details posted above).

just a thought - in my old job, encouragement went a long way and sticking it to my colleague developers was never ever a successful tactic ;)
 

Otter

Member
I think the term "RTM" is being confused with the concept of "Final, Absolutely Stable, Will Never Crash Even Under the Most Obscure Combo of Conditions" Release.
The second doesn't exist in the real world - just ask anybody on a MS forum. I maintain a bunch of boxes running Win10 and don't have problems with any of them. But I fix LOTS of problems for friends and extended family who expect to just buy a computer and trust it will always work (the expert at BigBoxStore said so)

I too upgraded to v6 for $30 (about what family of 3 spends at Burger Whatever) , but waited until the first "Stable" release.
While I tested a bunch of the Betas, every one I tried crashed in some way on my specific combo of source files, settings and outputs.
I didn't have a lot of time to play with v6 or tweak if it didn't work - might have been with the beta, or my files or the settings, just didn't have time to make it work.
I continued to use v5 for daily production - V6 functions independent of v5, so I just have both installed and icon'd on my desktop.

When "804 Stable" came out, it finally did what I needed without crashes or a lot of tweaking, so I begin using that. As I explored things v6 can do that v5 could not, I found some problems and had some crashes. I hit this forum, looked for info and posted some issues. Found fixes, tried new betas and some issues have been resolved. Some still exist.

VRD v6 is not some feature enhancement, it is a huge rewrite that changed many things we've grown used to , but added many things too - like GPU encoding.
I 'll spend $30 and will put up with a few bugs just for that.
The video quality I used to strive for with "2-pass slower" H264 can now be achieved with NVEnc on my Volta GPU with 1-pass CRF18 running at 6-7 times the fps encoding speed.

As hydra suggested above, post your issues and give details. It's impossible to solve a problem with no clues.
 

jmc

Active member
The video quality I used to strive for with "2-pass slower" H264 can now be achieved with NVEnc on my Volta GPU with 1-pass CRF18 running at 6-7 times the fps encoding speed.
Off Topic...

@Otter,
what NVEnc settings can you set in VRD6?
Seems to me that only Bitrate and Resolution have any affect.

Guess almost everything is "locked in" at the hardware level.
X264/HEVC only...was hoping it might accelerate .mpg encoding but no.

I did find that I only needed the Nvidia Display Drivers installed to access NVEnc.
No monitor needed or even the Nvidia Service running. (using Vega56)

Thanks,
jmc
 
Last edited:

Dan203

Senior Developer
Staff member
Also you're releasing a new version in 2019 with no 64bit support?
There are actually some valid reasons for this. We use some 3rd party libs in VideoReDo, mainly the license manager and the DVD authoring, that do not support 64bit. We've discussed breaking DVD off into a separate executable to eliminate that issue, but the license manager is a bit of a bigger deal. It's pretty ingrained in the product. Not just the product itself but the whole sales backend which has mechanisms for generating keys on the fly when someone purchases. That's a big undertaking. It's something we do eventually plan to tackle, but didn't feel it was crucial enough to hold up the release. (we've been promising an upgrade for almost 2 years now)

As for the bugs... we're a small company with just a couple of developers, it's hard for us to test every feature and catch every bug. We did do a public beta for a few months and fixed most of the bugs found during that beta, but the participation was relatively small. So when it hit the public paying of course they found more. VideoReDo has always been a dynamic product with constant free updates to both fix bugs and add features. v6 will be no different. This is just the beginning.
 

Fentropic

Member
As for the bugs... we're a small company with just a couple of developers, it's hard for us to test every feature and catch every bug. We did do a public beta for a few months and fixed most of the bugs found during that beta, but the participation was relatively small. So when it hit the public paying of course they found more. VideoReDo has always been a dynamic product with constant free updates to both fix bugs and add features. v6 will be no different. This is just the beginning.
the beta participation was relatively small... my case below...
I've been a licensed user of VRD since v3 and have been upgrading to each new version, now at v6 and use it daily. I do like and use your software.
You guys have always provided great support during each beta version and are relatively quick to resolve issues.
I held off on using the beta for v6 because of lack of documentation, lack of response to my issues and my experience with the beta of v5.

Where you are seriously lacking is documentation.
It's painful to have to search your forum, or continually ask, what does this mean, how do I do this, what is this option for, etc.
If I have to post to this forum and wait for a reply to figure out how to use your software, I will no longer use it. Just my opinion.

Improve your documentation. It's a great product.
 

Dan203

Senior Developer
Staff member
Yeah we're aware the documentation is lacking. We're active working on it right now though.
 

cp2

Member
As a driver of quite a few Leyland (Austin, Morris, Triumph, Rover, MG) over the years I am well aware of products being released and the users doing the final testing of the product. Realistically, in the case of software this is almost inevitable.
It is very likely that my computer, like just about every other, is an almost unique environment despite it being Windows 10 based. You cannot be expected to test against all possible hardware and software combinations.
The trick is to be responsive and agile in investigating and resolving these issues and I would say that you are that.
I can see that when you feel ready to start laying out the next major release, v7, the first plank will be 64 bit. I note that you already state that you willl not be extending VRD to include blu-ray authoring and I accept your reasoning. However, I think that you should now consider whether DVD authoring should carry over to v7: after all, if it was there already you wouldn't be putting it in.
 
Last edited:

Bulldog

New member
Off Topic...

@Otter,
what NVEnc settings can you set in VRD6?
Seems to me that only Bitrate and Resolution have any affect.

Guess almost everything is "locked in" at the hardware level.
X264/HEVC only...was hoping it might accelerate .mpg encoding but no.

I did find that I only needed the Nvidia Display Drivers installed to access NVEnc.
No monitor needed or even the Nvidia Service running. (using Vega56)

Thanks,
jmc
 

Bulldog

New member
I agree with you, all I can get is bitrate control, of what I assume are the default (hardware settings).

NVEnc doesn't seem to be supported very well.
With NVEnc, CRF seems to alter the output file size but otherwise no noticeable diff. from bitrate changes (not to me anyway).

The way I understand NVEnc, is that output control (quality, tuning, etc.) is achieved by altering the encoder presets, which for h264/h265 sofware encodes is available in the advanced settings, as encoding parameters.

Surely both h265/nvenc and h264/nvenc settings should be seperately available for selection as being distinct from the output codec HEVC (software).

Each type of NVEnc, h264 and h265, should have separate sets of encoding parameters available for selection.

At the moment selecting HEVC as output codec, and NVEnc as the encoder, gives the encoding parameters for software h265 encodes which have no effect at all on NVEnc output.

Very confusing !.

Any experts care to comment ?.
 

jmc

Active member
I agree...
Just did a NVEnc X264 encode at Preset UltraFast and VerySlow and NO effect at all.

EDIT...also look at this thead...
""https://videoredo.net/msgBoard/index.php?threads/16coreresults-finally-got-hevc-to-use-all-my-6core-12ht-cpu-ouch.37091/#post-130953""

Now that does not mean that intermediate setting won't have an effect...being within the Hardware Settings
range. More testing tomorrow.
I'm just afraid that NVEnc is almost completely LOCKED DOWN by the Hardware except for bitrate/resolution.

If I remember what I read about CRF is that it will try to maintain a certain level of Qualtiy and provides
whatever bit rate is required which means the file size will very.
Now does that mean 10%(ok) one way or the other or 50%(NOT OK) one way or the other...No idea...More testing.
 
Last edited:

Bulldog

New member
I agree...
Just did a NVEnc X264 encode at Preset UltraFast and VerySlow and NO effect at all.

EDIT...also look at this thead...
""https://videoredo.net/msgBoard/index.php?threads/16coreresults-finally-got-hevc-to-use-all-my-6core-12ht-cpu-ouch.37091/#post-130953""

Now that does not mean that intermediate setting won't have an effect...being within the Hardware Settings
range. More testing tomorrow.
I'm just afraid that NVEnc is almost completely LOCKED DOWN by the Hardware except for bitrate/resolution.

If I remember what I read about CRF is that it will try to maintain a certain level of Qualtiy and provides
whatever bit rate is required which means the file size will very.
Now does that mean 10%(ok) one way or the other or 50%(NOT OK) one way or the other...No idea...More testing.
 

Bulldog

New member
By experimenting with different setting, we are assuming that the parameters being changed, are actually being implemented by the hardware NVEnc.

To access the hardware encoder control settings, specific instuctions have to be supplied by the software control program (VRD encoder).
I am concerned that the settings you are changing are being ignored because VRD is passing the wrong settings ie.) the parameters are for the software encoder not NVEnc and are therefore being ignored.

My point concerning crf not working is along the same lines.
As I understand it, crf is not implemented by NVEnc at all.
A specific set of instructions has to be implemented to link a CRF value to a specific quality (Q, vbr, etc.) setting first, then subsequent crf values are assigned simulating a crf scale.

To my eyes, I see no evidence that changing the crf value, is changing the quality of the NVEnc encoded video.

The overall point I am trying to make is, I don't think NVEnc is getting the correct instructions from the VRD settings that we are changing.

Yes CRF changes the output file for different crf values but is it being implemented correctly ?
 

Dan203

Senior Developer
Staff member
To maintain a constant UI we use a single scale, which is the scale used by x264. (1-32) We then just use internal calculations to convert that number to the scale offered by each encoder. For NVEnc that's 1-51 so we're basically doing (CRF*51)/32.

That calculation is based on the assumption that the minimum number and the maximum number offered by each encoder would produce similar results, and the steps in between are just more granular in some encoders than others. However this stuff is not well documented so it's possible that's wrong.

For the speed settings a similar thing is happening. We're using all the speed settings offered by x264 and then mapping them the best we can to what's offered by each encoder. x264 offers like 9 different settings. Most offer less. So there is usually a lot of overlap where the several settings will produce the same result because they're being mapped to the same setting internally.

Actually adjusting all these params per encoder becomes very difficult with our profile system. We allow you to change the default encoder globally, which could affect the value even if you didn't touch the profile. So standardizing on a range like this, and then adjusting internally for different encoders is the only logical way we can do it.
 

Dartman

Member
I bought my V6 copy when the final was released and yes I've had various issues that cause it to crash but there always seems to be a setting or work around that makes it work for me so I'm happy and figure they'll get the issues sorted with time. I've been using it since it began as far as I know and it just does what I need it to do very quickly and with great quality once I get the settings dialed in and find the bugs and get around them. I like Beta testing and figuring things out and I use the betas and see what works but I especially like dropping my HD video content to half size with The HEVC/H265 codec in a fairly quick recode. I'm getting between 3 to 7 hundred FPS using it and a 1070 card with a 3960x I7 CPU. It's wicked fast doing H264 but having the same quality at half the size does it for me. I get these speeds setting the quality level to 80 percent with a few other tweaks and the video looks really clean and stable. Pretty sure the few times I tried H264 on a easy to recode file it was over 1k frame rate. My old AMD 1090t could take hours to do a similar recode.
 

Bulldog

New member
To maintain a constant UI we use a single scale, which is the scale used by x264. (1-32) We then just use internal calculations to convert that number to the scale offered by each encoder. For NVEnc that's 1-51 so we're basically doing (CRF*51)/32.

That calculation is based on the assumption that the minimum number and the maximum number offered by each encoder would produce similar results, and the steps in between are just more granular in some encoders than others. However this stuff is not well documented so it's possible that's wrong.

For the speed settings a similar thing is happening. We're using all the speed settings offered by x264 and then mapping them the best we can to what's offered by each encoder. x264 offers like 9 different settings. Most offer less. So there is usually a lot of overlap where the several settings will produce the same result because they're being mapped to the same setting internally.

Actually adjusting all these params per encoder becomes very difficult with our profile system. We allow you to change the default encoder globally, which could affect the value even if you didn't touch the profile. So standardizing on a range like this, and then adjusting internally for different encoders is the only logical way we can do it.
 

Bulldog

New member
OK, I now understand what has been done with the crf scale.

However if the crf is not implemented by NVENC in the same way, what comes out will not make sense, and it doesn't appear to !.

Are the speed setting's you refer to, the encoder preset scale (9 settings) ?.

NVENC has 12 encoder presets with tuning functions embedded so how can 9 settings be used to set 12 ?.

For instance I want to use the slow setting for NVENC which is a, - hq two pass, encode, I can see no way of doing this !.

If NVENC support is offered by VRD, it could be implemented, and selected the same way as a video codec is, from the output profile menu,
eg.) offer a h264-nvenc, and a h265-nvenc selection, the same as a codec, with it's own set of parameters for NVENC.

I do not see why this would be 'very difficult' using the existing profile system.
 

hydra3333

Member
Just wondering, NVEncC is built for nvidia nvenc encoding only.

Ignoring the filters, it has a range of "standard nvidia" settings/values to control the encoder.

I wonder, would some kind VRD support soul be able to produce a side-by-side table of VRD-to-NVEncC settings/values to show the equivalent values ?

That'd make choosing the right VRD settings much easier.
 

Bulldog

New member
Just wondering, NVEncC is built for nvidia nvenc encoding only.

Ignoring the filters, it has a range of "standard nvidia" settings/values to control the encoder.

I wonder, would some kind VRD support soul be able to produce a side-by-side table of VRD-to-NVEncC settings/values to show the equivalent values ?

That'd make choosing the right VRD settings much easier.
 

Bulldog

New member
Information would be helpful.
I have searched for information w.r.t. NVENC , with little success.

What is available, is often either out of date, vague, irrelevant, or just plain gibberish.

The VRD team would know how it has been employed as far as VRD is concerned.

Can they make the information available ?.

PLEASE.
 
Top Bottom