Video Encode API: Encoder gets stuck after varying amount of time.

[Xaymar]

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

[Xaymar]

Occasionally encoding will return to normal and hiccup every few minutes. This is extremely rare.

[Xaymar]

Can easily be reproduced by loading the dashboard on Twitch for example - it will cause a short hiccup because the encoding task has a much lower priority than it should. We need the ability to specify priority for the task again! Edit: Chrome with GPU acceleration can cause this about 6 out of 10 page loads.

[MikhailAMD]

Hi,
Please try to add InitOpenCL() after InitDX9() and InitDX11(). This will move some operations into Compute HW queue and make it easier on 3D queue.

[Xaymar]

Right, so I have the changes that you suggested in #12 (and here) implemented now. Seems to "fix" it, except that it now spams log messages. I've updated the code in my repository with what I have right now - do tell me if it's wrong somewhere.

21:17:08.610: [AMFTrace::AMFSurfaceImpl]    Error: ..\..\..\..\..\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL
21:17:08.610: [AMF Encoder] Packet: Type(2), PTS(1855,    30915430), DTS(1850,    30833334), Size(    3107)
21:17:08.626: [AMF Encoder] Packet: Type(3), PTS(1852,    30865432), DTS(1851,    30850001), Size(    2772)
21:17:08.626: [AMFTrace::AMFSurfaceImpl]    Error: ..\..\..\..\..\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL
21:17:08.643: [AMFTrace::AMFSurfaceImpl]    Error: ..\..\..\..\..\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL
21:17:08.643: [AMF Encoder] Packet: Type(3), PTS(1853,    30882098), DTS(1852,    30866668), Size(    2807)
21:17:08.660: [AMF Encoder] Packet: Type(3), PTS(1854,    30898764), DTS(1853,    30883334), Size(    2969)
21:17:08.660: [AMFTrace::AMFSurfaceImpl]    Error: ..\..\..\..\..\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL
21:17:08.676: [AMF Encoder] Packet: Type(2), PTS(1859,    30982094), DTS(1854,    30900001), Size(    2575)
21:17:08.676: [AMFTrace::AMFSurfaceImpl]    Error: ..\..\..\..\..\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL
21:17:08.693: [AMFTrace::AMFSurfaceImpl]    Error: ..\..\..\..\..\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL
21:17:08.693: [AMF Encoder] Packet: Type(3), PTS(1856,    30932096), DTS(1855,    30916668), Size(    2863)
21:17:08.710: [AMF Encoder] Packet: Type(3), PTS(1857,    30948762), DTS(1856,    30933334), Size(    2086)
21:17:08.710: [AMFTrace::AMFSurfaceImpl]    Error: ..\..\..\..\..\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL
21:17:08.727: [AMF Encoder] Packet: Type(3), PTS(1858,    30965428), DTS(1857,    30950001), Size(    1896)
21:17:08.727: [AMFTrace::AMFSurfaceImpl]    Error: ..\..\..\..\..\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL
21:17:08.744: [AMF Encoder] Packet: Type(2), PTS(1863,    31048758), DTS(1858,    30966668), Size(    2581)
21:17:08.744: [AMFTrace::AMFSurfaceImpl]    Error: ..\..\..\..\..\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL
21:17:08.760: [AMF Encoder] Packet: Type(3), PTS(1860,    30998760), DTS(1859,    30983334), Size(    2110) 
21:17:08.760: [AMFTrace::AMFSurfaceImpl]    Error: ..\..\..\..\..\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL
21:17:08.776: [AMFTrace::AMFSurfaceImpl]    Error: ..\..\..\..\..\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL
21:17:08.776: [AMF Encoder] Packet: Type(3), PTS(1861,    31015426), DTS(1860,    31000001), Size(    1855)
21:17:08.793: [AMFTrace::AMFSurfaceImpl]    Error: ..\..\..\..\..\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL
21:17:08.793: [AMF Encoder] Packet: Type(3), PTS(1862,    31032092), DTS(1861,    31016668), Size(    2666)
21:17:08.810: [AMF Encoder] Packet: Type(2), PTS(1867,    31115422), DTS(1862,    31033334), Size(    1817)
21:17:08.810: [AMFTrace::AMFSurfaceImpl]    Error: ..\..\..\..\..\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL

[MikhailAMD]

Can I see your latest code with this?

Mikhail

From: Michael Fabian Dirks [mailto:notifications@github.com]
Sent: September 12, 2016 3:24 PM
To: GPUOpen-LibrariesAndSDKs/AMF AMF@noreply.github.com
Cc: Mironov, Mikhail Mikhail.Mironov@amd.com; Comment comment@noreply.github.com
Subject: Re: [GPUOpen-LibrariesAndSDKs/AMF] Video Encode API: Encoder gets stuck after varying amount of time. (#19)

Right, so I have the changes that you suggested in #12#12 (and here) implemented now. Seems to "fix" it, except that it now spams log messages. I've updated the code in my repository with what I have right now - do tell me if it's wrong somewhere.

21:17:08.610: [AMFTrace::AMFSurfaceImpl] Error: ..........\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL

21:17:08.610: [AMF Encoder] Packet: Type(2), PTS(1855, 30915430), DTS(1850, 30833334), Size( 3107)

21:17:08.626: [AMF Encoder] Packet: Type(3), PTS(1852, 30865432), DTS(1851, 30850001), Size( 2772)

21:17:08.626: [AMFTrace::AMFSurfaceImpl] Error: ..........\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL

21:17:08.643: [AMFTrace::AMFSurfaceImpl] Error: ..........\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL

21:17:08.643: [AMF Encoder] Packet: Type(3), PTS(1853, 30882098), DTS(1852, 30866668), Size( 2807)

21:17:08.660: [AMF Encoder] Packet: Type(3), PTS(1854, 30898764), DTS(1853, 30883334), Size( 2969)

21:17:08.660: [AMFTrace::AMFSurfaceImpl] Error: ..........\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL

21:17:08.676: [AMF Encoder] Packet: Type(2), PTS(1859, 30982094), DTS(1854, 30900001), Size( 2575)

21:17:08.676: [AMFTrace::AMFSurfaceImpl] Error: ..........\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL

21:17:08.693: [AMFTrace::AMFSurfaceImpl] Error: ..........\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL

21:17:08.693: [AMF Encoder] Packet: Type(3), PTS(1856, 30932096), DTS(1855, 30916668), Size( 2863)

21:17:08.710: [AMF Encoder] Packet: Type(3), PTS(1857, 30948762), DTS(1856, 30933334), Size( 2086)

21:17:08.710: [AMFTrace::AMFSurfaceImpl] Error: ..........\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL

21:17:08.727: [AMF Encoder] Packet: Type(3), PTS(1858, 30965428), DTS(1857, 30950001), Size( 1896)

21:17:08.727: [AMFTrace::AMFSurfaceImpl] Error: ..........\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL

21:17:08.744: [AMF Encoder] Packet: Type(2), PTS(1863, 31048758), DTS(1858, 30966668), Size( 2581)

21:17:08.744: [AMFTrace::AMFSurfaceImpl] Error: ..........\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL

21:17:08.760: [AMF Encoder] Packet: Type(3), PTS(1860, 30998760), DTS(1859, 30983334), Size( 2110)

21:17:08.760: [AMFTrace::AMFSurfaceImpl] Error: ..........\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL

21:17:08.776: [AMFTrace::AMFSurfaceImpl] Error: ..........\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL

21:17:08.776: [AMF Encoder] Packet: Type(3), PTS(1861, 31015426), DTS(1860, 31000001), Size( 1855)

21:17:08.793: [AMFTrace::AMFSurfaceImpl] Error: ..........\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL

21:17:08.793: [AMF Encoder] Packet: Type(3), PTS(1862, 31032092), DTS(1861, 31016668), Size( 2666)

21:17:08.810: [AMF Encoder] Packet: Type(2), PTS(1867, 31115422), DTS(1862, 31033334), Size( 1817)

21:17:08.810: [AMFTrace::AMFSurfaceImpl] Error: ..........\runtime\src\core\SurfaceImpl.cpp(210):Assertion failed:pInteropDevice != NULL

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com//issues/19#issuecomment-246461640, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AOcWvzwXm848zfShqnt-9QJx4uikXbWjks5qpaa7gaJpZM4J6GRX.

[Xaymar]

The code is right here: https://github.com/Xaymar/OBS-AMD-Advanced-Media-Framework

[MikhailAMD]

Please separate issues. Let's consider this one is about stuck. I reviewed the dump. It doesn't have a thread that sits inside amfrt64.DLL. There are two threads sitting inside the plug-in (enc-amf.dll, thread IDs = 3332, 17724). What is the reason to believe that the plug-in is blocked by AMF?

[MikhailAMD]

About hick-ups: By default color space conversion in OBS is done on D3D HW queue. It may interfere with other applications. AMF provides you an option to use a different queue: Compute HW queue for the conversion. In this case there is much less interference. To enable this I tried to add InitOpenCL(NULL) after InitDX<>() call. And I switched OBS to submit RGB frames. Everything worked for me. If you experience crashes please provide exact code (maybe commented out in GitHub). Thanks,

[Xaymar]

I reviewed the dump. It doesn't have a thread that sits inside amfrt64.DLL. There are two threads sitting inside the plug-in (enc-amf.dll, thread IDs = 3332, 17724). What is the reason to believe that the plug-in is blocked by AMF?

The plugin queues up incoming frames, which leads to an increase of memory usage. If it wasn't stuck, it would happily send these off to the AMF component. If it is stuck, it only queues them up, but never dequeues them. This behaviour is not AMF SDK exclusive and also happened with Media SDK - even in the examples.

A normal dump from obs64.exe with my plugin is about 394mb big, a process dump where it got stuck is larger than that. This is easily visible when running OBS in the debugger, as the growth of memory will be quite visible in the Diagnostic View.

About hick-ups: By default color space conversion in OBS is done on D3D HW queue. It may interfere with other applications. AMF provides you an option to use a different queue: Compute HW queue for the conversion. In this case there is much less interference. To enable this I tried to add InitOpenCL(NULL) after InitDX<>() call. And I switched OBS to submit RGB frames. Everything worked for me.

I will try this on my end too, though I don't think it'll do much since it's not OBS that gets slower (OBS has Realtime priority on my System). If it was OBS, I would not receive 60 frames per second to queue/send of to the submission thread.

Please separate issues.

The issues are separate, it's just that you requested the same in both issues.

Everything worked for me. If you experience crashes please provide exact code (maybe commented out in GitHub).

I'm not sure how to provide more exact code than I already have provided. I could also upload the OBS .json files that will cause the issue if that helps.

[MikhailAMD]

I am confused. the plug-in accumulates frames in the queue and memory grows - understood. But what is the reason for not submitting frames? I see three possible variants:

1. AMF did not return from SubmitInput() - should be visible in the dump
2. AMF returned "INPUT_FULL" - should see tracing and it means that encoder output is not polled fast enough
3. Some synchronization or logical issues in the plug-in

Hick-up: We are talking about GPU priorities. They are not affected by CPU priorities. Compute queue is the way to un-tangle GPU-intensive application (game, browser) and color space conversion. Of course, switching to RGB will increase PCI-E traffic. This problem is going back to the discussion to submit GPU frames to AMF without moving them to system memory.

[Xaymar]

The reason is what you described in 1. I'll try to get a dump in which it is stuck inside SubmitInput so it can be seen better.