[Bug] Black screen when playing D+ on Android

[Maven85]

Describe the problem

When playing a stream from D+, all you see is a black screen while the sound is heard.

Possible fix

No response

Steps to reproduce

No response

Debug log

kodi_debug.log

Stream manifest file(s)

manifest_1732623875_master.txt
manifest_1732623876_child-video.txt
manifest_1732623877_child-audio.txt
manifest_1732623878_child-subtitle.txt
manifest_1732623883_child-video.txt

Additional info

The problem has been occurring since #1728

Operating system(s)

Android

Operating system version(s)

Android 9

InputStream Adaptive version(s)

v22.1.10

Kodi version(s)

v22

[CastagnaIT]

can you provide the login file to my email as last time?
im not able to reproduce the problem with HLS ISA samples
could be that D+ have something different

[CastagnaIT]

login received thanks,
i tried a movie and a tv show episode (loki) on nvidia shield and playback works correctly, same codec (avc)

try check kodi Player settings, mine are:
-allow hardware acceleration mediacodec surface ENABLED
-allow hardware acceleration mediacodec ENABLED
-use decode filters ENABLED

on ISAdaptive expert setting, make sure "disable secure decoder" is DISABLED

there is a particular video title that dont works?

[Maven85]

I tested 3 devices:

Fire HD 8 (2020) -> black screen from the beginning of a video
Chromecast with GoogleTV -> Video plays correctly from the start. However, if the resolution changes from one segment to the next, you will also have a black screen
Shield (2015) -> like the chromecast

[CastagnaIT]

Chromecast with GoogleTV -> Video plays correctly from the start. However, if the resolution changes from one segment to the next, you will also have a black screen

ok i reproduced the problem on my shield
seems to be something related with resolution change

[CastagnaIT]

i tested more,
the black screen happens every time that you try to switch from SD to 1080p (tested with "test" mode and OSD mode)
you affirm that the problem come from v22.1.10, but also v22.1.9 is affected of same problem
imo #1728 can be excluded

you cant test older ISA versions becase all them have an old standing bug that make crash kodi on HLS quality switching
my suspects is that this problem was already existing, for now no idea of the reasons behind it

a temporary workaround is set ISA stream quality to "fixed", so that avoid change stream quality

another weird thing is that from my log i can see more errors like this
2024-11-28 14:58:43.075 T:31260 error <general>: CDVDVideoCodecAndroidMediaCodec::AddData error
but there are no on your log
logcat show more

11-28 16:04:57.156 13985   937 W MediaCodec: Log queueSecureInputBuffer error: -2001
11-28 16:04:57.156 13985   945 W System.err: android.media.MediaCodec$CryptoException: Crypto key not available
11-28 16:04:57.156 13985   945 W System.err: 	at android.media.MediaCodec.native_queueSecureInputBuffer(Native Method)
11-28 16:04:57.156 13985   945 W System.err: 	at android.media.MediaCodec.queueSecureInputBuffer(MediaCodec.java:3066)
11-28 16:04:57.156 13985   945 E Kodi    : 2024-11-28 16:04:57.156 T:945     error <general>: CDVDVideoCodecAndroidMediaCodec::AddData error
11-28 16:04:57.167  3356  3400 E WVCdm   : [policy_engine.cpp(51):CanDecryptContent] Provided content key is not in license: key_id = AD1CFC1EC5F141299319D83821170F80
11-28 16:04:57.167  3356  3400 E WVCdm   : Decrypt error in session sid64 during a sample with protected data: 5

[CastagnaIT]

ok then at least one of the problems come from always the same bad use of HasLicenseKey

inputstream.adaptive/src/decrypters/widevineandroid/WVCencSingleSampleDecrypter.cpp

Lines 171 to 175 in 63e433d

	bool CWVCencSingleSampleDecrypterA::HasLicenseKey(const std::vector<uint8_t>& keyId)
	{
	// true = one session for all streams, false = one sessions per stream
	// false fixes pixaltion issues on some devices when manifest has multiple encrypted streams
	return true;

keep it "true" to reuse always same session its wrong
when the init data have different KID's e.g. from SD to HD the license server dont provide both key's
and so decrypting broken

please try install this test build on your devices and let me know
https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.adaptive/detail/PR-1737/1/artifacts

[Maven85]

It seems that there are 2 different problems.
The problem with changing segments is fixed with your version.
The problem with my Fire HD 8 still exists.

I created 2 debug logs again:
kodi_1.log -> Everything works
kodi_2.log -> Black screen from the beginning

Maybe you can see something.

[CastagnaIT]

i dont see differences on log also extradata have same size
weird that only that device have this problem
try disable "use decode filters" from kodi player setting, hoping kodi pick google codec decoder

if dont works re-enable it,
play the video and get the logcat, maybe it can give some hint

[Maven85]

Where exactly can I find the setting? Do you use the standard skin estuary?

[CastagnaIT]

[Maven85]

Thanks, my Kodi was too old (November 24th).
Changing the setting didn't change anything.

Here 2 logcats:
logcat_1.log -> Everything works
logcat_2.log -> Black screen from the beginning

[CastagnaIT]

following lines on logcat2 (black screen) there are no, so media codec surface is not initialized
and without it images cannot be rendered

11-29 06:39:31.252 21677 21695 I Kodi : 2024-11-29 06:39:31.252 T:21695 info : Instancing CRendererMediaCodecSurface
11-29 06:39:31.252 21677 21695 I Kodi : 2024-11-29 06:39:31.252 T:21695 info : CRendererMediaCodecSurface::Configure
11-29 06:39:31.352 21677 21815 I MediaCodecLogger: [ASAP] HW.video.avc Got First Frame Render 176225341(1585)
11-29 06:39:31.352 21677 21815 I MediaCodecLogger: App sets Timestamps for render in SurfaceFlinger

by following the source code means that following setting

has been disabled

make sure its enabled (both HW accel must be enabled)

if it is enabled, try play the video, and without stop the video, try navigate to kodi settings and check if "surface" setting has been for some reason disabled just before playback starts

[Maven85]

The settings were activated before playing. While playing, I checked again and the settings are still enabled.

The setup is the same in both playback attempts, only the input stream adaptive version has been changed.

How can it be that the media codec interface is not initialized with inputstream adaptive 22.1.10?

[CastagnaIT]

im trying to understand, its weird because on others devices "surface" works
could be some kind of problem with videobuffer

[Maven85]

I compared the logs and saw that the order was different in one place. Can that be a reason?

[CastagnaIT]

i dont think drm things can be async, and no changes on drm code

i tried compare vp packets sizes but i dont find differences between the 2 ISA versions
i tried test last ISA ver on my old android armv7 device but it play D+ videos correctly...

since im unable to reproduce locally the only way is build and test each ISA change reverted to try find something more
i have no more ideas

here i reverted suggested commit + above fix included
https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.adaptive/detail/PR-1737/2/artifacts
try to see what happen on Fire HD 8

[Maven85]

the version works for me.

[CastagnaIT]

try test this
https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.adaptive/detail/PR-1737/3/artifacts

[Maven85]

Unfortunately no improvement.

[CastagnaIT]

im not able to find whats could be wrong with #1728
i verified code tons of times
also compared extradata (printed as base64) with and without that PR
and the extradata and its conversion seem perfect as follow

22.1.10 with #1728 reverted
2024-12-02 10:02:35.889 T:9317 error <general>: AddOnLog: inputstream.adaptive: GetInformation: EXTRADATA: AAAAAWdkACis2UB4AiflwFqAgICgAAADACAAAAYcCAABhRkAABA2ZSWYB8YMZYAAAAABaOk7PI8=
22.1.10 + PR fixes
2024-12-02 10:15:56.998 T:11830 error <general>: AddOnLog: inputstream.adaptive: GetInformation: EXTRADATA: AAAAAWdkACis2UB4AiflwFqAgICgAAADACAAAAYcCAABhRkAABA2ZSWYB8YMZYAAAAABaOk7PI8=

the #1728 only change this behaviour but the resulting value is equal
atm im run out of ideas

[Maven85]

OK, too bad. Nevertheless, thank you very much for your efforts. If you need anything else, let me know.