AFS and avisynth plus 64 bit slow speed

[qo4on]

Does anybody know why encoding through AFS and Avithith plus is 3 times slower than usual ffmpeg encoding? The all commands which I used is bellow:
ffmpeg -vsync 0 -r 60 -i "C:\01.mp4" -pix_fmt yuv444p -c:v hevc_nvenc -preset lossless "02.mp4"
ffmpeg -vsync 0 -r 60 -i "C:\frameserver.avs" -pix_fmt yuv444p -c:v hevc_nvenc -preset lossless "02.mp4"

[poisondeathray]

You have a bottleneck, probably PP can't send frames fast enough through AFS

You can check speed without encoding or pix_fmt conversion or any other processing, to see raw afs speed

ffmpeg -i "C:\frameserver.avs" -c:v rawvideo -an -f null NUL

[qo4on]

You have a bottleneck, probably PP can't send frames fast enough through AFS

You can check speed without encoding or pix_fmt conversion or any other processing, to see raw afs speed

ffmpeg -i "C:\frameserver.avs" -c:v rawvideo -an -f null NUL

What does this command do? I ran it and saw 16 fps. It was faster than avs-mp4 (11 fps) and slower than mp4-mp4 (31 fps).

[poisondeathray]

You have a bottleneck, probably PP can't send frames fast enough through AFS

You can check speed without encoding or pix_fmt conversion or any other processing, to see raw afs speed

ffmpeg -i "C:\frameserver.avs" -c:v rawvideo -an -f null NUL

What does this command do? I ran it and saw 16 fps. It was faster than avs-mp4 (11 fps) and slower than mp4-mp4 (31 fps).

It's measuring the speed of the PP, afs, avs speed directly , without the effect of encoding, scaling, or other operations . That's the fastest speed you're current setup is sending data to ffmpeg, so that's the theoretical fastest encoding speed possible with that setup and afs . But it will never get 16fps, because you have scaling, pixel manipulation, encoding on top of that. Every frameserver, every manipulation you add will only slow down the speed by adding latency (afs is one, avisynth is another)

What was avs-mp4 (11fps) ? Direct decoding in avs should be faster than pp-afs-avs-ffmpeg which should be the slowest.

Another useful tool is avsmeter

These are diagnostic steps to determine where bottlenecks are, so you can manage/tweak you workflow better

[qo4on]

[QUOTE=poisondeathray;2508872][QUOTE=qo4on;2508869]

What was avs-mp4 (11fps) ?

ffmpeg -vsync 0 -r 60 -i "C:\01.mp4" -pix_fmt yuv444p -c:v hevc_nvenc -preset lossless "02.mp4" - 31 fps
ffmpeg -vsync 0 -r 60 -i "C:\frameserver.avs" -pix_fmt yuv444p -c:v hevc_nvenc -preset lossless "02.mp4" - 11 fps

After using ffmpeg -i "C:\frameserver.avs" -c:v rawvideo -an -f null NUL I have not seen any report with the speed of the PP, afs or avs speed directly.
I didn't do any manipulation. It's jast a test: 1 clip on the timeline. And avisynth: AviSource("c:\work\output.avi"). That is all.

[poisondeathray]

ffmpeg -vsync 0 -r 60 -i "C:\01.mp4" -pix_fmt yuv444p -c:v hevc_nvenc -preset lossless "02.mp4" - 31 fps
ffmpeg -vsync 0 -r 60 -i "C:\frameserver.avs" -pix_fmt yuv444p -c:v hevc_nvenc -preset lossless "02.mp4" - 11 fps

After using ffmpeg -i "C:\frameserver.avs" -c:v rawvideo -an -f null NUL I have not seen any report with the speed of the PP, afs or avs speed directly.
I didn't do any manipulation. It's jast a test: 1 clip on the timeline. And avisynth: AviSource("c:\work\output.avi"). That is all.

Did you ConvertToXX or something ? It's just 1 line script ?

It's measuring what ffmpeg "sees" from pp=>afs=>avs . Your theoretical max is 16fps. You will never get this for actual encoding.

But in ffmpeg you have -pix_fmt yuv444p , which means conversion to YUV444, which takes more cpu cycles . afs can only serve RGB or YUV422. You can test the effect of that additional operation on the 16 fps without it

ffmpeg -i "C:\frameserver.avs" -c:v rawvideo -pix_fmt yuv444p -an -f null NUL

In PP, If the source clip is YV12 (4:2:0), then it gets converted before it gets piped through afs. Actually it gets converted to RGB (clipping of superbrights/darks), even if you select UVYV or YUY2 - another reason NOT to use afs . It uses Rec601 for the conversion (wrong matrix, wrong colors for HD or UHD) , but if you use -pix_fmt yuv.... in ffmpeg it uses Rec601 as well. In that case "2 wrongs make a right", they sort of cancel each other out . But you still get clipping of YUV sources

99.99% of the time , the bottleneck is PP and afs. It doesn't serve frames fast enough for most types of projects. That's why you are seeing ~1/3 the speed. It doesn't matter if nvenc or the downstream encoder can encode 2000fps , if you have a bottleneck upstream

[lordsmurf]

Afs?

[qo4on]

It's just 1 line script. I'm getting BGR24 at ffmpeg input.
I see much faster speed and more gpu usage using nvenc plugin 1.12. it's based on frameserver too.
As far as I know nvenc can take rgb input and convert it to yuv. That is what I'm trying to do with -pix_fmt yuv444p.
I don't see color clipping. All colors remain the same at full range from 0 to 255. Why do you think that afs uses Rec601 for the conversion from source to rgb24? How can I check colorspace in ffmpeg it shows me only bgr24 on input?
I checked speed for every afs supported format: rgb24, rgb32, yuy2 - 15...16 fps, uyvu - doesn't work. I don't understand why, but nvenc plugin works faster.

[poisondeathray]

It's just 1 line script. I'm getting BGR24 at ffmpeg input.
I see much faster speed and more gpu usage using nvenc plugin 1.12. it's based on frameserver too.

Did you mean NVEncC ? (not ffmpeg nvenc). It is faster in some cases because some colorspace conversions are done on the GPU, but not all default settings are equivalent to the ffmpeg nvenc version

As far as I know nvenc can take rgb input and convert it to yuv. That is what I'm trying to do with -pix_fmt yuv444p.
I don't see color clipping. All colors remain the same at full range from 0 to 255. Why do you think that afs uses Rec601 for the conversion from source to rgb24? How can I check colorspace in ffmpeg it shows me only bgr24 on input?
I checked speed for every afs supported format: rgb24, rgb32, yuy2 - 15...16 fps, uyvu - doesn't work. I don't understand why, but nvenc plugin works faster.

0-255 in RGB , right? What was your original source?

I'm talking about a full range YUV source 16-235 Y gets "mapped" to 0-255 in RGB .

90% of cameras record 16-255 , with usuable highlights in the Y= 235-255 range. Those get clipped unless you fix them in PP before frameserving.

Moreover, there is loss when you convert RGB <=> YUV and back. It's a lossy conversion unless it's done in float precision (dfs and afs only use 8bit precision)

These tests were posted before, it's fairly common knowledge about afs and dfs (at least for "serious" users; "casual" users might not know these things)



-pix_fmt yuv444p uses swscale on the CPU from ffmpeg to do the conversion. Not NVEnc. NVEnc can do some accelerated colorspace conversions (for example NV12 is what it uses for 4:2:0, not YV12, and that YV12=>NV12 conversion can use things like AVX2 instructions) , but the ffmpeg nvenc version doesn't use it (unless something has changed recently) . Not sure about YUV444, I didn't test those recently.

HEVC encoding is slow , especially at UHD resolutions . "GPU" encoding will be faster on most systems - that's expected.

voukoder has NVENc implementation planned on the timeline - that would be direct encoding from PP and faster because it can pull YUV frames directly, no afs or avisynth overhead.

There is another free 3rd party NVEnc plugin for PP, but IIRC development stopped a while back. It's was available on the adobe forum

[poisondeathray]

voukoder has NVENc implementation planned on the timeline - that would be direct encoding from PP and faster because it can pull YUV frames directly, no afs or avisynth overhead.

I spoke too soon. He just released it today

https://github.com/Vouk/voukoder/releases

Hardware accelerated h.264 encoder (NVENC)
Hardware accelerated h.265 encoder (NVENC)

[qo4on]

Did you mean NVEncC ?

I see BGR24 using ffmpeg -i "C:\frameserver.avs"

0-255 in RGB , right? What was your original source?

Original source was yuv 4:2:0 with png/jpeg pictures at several places.
I recently found out that if you set mercury gpu adobe renderer exports YUV444 only. Evidently there is a convertation YUV444 to RGB24 inside afs. There is no YUV444 option availiable in afs. I suppose that is the main reason why I get slower speed relatively to nvenc plugin. And nothing I can do with afs to fix that.

Moreover, there is loss when you convert RGB <=> YUV and back. It's a lossy conversion unless it's done in float precision (dfs and afs only use 8bit precision)

These tests were posted before, it's fairly common knowledge about afs and dfs (at least for "serious" users; "casual" users might not know these things)

This is the first time with afs for me.
In PP I see the same colors, but there is an outline at the bright colored edges in layer difference mode. Does it look like RGB <=> YUV loss?

[Attachment 44438 - Click to enlarge]

voukoder has NVENc implementation planned on the timeline - that would be direct encoding from PP and faster because it can pull YUV frames directly, no afs or avisynth overhead.

It is very interesting. Does anybody know how it works?

[poisondeathray]

0-255 in RGB , right? What was your original source?

Original source was yuv 4:2:0 with png/jpeg pictures at several places.
I recently found out that if you set mercury gpu adobe renderer exports YUV444 only. Evidently there is a convertation YUV444 to RGB24 inside afs. There is no YUV444 option availiable in afs. I suppose that is the main reason why I get slower speed relatively to nvenc plugin. And nothing I can do with afs to fix that.

But did your YUV source have Y range >16-235 or CbCr > 16-240 ? Because those get clipped by afs. 100% certain about this. Easy to demonstrate this

No - RGB in/out is lossless, even with MPE , even with afs (if it doesn't crash or drop frames, that is . So an RGB24 asset => MPE => RGB encoding reimport is lossless if you use lossless RGB encoding (YUV444 is not lossless, because RGB=>YUV444 is lossy most of the time)

When you "see" a 255 patch, that's RGB converted. Not actual YUV values

In PP I see the same colors, but there is an outline at the bright colored edges in layer difference mode. Does it look like RGB <=> YUV loss?

Could be, but you have it set to "fit" which might resize some artifacts

Artifacts on vertical bars suggests chroma resizing , but you'd expect that on other bars as well, not just on the outside edge

voukoder has NVENc implementation planned on the timeline - that would be direct encoding from PP and faster because it can pull YUV frames directly, no afs or avisynth overhead.

It is very interesting. Does anybody know how it works?

The NVEnc part was released today . Test it and report any bugs . But the libav/ffmpeg libx264/libx265 (CPU) is working well

A to B to C will always be slower than A to C directly . It should be faster for that reason alone because you cut out afs and avisynth steps . Also , there should be no additional colorspace conversions (not just qualty loss, but slower when you do other conversions back and forth)

[qo4on]

But did your YUV source have Y range >16-235 or CbCr > 16-240 ?

According to MediaInfo it is limited 709, but I don't know how to proove it in PP. PP always shows full range.

No - RGB in/out is lossless

Standalone RGB - yes, but nvenc works in yuv. That is why the only one way to get lossless in this case is YUV444, am I wrong?

Could be, but you have it set to "fit" which might resize some artifacts
Artifacts on vertical bars suggests chroma resizing , but you'd expect that on other bars as well, not just on the outside edge

100% and 400% does not change anything.

[Attachment 44441 - Click to enlarge]
I saw the same outlines with voukoder lossless hevc. And I have no idea why it happens. But voukoder works faster and better than afs. And even better than nvenc plugin 1.12.

[poisondeathray]

But did your YUV source have Y range >16-235 or CbCr > 16-240 ?

According to MediaInfo it is limited 709, but I don't know how to proove it in PP. PP always shows full range.

In PP the waveform will show <0 or >100 IRE if you have full range YUV values and you set the waveform not to clip . Those values are "recoverable" with YUV filters. They are known as "superbrights" and "superdarks"

No - RGB in/out is lossless

Standalone RGB - yes, but nvenc works in yuv. That is why the only one way to get lossless in this case is YUV444, am I wrong?

I think NVEnc does not support RGB . But you're limit yourself to NVEnc only ?

Could be, but you have it set to "fit" which might resize some artifacts
Artifacts on vertical bars suggests chroma resizing , but you'd expect that on other bars as well, not just on the outside edge

100% and 400% does not change anything.

[Attachment 44441 - Click to enlarge]
I saw the same outlines with voukoder lossless hevc. And I have no idea why it happens. But voukoder works faster and better than afs. And even better than nvenc plugin 1.12.

It might be PP decoding issue. It had problems decoding hevc lossless profile, but AVC lossless was fixed a while back

[qo4on]

[QUOTE=poisondeathray;2509030]

In PP the waveform will show <0 or >100 IRE if you have full range YUV values and you set the waveform not to clip . Those values are "recoverable" with YUV filters. They are known as "superbrights" and "superdarks"

Waveform shows full range in RGB (recovered) and 16-235 YUV, mediainfo - limited. AE shows the same artifacts in difference mode.

[Attachment 44445 - Click to enlarge]
I don't think that it is PP issue:
[Parsed_ssim_0 @ 0000022df4dfef00] SSIM Y:0.999932 (41.651371) U:0.999964 (44.418718) V:0.999966 (44.746317) All:0.999943 (42.426614)
[Parsed_psnr_1 @ 0000022df8625a80] PSNR y:54.334727 u:69.354318 v:68.732008 average:56.022632 min:27.665726 max:inf

I need nvenc only because of speed.

Libx264 lossless shows no artifacts, it has better compression but time of encoding is huge.

[poisondeathray]

Waveform shows full range in RGB (recovered) and 16-235 YUV, mediainfo - limited. AE shows the same artifacts in difference mode.

[Attachment 44445 - Click to enlarge]
I don't think that it is PP issue:
[Parsed_ssim_0 @ 0000022df4dfef00] SSIM Y:0.999932 (41.651371) U:0.999964 (44.418718) V:0.999966 (44.746317) All:0.999943 (42.426614)
[Parsed_psnr_1 @ 0000022df8625a80] PSNR y:54.334727 u:69.354318 v:68.732008 average:56.022632 min:27.665726 max:inf

I need nvenc only because of speed.

Libx264 lossless shows no artifacts, it has better compression but time of encoding is huge.

RGB is always 0-255. You have no Y values above 100 or below 0 (ie your test doesn't show full range values) . Mediainfo only reads the header , it doesn't scan the file so it does not indicate any useful information (you can have full range values with a tagged limited range "label" , or limited range values only with a tagged full range "label")

It's definitely a premiere decoding bug. It doesn't support lossless hevc profile decoding. HEVC using libx265 is lossless in other programs/decoders , even when exporting from PP. There might be other problems with NVEnc HEVC , I don't have a pascal card to test

But AVC (libx264) lossless decoding is fixed in the last few PP versions . You can use NVEnc lossless AVC (not sure if it's available in the vouk plugin)

[qo4on]

It's definitely a premiere decoding bug. It doesn't support lossless hevc profile decoding.

If so, why AE shows the same? I tried to compare original file with png picture which was created from encoded file. It showed the same artifacts. Why ssim and psnr shows lossy?
[Parsed_ssim_0 @ 0000022df4dfef00] SSIM Y:0.999932 (41.651371) U:0.999964 (44.418718) V:0.999966 (44.746317) All:0.999943 (42.426614)
[Parsed_psnr_1 @ 0000022df8625a80] PSNR y:54.334727 u:69.354318 v:68.732008 average:56.022632 min:27.665726 max:inf

You can use NVEnc lossless AVC (not sure if it's available in the vouk plugin)

It's not availiable there.

[poisondeathray]

It's definitely a premiere decoding bug. It doesn't support lossless hevc profile decoding.

If so, why AE shows the same? I tried to compare original file with png picture which was created from encoded file. It showed the same artifacts. Why ssim and psnr shows lossy?
[Parsed_ssim_0 @ 0000022df4dfef00] SSIM Y:0.999932 (41.651371) U:0.999964 (44.418718) V:0.999966 (44.746317) All:0.999943 (42.426614)
[Parsed_psnr_1 @ 0000022df8625a80] PSNR y:54.334727 u:69.354318 v:68.732008 average:56.022632 min:27.665726 max:inf

Because it's an Adobe issue. Adobe makes AE too...

It took them a few years to fix the AVC lossless issue. I don't expect a quick fix HEVC lossless decoding...

SSIM and PSNR are lossless when I use libx265 export from Adobe. Confirmed with multiple tests. It's a decoding issue with Adobe. Make sure your frames are aligned (that plugin has issues with short tests and timecodes). It's also possible that NVEnc or that specific implementation has problems , but software HEVC bitstream is the "gold standard" to test against. If that has problems, then everything else will have problems. That' s how you know it's a decoding issue. It was the same thing with AVC lossless a few years ago

(You take a known AVC input stream, encode it with HEVC externally , test it externally. If it's proven to be lossless, you import all streams into PP or AE or anything Adobe and it will show "non lossless", but lossless in everything else. The 2nd test is exporting that AVC input with libx265 lossless, and testing that externally. That too is lossless . So the AVC decoding pathway works . It's the HEVC decoding pathway that has problems)

[qo4on]

AE was a different company before. It has absolutely another engine. SSIM and PSNR are lossless with libx265, and not lossless with nvenc hevc. I checked this without Adobe programs. My frames are aligned for sure. I think it is nvenc hevc issue.
We can close this branch as AFS and avisynth is no longer needed. Voukoder is very good! I will post short source and nvenc hevc encoded example in another branch of this forum which I have created for that.

[poisondeathray]

AE was a different company before. It has absolutely another engine.

Yes a long time ago, but how is that relevant now ?

At exactly the same time AVC lossless was fixed in PP, it was fixed in AE. The reason is they use the same decoder based on the Mainconcept SDK . They link to the same MC .dll and .dat files . The same is true for HEVC

AE only works in RGB, so the decoded frames are converted to RGB and you are comparing in RGB (the assumption is that they will convert in the same manner) , otherwise it's technicallly not "lossless" in AE with YUV sources

I think it is nvenc hevc issue.

It could be additionally, but it's definitely an Adobe HEVC lossless profile decoding issue in PP and AE. 100% certain

For NVEnc outside of Adobe - It might be you did not configure NVenc correctly , or they might be additional conversions going on in the pipe .

[qo4on]

Yes a long time ago, but how is that relevant now ?

Now AE can't handle 2 pass vbr for example. PP does that.
May be you are right. I'm going to check once again and show it in h265 forum branch.

[poisondeathray]

Yes a long time ago, but how is that relevant now ?

Now AE can't handle 2 pass vbr for example. PP does that.
May be you are right. I'm going to check once again and show it in h265 forum branch.

You're confusing DEcoding with ENcoding

When you are checking if something produced is lossless compared to the original , you are DEcoding.


Not all features of the SDK library are implemented the same way in all programs. Some advanced encoding options are not exposed to the user in PP, AME, or AE . Only the SDK has them. Adobe only licenses a small subset . If you want more features, you have to pay more