Guest - Testers are needed for the reworked CDateTime core component. See... https://forum.kodi.tv/showthread.php?tid=378981 (September 29) x
Bug Crashes when trying to resume playback of x265 from time X
#1
Tried 16.1 and 17 on windows 10 64 bit, I find that kodi crashes every time I try to resume playback of this certain file. I tell it to start playing, screen goes black and then "kodi has stopped working"

Event Viewer records the error as:
Faulting application name: kodi.exe, version: 16.9.801.0, time stamp: 0x57b96f7c
Faulting module name: ntdll.dll, version: 10.0.10586.306, time stamp: 0x571afb7f
Exception code: 0xc0000005
Fault offset: 0x00049f83
Faulting process ID: 0x540
Faulting application start time: 0x01d206fbe4997d85
Faulting application path: C:\Program Files (x86)\Kodi\kodi.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report ID: f6a4edb6-cc8d-46a1-b3b2-aad541c6b88e
Faulting package full name:
Faulting package-relative application ID:


The pastebin of kodi's log is: http://pastebin.com/8danQVaN

I have a DMP file too if needed

Setup wise, my htpc connects via hdmi to my denon amp, then to a 720p tv. I think I've enabled passthrough for everything the amp can handle; it's getting to be an old amp now (AVR2809 / 2009 year). th htpc is a gigabyte brix with an intel onboard gfx card

thanks for any help!

ps; if its any help I sometimes kind kodi crashing in similar ways in other contexts such as turning the tv and amp on - screen is black then appears "kodi has stopped working"
Reply
#2
From the log: rendering method forced to DXVA processor

Have you tried software rendering?
Reply
#3
Same problem here, also I've done some tests:
  • Clean install (the settings I have are inherited from the previous version).
  • Turn off audio passthrough.
  • Turn off DXVA2.
  • Force software rendering.
  • Latest Intel graphics drivers tested / default Windows 10 driver / previous Intel drivers.
No success with any adjustment.

The system is an Intel NUC i5-4250U, Windows 10 64-bit

The problem is only with the x265 codec to resume playback. Jump between chapters when playback is already in progress works OK.

Curiously on a Skylake i7-6700K system, same Windows 10 64-bit and same Intel Graphics drivers x265 resume playback works OK.

Thanks!
Reply
#4
Here you have my log if helps identify the issue:

http://pastebin.com/a3uRnSHE
Reply
#5
You're still having issues with the rednering chosen scaling method 1 is not supported by renderer Check the properties of the launch icon, comparability mode 'disable display scaling on high dpi settings' and tick compatibility mode. I did have an issue with KB2 and switched to nighties and found it fixed the problem.

P.S. Your log didn't have debug turned on in settings, which imparts much more information.
Reply
#6
Comparability mode 'disable display scaling on high dpi settings' seems have no effect.

Here a log with debug enabled: http://pastebin.com/MYdMrCn3
Reply
#7
I have the same issue with Intel HD graphics and resume HVEC files. did you find a solution?
Reply
#8
Tested today with latest nightly and results turn off DXVA2 acceleration (SW rendering) workarounds the issue.

However, this bug still exists:

Resume playback + HEVC file + Intel Graphic Drivers + DXVA2 acceleration ON = CRASH

Seems that previous beta2 has additional bug that causes turn off DXVA2 switch in GUI does not force SW rendering really.
Reply
#9
I have reproduced the issue. The crash occurs inside Intel driver. I think there is no an issue in Kodi code.
Reply
#10
I found that open-gop encode parameter is related with crash.

If x265 encode is made with --no-open-gop parameter does NOT crash on resume playback.

However, since x265 with defaults parameters produces open-gop encodes, the vast majority of x265 encodes that can be found are all "open-gop".

To confirm, I have made two encodes with all same parameters except open gop:

open-gop sample (crash)
Quote:Writing library : x265 2.1+12-11bfa0ae9710:[Windows][GCC 6.2.0][64 bit] 8bit
Encoding settings : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=240 / min-keyint=24 / scenecut=40 / rc-lookahead=20 / lookahead-slices=6 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / limit-refs=3 / no-limit-modes / weightp / no-weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=2.00 / rdoq-level=0 / psy-rdoq=0.00 / log2-max-poc-lsb=8 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ipratio=1.40 / pbratio=1.30

--no-open-gop sample (not crash)
Quote:Writing library : x265 2.1+12-11bfa0ae9710:[Windows][GCC 6.2.0][64 bit] 8bit
Encoding settings : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / no-open-gop / no-temporal-layers / interlace=0 / keyint=240 / min-keyint=24 / scenecut=40 / rc-lookahead=20 / lookahead-slices=6 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / limit-refs=3 / no-limit-modes / weightp / no-weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=2.00 / rdoq-level=0 / psy-rdoq=0.00 / log2-max-poc-lsb=8 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ipratio=1.40 / pbratio=1.30

Download x265 samples => https://mega.nz/#!o5JA3RpI!h14QP9Q9upR57...kCkCPxBIRc

Maybe the origin of crash is inside of Intel driver, however a workaround may be possible... (or not).

I think to can be interesting that a developer who knows well the decoding and VideoPlayer part of Kodi take a look to this issue.

Thanks!
Reply
#11
Good catch, but it's still an issue of Intel driver and taking in account that you wrote that Skylake has no issue I can make a conclusion that issue exists only in hybrid hevc decoding.
Reply
#12
Personally I do not think the bug is in the Intel driver. There are many layers in between: ffmpeg, DXVA2. But it is difficult to prove...

Skylake full HW HEVC decode has another problem even more serious than this on Kodi and no one seems to have noticed. The reconstructed image has a pattern of visible big macro blocks (such as a watermark). Another time I put some screenshoot.

Same streams decoded on same sytems using Skylake HW decode and native Windows 10 apps (Windows Media Player or Movies and TV) do not have this problem.
Reply
#13
No matter what happens a driver should not crash. Resuming h265 works fine on linux with same hw. Also I didn't see reports from owners nvidia or amd about the same.
Reply
#14
Same problem here.
Resume playback + HEVC file + Intel Graphic Drivers + DXVA2 acceleration ON = CRASH
Kodi 16.1 "Jarvis", Windows 10 64 bits, GPU Intel HD 4400.

Any solution?
Reply
#15
try an older GPU driver.
Reply

Logout Mark Read Team Forum Stats Members Help
Crashes when trying to resume playback of x265 from time X1