In the next build, I've added both ProRes and Cineform as options for the ImportAssist tool, but not R+.
Although it can easily be added, it would only be useful for rendering 8bit projects since the FrameServer is currently 8bit.
Just discovered HOS! Great job and thank you for your efforts! I'm working exclusively in 8-bit at these acquisition-resolutions/framerates: 1080p24,1080p240, 480p24 (native-16:9 w/2:3 pulldown), and 480i60. Primary acquisition-format: H.264 AVCHD Ver.2.0. All this is pretty new to me and I'm also in the market for a new laptop, so I have two general questions:
1. Does Vegas + HOS generally benefit more from current Intel or AMD Ryzen CPUs for the relevant scripts?
2. Does Vegas + HOS generally benefit more from current AMD or NVIDIA GPUs for the relevant scripts?
Thanks!
1. Does Vegas + HOS generally benefit more from current Intel or AMD Ryzen CPUs for the relevant scripts?
2. Does Vegas + HOS generally benefit more from current AMD or NVIDIA GPUs for the relevant scripts?
I will just tell you about experience. I dont see that HOS prefers for its tasks AMD or Intel CPUs. On the GPUs side you have to consider most likely GPU hardware encoding for x264 and x265 it offers a wide range of GPUs.
(Note, this just shows my notebook available GPUs)
But wwaag will probably tell you a bit more about both, CPUs and GPUs
1. Although I don't have any AMD CPUs, I would think it really doesn't matter. I've always leaned toward Intel for 2 reasons--hardware decoding and the availability of QuickSync as an additional rendering option.
2. HOS makes use of dedicated open source apps for GPU supported rendering for Nvenc(Nvidia), VCE (AMD) and QSV (Intel). So again, it probably doesn't make any difference for HOS. Of the two, I would lean toward Nvidia since Nvenc support seems more widespread and there are also more options available for this format using the HOS render apps.
Having said that, if your interest is a high quality final render, I wouldn't recommend any of the GPU supported options. Rather, use the x264 (AVC) or x265 (HEVC) encoder options which are CPU-only.
The bottom line--it really doesn't matter which you chose for HOS. Good luck.
1. Does Vegas + HOS generally benefit more from current Intel or AMD Ryzen CPUs for the relevant scripts?
2. Does Vegas + HOS generally benefit more from current AMD or NVIDIA GPUs for the relevant scripts?I will just tell you about experience. I dont see that HOS prefers for its tasks AMD or Intel CPUs. On the GPUs side you have to consider most likely GPU hardware encoding for x264 and x265 it offers a wide range of GPUs.
(Note, this just shows my notebook available GPUs)
But wwaag will probably tell you a bit more about both, CPUs and GPUs
Thanks for your advice! Appreciate the screen-grab, too!
1. Although I don't have any AMD CPUs, I would think it really doesn't matter. I've always leaned toward Intel for 2 reasons--hardware decoding and the availability of QuickSync as an additional rendering option.
2. HOS makes use of dedicated open source apps for GPU supported rendering for Nvenc(Nvidia), VCE (AMD) and QSV (Intel). So again, it probably doesn't make any difference for HOS. Of the two, I would lean toward Nvidia since Nvenc support seems more widespread and there are also more options available for this format using the HOS render apps.
Having said that, if your interest is a high quality final render, I wouldn't recommend any of the GPU supported options. Rather, use the x264 (AVC) or x265 (HEVC) encoder options which are CPU-only.
The bottom line--it really doesn't matter which you chose for HOS. Good luck.
Ah, gotcha—thanks! Okay, so knowing that now, I would have two use-cases:
1. GPU-accelerated renders: Extremely frequent.
2. High-quality CPU-renders: Only occasionally; reserved for finished projects.
My priority would be on high-quality preview-window playback and GPU-accelerated renders for eveyday-use (if notably faster than CPU-renders); i.e., I quickly just want to "see what I have." High-quality renders would be fairly infrequent since these would only be used for final-output of finished projects (of which I have every few!). Thanks for all your advice!
@wwaag Just asking here, maybe you have an idea, if you want i also can make an support email request.
what can be the reason that HOS x264 CPU encodes generate many compression artifacts? The internal AVC Vegas Pro encoder does not such things. I cant imagine that the fault is at FFMPEGs side. Maybe DebugMode FrameServer is the issue or AviSynth?
Internal Vegas Pro AVC encode
HOS x264 CPU encode
The HOS R+ Encoder Settings are:
ffmpeg -y -i <inAVS> -itsoffset 0.0444 -i <inTempWav> -map 0:v -map 1:a -c:v libx264 -pix_fmt yuv420p -crf 20 -preset veryslow -x264-params keyint=96 -c:a:0 aac -b:a:0 256k <outFile>.mp4
So nothing special, beside the keyframe addition (same result with -g 96) its the taken over settings from HOS itself.
Any idea?
Hope neither of u mind my adding my 2 cents worth. To compare like for like, the 2 output files need to be close in size and data rate.
@eikira Maybe worth changing the -g 96 to say -g 15 to match what is typically MC CPU output. For example ... GOP length=15, M=4, N=15, Mini-GOP=IBBBP ... GOP=IBBBPBBPBBBPBBPI
Hope neither of u mind my adding my 2 cents worth. To compare like for like, the 2 output files need to be close in size and data rate.
@eikira Maybe worth changing the -g 96 to say -g 15 to match what is typically MC CPU output.
The input has keyframe interval of 24 (GH5 LongGOP), and i am very sure it has absolute nothing to to with the MC CPU itself. I also tryed without a keyframe attribute, the same result. Therefore i ruled out that this command is the culprit. And sorry for my rude tone in this, but its silly to think it has to be the same data rate and size, that is the sole reason why encoders with many commands and setting abilities exist. And CRF 20 (HOS) is a more than enough high datarate.
What i will try now is, i will export in AppleAnimation and encode in FFMPEG directly to see if its an FFMPEG problem. But thanks for the input, its always important to get ideas what could be the issue.
EDIT: THAT is some ultra strange behavior! Exportet in Apple Animation, the footage does not show any breaking artifacts at all. Loading up FFMPEG, put this string in it
ffmpeg -i Scene24_EndEncode.mov -c:v libx264 -pix_fmt yuv420p -crf 20 -preset veryslow -x264-params keyint=96 -c:a aac -b:a:0 256k Scene24_EndEncode_FFMPEG.mp4
I get again artifacts... Will now remove the keyframe command and see what that does. (Using btw FFMPEG 4.4 gyan, had also the same with 2 hours ago 4.3), will try to use the other ffmpeg.
EDIT2: Ok, i tryed now without any keyframe commands. Same result, artifacts. I replaced FFMPEG gyan with FFMPEG BtbN, same result, well the artifacts got just bigger. It is almost as if the libx264 encoder included in FFMPEG is broken.
EDIT3: I let FFMPEG now encode in libx265 and no artifacts, what tells me, something is fishy with the libx264 at least in ffmpeg 4.3.4-4.4.
Sorry for the delay in responding.
There was a similar issue reported awhile back by Nick Hope and I just received the link from JohnDennis who prepared a custom command line that seemed to work. Here's the link to the discussion https://www.vegascreativesoftware.info/us/forum/happy-otter-scripts-for-vegas-pro--113922/?page=18#ca730040
Turns out it was on the HOS thread a year and a half ago. John will try to reconstruct the CCL, but in the interim, the gop structure he used can be found a few posts down.
I'm sure you've tried, but have you turned off GPU support and attempted a render of just the region around that transition? I've seen similar artifacts in the past.
Another thing you might try is to change the preset from very slow to medium. From my understanding, the value of slower presets is the reduction in file size and not the quality of the encode. Just a suggestion.
I'll post the CCL once I receive it.
@wwaag it turns out it has nothing to do with HOS. I did not find a true fix so far but it is an issue with ffmpeg.exe
1. I tried to encode it directly in vp18 with HOS, with cpu x264 420. artifacts.
2. I tried to encode it directly in vp18 with HOS, with cpu ProRes. clean.
3. I tried to encode it directly in vp18 with HOS, with cpu Apple Animation. clean.
4. I tried to encode it directly in vp18 with HOS, with cpu x264 but this time set 422. clean.
5. Took the Apple Animation file, encode directly with FFMPEG to x264 420. artifacts.
6. Took the Apple Animation file, encode directly with FFMPEG to x264 422. clean.
The fact that the encoded Apple Animation file is clean but outside from vp18 and HOS that FFMPEG reproduce the artifacts (mind always at the same spots), and that it has nothing to do anymore with transitions of vp18 at all, and is clearly connected to -pix_fmt yuv420p, shows me that something is wrong with FFMPEG libx264+420.
libx265 shows nothing of that at all, but the time to encode in x265 takes 6-8 times longer...
Have you tried HOS using 422 or even 444 rather than 420?
Oops!! Just saw that you've done this and its OK.
I do have earlier FFmpeg versions that I could upload to DB that were used in previous versions.
Have you tried HOS using 422 or even 444 rather than 420?
I do have earlier FFmpeg versions that I could upload to DB that were used in previous versions.
Yes that is 4. like mentioned above. I also tried 4 different versions of FFMPEG. 4.3.2 / 4.3.4 / 4.4. I also tried on my notebook and on my desktop same results.
Sorry. I just saw that you had already done that. Could you upload a sample clip that's giving problems?
Sorry. I just saw that you had already done that. Could you upload a sample clip that's giving problems?
No, cant share those files. What i will try now is, to encode the Apple Animation file with RipBot264 since it uses also x264 from VideoLan.org like FFMPEG by gyan and by BtbN.
EDIT: RipBot264 seems to become unusable, it cant understand Apple Animation and ProRes it seems.
But i narrowed it even further down.
THIS produces artifacts:
ffmpeg -i AppleAnimation.mov -c:v libx264 -pix_fmt yuv420p -crf 20 -preset veryslow -x264-params keyint=96 -c:a aac -b:a 256k 420.mp4
This does not:
ffmpeg -i AppleAnimation.mov -c:v libx264 -pix_fmt yuv420p -crf 20 -x264-params keyint=96 -c:a aac -b:a 256k 420.mp4
For whatever, absolute not understandable reason, the -preset veryslow in combination with -pix_fmt yuv420p does produce the artifacts. -preset slow seems fine. This is sooo above me. It makes 0 sense to me
Mind, i am talking outside HOS. Its FFMPEG+libx264.
Tried now in vp18 with HOS and did NOT use preset 'veryslow', now its also clean again, with 420. I really dont understand what is going on and why 'veryslow' would generate artifacts at all...
No problem. Or, you can download x264 and encode directly, thus bypassing FFmpeg altogether. Here's a link to a simple GUI that I've used in the past if you don't want to run command line. https://github.com/lordmulder/Simple-x264-Launcher
No problem. Or, you can download x264 and encode directly, thus bypassing FFmpeg altogether. Here's a link to a simple GUI that I've used in the past if you don't want to run command line. https://github.com/lordmulder/Simple-x264-Launcher
Thanks. Never heard of that launcher. BUT, even with the bypass of FFMPEG, it produces artifacts even with x264.exe standalone IF i use -preset veryslow.
Did you try a different preset?
Did you try a different preset?
slower, slow and medium seem to work just fine.
That's very interesting. When I first wrote R+, I used the "very slow" preset for the simple, high-quality option. It was "very, very slow" to the point, I decided to just user "slower" which seemed to work as well, but not take nearly as long. Supposedly, the only advantage of the slower options is that it reduces file size for the same CRF value. I guess your solution is to just "slower".
@wwaag i just right now saw Happy Otter AudioSyncR on the HOS webpage. Will there be also trial for it, and can you tell how much it will cost, roughly? At least judging from the demovideos it seems to kick PluralEyes ass. Ok PE works also on other NLE but still, i am amazed by your work!