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 7 years ago

Still having the issue with it not using the limits I gave it. Could you verify if this is the correct order I should be applying the settings in? I can't seem to figure out why it doesn't work.

Init() gets called here.

MikhailAMD commented 7 years ago

Parameters and log look correct. I will be able to do the tests on Monday. Two questions for now:

  1. To confirm: did you get 54 MBits stream with 3.5 MBit setting?
  2. Please verify that you don't have performance delays in CPB mode that we saw before. Just out of curiosity: can you try the same with B-frames disabled? Thanks,
Xaymar commented 7 years ago
  1. Yup, I got a 54.4mbit/s stream with 3.5mbit setting. Same thing happens with VBR, only CQP and VBR_LAT seem to still work fine.
  2. I will need to wait for the RX to arrive before I can test that. On VCE3 I had no performance issues/Filler Data weirdness.

I will test with B-Pictures disabled once I have fixed some issues with Direct3D11 initialization.

Xaymar commented 7 years ago

Test with BPictures at 3

Test with BPictures at 0, BReference Disabled

Edit: Log file says that "Pre-Analysis Pass" is active, but I never set it in my code. Possibly just a logging error, wanted to make you aware of it though.

MikhailAMD commented 7 years ago

CBR developer provided following comment: in the log: VBV BuffSize: 58333 Vbv_buffer_size should be no less than peak_bitrate/frame_rate (3500000/60=58333.33333), please suggest them try vbv_buffer_size = 58400

Xaymar commented 7 years ago

Test - B-Pictures Disabled, VBV Buffer Size at 58400

Test - B-Pictures Disabled, VBV Buffer Size at 3500000

I don't understand why this happens. The log file shows the proper settings being applied, but for some reason they don't end up being used. Some users report that an older plugin version (1.3.3.1, which had set things wrongly) works though I find that to be rather strange.

Xaymar commented 7 years ago

Further reading through the logs sent in by users and produced by me reduced a weird inconsistency:

18:12:30.898: [VCEEncoderTrace]     Info: SetProperty TargetBitrate:3500000
18:12:30.898: [VCEEncoderTrace]     Info: SetProperty PeakBitrate:3500000
18:12:30.898: [VCEEncoderTrace]     Info: SetProperty FillerDataEnable:true
18:12:30.898: [VCEEncoderTrace]     Info: SetProperty MinQP:1
18:12:30.898: [VCEEncoderTrace]     Info: SetProperty MaxQP:51
18:12:30.898: [VCEEncoderTrace]     Info: SetProperty RateControlMethod:1
18:12:30.898: [VCEEncoderTrace]     Info: SetProperty VBVBufferSize:100705
18:12:30.898: [VCEEncoderTrace]     Info: SetProperty InitialVBVBufferFullness:64
18:12:30.898: [VCEEncoderTrace]     Info: SetProperty RateControlSkipFrameEnable:false
18:12:30.899: [VCEEncoderTrace]     Info: SetProperty EnforceHRD:true

...

18:12:30.902: [VCEEncoderTrace]     Info: <--------------------- Rate Control Params(-1) ----------------------------->
18:12:30.902: [VCEEncoderTrace]     Info:     RateCtrlMethod: 3
18:12:30.902: [VCEEncoderTrace]     Info:     Target bitrate: 3500000
18:12:30.902: [VCEEncoderTrace]     Info:     Peak bitrate:   3500000
18:12:30.903: [VCEEncoderTrace]     Info:     RCFrameRateNum: 60
18:12:30.903: [VCEEncoderTrace]     Info:     RCFrameRateDen: 1
18:12:30.903: [VCEEncoderTrace]     Info:     GOPSize:        0

Somehow the Rate Control Method is not being set properly. The exact reason (and why it only works on certain systems) still eludes me.

Edit: On some systems that line shows a 4 instead of a 3. I'm seriously lost now.

MikhailAMD commented 7 years ago

depend on which part of tracing you are looking rate control is in AMF enum or in internal enum, They have different values. AMF CQP = 0 internal = 0 AMF CBR = 1 internal = 3. AMF VBR_PEAK = 2 internal = 4
AMF VBR_LAT = 3 internal = 6 AMF logging is here: Info: SetProperty RateControlMethod:1 Internal values are reported just before sending them to the driver after this line. Info: <--------------------- Rate Control Params Compare what you set and what driver get in one log.

Xaymar commented 7 years ago

Log file matches what you said:

20:13:45.457: [AMF Encoder]   Method: Constant Quantization Parameter (CQP)
20:13:45.523: [VCEEncoderTrace]     Info:     RateCtrlMethod: 4
20:13:45.523: [VCEEncoderTrace]     Info: SetProperty RateControlMethod:0
20:13:45.624: [VCEEncoderTrace]     Info:     RateCtrlMethod: 0

20:13:53.545: [AMF Encoder]   Method: Constant Bitrate (CBR)
20:13:53.558: [VCEEncoderTrace]     Info:     RateCtrlMethod: 4
20:13:53.559: [VCEEncoderTrace]     Info: SetProperty RateControlMethod:1
20:13:53.660: [VCEEncoderTrace]     Info:     RateCtrlMethod: 3

20:14:00.628: [AMF Encoder]   Method: Peak Constrained Variable Bitrate (VBR)
20:14:00.690: [VCEEncoderTrace]     Info:     RateCtrlMethod: 4
20:14:00.690: [VCEEncoderTrace]     Info: SetProperty RateControlMethod:2
20:14:00.792: [VCEEncoderTrace]     Info:     RateCtrlMethod: 4

20:14:08.114: [AMF Encoder]   Method: Latency Constrained Variable Bitrate (VBR_LAT)
20:14:08.127: [VCEEncoderTrace]     Info:     RateCtrlMethod: 4
20:14:08.128: [VCEEncoderTrace]     Info: SetProperty RateControlMethod:3
20:14:08.229: [VCEEncoderTrace]     Info:     RateCtrlMethod: 6

Testing with the above revealed that all files but CQP are perfectly identical in terms of bitrate and setup. I will test with an earlier driver tomorrow and see if it is a regression in 16.10.3 and up, it's quite late here.

MikhailAMD commented 7 years ago

Please note than not all rate control modes are available on all HW. I will ask Monday for a table but you can get property description from AMF interface GetPropertyInfo() and use pEnumDescription to enumerate what is available on active HW. I checked, currently AMF does not validate vs available rate control modes and I plan to add this in the future.

Xaymar commented 7 years ago

Afaik CBR and VBR are available on all VCE 3 and 2 cards, as they worked fine with an older driver (16.9.2 + R9 285 = CBR that worked, it was only the RX 4xx series having trouble with CBR). Even VCE 1 cards and APUs had 0-issues with this until now. I will be waiting for your reply on monday and try to implement the GetPropertyInfo thing tomorrow.

MikhailAMD commented 7 years ago

I understand. Work from home today. Monday will test and bring rate control guy if needed.

Xaymar commented 7 years ago 
[AMF Encoder] Name: RateControlMethod
[AMF Encoder] Desc: Rate Control Method
[AMF Encoder] Type: 2
[AMF Encoder] Content Type: 0
[AMF Encoder] Min Value Type: 0
[AMF Encoder] Min Value Int64: 0
[AMF Encoder] Max Value Type: 0
[AMF Encoder] Max Value Int64: 0
[AMF Encoder] Default Value Type: 2
[AMF Encoder] Default Value Int64: 2
[AMF Encoder] Constant QP 0
[AMF Encoder] CBR 1
[AMF Encoder] Peak constrained VBR 2
[AMF Encoder] Latency constrained VBR 3

Quick & Dirty implementation, GetPropertyInfo and pEnumDescription show that all of them are there.

Xaymar commented 7 years ago

Some people report that it works on VCE2 cards while others report that it's completely random if it works or not. This couldn't get any more random if it tried to, could it?

Xaymar commented 7 years ago

Settings Tested

Driver 16.9.2 (Downgrade from 16.11.1)

Driver 16.10.1 (Upgrade from previous)

Driver 16.10.2 (Upgrade from previous)

Driver 16.11.2 (Upgrade from previous)

Test Setup

These tests would have been a pain without a portable test setup, so I have finally made one. It contains a fully configured profile and a mostly configured scene (may need to adjust the path for the Image Source to match wherever it extracted "noise.gif" to) and should easily produce files that show behaviour like the above on the right cards. "-1.3.3.1" is the old plugin version (that did things wrong) and "-1.4.1.1" is the new one (that does things a little bit better than before).

Starting each of the versions is as easy as double-clicking the Portable32/64.bat file, starting the recording and stopping it after a few seconds (5-10). Make sure to point the Image Source at the noise.gif though, otherwise it's cheating.

Download: http://cdn.xaymar.com/private/2016/11/OBS-Studio-Portable-Test.7z

Xaymar commented 7 years ago

I get similar results with VCEEncoderD3D:

>VCEEncoderD3D.exe -FRAMES 600 -HEIGHT 1080 -WIDTH 1920 -OUTPUT test.h264 -Usage TRANSCODING -Profile High -ProfileLevel 42 -QualityPreset Quality -FrameRate 60,1 -FillerDataEnable true -TargetBitrate 20000000 -RateControlMethod CBR
DX9: List of adapters:
          0: Device ID: 6939 [AMD Radeon R9 200 Series]
DX9 : Chosen Device 0: Device ID: 6939 [AMD Radeon R9 200 Series]
Start: 1 threads

 Average (Max, fr#) Encode Latency: 10.4 ms (22.7 ms frame# 0)
 Average (Max) Frame size: 1771 bytes (5069 bytes)
 Frames processed: 600 Frame process time: 10.4ms FPS: 95.8
 Average FPS: 95.8 Combined FPS: 95.8

D:\Software\SDK\AMD-AMF\amf\bin\vs2013x32Debug
> ffmpeg -i test.h264 -codec:v copy -codec:a copy -y "test.mp4"

Resulting file after file format conversion:

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.2
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 4 frames
Format settings, GOP                     : M=2, N=15
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 10 s 24 ms
Bit rate                                 : 848 kb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Variable
Frame rate                               : 59.859 FPS
Minimum frame rate                       : 25.000 FPS
Maximum frame rate                       : 60.000 FPS
Original frame rate                      : 60.000 FPS
Standard                                 : Component
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.007
Stream size                              : 1.01 MiB (99%)
Color range                              : Limited

Raw File: http://cdn.xaymar.com/private/2016/11/test.h264

I am out of ideas and things to test now, this problem doesn't make any sense to me. CBR and VBR worked when I had 16.10.2 installed, then I upgraded to 16.11.1 and things broken, but downgrading back to 16.10.2 does not fix the problem.

MikhailAMD commented 7 years ago

I tested most of GPUs I have with this portable OBS setup. It was really easy to use. I tested the latest public driver: 16.11.2 and I cannot reproduce CBR problem. All GPUs I tried produce 3.5 Mbit stream. I tried: Tonga (R9 285), Ellesmere (RX 480), Fiji (R9 Nano). With Hawaii (R9 390) VCE plug-in failed to start recording. The reason is that 390 doesn't support 5.2 profile level and the property failed to set. 5.2 level is needed for 4K only. For 1080p it should be 4.2. Check table for levels here: https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC. This should be easy to fix.

I repeated your command line for VCEEncoderD3D.exe on Tonga (R9 285) and got 25 MB file - not 1 MB you posted.

All this points to the driver installation. One thing I would like to confirm: sometimes driver installation cannot cleanly downgrade. There is a cleanup tool that should help: http://support.amd.com/en-us/kb-articles/Pages/AMD-Clean-Uninstall-Utility.aspx In any case it is recommended to check device manager and uninstall video driver versions one by one from there with deleting driver files option till you see Microsoft Basic Display (Adapter). And then reboot and install the driver you want.
Please try clean install of 16.11.1 or 16.11.2 (they are identical for VCE).

Xaymar commented 7 years ago

I tried the clean install steps you provided, however the results are still the same. CBR & VBR both ignore anything I tell it to do and it's unfortunately not just me that has this issue. I have also tried disabling the Intel GPU in the CPU and removing the drivers for those to see if that would help, that also didn't help.

I've asked Kytos (he also has this issue) to test with a clean Windows install, I'll hear back from him tomorrow afternoon/evening.

One question, the drivers don't reflash the GPU hardware right? I don't know how AMD hardware works internally, so this might sound stupid to someone who does.

MikhailAMD commented 7 years ago

Which OS do you have, is it Win10 with RS1 (Redstone) or without? In general, driver will check and update VCE firmware during boot time if needed. Depend on RS1 or not RS1 the firmware is located in different folder. I don't think Intel GPU can interfere. Can I access your computer via TeamViewer and check few things? If so let's contact tomorrow via Skype.

Xaymar commented 7 years ago

I have Windows 10 Pro 64-Bit with Anniversary Update "Redstone 1", winver reports Version 1607 (OS Build 14393.351)".

Can I access your computer via TeamViewer and check few things? If so let's contact tomorrow via Skype.

Sure, I have TeamViewer installed now.

Xaymar commented 7 years ago

With the help of @MikhailAMD we've found a way to fix one of the problems: It was a stale driver install/uninstall that didn't go through completely, possibly from Windows Update or similar. After removing this stale driver, VCE encoding worked as expected again.

Steps for a fully clean Driver install

  1. Uninstall the AMD Driver in Windows, make sure Device Manager says "Microsoft Basic Display Adapter"
  2. Reboot to Safe Mode (using DDU or any other means)
  3. If DDU was used, let it remove the driver stuff without restarting.
  4. Navigate to C:\Windows\System32\DriverStore\FileRepository in Explorer
  5. Delete any folders called c030.inf (* being anything) (there should only be one or two if DDU and Uninstall worked)
  6. Reboot to System
  7. Install latest AMD driver normally
  8. Reboot

As for the bitrate going way over the targetted bitrate, that is due to limits on how much a frame can be compressed. Enabling RateControlSkipFrame may help here.

Solution: Don't trust your driver to be actually uninstalled.

Benman2785 commented 7 years ago

with new driver still persists -> only fixed when i set minQP to 0 or 1 -> fix that please

Xaymar commented 7 years ago

Can't confirm that Benman. I have been testing all the reported issues on both my R9 285 and the RX 480 that Mikhail sent me and have only noticed one issue with VBV Buffer Size, which also doesn't happen all the time (1 in 10 chance that it happens).

Benman2785 commented 7 years ago

then pls set minQP to 20 (to reduce load on GPU) and try FillerData -> you will see its bugged

wazerstar commented 7 years ago

@Xaymar I contacted the DDU developer, he will look into ASAP why the c030 files/folders are not deleted while using his tool, and possible make an update ;)

Xaymar commented 7 years ago

@Benman2785: then pls set minQP to 20 (to reduce load on GPU) and try FillerData -> you will see its bugged

You don't reduce the load on the GPU by increasing Min QP, you only reduce PCI-E bandwidth requirements. And most often your frames will never go below a QP of 18 anyway. The only thing you tell AMF that way is "fuck my quality up, i want as little data as possible" which only works by compressing more (which has a negative impact on performance). To quote what Mikhail told me: AMF does not make any adjustments to user settings - errors in the configuration will be used as is.

I used your own tool to "analyze" a recorded file, the bitrate is completely fine:

R9 285 image

RX 480 image

If you want me to test further, do upload a log with a recording attempt in which it actually happens and post it on the plugins issue tracker instead of here.

@wazerstar: @Xaymar I contacted the DDU developer, he will look into ASAP why the c030 files/folders are not deleted while using his tool, and possible make an update ;)

That's great to hear.