OBS branch with AMD VCE support.

laistrogian

New Member
So far, running 720P 30fps on 3K / 3.5K bitrate is fine for me. However, i tried running 720P 60FPS on 3.5K bitrate but the bitrate would just spike all the way to 20-40K bitrate and then the OBS would crash immediately.

I'm running 7850 2GB with i5 3350 with CBR & CBR padding on
 

quickshot101

New Member
Everything seems to be working for me as I said in my earlier post. If you need anything tested just give me a shout. Hoping to see a update soon :)
 
Has there been any tests comparing VCE 1.0 to 2.0.
I am quite interested in the difference.

I would also like to know how it compared to x264 SuperFast
 

laistrogian

New Member
In the meantime while im trying to repro crashes, it looks from your log it may still hang when rtmp is flushing buffers. Try this.

I tried the version that you linked, it's the 32 bit version right?

Tried running it again and still got crashes. I ran it 3.5K bitrate 720P 60FPS with MFT turned on. It's weird because if i run those settings in 30FPS it's fine but in 60 fps, the bitrate would go higher than i what i set the max and then it would eventually crash

Crash log
Normal log
Dump file
 

jackun

Developer
Yeah, MFT is extra crashy currently for some reason. Just disable it, then it uses older OpenVideo API.
My test cap. Sheesh, like a CGI movie.
@Jarod, valley demo shows you have R9 290, well, that is a VCE 2.0 card :P

E: MFT crashes because List<T> copies DataPacket struct only :P Then you get 2 output frames and previous frame data gets Clear()'ed. Oops.
 
Last edited:
Here is a comparison of VCE vs x264, ( i guess it's VCE 2.0 as jackun says, but i can't find it saying R9 290 anywhere).

AMD VCE 3200bitrate
uc

x264 VeryFast 3200bitrate
uc



The difference in quality is quite huge, even on VeryFast, i am guessing it's on par with SuperFast or perhaps UltraFast.

This probably depends on the Quality settings of AMD VCE as well, as i guess it must have some sort of "Presets" to control the quality?
 
Last edited:

vbdkv

Member
Hardware encoding will never be as good looking as software encoding. Well, never is maybe pushing it, but so far it's far behind. That's why I dont use GPUs to encode my videos :)
 

seronx

New Member
Hardware Encoders after a certain bitrate are indistinguishable from Software.

Realtime performance is better with HW. Really good for streaming at screen resolutions above your CPU can handle.
Archival performance is better with SW. Really good for compressing already existing files to much higher compressions.

AMD VCE "Lossless" -> x264 Software "Medium <-> Very Slow" = Really good archival performance.
Capture -> VCE -> Broadcast = Really good stable realtime performance for much lower CPU usage.


slide-5-1024.jpg

AMD gives off good examples for all three solutions. Except, AMD VCE isn't just a FFHW and has a second mode which is FFHW+GPU. Which will be used for x265/h265 encoding/decoding examples from Media SDK 1.1 Beta later this year.

---

VBR (Speed) works with 1080/60p, it is pretty close to VeryFast at 6000 kbps.
 
Last edited:
I know that SW and HW isn't comparable in quality at the same settings. The point however is, Can you make it transparent enough, at a good enough bitrate.

For me that would mean, can it beat SuperFast x264 at about 40-60mbps, if it can, it's a winner:)

AMD VCE "Lossless" -> x264 Software "Medium <-> Very Slow" = Really good archival performance

Wait, does AMD VCE has a lossless mode?
And i guess it's not lossless from your writing, and simply at the extend to compare to x264 at medium?

Do you mean that VCE is very slow at this, no 30fps at 1920x1200;P?

VBR (Speed) works with 1080/60p, it is pretty close to VeryFast at 6000 kbps.

What happens at lower bitrate (i guess it loses more?
If so, what happens at higher bitrates?

I am very interested in very high bitrates, as i got a lot of bandwidth to spare, so around 50mbps is completely possible in terms of size for me.


AMD gives off good examples for all three solutions. Except, AMD VCE isn't just a FFHW and has a second mode which is FFHW+GPU. Which will be used for x265/h265 encoding/decoding examples from Media SDK 1.1 Beta later this year.

This is what i am a bit confused about, according to the Mantle stress test, performance of the FFHW is degraded as the GPU usage increases, i doubt it's a bug in the driver, as the GPU and FFHW should be separated anyhow.
Which makes this degration impossible?

So wouldn't that mean that the FFHW is currently using the GPU?

(x265, god it will take a Long time to see that in realtime, and it's Far from comparable to x264 in quality now, except Extremely Low birates (1k bitrate for 4k and stuff like that).
 

jackun

Developer
Wait, does AMD VCE has a lossless mode?
And i guess it's not lossless from your writing, and simply at the extend to compare to x264 at medium?

Do you mean that VCE is very slow at this, no 30fps at 1920x1200;P?

Every setting set to max quality, VCE runs about 40+ fps and fastest some 80+ fps at 1920x1080.
So QuickSync seems to be fastest of the bunch.
 
Hmm, i guess it can run at 30fps+ on 1920x1200 then, as it's fairly close and should only differ by 5 fps or so at best.

QuickSync idd seems to be the faster, but it also seems to have the worst quality (at least compared to Nvidia, don't know about VCE).


Can you record 1080p (or 1200p if you have that resolution), and have like 30-40mbps and max settings?

Thanks
 

seronx

New Member
I know that SW and HW isn't comparable in quality at the same settings. The point however is, Can you make it transparent enough, at a good enough bitrate.
Other than NVENC's green-blur in the lower part of the screen yes you can make it transparent.
Wait, does AMD VCE has a lossless mode?

And i guess it's not lossless from your writing, and simply at the extend to compare to x264 at medium?

Do you mean that VCE is very slow at this, no 30fps at 1920x1200;P?
Lossless mode = "--qp 0", the reason to use this mode is the lower latency capture. VCE can directly receive the displayed image from the GPU's display controller.

If you want to archive transparently with the least amount of space used x264 software is the best bet. If you want to broadcast with the highest realtime performance then you want VCE, QuickSync, NVENC.

VCE Hybrid with x264 or x265 controls isn't out yet so I can't confirm if archival performance is better with more units.
What happens at lower bitrate (i guess it loses more?
If so, what happens at higher bitrates?

I am very interested in very high bitrates, as i got a lot of bandwidth to spare, so around 50mbps is completely possible in terms of size for me.
Higher Bitrate = closer to lossless
Lower Bitrate = closer to blurcity
This is what i am a bit confused about, according to the Mantle stress test, performance of the FFHW is degraded as the GPU usage increases, i doubt it's a bug in the driver, as the GPU and FFHW should be separated anyhow. Which makes this degration impossible? So wouldn't that mean that the FFHW is currently using the GPU?
It is probably has something to do with the PCIe interconnect bus and logic not with the FFHW.

---
I did an oops in my OBS VCE test, I went with 6 mbps + 6 mbps buffer. When it is more recommend to use a 6 mbps + 0.1 mbps buffer because VCE is really really low latency. This is probably why the encoder when it hit 12-15 mbps in a second said "Encoder is taking to long."
 
Last edited:

Jarod

New Member
@Jarod, valley demo shows you have R9 290, well, that is a VCE 2.0 card :P

Nope. It says, R9 200 Series, and something about the human brain reads that as 290. Yeah, I've given it a double take a couple of times now. I am testing with an Gigabyte R9 280X.

This is what i am a bit confused about, according to the Mantle stress test, performance of the FFHW is degraded as the GPU usage increases, i doubt it's a bug in the driver, as the GPU and FFHW should be separated anyhow.
Which makes this degration impossible?

So wouldn't that mean that the FFHW is currently using the GPU?

I've been curious about this. During the original media release back in 2011, there were many reports about the operation modes of VCE; one mode worked using only the dedicated encoder hardware, and the other mode used GPU compute for part of the encode process.

Yet I see nothing that definitively switches between the covered modes. Not sure if it was something that was made up in the mind of AMD marketing or what...

It is probably has something to do with the PCIe interconnect bus and logic not with the FFHW.

I'm leaning this way too, but the doubt lingers.

It was my intention this weekend to do a commit that mitigated the absurb CBR bitrate spikes by proactively dropping frames when encoding latency increased. Instead, I spent the weekend replacing storm doors. Such is summer.
 

seronx

New Member
I've been curious about this. During the original media release back in 2011, there were many reports about the operation modes of VCE; one mode worked using only the dedicated encoder hardware, and the other mode used GPU compute for part of the encode process.

Yet I see nothing that definitively switches between the covered modes. Not sure if it was something that was made up in the mind of AMD marketing or what...
https://github.com/jackun/openencodevfw/tree/master/samples

Line 6: "EncodeMode 1 // 0 - OVE_MODE_NONE, 1 - OVE_AVC_FULL, 2 - OVE_AVC_ENTROPY"

http://images.anandtech.com/doci/5261/VCE.jpg
The yellow boxes are what are done on the GPU with "Entropy mode."
 
Higher Bitrate = closer to lossless
Lower Bitrate = closer to blurcity
That much i know;P

What i meant was, does the difference (The gap between efficiency), get higher at higher bitrates, or lower?

Meaning, does 30mbps x264 vs VCE look closer than 3mbps?

I know QuickSync loses more and more the higher bitrate, i think it loses extremely fast at like 12mbps or something like that.

Yeah, Entropy mode never worked during my testing. Settles that I guess.
I read the article but there was only 2 modes, Full = Only dedicated hardware encoder,
Hybrid = Let the GPU do calculations that's fitted for it.

What does Entropy mode do?
 
Top