-
Notifications
You must be signed in to change notification settings - Fork 238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Android] Use multiple WV sessions #734
Conversation
initial results look promising:
So i think this solves the problem of having both encrypted audio and video streams on android causing pixalation / buffering. |
@CastagnaIT |
do not think "preinit" opens only one session without any check but in your commit should be better if you add a comment somewhere for this particularity, |
I'd love to add a comment if I knew exactly what it was doing. I simply going off peaks suggestion in the linked forum. Maybe I'll just put "return false to allow multiple sessions for different streams" Be handy if you could test with Netflix with the init stuff. Just to make sure it doesn't affect that |
yes i will do |
Tried on my smartphone played 3 videos without problems the data there are |
I'm not sure if I know the right answer to this, but should we have a setting for this behaviour? Peak3d did mention that the tradeoff is streams may be slower to start up due to the need to create multiple DRM sessions in Android which would affect all users, not just ones affected by the issue this solves. |
I havn't noticed any delayed start up
Pretty sure more reliable streams should be more important than 0.5s delay?
Adding a setting just means more users reporting the issue and then needing
to figure out that's how they fix it. So would need to be default to true
at least. Then what's the point?
I'm sure we could make up the slight delay (if any) by improving other code
:)
…On Thu, 29 Jul 2021, 18:26 Glenn Guy, ***@***.***> wrote:
I'm not sure if I know the right answer to this, but should we have a
setting for this behaviour? Peak3d did mention that the tradeoff is streams
may be slower to start up due to the need to create multiple DRM sessions
in Android which would affect all users, not just ones affected by the
issue this solves.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#734 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABPQAKLJDGFQELEVEOKPUWTT2DYA3ANCNFSM5AISIQDA>
.
|
In my test i did not notice any startup slowdowns noticeable |
I don't mind adding a setting. But I actually think we need less settings, not more. As IA is used by other add-ons, it's not really that obvious to end users that it has its own settings. Therefore, as less settings and best defaults is always best I reckon. We are doing a good job if users never need to adjust the settings :) When adaptive comes in, then that should remove need for users to muck around with bandwidth settings as well . |
@matthuisman all good points, totally agree :) |
:) UPDATE: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
fixes: #693
as per peaks comment here:
https://forum.kodi.tv/showthread.php?tid=350092&pid=2908844#pid2908844
This fixes pixalation issues on some streams mainly on Sony android tvs.
Seems the issue appears when both audio and video are encrypted
Test build (Android AARCH64)
https://jenkins.kodi.tv/job/xbmc/job/inputstream.adaptive/job/PR-734/5/artifact/cmake/addons/build/zips/inputstream.adaptive+android-aarch64/inputstream.adaptive-2.6.22.zip
Test build (Android ARMV7)
https://jenkins.kodi.tv/job/xbmc/job/inputstream.adaptive/job/PR-734/5/artifact/cmake/addons/build/zips/inputstream.adaptive+android-armv7/inputstream.adaptive-2.6.22.zip