search

GPUOpen-LibrariesAndSDKs / AMF

The Advanced Media Framework (AMF) SDK provides developers with optimal access to AMD devices for multimedia processing
Other
597 stars 149 forks source link

Constant Bitrate ignores given Target Bitrate and Filler Data constraints. #18

Closed Xaymar closed 7 years ago

Xaymar commented 8 years ago

For an unknown reason, AMF currently fails to properly meet the given Target Bitrate on a number of cards. Mostly affected by this are VCE3.x based cards, like the R9 285, R9 380 and the RX 4xx series.

The bitrate will always be lower than needed or be way above the target, which makes streaming hard if not impossible.

System Information

Reproduction Data

1. Dump Files

2016-11-02 Bitrate Problem returns on R9 285

2016-11-03 (20mb/s instead of given 3500kbit/s)

Xaymar commented 8 years ago

It seems that AMF decides to go for a lower overall bitrate in darker areas, instead of increasing the bitrate for those - which leads to drastic quality loss for those areas or games.
Edit: A perfectly black frame will result in a bitrate near 50kbit/s for 1280x720. Ouch.

I tested out a few changed but none really changed things - it would always either go below target bitrate or above: https://r-1.ch/analyzer/results/xaymar.e34745

Xaymar commented 8 years ago

This also applies to Variable Bitrate with a Peak restriction. It will never meet the target bitrate if the frame is too dark or there is little going on.

MikhailAMD commented 8 years ago

Variable Bitrate with a Peak restriction works as expected. It will not guarantee to reach target because there is no filler data. We confirm that CBR with filler data doesn't work correctly on VCE3. Earlier versions are OK. The fix will be in the driver package and will follow shortly.

Xaymar commented 8 years ago

We confirm that CBR with filler data doesn't work correctly on VCE3.

Does that mean that a R9 290, R7 370 and a RX 480 are all VCE3? Users on these cards have reported the issue to me, which I was able to reproduce on my R9 285 too without any issues.

It's good to see that it can and will be fixed.

MikhailAMD commented 8 years ago

check the list here: https://en.wikipedia.org/wiki/Video_Coding_Engine

Xaymar commented 7 years ago

Pinging this issue again as it was not fixed in 16.9.2. When can we expect to see a working version?

Benman2785 commented 7 years ago

Hi - found out that the ONLY non-changeable variable is minQP 1 -> all others can be changed and still uses CBR (even when its not that correct in terms of set bitrate - but has not that "up n down bitrate" behaviour)

Xaymar commented 7 years ago

CBR works like a charm in 16.9.2, no issues anymore.

MikhailAMD commented 7 years ago

Not so fast. We did find a problem with filler data. The meaningful bits are OK. Please test the upcoming next public driver (hotfix). Thanks, Mikhail

Xaymar commented 7 years ago

I will once it's out. What should I look out for? Is it a card specific error with Filler Data?

MikhailAMD commented 7 years ago

You should see very steady bitrate with CBR on RX480. On black areas or in general on low information areas encoder adds filler data with zeros to the encoded frame. They don’t have meaningful bits but are important for certain streaming types and certain decoders.

Mikhail

kytos22 commented 7 years ago

CBR + filler data isn't stable at this moment on my rx480. I'll try the next driver update.

Xaymar commented 7 years ago

It seems to have been fixed by 16.10.1 now. Waiting for more reports that it was fixed before closing it again.

MikhailAMD commented 7 years ago

Yes, the fix is in. Take your time to verify.

Mikhail On Wed, Oct 05, 2016 at 3:55pm, Michael Fabian Dirks notifications@github.com<mailto:notifications@github.com> wrote:

It seems to have been fixed by 16.10.1 now. Waiting for more reports that it was fixed before closing it again.

You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/18#issuecomment-251823196, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AOcWv8tP17c9Z4RXhdlyatw9Ro4IZi2Aks5qxCrngaJpZM4J6Fco.

kytos22 commented 7 years ago

Hi, I've noticed some variances in the bitrate going from 8600 to 12000 Kbps when the Bitrate setting is 10000 Kbps CBR + Filler data (RX480). This happen sometimes at the start of the streaming and a few times latter. I don't know if this is a issue but I want to keep you informed. In practice I can stream now with a stable bitrate.

Benman2785 commented 7 years ago

@M4RK22 use my settings provided at https://github.com/Xaymar/OBS-AMD-Advanced-Media-Framework/issues/90 and change to disired bitrate + calculate strict VBV Buffer (bitrate/FPS*10-1 = Buffer)

@MikhailAMD "minQP 1" is still forced when using CBR -> without it the problem still persists in 16.10.1

xaymar_obs_amd_amf_1 3 3 1-cbr_3400kbps here u see it still persists in 16.10.1 (but is much better then before)

Xaymar commented 7 years ago

There are still reports of RX 4xx having trouble with CBR and Filler Data. Bitrate seems to ignore Filler Data or Target Bitrate at times.

MikhailAMD commented 7 years ago

if you want strict flow of the data please set VBV buffer size to bitrate/FPS. Please verify that users got the latest driver (16.10.1). The glitches maybe related to the performance issue in CBR we are still investigating. Please note that VBR doesn't have performance issues.

Benman2785 commented 7 years ago

@MikhailAMD but setting VBV to Bitrate/FPS is "to strict" - better is Bitrate/FPSx10-1 // but i will test it and say if its working

Xaymar commented 7 years ago

Only rare cases where fillerdata gets added to the second after the one where it should have been in remain, but those are probably due to encoding stress. I'll close this as resolved on my end.

Benman2785 commented 7 years ago

when there is no movement and a mostly black screen the FillerData doesnt work properly -> i can upload footage of this

Benman2785 commented 7 years ago

3400kbps_fillerdata-bug_persists http://benmanshafen.de/pics/OBS/Xaymar/3400kbps_FillerData-Bug_persists.mp4 (160mb)

here u have video and you see the problem in picture

Xaymar commented 7 years ago

Update to the latest 16.10.1, check "Debug Tracing" in the plugin and then upload a video and log file.

On Oct 20, 2016 10:20, "Benman2785" notifications@github.com wrote:

[image: 3400kbps_fillerdata-bugpersists] https://cloud.githubusercontent.com/assets/21282980/19552101/ad569962-96ae-11e6-8482-2042b7c726bb.jpg http://benmanshafen.de/pics/OBS/Xaymar/3400kbps FillerData-Bug_persists.mp4

here u have video and you see the problem in picture

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/18#issuecomment-255040189, or mute the thread https://github.com/notifications/unsubscribe-auth/AAask9W4JbiylHYYWVE3fz8qvev0uIUYks5q1yQ5gaJpZM4J6Fco .

Benman2785 commented 7 years ago

will be uploaded in 30min

Benman2785 commented 7 years ago

still persists - and worse -> it PEAKS hard now "to maintain bitrate over time" - instead of dropping "bitrate" to hit 3500kbps

3500kbps_fillerdata-bug_persists

3500kbps_FillerData-Bug_persist_log.txt

http://benmanshafen.de/pics/OBS/Xaymar/3500kbps_FillerData-Bug_persists.mp4 (160mb)

Xaymar commented 7 years ago

Total still looks okay, it just moved all the data from what should have been there to when it could push them out. Make sure that your system is not overloaded during encoding, as it is the case here.

Benman2785 commented 7 years ago

what you men with overloaded? i just have 8gb RAM -> will upgrade soon

with CBR it shouldnt peak that much - because this will result in dropped frames at twitch or even youtube (when its that high)

when u check video + timestamps u see that there is a nearly black screen with no movement -> so fillerdata is buged and doesnt fill up bitrate-target and then pushes them out on next GOP after more data appears -> its a bug

so it needs to be fixed

Xaymar commented 7 years ago

No it doesn't because it's not a bug. It's your system being overloaded (too slow, too much workload at that time, etc). It has nothing to do with RAM.

Edit: Try using Compute Type OpenCL with Memory Type DirectX 9 or DirectX 11. It should help with this.

Benman2785 commented 7 years ago

ah - ok -> but that peak doesnt occure in 16.9.2

my cpu loaded new stage of game -> its impossible to avoid that -> so its still a bug btw its just 60% load on CPU when "no fillerdata bug" was just peaked to 100% CPU as GPU send "peaked bitrate" into recording u can watch load of computer in left corner

CKannas commented 7 years ago

@Benman2785 are you using the 32-bit version of OBS? Because is listing only 2GB of ram and OBS Version -> OBS 0.16.2 (windows), while just looking some logs from my system is states OBS version -> OBS 0.16.2 (64bit, windows).

Tip: You can add the CoreAudio AAC encoder in you OBS by installing some parts of iTunes google it and you will find how to do it. They say it is better than windows AAC encoder.

On 20 October 2016 at 14:17, Benman2785 notifications@github.com wrote:

ah - ok -> but that peak doesnt occure in 16.9.2

my cpu loaded new stage of game -> its impossible to avoid that -> so its still a bug btw its just 60% load on CPU when "no fillerdata bug" was just peaked to 100% CPU as GPU send "peaked bitrate" into recording u can watch load of computer in left corner

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/18#issuecomment-255078203, or mute the thread https://github.com/notifications/unsubscribe-auth/ADj_Sm0GieiBNlAKqEudkcO19P4YJSu6ks5q102tgaJpZM4J6Fco .

Xaymar commented 7 years ago

I took a look at your video upload:

Overall, nothing is wrong with the file or CBR - it did what it should have done.

Benman2785 commented 7 years ago

@CKannas - i have an different AAC Codec (i think) from dB PowerAMP i use 32Bit version of OBS because my Webcam has only 32bit driver -> in OBS classic 64bit i had problems with 32bit drivers -> so i stick 2 use 32bit OBS

@Xaymar thank you - but i cant believe that a peak of 16000kbps is normal with CBR due to limitations of most bitrate-limited streaming servers and it adds up bitrate after a scene with no movement and nearly black screen -> it SHOULDNT peak after that (and better use FillerData to avoid that peak) (german: bei CBR sollte der Peak nicht sostark ausfallen nach schwarzem bild -> sonst geben streamingserver dropped frames aus -> ergo muss das gefixt werden // entweder baust du ein maxPeakLimiter von 4/3 Bitrate max ein oder AMD fixt das im AMF)

Xaymar commented 7 years ago

You're recording to a file, muxing is different for files than for streaming. Streaming enforces stricter rules, while recording can mux video, audio and whatever however it wants - as long as it's in order. You shouldn't see this happening while streaming, so you should try streaming first - if it occurs there, then it's a problem.

Benman2785 commented 7 years ago

i will try streaming now - (on my own server - and tell u then)

oh and i use streamencoder for recording

EDIT: tested -> still peaks while streaming & recording -> also FillerData bugs when no movement and nearly black screen -> just had 300kbps show in bitrate counter then

EDIT2: if u want i set my streamserver to record my streams -> will send you the file then (and analyse it also for myself - but its flv)

EDIT3: i know its not "your fault" but its annoying and should be fixed by AMD to maintain a proplery working CBR for streams to twitch or youtube (or other sites with limited bitrate)

Benman2785 commented 7 years ago

still does that while streaming -> so streaming to most platforms not possible -> because you will have drops

stream-1476968574 http://benmanshafen.de/pics/OBS/Xaymar/stream-1476968574.flv (68mb)

Xaymar commented 7 years ago

Try 16.10.2 Hotfix, it might help.

Xaymar commented 7 years ago

I took a look at the log file, here is what you're doing wrong:

  1. You're using the Advanced Interface, it is not supported.
  2. Memory Type is set to DirectX11 without OpenCL Compute Type, this can have severe performance effects.
  3. You've changed Maximum Long-Term Reference Frames to 1, keep it at 0.
  4. Peak Bitrate is 10000, it is not recommended to override this when using CBR.
  5. Minimum QP and Maximum QP are wrong for CBR, Minimum QP should be 0 and Maximum QP 51.
  6. GOP Size is set to 15 frames - this is extremely experimental, never change it unless you're prepared to see issues.
  7. CABAC has been Enabled - this is extremely experimental, never change it unless you're prepared to see issues.
Benman2785 commented 7 years ago

1-3 - ok -> will change that 4 - why is that? because peak bitrate is added to "normal" Bitrate nearly all the time -> so it wont work properly when streaming to twitch 5 - minQP 1 is a BUG of new AMD AMF -> has to be fixed -> when 18 or 20 you save bitrate for high-movement scene in h264 // maxQP 51 looks bad -> so i stick using 42 (as this wont produce peaks even on high movement scenes in 720p when min 3000kbps) 6 - GOP 15 is recommended for YT when rec/stream in 30 FPS -> so would be nice if this wont be experimental anymore 7 - we need CABAC to handle CBR right with low Bitrate

will try hotfix now and send links to orginal files ;)

Xaymar commented 7 years ago

GOP Size and CABAC are not official VCE/AMF options. They are the result of reverse engineering. Do not use them.

Benman2785 commented 7 years ago

same problem with 16.10.2 Hotfix at 2:13 you can see it clearly drops frames -> would suck when i stream this to twitch stream-1477038232 stream-1477038232.txt http://benmanshafen.de/pics/OBS/Xaymar/stream-1477038232.flv (150mb)

oh i noticed stutter when activate OpenCL -> in OLD VCE build OpenCL (OVE) was replaced with AMD AMF for NV12

EDIT: will test now with "simple" instead of advanced settings

Benman2785 commented 7 years ago

with simple: Bitrate 3500 CustomBuffer 116 FillerData Enabled MemoryType DX11 Compute Type OpenCL no custom GOP CABAC default

still same problem - and it also drops frames now (when high peak occure) while streaming

stream-1477039980 stream-1477039980.txt http://benmanshafen.de/pics/OBS/Xaymar/stream-1477039980.flv (130mb)

also noticed 1% more CPU load on average and my GPU also has more load -> peaks to 100% and wont hold max Boost everytime (what she did with advanced settings and 16.9.2)

Benman2785 commented 7 years ago

tested with old game - peak has nothing to do with high load on CPU or GPU -> as i said before it occures when there is nearly black screen with no movement -> then FillerData bugs and result in low bitrate and later high peak - and now with 16.10.2 in dropped frames

stream-1477041730 http://benmanshafen.de/pics/OBS/Xaymar/stream-1477041730.flv (201mb) stream-1477041730.txt (scroll down after settings - had some probs capturing old game properly

MikhailAMD commented 7 years ago

The fix for filler data bug is in testing. I am trying to push it into the earliest possible release. Stay tuned.

Benman2785 commented 7 years ago

still persists in 16.10.3

after install and reboot i could do it once without bug -> now it always bugs (ever) since

MikhailAMD commented 7 years ago

I will send a note when the fixes are available.

Xaymar commented 7 years ago

For tracking purposes, I'll keep this open.

Xaymar commented 7 years ago

I have updated the original report with more information. I'm not sure why, but Filler Data seems to be broken on my R9 285 again with driver 16.10.3, but that might just be a temporary problem.

Edit: A change to before is that now I have an Intel IGP. This could perhaps be the cause for strange issues if this case isn't treated properly.

Edit 2: Tested with 16.9.2, IGP disabled and an older plugin version, same issue. Filler Data is being ignored for some weird reason.

Xaymar commented 7 years ago

Both CBR and VBR seem to be broken completely in 16.10.3 now. I will need additional people to test, but right now AMF encoding is pretty much useless except for recording - and even there it seems to start showing issues with random permanent encoding freezes until reboot.

Xaymar commented 7 years ago

16.10.3 seems to be the the Driver that breaks CBR on some cards again. I have implemented all the changes suggested in the VBR issue too but they had little effect here.

Result: 20mb/s instead of the set 3500kb/s, Filler Data and Target Bitrate are being ignored again.

MikhailAMD commented 7 years ago

The fix should be in the release hot fix driver: 16.11.1 http://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-Crimson-Edition-16.11.1-Release-Notes.aspx