[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 https://github.com/xbmc/inputstream.adaptive/blob/63e433d4fb62ae1293fc915620a0d918ad9b2186/src/decrypters/widevineandroid/WVCencSingleSampleDecrypter.cpp#L171-L175 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.

[CastagnaIT]

just out of curiosity try test this build on Kodi 22: https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.adaptive/detail/PR-1724/15/artifacts

[Maven85]

Unfortunately no improvement.

[kjvalencik]

I encountered this same issue. I have two identical devices (Firestick 4k Max) with identical Kodi versions and Disney+ was only playing on one device--interestingly only certain content.

Same errors as listed in this thread. The working version was on 21.5.9 and the non-working version was on 22.1.10. Downgrading resolved the issue.

Let me know if there's any additional debugging that I can provide.

[CastagnaIT]

I have spent days to investigating without results, and i have no indications of what is wrong, not from the log, not from logcat, not even from the extradata data so having more debug logs is unfortunately useless

the problem is very specific to a single platform (Android ARM 32-bit) which is quite strange

as far as i am concerned the only way for me to investigating to a solution is to have the same android device, or a similar device with same platform in my hands, currently i have only arm64 devices

[kjvalencik]

@CastagnaIT Wow! Sounds like an elusive bug. I'll setup a dev environment and look around a bit. Arm 32-bit is a good hint since that's the case for me (Firestick is a 64-bit CPU, but runs 32-bit Android).

Am I understanding correctly that the version in https://github.com/xbmc/inputstream.adaptive/pull/1737 before the force push worked and the version after does not? Is that a good minimal diff for me to investigate?

Thanks for the pointers. I know you've already spent a bunch of time on this.

[CastagnaIT]

not exactly, there were initially two problems, one has been corrected that should be related to change "before" force push, the second problem should be about https://github.com/xbmc/inputstream.adaptive/pull/1728 change so https://github.com/xbmc/inputstream.adaptive/pull/1728 if reverted "solve" the problem since revert is not a solution, its needed to understand why this happens

[Maven85]

@CastagnaIT I can confirm that @rootcoder's change solves my problem with D+

[CastagnaIT]

in reference to comment https://github.com/xbmc/inputstream.adaptive/issues/1885#issuecomment-3062405725 about code change

diff --git a/src/samplereader/FragmentedSampleReader.cpp b/src/samplereader/FragmentedSampleReader.cpp
index ddf934dd..53c4707f 100644
--- a/src/samplereader/FragmentedSampleReader.cpp
+++ b/src/samplereader/FragmentedSampleReader.cpp
@@ -256,6 +256,7 @@ bool CFragmentedSampleReader::GetInformation(kodi::addon::InputstreamInfo& info)
       extraData, (m_decrypterCaps.flags & DRM::DecrypterCapabilites::SSD_ANNEXB_REQUIRED) != 0))
   {
     info.SetExtraData(extraData);
+    m_codecHandler->m_extraData.SetData(extraData.data(), static_cast<AP4_Size>(extraData.size()));
     isChanged = true;
   }
 
@@ -503,9 +504,12 @@ void CFragmentedSampleReader::UpdateSampleDescription()
       return;
     }
   }
+#ifndef ANDROID
+  // this causes black screen on some android devices
   else {
     m_protectedDesc = nullptr;
   }
+#endif
 
   LOG::LogF(LOGDEBUG, "Codec fourcc: %s (%u)", CODEC::FourCCToString(desc->GetFormat()).c_str(),
             desc->GetFormat());

the change to line ~256 maybe its correct but i need to verify the flow the change at line 504, its a weird hack and this will broke other streams, you are forcing use decrypter on unencrypted packets, and ifdeffing is not an acceptable solution

if the change at line 256 is enough to solve your problem, i will try investigate on next days to verify correctness, if also the line 504 is required, then its needed more deeply investigations

[Maven85]

I will test it and then give feedback