Bug Report 0.633b - QSVHelper.exe was killed, encode failed
- Thread starter gdlk
- Start date
- Status
Update on my earlier post. Quick sync is working only when playing console games with the on board video adapter selected in OBS. When I try to stream PC games with the on board video, game capture wont work, I have to select my nvdida card but then quick sync gets that error.
PixelPolish
New Member
So still no luck with QuickSync? Such a damn shame, as it helped a ton with the performance. Now I'm testing the AMD build with VCE and it seems to be better than stock, but still, streaming while using hardware that is not being used by the games seems like the better option. If it would only work...
So i had a little time today to do some more testing. I can't make any sense of these results but maybe someone else can see something I'm missing.
I've tested 3 games so far, FFXIV, Black Ops 2, and Diablo 3.
FF and Black Ops 2 will cause the crash within 5 minutes, most of the time less, however while playing Diablo 3 OBS never freaked. I streamed it for a good 45 minutes without a single crash. The only difference i could think of was Diablo had Vsync on so i switched it off and another 45 minutes without a hitch.
So I'm at a loss as to whats causing the issue. All 3 games are DX9, i have all 3 in Full screen windowed, all 3 are max res downscaled to 720p.
Anyone else have Diablo 3 that wouldn't mind testing for an hour or so to see if they run into the same results? Can anyone think of something unique to Diablo vs any other game thats currently crashing for all of us?
Void4ever
I've tested 3 games so far, FFXIV, Black Ops 2, and Diablo 3.
FF and Black Ops 2 will cause the crash within 5 minutes, most of the time less, however while playing Diablo 3 OBS never freaked. I streamed it for a good 45 minutes without a single crash. The only difference i could think of was Diablo had Vsync on so i switched it off and another 45 minutes without a hitch.
So I'm at a loss as to whats causing the issue. All 3 games are DX9, i have all 3 in Full screen windowed, all 3 are max res downscaled to 720p.
Anyone else have Diablo 3 that wouldn't mind testing for an hour or so to see if they run into the same results? Can anyone think of something unique to Diablo vs any other game thats currently crashing for all of us?
Void4ever
djdynamite123
New Member
Yup, same error here, tried allsorts to no avail. Running DXTory (my licensed version) through it (DirectShow output).Win 7 x64, i7 4770k, 16GB Ram, R9 290 Gaming
djdynamite123
New Member
I seriously hope this gets sorted because you can get some damn sexy looking quality streaming using quicksync and certain quicksync encoder settings.
dacoder
Member
IK this is old, but i found a REAL solution.
First off, bios must have audio enabled.
Set the RAM there to something high, leaving it on auto would cause QSV error again.
Computer > Device Manager > Display Adapters > Intel HDxxxx > Uninstall (CHECK "uninstall driver software")
Restart PC
Go here to get August's IRIS drivers, http://www.guru3d.com/files-details/intel-iris-and-hd-graphics-driver-v15-36-3-64-download.html
Intel actually deleted that from their site in 3/2015 so thats the only download I found to be good.
Right click the .rar, properties, un-block
Exctract all
Install
That solved it for me on Windows 7 64bit.
2 Hours stream, no issues.
UPDATE: Broke after some windows updates.
First off, bios must have audio enabled.
Set the RAM there to something high, leaving it on auto would cause QSV error again.
Computer > Device Manager > Display Adapters > Intel HDxxxx > Uninstall (CHECK "uninstall driver software")
Restart PC
Go here to get August's IRIS drivers, http://www.guru3d.com/files-details/intel-iris-and-hd-graphics-driver-v15-36-3-64-download.html
Intel actually deleted that from their site in 3/2015 so thats the only download I found to be good.
Right click the .rar, properties, un-block
Exctract all
Install
That solved it for me on Windows 7 64bit.
2 Hours stream, no issues.
UPDATE: Broke after some windows updates.
Last edited:
Does anyone know if this issue is fixed with Win 10? Just weird how it was working and then a windows patch came out and it stopped working. Anyone know of a another program that will let you capture game footage with Quick Sync? If OBS is not going to support it, might move on to something else that does. Thought about donating money to the project but if it does not work, not sure why I should support with money. I know a lot of people use it but I can never get my videos to look as good as others without the Quick Sync.
After running OBS for like half a year without major I foolishly used Win Update to update my Intel Graphics driver. After that OBS crashed after some minutes with this error. I tried all the new drivers from Intel without success. Then I remembered that I still had a driver I downloaded half a year ago when I clean installed Windows.
After using this driver I had not had a single crash of OBS but I could only test about 15-20 min each time cause my game crashed because of a Nvidia driver issue. With a new Nvidia driver I just played for an hour without OBS problem and it looks like everything is back to normal.
So the Intel driver I used is Version: 15.31.9.64.3165 from May 10, 2013.
My System:
Asrock Z77 Extreme 4
Intel i5-3570K
Nvidia GTX 560
I only use OBS to capture locally and not for streaming, but I guess it (if it works) should work for streaming too.
By the way, this driver version is the only one where I can see settings in the Intel Graphics setting menu in the Display tab in the advanced Settings menu. Maybe this already shows some problems.
After using this driver I had not had a single crash of OBS but I could only test about 15-20 min each time cause my game crashed because of a Nvidia driver issue. With a new Nvidia driver I just played for an hour without OBS problem and it looks like everything is back to normal.
So the Intel driver I used is Version: 15.31.9.64.3165 from May 10, 2013.
My System:
Asrock Z77 Extreme 4
Intel i5-3570K
Nvidia GTX 560
I only use OBS to capture locally and not for streaming, but I guess it (if it works) should work for streaming too.
By the way, this driver version is the only one where I can see settings in the Intel Graphics setting menu in the Display tab in the advanced Settings menu. Maybe this already shows some problems.
Kisai
New Member
I'll apologize for bumping this in advance...
Conditions under which QSVHelper.exe dies:
Running for 2hours+ which correlates with roughly 10GB of data.
Running where the output rate exceeds 100Mbits for extended amounts of time. I'm not sure the exact point it did it, but bright scenery in FFXIV will send the bitrate into the 70's with ICQQuality at 21 and using ICQ Rate control. Normally one wouldn't even override QSV, but it's CBR is awful.
Something I want to point out however... for whatever reason, OBS is using an older version of QSVhelper.exe (32bit) even with the 64bit OBS. If I download the source, compile QSVHelper as 64bit, it exhibits the same problem, however I'll note this warnings:
Warning 2 warning C4267: '=' : conversion from 'size_t' to 'mfxU16', possible loss of data \OBS-master\QSVHelper\QSVStuff.cpp 182 1 QSVHelper
Warning 3 warning C4267: 'initializing' : conversion from 'size_t' to 'unsigned int', possible loss of data \OBS-master\QSVHelper\QSVStuff.cpp 189 1 QSVHelper
Warning 4 warning C4267: '=' : conversion from 'size_t' to 'mfxU16', possible loss of data \OBS-master\QSVHelper\QSVStuff.cpp 217 1 QSVHelper
Warning 5 warning C4267: '=' : conversion from 'size_t' to 'mfxU16', possible loss of data \OBS-master\QSVHelper\QSVStuff.cpp 226 1 QSVHelper
Warning 6 warning C4267: '=' : conversion from 'size_t' to 'uint16_t', possible loss of data \obs-master\obs-master\qsvhelper\Encoder.h 273 1 QSVHelper
Warning 7 warning C4267: '=' : conversion from 'size_t' to 'uint16_t', possible loss of data \obs-master\qsvhelper\Encoder.h 274 1 QSVHelper
Warning 8 warning C4267: 'argument' : conversion from 'size_t' to 'mfxU16', possible loss of data \obs-master\qsvhelper\Encoder.h 290 1 QSVHelper
Warning 9 warning C4267: '=' : conversion from 'size_t' to 'int32_t', possible loss of data \obs-master\qsvhelper\Encoder.h 324 1 QSVHelper
Warning 10 warning C4267: 'initializing' : conversion from 'size_t' to 'uint32_t', possible loss of data C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\utility 157 1 QSVHelper
Note the third, and the last two warnings are cast warnings from size_t to int32_t. This means a 64-bit number (on a 64bit system) would "roll over"
So my best guesses, based on what I've been able to reliably crash QSVHelper.exe with are numbers that have been over-run some internal counter. Because I've been able to have it crash at 16 minutes when the data rates end up at 120Mbits.
But, as for what actually sends the "killed" to OBS:
void ProcessEncodedFrame(List<DataPacket> &packets, List<PacketType> &packetTypes, DWORD outputTimestamp, DWORD &out_pts, mfxU32 wait=0)
{
if (!filled_bitstream_waiter.wait_for(2, wait))
{
if (wait <= 0)
return;
TerminateProcess(qsvhelper_process, (UINT)-1);
AppWarning(L"Terminating QSVHelper.exe after timeout");
helper_killed = true;
return;
}
...
Is OBS itself. It looks like it does it if there's 2 seconds without any data. Such is the case if your stream fades in and out when not CBR.
As for how to fix any of this. I'm not really much of a C++ developer, I'm basically speculating, and OBS doing this doesn't reliably create any crash dumps unless OBS locks up.
Related, but unrelated.
DirectX11. I was using NVenc before QSV, because it worked just fine in DX9, but when I switched to DX11, NVenc just kept sending blank frames, so I'd go for like half an hour thinking it's been streaming a 8Mbit stream, but then when I pull the video it's been sending empty frames for most of that time. So that's why I switched to QSV, but it produced awful realtime CBR, so I had another computer do the bitrate reduction. But, good gawd the amount of times QSV crashes makes me question if it's even worth the effort if I lose 25% of the the stuff I've recorded randomly between 15 minutes and 2 hours. I lost enough already with the NVenc.
Anyhow, two of the hangs related show "Cross-thread" in the Windows log, but it doesn't appear mean anything since those were user-initiated closing OBS due to the stream being told to stop, and not responding.
Conditions under which QSVHelper.exe dies:
Running for 2hours+ which correlates with roughly 10GB of data.
Running where the output rate exceeds 100Mbits for extended amounts of time. I'm not sure the exact point it did it, but bright scenery in FFXIV will send the bitrate into the 70's with ICQQuality at 21 and using ICQ Rate control. Normally one wouldn't even override QSV, but it's CBR is awful.
Something I want to point out however... for whatever reason, OBS is using an older version of QSVhelper.exe (32bit) even with the 64bit OBS. If I download the source, compile QSVHelper as 64bit, it exhibits the same problem, however I'll note this warnings:
Warning 2 warning C4267: '=' : conversion from 'size_t' to 'mfxU16', possible loss of data \OBS-master\QSVHelper\QSVStuff.cpp 182 1 QSVHelper
Warning 3 warning C4267: 'initializing' : conversion from 'size_t' to 'unsigned int', possible loss of data \OBS-master\QSVHelper\QSVStuff.cpp 189 1 QSVHelper
Warning 4 warning C4267: '=' : conversion from 'size_t' to 'mfxU16', possible loss of data \OBS-master\QSVHelper\QSVStuff.cpp 217 1 QSVHelper
Warning 5 warning C4267: '=' : conversion from 'size_t' to 'mfxU16', possible loss of data \OBS-master\QSVHelper\QSVStuff.cpp 226 1 QSVHelper
Warning 6 warning C4267: '=' : conversion from 'size_t' to 'uint16_t', possible loss of data \obs-master\obs-master\qsvhelper\Encoder.h 273 1 QSVHelper
Warning 7 warning C4267: '=' : conversion from 'size_t' to 'uint16_t', possible loss of data \obs-master\qsvhelper\Encoder.h 274 1 QSVHelper
Warning 8 warning C4267: 'argument' : conversion from 'size_t' to 'mfxU16', possible loss of data \obs-master\qsvhelper\Encoder.h 290 1 QSVHelper
Warning 9 warning C4267: '=' : conversion from 'size_t' to 'int32_t', possible loss of data \obs-master\qsvhelper\Encoder.h 324 1 QSVHelper
Warning 10 warning C4267: 'initializing' : conversion from 'size_t' to 'uint32_t', possible loss of data C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\utility 157 1 QSVHelper
Note the third, and the last two warnings are cast warnings from size_t to int32_t. This means a 64-bit number (on a 64bit system) would "roll over"
So my best guesses, based on what I've been able to reliably crash QSVHelper.exe with are numbers that have been over-run some internal counter. Because I've been able to have it crash at 16 minutes when the data rates end up at 120Mbits.
But, as for what actually sends the "killed" to OBS:
void ProcessEncodedFrame(List<DataPacket> &packets, List<PacketType> &packetTypes, DWORD outputTimestamp, DWORD &out_pts, mfxU32 wait=0)
{
if (!filled_bitstream_waiter.wait_for(2, wait))
{
if (wait <= 0)
return;
TerminateProcess(qsvhelper_process, (UINT)-1);
AppWarning(L"Terminating QSVHelper.exe after timeout");
helper_killed = true;
return;
}
...
Is OBS itself. It looks like it does it if there's 2 seconds without any data. Such is the case if your stream fades in and out when not CBR.
As for how to fix any of this. I'm not really much of a C++ developer, I'm basically speculating, and OBS doing this doesn't reliably create any crash dumps unless OBS locks up.
Related, but unrelated.
DirectX11. I was using NVenc before QSV, because it worked just fine in DX9, but when I switched to DX11, NVenc just kept sending blank frames, so I'd go for like half an hour thinking it's been streaming a 8Mbit stream, but then when I pull the video it's been sending empty frames for most of that time. So that's why I switched to QSV, but it produced awful realtime CBR, so I had another computer do the bitrate reduction. But, good gawd the amount of times QSV crashes makes me question if it's even worth the effort if I lose 25% of the the stuff I've recorded randomly between 15 minutes and 2 hours. I lost enough already with the NVenc.
Anyhow, two of the hangs related show "Cross-thread" in the Windows log, but it doesn't appear mean anything since those were user-initiated closing OBS due to the stream being told to stop, and not responding.
Kisai
New Member
So I did some more digging.
Every instance where QSVHelper.exe was killed, the logfile will show this:
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
Warning -- Terminating QSVHelper.exe after timeout
Error: QSVHelper.exe was killed, encode failed
11:36:18: Error: all frames are in use
11:36:18: Error: all frames are in use
Always 10 "Error: all frames are in use" followed by the timeout.
These error messages are inside the RequestBuffers function of Encoder_QSV.cpp.
So my next guess on this is that whatever "buffers" are being set for Quicksync just aren't high enough, but the message OBS gives to the user is completely unclear as to how to fix it.
Every instance where QSVHelper.exe was killed, the logfile will show this:
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
11:36:17: Error: all frames are in use
Warning -- Terminating QSVHelper.exe after timeout
Error: QSVHelper.exe was killed, encode failed
11:36:18: Error: all frames are in use
11:36:18: Error: all frames are in use
Always 10 "Error: all frames are in use" followed by the timeout.
These error messages are inside the RequestBuffers function of Encoder_QSV.cpp.
So my next guess on this is that whatever "buffers" are being set for Quicksync just aren't high enough, but the message OBS gives to the user is completely unclear as to how to fix it.
Dave_Scream
New Member
I have almost the same rig mate)) Asus Z77, 3570k @ 4.6, GTX560ti, Windows 7 x64
I confirm that after reinstall Intel HD driver to version 3165, QSVHelper do not crush.
So to resolve crashes there is two ways:
1. Use Windows 8
2. Use old Intel HD Graphics Driver (15.31.9.64.3165 from May 10, 2013).
Last edited:
TheRealBigBudz
New Member
Tried setting up QuickSync today with my i5-3570k / HD 7950 / 8gb DDR3 gaming rig.
I kept getting the QSV crash as mentioned in the title every few minutes once in game (never happened while idling).
Then I found this thread, downloaded the .3165 driver from May, and installed it in safe mode. Just streamed CS:GO for 4 hours straight with no issue.
I went from ~200 FPS in game to ~300 FPS in game while streaming in 720p60fps. Pretty amazing stuff I must say!
I kept getting the QSV crash as mentioned in the title every few minutes once in game (never happened while idling).
Then I found this thread, downloaded the .3165 driver from May, and installed it in safe mode. Just streamed CS:GO for 4 hours straight with no issue.
I went from ~200 FPS in game to ~300 FPS in game while streaming in 720p60fps. Pretty amazing stuff I must say!
- Status