@apvv and @Jep

Please do this. Try a render again. After it hangs again and you have killed or reset everything, go to C:\ProgramData\HappyOtterScripts\Magix Vegas Pro\RenderPlus for Magix or C:\ProgramData\HappyOtterScripts\Sony Vegas Pro\RenderPlus for Sony and send the file "RenderAbort.log" to support@tools4vegas.com. You can view its contents with any text editor. Thanks.

@apvv and @Jep

Please do this. Try a render again. After it hangs again and you have killed or reset everything, go to C:\ProgramData\HappyOtterScripts\Magix Vegas Pro\RenderPlus for Magix or C:\ProgramData\HappyOtterScripts\Sony Vegas Pro\RenderPlus for Sony and send the file "RenderAbort.log" to support@tools4vegas.com. You can view its contents with any text editor. Thanks.

Ok. I sent already. Thanks.

 

@Jep

Thanks for the info. That is indeed helpful. The "bug" is in the main app that links Vegas to ffmpeg. For some reason, ffmpeg is not closing after a successful run in V13. I must admit that I don't do as much testing with Sony versions since most are now using Magix versions. Hopefully, I can post a fix in the next couple of days. One question the same as to appv. Do you ever get the crash report dialog? If so,i please send with some identification that it's from you.

 

As always - thanks for the quick reply Wayne. No, I never get a crash report dialog, everything just freezes. I wouldn't worry about fixing it quickly, as ultimately I can still get HOS to render even if it is a bit of a workaround. In any event I can go back to version 1.0.2.61 until you get time to fix it. 😉

@apvv and @Jep

Please do this. Try a render again. After it hangs again and you have killed or reset everything, go to C:\ProgramData\HappyOtterScripts\Magix Vegas Pro\RenderPlus for Magix or C:\ProgramData\HappyOtterScripts\Sony Vegas Pro\RenderPlus for Sony and send the file "RenderAbort.log" to support@tools4vegas.com. You can view its contents with any text editor. Thanks.

Hi Wayne. I'd gone back to version 1.0.2.61 before I saw your post above. So I reinstalled version 1.0.2.63 and ran my tests again and ran into some more weirdness.

I couldn't find ffmpeg listed anywhere in Task Manager. So I clicked the red X in the HOS progress bar. The render resumed but when completed Vegas froze with the DebugMode FrameServer window Stop Serving button unclickable. So I had to close Vegas with End Task in Task Manager. Rebooted and tried again, but still no ffmpeg showing in Task Manager. The rendered file looks fine though. Strange.

Anyway, HOS did generate a RenderAbort.log and I'll send that to you now.

Thanks again for everything.

@apvv and @Jep

Please do this. Try a render again. After it hangs again and you have killed or reset everything, go to C:\ProgramData\HappyOtterScripts\Magix Vegas Pro\RenderPlus for Magix or C:\ProgramData\HappyOtterScripts\Sony Vegas Pro\RenderPlus for Sony and send the file "RenderAbort.log" to support@tools4vegas.com. You can view its contents with any text editor. Thanks.

Hi Wayne. I'd gone back to version 1.0.2.61 before I saw your post above. So I reinstalled version 1.0.2.63 and ran my tests again and ran into some more weirdness.

I couldn't find ffmpeg listed anywhere in Task Manager. So I clicked the red X in the HOS progress bar. The render resumed but when completed Vegas froze with the DebugMode FrameServer window Stop Serving button unclickable. So I had to close Vegas with End Task in Task Manager. Rebooted and tried again, but still no ffmpeg showing in Task Manager. The rendered file looks fine though. Strange.

Anyway, HOS did generate a RenderAbort.log and I'll send that to you now.

Thanks again for everything.

Exactly the same as Jep situation.

I rendered a UHD 3840x2160-30p stock footage preview in Render+ in HOS 1.0.2.62 from VP16 build 424, with my usual very-high-quality (actually OTT) settings:

No artifacts in the output MP4 but the rendered video on YouTube (VP9 codec) shows bad artifacts, the first one starting at 0:43:

I have used this workflow before, a few months ago, and the YouTube videos ended up fine. Not sure what's changed.

I don't have a GPU capable of VCE or NVENC.

Anyone seen this before? Any suggestions to solve it? Alternative formats to upload? I'm thinking of a straightforward MAGIX AVC (MainConcept) render next, but open to suggestions.

I believe the technical term for that is "gnarly."

I think YouTube is recommending 50Mbps for 4k p60 uploads. Is yours in significant excess of that bitrate?

The artifacts also show up on the MP4 versions, as well.

@NickHope

Do you get the same artifacts with Vimeo?

As an aside, I gave up with both YT and Vimeo for the demos on the HOS website because of poor quality.

Regarding HOS, nothing has changed in R+ unless there have been changes to the basic x264 encoder.

@NickHope

I think Progressive Download is useless for youtube, because it transcodes the video.

You might try x265 instead of x264, more efficient with 4k, also probably the case of youtube transcoder.

PS: Very beautiful animal

whydat wrote on 9/18/2019, 2:33 PM

I think Progressive Download is useless for youtube, because it transcodes the video.

I propose you test this by uploading two otherwise identical videos to YouTube, one with and one without faststart. Measure the exact times it takes to upload + process the video before going "live."

I predict "one" of the uploads will take nearly twice as long to upload + process.. Any decoder needs to actually see the moov atom header metadata before it can start processing or playing. Unless something has changed very recently, I know of no exceptions involving Youtube.

@NickHope

Try my custom command line. The cadence closely matches AMD VCE without the hardware encoding.

...I think YouTube is recommending 50Mbps for 4k p60 uploads. Is yours in significant excess of that bitrate?...

103 Mb/s at half that frame rate. OTT really, but I like to give my videos the best chance. Has worked well for me before. But I should probably dial it back a bit, especially for 4k.

...The artifacts also show up on the MP4 versions, as well.

Thanks for that info. It looks like the error is in YouTube's decoding of my uploaded file, rather than their re-encoding, as the artifacts are appearing on various devices at various resolutions.

Do you get the same artifacts with Vimeo?

Didn't try that yet as I really need to get this working on YouTube. Upload of a 2.78GB file takes a long time on my connection. May try it later as part of troubleshooting.

I think Progressive Download is useless for youtube, because it transcodes the video.

I thought YouTube recommend that because they can start transcoding while the video or still uploading. Or was it "Fast Decode" they prefer?? 😕 Hmm... Looking at Musicvid's later comment, I think I got that the wrong way around. However, looking at the command line, "-faststart" is included.

So does "faststart"="progressive download" or "fast decode"? And which is it that YT benefits from?

You might try x265 instead of x264, more efficient with 4k, also probably the case of youtube transcoder.

Good idea.

PS: Very beautiful animal

Thanks. And they're only about 1" long. Sea stars aren't very fond of them though!

Try my custom command line. The cadence closely matches AMD VCE without the hardware encoding.

Also a good idea.

Thanks for all the suggestions. Lots to go on there 😊. Will report back.

Thanks for that info. It looks like the error is in YouTube's decoding of my uploaded file, rather than their re-encoding, as the artifacts are appearing on various devices at various resolutions.

I agree with that. The artifacts are reminiscent of player decoding glitches of terribly high bit rates on weak CPUs in the earlier years of AVC -- A better question to ask is, are the artifacts still there if you upload 50 Mbps?

https://www.vegascreativesoftware.info/us/forum/wagging-the-dog-effects-of-hyperoptimal-youtube-upload-bitrates--114098/

Pardon the fact that the y-axis index is mistakenly in Kb/KB rather than Mb/MB as the legend suggests.

Faststart=progressive download=web optimized=streaming enabled = moov atom at front, to my understanding. "Fast decode" is just a tweak if I am not mistaken. So yes, YT can start working immediately when it sees the header info in moov.

Glad to see you out and about!

Hi Wayne. I'd gone back to version 1.0.2.61 before I saw your post above. So I reinstalled version 1.0.2.63 and ran my tests again and ran into some more weirdness.

I couldn't find ffmpeg listed anywhere in Task Manager. So I clicked the red X in the HOS progress bar. The render resumed but when completed Vegas froze with the DebugMode FrameServer window Stop Serving button unclickable. So I had to close Vegas with End Task in Task Manager. Rebooted and tried again, but still no ffmpeg showing in Task Manager. The rendered file looks fine though. Strange.

Anyway, HOS did generate a RenderAbort.log and I'll send that to you now.

Thanks again for everything.

I have the same problem :( Can someone send me version 1.0.2.61, please?

Can someone send me version 1.0.2.61, please?

@max9

Download link HOS 1.0.2.61

https://www.dropbox.com/s/iohzwzo6gvc47ff/HappyOtterSetup-1.0.2.61.rar?dl=0

Thank you very much

@apvv

@max9

and anyone else experiencing render problems with v62 or v63.

A fix is available and can be downloaded at https://www.dropbox.com/s/rxtne1htpxp73gc/fs2enc.exe?dl=0

To apply, download the file and copy it to the following folder: C:\Program Files\HappyOtterScripts. It's probably best to first rename the existing file in the event you need to revert.

Make sure that the file is not "blocked" by Windows. To check, right-click and select properties. If blocked, there is an option to "unblock" which you must do. Windows often blocks files downloaded from Dropbox.

Jep has reported that the new file seems to solve the rendering problems. If not, please advise. Thanks.

Regarding my issues with YouTube artifacts (above), I dropped the quality from crf18 to crf20, which dropped the bit rate from 103Mb/s to 66Mb/s, and still got those issues. So I tried John Dennis' custom command line. Even though it's crf20, the bit rate comes out at 100Mb/s, so it's nearly the same as crf18 without the various additions such as "zerolatency". But it looks good and results in no artifacts on YouTube, so I'm going with that for the time being. Thanks John!

I'll also say that MAGIX AVC (Mainconcept) at 2-pass 70Mb/s max 50Mb/s ave also looks good, but the x264 renders match the original more closely on the waveform scope. Fine detail is important in my subject matter.

I did try MAGIX HEVC but it was painfully slow to render, so I won't be using that.

wwaag, one minor issue I'm getting with Render+ is that "-Test Render" is always appended to my mp4 file names, and I'm not sure where it's coming from. It may have been a file name I was using previously, but somehow it's "stuck in the works".

I've also been getting a lot of hangs at the start of renders with 1.0.2.62, requiring me to kill Vegas with the task manager. Will update to .63 and try your fix.... [Edit: So the first render after a reboot worked OK, where previously I think it would have hung]

"Even though it's crf20, the bit rate comes out at 100Mb/s, so it's nearly the same as crf18 without the various additions such as. But it looks good and results in no artifacts on YouTube, so I'm going with that for the time being. Thanks John!"

You're welcome. I'm happy that I could finally do something to help you.

The shade-tree encoder responds...

The bit rate is high for a given CRF because there are index frames every 15 frames and no B-frames. My non-mathematical, knee-jerk, techno-philosophical opinion is that a file that's going to be re-encoded should be All-I. Failing that, it should have as many full frames as one can afford for the bandwidth limitation. But, you know about opinions...  

"My non-mathematical, knee-jerk, techno-philosophical opinion is that a file that's going to be re-encoded should be All-I."

Its a pretty simple command line in x264 for a bare bones all-intra render. At one time, I had included such an all-intra preset in HOS. If there's any interest, it could be added back as an option.

ffmpeg -i input -c:v libx264 -intra output

Regardless, it would be interesting to see if it makes any difference for YT. Sounds like a good test in the making to me.

So I replaced the GOP parts of John's ccl...

-force_key_frames "expr:eq(mod(n,15),0)" -x264opts rc-lookahead=30:keyint=30:min-keyint=15

...to just...

-intra

...resulting in...

ffmpeg -y -i <inAVS> -itsoffset 0.0444 -i <inTempWav> -map 0:0 -map 1:0 -c:v libx264 -intra -pix_fmt yuv420p -crf 20 -preset slow -tune zerolatency -profile:v high -movflags +faststart -c:a aac -b:a 320k <outFile>.mp4|||

Result is no artifacts on YouTube but bit rate of the uploaded file was unsurpsingly higher at 136 Mb/s and gave black frames on the Vegas timeline, requiring restart of Vegas. Don't think I'll be going with this option. Seems John's ccl is a good compromise.

Some documentation here. John, where did you get the syntax for those parts of your ccl?

Hi Wayne - thanks for the fs2enc fix. Unfortunately I'm having problems again with R+ but I'm not sure if it is related to ffmpeg or fs2enc issue.

First my system - Win 10 64bit, 32Gig Ram, Intel i7-7820X CPU @ 3.6Ghz, Nvidia GeForce GTX 1070 Ti graphics card, over 3Tb hard drive space free. I'm using Vegas Pro 13 64bit. HOS Version 1.0.2.63.

The original media I'm working with is 1920x1080 50p @ 24506kbps. The length of the video to render is just shy of 1 hour 22 minutes.

When I click Render in R+ it goes through the .wav phase signpost.avi render phases, but when the DebugMode FrameServer window pops up rendering does not start, and the HOS render progress box does not appear. (Also DebugMode Frameserer appears in the middle of my screen rather than the top left where it normally does - not sure if that's indicative of anything). I then have to click "Stop Serving" and I get an error message telling me to look at the "LastRenderLogFile.txt" in C:\ProgramData\HappyOtterScripts\Sony Vegas Pro\RenderPlus, but I can't find that file in that folder. I then get a Crash Report pop-up from HOS, and I've sent the crash report using the send function.

I also had a quick look at the proccesses in Task Manager - neither ffmpeg or fs2enc appeared to be listed.

However, If I try rendering a small 2 minute loop from the same Vegas project using the exact same settings it renders without a problem. So, I'm wondering if this has something to do with the overall length of the video I'm rendering with R+?

Finally, I went back to HOS version 1.0.2.61 and tried rendering the same Vegas project with the same settings in R+. The full project rendered without a hitch and the output file looks fine.

As always - thanks for all the hard work.