This Page states that Polaris supports VP9 encoding. When will we have an interface to use this type of encoding? Will it be even longer than the wait for HEVC?

Edit: Does Polaris actually support encoding VP9 or just decoding?

32-Bit:

10:32:11.675: [AMF Encoder] <Plugin::AMD::AMF::AMF> Loaded 'amfrt32.dll'.
10:32:11.676: [AMF Encoder] <Plugin::AMD::AMF::AMF> Runtime is on Version 1.0.3.0

64-Bit

10:33:03.606: [AMF Encoder] <Plugin::AMD::AMF::AMF> Loaded 'amfrt64.dll'.
10:33:03.607: [AMF Encoder] <Plugin::AMD::AMF::AMF> Runtime is on Version 1.3.0.4

SDK Version is 1.3.0.5 so there is something weird here.

Hi,
three questions:

1. last week release of Relive game capture tool slides, mention that no current AMD GPU support capturing games at 4k 60hz only 4k 30fps maximum on Fiji and Polaris.. is that due to limitation of HW or AMF framework or the Relive tool by itself? i.e. AMF supports 4k 60fps encoding (either HEVC or H264) on current Polaris HW? if not hope upcoming Vega GPU supports that use case..
2. also from Nvidia recieved mail "DesignWorks December 2016 Release" saying new codec sdk and
   Nvidia capture sdk releases:
   *Codec SDK supports already 10bit color with HEVC codec and mentions "H264 ME only mode" seems used for Oculus spacewarp but nice to expose also for developers wanting to use it..
   *Capture sdk "Version 6.0 focuses on NVFBC improvements including, improved capture times, stereo support, and 10-bit ARGB and HDR support for Pascal based GPUs. Available early 2017"
   so question is easy, how about all this features in AMF:
   can explitily mention for every A),B),C) what is current status: existing support, planned/upcoming support, no ETA support..
   A)HDR encoding support (i.e. 10 bit color depth) and also support for Relive tool.
   Please route request to Relive devs of once this supported allow uploading as "Youtube HDR" videos..
   B)Stereo encoding support
   C)H264 ME only?

Thanks..

I'm trying to add proper multi-GPU support to my plugin, but currently fail to actually do this. My attempt right now is to create a DirectX11/DirectX9/OpenGL device, initialize the amf::AMFContext with it (InitDX11/InitDX9/InitOpenGL) and then use CreateComponent and GetCaps to get the device capabilities.

This doesn't work as expected, as it will always output the capabilities of the primary GPU - which is not what I need or want.

Is there an example that shows how to do this properly? Or is this not yet possible?

As I now have a system with multiple GPUs and an internal GPU, I wanted to add this feature to my encoder plugin. However, I couldn't yet figure out how to do this properly.

1. For InitDX9, InitDX11 and InitOpenGL**

Do I have to create a proper DirectX/OpenGL context for the encoder to use or is there a simpler way to do this?

2. For InitOpenCL

I saw that there is a class called AMFComputeFactory which can be used to gather AMFComputeDevices. However I saw no way to read out the device id as a human readable name.
Do I have to create a custom openCL context for this as well?

Any help is greatly appreciated.

I do not see any reference to H265 or HEVC in the code or an example on how to encode with it, only a decoding example. Is this still missing or did I just miss the one line that has it?

AMFInit_Fn init = GetProcAddress(hAMFDll, AMF_INIT_FUNCTION_NAME);

should actually be

AMFInit_Fn init = (AMFInit_Fn)GetProcAddress(hAMFDll, AMF_INIT_FUNCTION_NAME);

With AMD Media SDK 1.1 was samples to Direct encode mode that allow encode video card buffer without passing directx or opengl frames.
In new sdk i just found few constant about DEM and no more

Using SubmitInput and QueryOutput cause high CPU usage, much more than the old Media SDK had with the same setup. Where Media SDK would sit nicely at 3-4%, AMF SDK shoots up to 10-12% (7-8% extra).

Previously: This is an issue that was already present in Media SDK, where it would only affect SubmitInput. Now it is also affecting QueryOutput, which will seemingly get stuck.

On Page 11 of the AMF_Video_Encode_API.pdf the RateControlMethod is described to have the following options:

• CQP – Constrained QP,
• CBR - Constant Bitrate,
• VBR - Peak Constrained VBR,
• VBR_LAT - Latency Constrained VBR

However in the API headers the following constants are defined in the AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_ENUM:

    AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CONSTANT_QP = 0,
    AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CBR,
    AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_PEAK_CONSTRAINED_VBR,
    AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_LATENCY_CONSTRAINED_VBR

So is the first option called Constant or Constrained QP?
For my project I need to dynamically control the QP of the encoder. Is the first control method the right one to choose for this job (according to the docs QPI, QPP and QPB are only applied if this mode is choosen)?

Right now ->GetPts returns the Decode Timestamp, which in turn means that I have no idea what the presentation timestamp is supposed to be. If I send in let's say 60 frames with keyframes every 60 frames and the current frame index set as a custom property will I get the proper presentation timestamp by retrieving that property?

Example:

Frame:   0 1 2 3 4 5 6 7 8 9 ...
Output:  I P B B B P B B B P ...
Decode:  I P B B B P B B B P ...
Decode:  0 1 2 3 4 5 6 7 8 9 ...
Present: I B B B P B B B P B ...
Present: 0 2 3 4 1 6 7 8 5 - ...

Reported by quite a few users, it seems that setting B-Pictures to anything but 0 causes severe flickering artifacts or even makes the output outright unwatchable. It only affects VCE 2 cards, VCE 3 cards have no issues like this at all.

Examples:

• 1st Example: https://www.youtube.com/watch?v=bOvXzNpiobg (first part before the black screen)
• 2nd Example: B-Pictures at 3, B-Pictures at 0, Log File

Graphics Driver crashes for no apparent reason, rendering SubmitInput to do exactly nothing and QueryOutput to return AMF_REPEAT. Might be related to #22.

Happens with any Memory Type, including with and without OpenCL. Occasionally a BSOD is going to happen with the message THREAD_STUCK_IN_DEVICE_DRIVER.

My System Specs:

• MB: ASRock 970 Pro3
• CPU: AMD FX-6100 (Stable 4.0 Ghz, tested with Prime95 over 8 hours)
• GPU: AMD R9 285 (ASUS Radeon R9 285 Strix OC DirectCU II)
• HDD: 2x Seagate 2TB 7200rpm
• Windows 10 64 Bit (Auto-updated, Anniversary Update is installed)

Dump Files:

• http://cdn.xaymar.com/private/2016/09/DriverCrash_16-9-2_obs64.7z

Developer Community: https://community.amd.com/message/2751281

The documentation says that some parameters are only available when MaxOfReferenceFrames is greater than 1. There is no such parameter in VCECaps though, so how do I query this?

The closest I found is:

• AMF_VIDEO_ENCODER_CAP_MIN_REFERENCE_FRAMES
• AMF_VIDEO_ENCODER_CAP_MAX_REFERENCE_FRAMES

For my card, it returns 1 - 16. For a VCE 1 card it also returns 1 - 16 but AMF_VIDEO_ENCODER_CAP_BFRAMES is 0. Is this a driver bug?

A user of my plugin found out how to reproduce a long standing issue with streaming to Twitch that caused "screen corruption" (best way to describe it, similar to #15 files). I'm not sure what exactly AMF_VIDEO_ENCODER_DE_BLOCKING_FILTER does when it's off, but it seems to break some sort of rule in h264 encoding. I'll quote it here:

EDIT: @Xaymar I think I've replicated the issue. As soon as I disable the Deblocking Filter, I get the same weird green pixelation and distortion. When I enable it again, the issue is resolved. I'm still using pre7.

Example: https://www.twitch.tv/bgshiny/v/87384175

On Page 11 it says

IDRPeriod, 0 ... 1000, Sets IDR period. IDRPeriod= 0 turns IDR off

It should actually say 1000*FrameRateDen (like before in Media SDK) and 0 doesn't turn IDR off, it creates exactly one IDR frame (at the beginning).

This took a while to track down, mostly because it is so insanely rare to reproduce - in my 14 tests, it happened 3 times and it seems heavily dependent on instantaneous GPU load. Since it was so incredibly difficult to reproduce, I don't yet have a log or dump file with AMF trace active.

I used actual game footage to produce this issue, since my attempts with pre-rendered footage didn't seem to cause it at all. It's possible that this only happens in very extreme GPU usage situations. I will continue trying to reproduce it more accurately.

Files

2016-11-21

• Portable Test Setup: http://cdn.xaymar.com/private/2016/11/2016-11-21_Issue44_PortableRepro.7z (Also contains log files of earlier tests)
• Example Video Files: http://cdn.xaymar.com/private/2016/11/2016-11-21_Issue44_ExampleVideos.7z

Test setup needs to have the Game Capture pointed real world use case footage like games or benchmarks (Ashes of the Singularity for example).

Basically what the title says. People have been asking for HEVC and Two Pass support for a while, and the ReLive driver launch seems to promise exactly that support - at least for the recording tool inside Radeon Settings.

I couldn't find it being mentioned anywhere in the AMF_Video_Encode_API.pdf, so what does it do? The first parameter seems to define the surface format - which can again be defined in the actual surface itself. Since VCE always outputs 4:2:0 Partial (even though Full would be nice to have), what's the point of this parameter? Is it even used?

I didn't check with reverse engineering yet, since I haven't yet managed to fully reverse engineer the wrapper classes.

When AMF_VIDEO_ENCODER_B_REFERENCE_ENABLE is set to true, the log file will show the following:

12:40:43.297: [VCEEncoderTrace]     Info:     encBPicPattern: 3
12:40:43.298: [VCEEncoderTrace]     Info:     disableBRefere: 1

Needless to say, that is wrong since BReference is enabled.

It seems that bitrate detection is not done properly for dark frames, making these basically a block-hell. Possibly needs #2 to be done, but x264 can do it with single-pass encoding, so it is more likely a bitrate detection issue.

Appears for everyone that uses this driver, something is now broken here. Unsure if it affects anything serious, i hope not.

Issue #19 referred to this as problem scenario 3. Basically what happens is that SubmitInput will return AMF_INPUT_FULL every few seconds while QueryOutput will immediately return AMF_REPEAT. For some reason, this makes the entire computer stutter for about half a second or less.

Debug Data provided:

• Commit that it was last reproduced with
• Dump+Log 1: xaymar.com mega.co.nz

Currently AMFQueryVersion will always return 1.3.0.5, which makes it impossible to tell what driver a user is actually on - there are about 12 drivers that contains 1.3.0.5, so how would I tell them apart without querying another interface?

AMF already has a define called AMF_VERSION_BUILD_NUM, it would be nice if it was increased for every driver build in the future.

Reported here by one of my plugin users, it seems that when the GPU/APU has no monitors attached that the DLL is nowhere to be found. Perhaps install the DLL files into a common folder in the next driver release no matter if there is a Monitor attached or not?

I posted this issue on the OBS forums and was directed here by Xaymar.

Previous versions of his plugin work, but upon using the most up to date version RC 4 my OBS crashes. Right before crashing, OBS states "Encoding overloaded! Consider turning down video settings or using a faster encoding preset." Here are some logs:

OBS Log: https://gist.github.com/f358c76d6279a2527f2ee2d7a2438245
Crash Log: http://pastebin.com/cUnGwHpJ

Normal OBS Log on RC3: https://gist.github.com/1a3cd1488d11499432df712b8c9da87e

I have done the following:

• Entered Safemod followed by using DisplayDriverUninstaller to remove AMD files, then reinstalling 16.9.1 on my RX 480.
• Installed some Windows7 updates.
• Reinstalled plugin.

Right now, there seems to be no way to tell AMF/VCE what the input color profile and range actually is. This leads to darker recordings with colors that don't match the input.

Video Converter seems to already have a parameter to define the profile called 'AMF_VIDEO_CONVERTER_COLOR_PROFILE'.

Edit: The default now seems to be Partial .701 instead of Partial .609.

I am unsure as to why this happens. I know that with Media SDK it did not happen, am I forgetting to set something per frame?

Encoder Parameters (in the order they were assigned):

AMF_VIDEO_ENCODER_USAGE = Transcoding
AMF_VIDEO_ENCODER_QUALITY_PRESET = Speed
AMF_VIDEO_ENCODER_PROFILE = High
AMF_VIDEO_ENCODER_PROFILE_LEVEL = 5.2
AMF_VIDEO_ENCODER_FRAMESIZE = 1920x1080
AMF_VIDEO_ENCODER_FRAMERATE = 60/1
AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD = CQP
AMF_VIDEO_ENCODER_FILLER_DATA_ENABLE = False
AMF_VIDEO_ENCODER_RATE_CONTROL_SKIP_FRAME_ENABLE = False
AMF_VIDEO_ENCODER_VBV_BUFFER_SIZE = 65535000
AMF_VIDEO_ENCODER_INITIAL_VBV_BUFFER_FULLNESS = 64
AMF_VIDEO_ENCODER_MIN_QP = 11
AMF_VIDEO_ENCODER_MAX_QP = 41
AMF_VIDEO_ENCODER_QP_I = 27
AMF_VIDEO_ENCODER_QP_P = 29
AMF_VIDEO_ENCODER_QP_B = 31
AMF_VIDEO_ENCODER_ENFORCE_HRD = False
AMF_VIDEO_ENCODER_IDR_PERIOD = 60
AMF_VIDEO_ENCODER_DE_BLOCKING_FILTER = False
AMF_VIDEO_ENCODER_B_PIC_PATTERN = 3
AMF_VIDEO_ENCODER_B_REFERENCE_ENABLE = False
AMF_VIDEO_ENCODER_B_PIC_DELTA_QP = 2
AMF_VIDEO_ENCODER_REF_B_PIC_DELTA_QP = 1
AMF_VIDEO_ENCODER_MOTION_HALF_PIXEL = True
AMF_VIDEO_ENCODER_MOTION_QUARTERPIXEL = True
AMF_VIDEO_ENCODER_FRAMESIZE = 1920x1080
AMF_VIDEO_ENCODER_FRAMERATE = 60/1

Submission Parameters (in the order they were assigned):

PTS = Frame Index converted to real time
Frame = Frame Index

Here is a file which won't support skipping in decoders that don't automatically fix this: 2016-08-30 08-40-44.zip

For video transcoding, Linux is an ideal platform. And for this use case, no Vulkan support is necessary, just access to hardware decode/encode.

Trying to get more alternative backends into my plugin and I stumbled upon these memory types. How would I use them?

Right now I have an optional OpenCL backed version, would this no longer be needed with that?

Basically the Encoder will stop returning valid information for frames after a while, rendering a 2 hour 20 minute recording to be only 800 mb big - because it only contains information for 20 minutes and 48 seconds. No player can play this file back properly after a the ~20 minute mark.

This was first reported to me by ball2hi on obsproject.com and has now been reproduced by me. Perhaps some obvious error can be spotted that I didn't see. Dump will be provided once I figure out how to spot this issue actually happening before i stop encoding.

Debug Data:

• Project Code
• Recording & Log: xaymar.com
• Recording, Log & Dump: #23 (comment)

Attempted Solutions:

• Extract & Remux using FFMPEG: Failed. (Only recovered 20:48 of Video.)

10:41:06.215: [AMF Encoder]  Type | Acc.Type | Max Bitrate | Stream # | Max Profile | Max Level | BFrames | Ref. Frames | Layer # | FSM | Instance #   
10:41:06.215: [AMF Encoder]   AVC | Hardware |   100000000 |       16 |         100 |        52 |      No |    1 -   16 |       1 |  No |          1  
10:41:06.215: [AMF Encoder]   SVC | Hardware |   100000000 |       16 |         100 |        51 |      No |    1 -   16 |       3 |  No |          1 

I get this result when querying the AMF Encoder for capabilities. The RX 480 has a newer VCE (sub-)generation, shouldn't it support BFrames like the R9 380/R9 285?
This is the output when I select the R9 285 (using the older SDK).

10:41:06.215: [AMF Encoder]  Type | Acc.Type | Max Bitrate | Stream # | Max Profile | Max Level | BFrames | Ref. Frames | Layer # | FSM | Instance # 
10:41:06.215: [AMF Encoder]   AVC | Hardware |  1000000000 |       16 |         100 |        51 |     Yes |    1 -   16 |       1 |  No |          1 
10:41:06.215: [AMF Encoder]   SVC | Hardware |  1000000000 |       16 |         100 |        42 |     Yes |    1 -   16 |       3 |  No |          1 

Hi,

I'm facing issue while trying to decode a simple 1080p h264 elementary stream using AMF SDK 1.3 running on AMD Firepro W7100 and the last AMD radeon.

I modified the "PlaybackHW" AMF sample in the following manner:

• In the "PlaybackHW", the decoder is initialized to generate BGRA instead of NV12.
• In the "PlaybackPipeline.cpp", I disabled the video converter (m_pConverter is no more instantiated and not connection to the decode pipeline).
• In the "VideoPresenterOpenGL.cpp", I replaced the call
  -- pSurface->Convert(amf::AMF_MEMORY_OPENGL) by
  ++pSurface->Interop(amf::AMF_MEMORY_OPENGL) and check the error code.

When I run the application using VideoPresenter OpenGL, The interop function call returns error 10 (AMF_NOT_SUPPORTED).

When I keep the call to convert, the surface is correctly converted to opengl but it is done using CPU and by the way it takes a long time (about 28 msec).

I don't see the reason, interopt shall be working on such hardware.

Regards
HB

Right now I do not see a way to do this, but it would be nice to have for services like YouTube, Beam and Hitbox which support Variable Bitrate (if it doesn't go too low). Technically all that is needed is Filler Data support for Variable Bitrate and everything would be okay.

Reported by one my users and shortly afterwards reproduced, it seems that encoding will get stuck at some point, never returning from SubmitInput or QueryOutput - it simply doesn't do things anymore.

Parameters (Applied in the order shown)

• Quality Preset: Speed
• Usage: Transcoding
• Profile: Main
• Profile Level: 41
• Frame Size: 1280, 720
• Frame Rate: 60, 1
• Rate Control Method: Constant Bitrate
• Rate Control Skip Frame: Disabled (false)
• Minimum QP: 18
• Maximum QP: 51
• Target Bitrate: 3000000
• Peak Bitrate: 3000000
• VBV Buffer Size: 3000000
• Initial VBV Buffer Fullness: 100% (64)
• Filler Data: Enabled (true)
• IDR Period: 120
• B-Pictures Pattern: 3
• B-Reference: Enabled (true)
• B-Picture Delta QP: 0
• Reference B-Picture Delta QP: 0
• Scan Type: Progressive
• Half Pixel Motion Estimation: Enabled (true)
• Quarter Pixel Motion Estimation: Enabled (true)
• Frame Size: 1280, 720
• Frame Rate: 60, 1

Dump File

• xaymar.com: http://cdn.xaymar.com/private/2016/09/11-09-2016_obs64_2.7z
• mega.co.nz: https://mega.nz/#!eBdxlbhJ!MxAcaFGigTQ2OusIHGocdiQMsD9O0sUO0pgtp4BGhBE

Hi,

Does this project superseed the AMD Media Package located http://www.amd.com/en-us/innovations/software-technologies/enhanced-media ?

Thanks
Scott

On Page 7, the following line

AMFQueryVersion_Fn queryVersion = GetProcAddress(hAMFDll, AMF_QUERY_VERSION_FUNCTION_NAME);

must be changed to

AMFQueryVersion_Fn queryVersion = (AMFQueryVersion_Fn)GetProcAddress(hAMFDll, AMF_QUERY_VERSION_FUNCTION_NAME);

for it to compile. Similar thing some lines below, with AMFInit_Fn.

Reported by two users, for some reason the encoding crashes inside the Driver on QueryOutput or SubmitInput.

1. Report: obsproject/obs-amd-encoder#143
2. Report: https://obsproject.com/forum/threads/obs-crashing-when-streaming-recording-using-amf-plugin.57619/#post-252017, obsproject/obs-amd-encoder#144
3. Report: obsproject/obs-amd-encoder#145

Data

1. Report

• Log: https://github.com/Xaymar/obs-studio_amf-encoder-plugin/files/587270/2016-11-12.15-23-26.txt
• Crash Log: https://github.com/Xaymar/obs-studio_amf-encoder-plugin/files/587274/Crash.2016-11-12.15-35-46.txt
• Video: https://drive.google.com/open?id=0B1y2xDp8Jscna29UNG1GZGdZeHM
• Dump: https://drive.google.com/open?id=0B1y2xDp8JscnQ1pMbE5pdzE2cjQ (look at Thread ID 13388)

2. Report

• Log, Crash Log, System Specs, Dump: https://www.dropbox.com/s/1sm9uv7sz4a7vr8/r4b.7z?dl=0 (Thread Id: 2284)

Hi xaymar not really sure if this is the place where I should report this, since OBS 0.16.2 have now your plugin built-in, but..
I had set the recording to 60FPS, and the game runs perfectly fine at 60FPS or above, altough, the video file ends up being 35FPS, or 39FPS or 48FPS, it's variable.
How can I solve this?

I left my obs log attached after a recording, I couldn't stop notice that obs failed to load some services too
https://gist.github.com/c4775e1b02e05cb044f31c138d2a1286

Cheers

Initialliy reported here (https://obsproject.com/forum/threads/fresh-install-results-in-crash.57277/), it seems that AMF successfully initializes but then fails later on in CreateComponent with an unhandled null pointer exception.

Data

• Dump: http://www.mediafire.com/file/jbyamki015mylkp/obs32.rar (Thread Id: 3396)
• Device Id: 6660 (Vendor Id: 1002, SubSystem: 3818, SubSystem Vendor: 17AA, Revision: 83) (R5 M330)
• Driver Version: 16.11.2 (Radeon Settings Version: 2016.1103.2042.35350)

Was trying to test streaming when all of a sudden everything stopped and the screens flickered black. Happened as soon as the Twitch stream loaded in, so something collided there.

Encoding was done using the R9 285 instead of the RX 480, since the R9 285 is slightly more powerful with AVC encoding.

System

• MB: Gigabyte H97-D3H-CF
• CPU: Intel i5-4690
• RAM: 16GB DDR3 1333Mhz
• GPU: AMD RX 480 8GB + AMD R9 285
• DSK: 256GB M.2 SSD + 1TB+1TB RAID0
• OS: Windows 10 64-Bit

Data

2016-11-21

• Log: https://gist.github.com/1569bb38c176fe1d73e2e579ab4b3a0f (see the end of it, there was more than one recording/streaming attempt to reproduce another issue)
• Dump: http://cdn.xaymar.com/private/2016/11/obs64.7z
• Video: http://cdn.xaymar.com/private/2016/11/2016-11-21%2022-42-28.mkv

2016-11-21 22-55

• Log: https://gist.github.com/ea314ca1e16f55099999d68a2d21e0c5
• Dump: http://cdn.xaymar.com/private/2016/11/2016-11-21-22-55_obs64.7z
• Video: http://cdn.xaymar.com/private/2016/11/2016-11-21%2022-54-14.mkv

VBVBuffer currently is broken, causing visual quality loss that worsens over time, depending on how large the VBVBuffer is. The same effect can be immediately triggered by setting InitialVBVBufferFullness to 0 instead of 64.

Edit: Only values above the Bitrate and below exactly 66666666 work "fine", the rest will cause quality problems and massive issues further into encoding.

Issue Files

Test 1

• System: Intel 4690, R9 285, 16GB DDR3, Plugin Version 1.4.1.1 (PortableRepro thing)
• Log: http://cdn.xaymar.com/private/2016/11/2016-11-08%2023-49-48.txt
• Video: https://www.twitch.tv/xaymar/v/99911564 (Recording to disk crashed in atiumdag)

I'm relying on a user report for this one, something is causing the stream to be corrupted. See ffprobe output below.

ffprobe for Video 1:

[h264 @ 00000000033005c0] nal_unit_type: 12, nal_ref_idc: 0
[h264 @ 00000000033005c0] Frame num gap 9 7
[h264 @ 00000000033005c0] bytestream overread -8
[h264 @ 00000000033005c0] error while decoding MB 58 29, bytestream -8
[h264 @ 00000000033005c0] concealing 1271 DC, 1271 AC, 1271 MV errors in P frame
[h264 @ 00000000033005c0] nal_unit_type: 9, nal_ref_idc: 0
[h264 @ 00000000033005c0] nal_unit_type: 1, nal_ref_idc: 2
... later ...
[h264 @ 00000000033005c0] nal_unit_type: 12, nal_ref_idc: 0
[h264 @ 00000000033005c0] no picture ooo
[h264 @ 00000000033005c0] bytestream overread -6
[h264 @ 00000000033005c0] error while decoding MB 53 1, bytestream -6
[h264 @ 00000000033005c0] concealing 3516 DC, 3516 AC, 3516 MV errors in P frame
[h264 @ 00000000033005c0] nal_unit_type: 9, nal_ref_idc: 0
[h264 @ 00000000033005c0] nal_unit_type: 1, nal_ref_idc: 2
[h264 @ 00000000033005c0] Frame num gap 38 33
[h264 @ 00000000033005c0] Frame num gap 38 34
[h264 @ 00000000033005c0] Frame num gap 38 35
[h264 @ 00000000033005c0] Frame num gap 38 36
[h264 @ 00000000033005c0] nal_unit_type: 9, nal_ref_idc: 0
[h264 @ 00000000033005c0] nal_unit_type: 1, nal_ref_idc: 2
[h264 @ 00000000033005c0] nal_unit_type: 12, nal_ref_idc: 0
[h264 @ 00000000033005c0] bytestream overread -4
[h264 @ 00000000033005c0] bytestream overread -6
[h264 @ 00000000033005c0] error while decoding MB 56 39, bytestream -6
[h264 @ 00000000033005c0] concealing 473 DC, 473 AC, 473 MV errors in P frame
[h264 @ 00000000033005c0] nal_unit_type: 9, nal_ref_idc: 0
[h264 @ 00000000033005c0] nal_unit_type: 1, nal_ref_idc: 2
[h264 @ 00000000033005c0] Frame num gap 47 42
[h264 @ 00000000033005c0] Frame num gap 47 43
[h264 @ 00000000033005c0] Frame num gap 47 44
[h264 @ 00000000033005c0] Frame num gap 47 45
[h264 @ 00000000033005c0] nal_unit_type: 9, nal_ref_idc: 0
[h264 @ 00000000033005c0] nal_unit_type: 1, nal_ref_idc: 2
[h264 @ 00000000033005c0] nal_unit_type: 12, nal_ref_idc: 0
[h264 @ 00000000033005c0] bytestream overread -4
[h264 @ 00000000033005c0] bytestream overread -6
[h264 @ 00000000033005c0] error while decoding MB 0 3, bytestream -6
[h264 @ 00000000033005c0] concealing 3409 DC, 3409 AC, 3409 MV errors in P frame
[h264 @ 00000000033005c0] nal_unit_type: 9, nal_ref_idc: 0
[h264 @ 00000000033005c0] nal_unit_type: 7, nal_ref_idc: 3
[h264 @ 00000000033005c0] nal_unit_type: 8, nal_ref_idc: 3
[h264 @ 00000000033005c0] nal_unit_type: 5, nal_ref_idc: 3
[h264 @ 00000000033005c0] nal_unit_type: 9, nal_ref_idc: 0
... later ...
[h264 @ 00000000033005c0] nal_unit_type: 1, nal_ref_idc: 2
[h264 @ 00000000033005c0] nal_unit_type: 12, nal_ref_idc: 0
[h264 @ 00000000033005c0] Frame num gap 24 19
[h264 @ 00000000033005c0] Frame num gap 24 20
[h264 @ 00000000033005c0] Frame num gap 24 21
[h264 @ 00000000033005c0] Frame num gap 24 22
[h264 @ 00000000033005c0] bytestream overread -54
[h264 @ 00000000033005c0] error while decoding MB 39 32, bytestream -54
[h264 @ 00000000033005c0] concealing 1050 DC, 1050 AC, 1050 MV errors in P frame
[h264 @ 00000000033005c0] nal_unit_type: 9, nal_ref_idc: 0
[h264 @ 00000000033005c0] nal_unit_type: 7, nal_ref_idc: 3
[h264 @ 00000000033005c0] nal_unit_type: 8, nal_ref_idc: 3
... later ...
[h264 @ 00000000033005c0] nal_unit_type: 12, nal_ref_idc: 0
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -5
[h264 @ 00000000033005c0] error while decoding MB 77 38, bytestream -5
[h264 @ 00000000033005c0] concealing 532 DC, 532 AC, 532 MV errors in P frame
[h264 @ 00000000033005c0] nal_unit_type: 9, nal_ref_idc: 0
[h264 @ 00000000033005c0] nal_unit_type: 7, nal_ref_idc: 3
[h264 @ 00000000033005c0] nal_unit_type: 8, nal_ref_idc: 3
... 
[h264 @ 00000000033005c0] nal_unit_type: 12, nal_ref_idc: 0
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -5
[h264 @ 00000000033005c0] error while decoding MB 77 38, bytestream -5
[h264 @ 00000000033005c0] concealing 532 DC, 532 AC, 532 MV errors in P frame
[h264 @ 00000000033005c0] nal_unit_type: 9, nal_ref_idc: 0
...
[h264 @ 00000000033005c0] nal_unit_type: 1, nal_ref_idc: 2
[h264 @ 00000000033005c0] nal_unit_type: 12, nal_ref_idc: 0
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -3
[h264 @ 00000000033005c0] bytestream overread -5
[h264 @ 00000000033005c0] error while decoding MB 22 17, bytestream -5
[h264 @ 00000000033005c0] concealing 2267 DC, 2267 AC, 2267 MV errors in P frame
[h264 @ 00000000033005c0] nal_unit_type: 9, nal_ref_idc: 0
[h264 @ 00000000033005c0] nal_unit_type: 1, nal_ref_idc: 2
[h264 @ 00000000033005c0] nal_unit_type: 12, nal_ref_idc: 0
[h264 @ 00000000033005c0] Frame num gap 10 8
[h264 @ 00000000033005c0] bytestream overread -55
[h264 @ 00000000033005c0] error while decoding MB 50 32, bytestream -55
[h264 @ 00000000033005c0] concealing 1039 DC, 1039 AC, 1039 MV errors in P frame
[h264 @ 00000000033005c0] nal_unit_type: 9, nal_ref_idc: 0
[h264 @ 00000000033005c0] nal_unit_type: 7, nal_ref_idc: 3

Data

2016-11-22 00-27

• Video 1: https://drive.google.com/open?id=0B-MVqNVDSsJ5WEJHZTlZdzg2ekU (same as ffprobe)
• Log 1: https://gist.github.com/anonymous/146aac62f5d550dbe722c25f3742a702
• Video 2: https://www.twitch.tv/everyth1ngtv/v/101951983
• Log 2: https://github.com/Xaymar/obs-studio_amf-encoder-plugin/files/602384/2016-11-18.22-44-10.txt

When Rate Control Method is set to AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CONSTANT_QP, the properties AMF_VIDEO_ENCODER_QP_I, AMF_VIDEO_ENCODER_QP_P and AMF_VIDEO_ENCODER_QP_B are ignored. Instead only AMF_VIDEO_ENCODER_MIN_QP and AMF_VIDEO_ENCODER_MAX_QP are respected, resulting in what is actually Constrained QP and not Constant QP.

Possibly a driver bug in the library shipped with 16.8.2

There currently seems to be no way to tell AMF/VCE which encoding type should be used. It is either missing from the include files or not properly documented. I may have missed it though.

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

• Windows 10 64-Bit (Anniversary Update, automatic Updates enabled)
• CPU: Intel 4690
• Mainboard: GIGABYTE H97-D3H
• GPU: RASUS Radeon R9 285 Strix OC DirectCU II
• Driver: 16.10.3

Reproduction Data

1. Dump Files

• mega.co.nz: https://mega.nz/#!jBcDRZ4R!G8K59-e0pUPFhvyHxNxmMmAcXKYmbpa56ZdEWl1I_Bw
• xaymar.com: http://cdn.xaymar.com/private/2016/09/11-09-2016_obs64.7z

2016-11-02 Bitrate Problem returns on R9 285

• Recording (correct Bitrate): http://cdn.xaymar.com/private/2016/11/2016-11-02%2020-35-35.mkv
• Log: http://cdn.xaymar.com/private/2016/11/2016-11-02_20-36-09.txt
• Recording (wrong Bitrate): http://cdn.xaymar.com/private/2016/11/2016-11-02%2020-26-28.mkv
• Log: http://cdn.xaymar.com/private/2016/11/2016-11-02_20-30-43.txt

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

• Log: http://cdn.xaymar.com/private/2016/11/2016-11-03%2018-21-18.txt
• Video: http://cdn.xaymar.com/private/2016/11/2016-11-03_18-21-26.mkv

To split the "expose some properties" from my GitHub, here is the ones I'd like to be able to control without having to rely on reverse engineering to understand how they work:

CABACEnable

CABAC is a more efficient way of entropy coding and on average allows up to 5% extra data to be stored for most use cases. x264 software encoding has this enabled by default. Use cases would be streaming or recording to surveillance disks which are massively slower than consumer grade disks.
There is currently a bug with CABAC encoding which makes the stream unseekable, so CABAC coded files need to be played back from the start. I'd recommend fixing this on the driver side before exposing the parameter officially.

Aspect Ratio

While only something that is needed for special encoding (like with Adobe Media Encoder and similar), it would be nice if this is officially available.

NominalRange

Full Range encoding for recording in true color. Helps with games such as Thief, Killing Floor, The Forest (in caves), Space Engineers (when there is no sun) and other games where most of the visible stuff is near the dark end of colors (<20) or when there are really bright spots (>230).
Supported already by some cards in Driver 16.11.1 and up.

I will add more to this request once I find them and figure out if they are useful or not.

Seems to be a regression from an earlier driver (accidentally changed the wrong code?), VBR seems to completely ignore any constraints. Min/Max QP, VBV Buffer Size, Target/Peak Bitrate all have no effect on what it is going to use for the actual bitrate and usually it hovers at around a fixed 20mbit/s.

Edit: Bitrate drops below 20mbit/s when Target Bitrate is set to exactly 0. Still does not follow any other constraints.

Constraints being ignored completely:

• Min QP (unless 0)
• Target Bitrate
• Peak Bitrate
• VBV Buffer

System Information

• Windows 10 64-Bit (Anniversary Update, automatic Updates enabled)
• CPU: Intel 4690
• Mainboard: GIGABYTE H97-D3H
• GPU: RASUS Radeon R9 285 Strix OC DirectCU II
• Driver: 16.10.3

Report Data

2016-11-03 (Wrong Target Bitrate)

• Log: http://cdn.xaymar.com/private/2016/11/2016-11-03_14-19-53.txt
• Video 1: http://cdn.xaymar.com/private/2016/11/2016-11-03%2014-18-17.mkv
• Video 2: http://cdn.xaymar.com/private/2016/11/2016-11-03%2014-18-57.mkv
• Video 3: http://cdn.xaymar.com/private/2016/11/2016-11-03%2014-19-22.mkv

2016-11-03 (Corrected Target Bitrate)

• Log: http://cdn.xaymar.com/private/2016/11/2016-11-03_15-07-56.txt
• Video 1: http://cdn.xaymar.com/private/2016/11/2016-11-03%2015-02-50.mp4
• Video 2: http://cdn.xaymar.com/private/2016/11/2016-11-03%2015-06-39.mp4

2016-11-03 (Applied fixes by Mikhail)

• #39 (comment)

This is one of the more stranger things that I found that I fixed by moving all GetProperty calls into a synchronized/single-threaded approach. For some reason GetProperty would not work when multiple threads used it.

Example:

• Thread A calls SetPropery on a Surface, "Frame" is being set to 29392 (8m 09s 52frames).
• Thread B calls GetProperty "Frame" that happens to overlap the SetProperty call, expected returned value is 29388 (4 frame encoding delay).
• Thread A successfully sets the property "Frame".
• Thread B returns from GetPropery with an invalid value or a value further in the future (29392 for example).

I'm still working on a test case in which it happens more often, but basically it can be fixed by forcing SetPropery and GetProperty to never overlap.