-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Chore(android): refactor drm props #3846
Chore(android): refactor drm props #3846
Conversation
…oplayerView code size
…ideo # Conflicts: # android/src/main/java/com/brentvatne/exoplayer/ReactExoplayerViewManager.java # src/Video.tsx
…fix/avoidVideoResizingFlickering # Conflicts: # .github/ISSUE_TEMPLATE/bug-report.yml
android/src/main/java/com/brentvatne/exoplayer/ReactExoplayerView.java
Outdated
Show resolved
Hide resolved
…tive-video into chore/refactorDrmProps
} | ||
DRMProps drmProps = DRMProps.parse(drm); | ||
if (drmProps != null) { | ||
videoView.setDrm(drmProps); |
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.
nit; If the drm prop is inserted as null, the old drm prop will still be there. wouldn't it be a problem? (I think it's a problem from the old behavior, not from this change)
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.
If purpose of this PR is to preserve the old behavior, it's fine.
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.
No It was not the goal of this PR, So I remove the test.
It doesn't make sense to keep previous DRM config when user remove it !
Thank you for the catch !
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.
LGTM
I agree with @YangJonghun that we should considerate if we need old behaviour
…ideo into chore/refactorDrmProps # Conflicts: # android/src/main/java/com/brentvatne/exoplayer/ReactExoplayerView.java # android/src/main/java/com/brentvatne/exoplayer/ReactExoplayerViewManager.java
android/src/main/java/com/brentvatne/exoplayer/ReactExoplayerView.java
Outdated
Show resolved
Hide resolved
} | ||
DRMProps drmProps = DRMProps.parse(drm); | ||
videoView.setDrm(drmProps); | ||
videoView.setUseTextureView(false); |
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.
if drm props is null, we have to follow injected prop (useSecureView or useTextureView)
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.
Yes you are right, thank you. I am also wondering if it can make sense to use Surface View by default? What is your opinion?
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.
It's hard question. because it depends on what user using this library for
I prefer SurfaceView from a user perspective. In most situations, this is beneficial.
However, it can cause to make issue threads being created by people who don't read the documentation or don't know much about Android.
Decision is yours🫡
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.
I am working to remove this videoView.setUseTextureView(false);
It is a bit. The ugly solution is to add new variables recording the last calls to setUseTextureView and setUseSecureView and apply it in the else.
I would prefer implement it in another way:
- move DRM & viewType inside the source prop.
-
It will decrease the bridge usage, avoid restarting playback if we receive DRM prop after source and make cleaner code.
I will try to implement it, but I think we can merge this part now, and the next fix will come soon !
I propose to merge this PR as the setUseTextureView is already present in the code !
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.
@YangJonghun here is The patch I would to do for ensure we correctly reset the view state in the app:
#3867
initially I didn't plan to it right now, but you make me accelerate :)
Still in draft as I need to do the same thing on ios, but that's the idea.
Let me know you thought please !
And ping @KrzysztofMoch
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.
I apologize for late response.
I left related comment in #3867 .
…ideo into chore/refactorDrmProps # Conflicts: # android/src/main/java/com/brentvatne/exoplayer/ReactExoplayerView.java
bb17e1b
to
8b0e2a6
Compare
this.drmProps = drmProps; | ||
if (drmProps != null && drmProps.getDrmType() != null) { | ||
this.drmProps.setDrmUUID(Util.getDrmUuid(drmProps.getDrmType())); | ||
} |
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.
if (drmProps != null && drmProps.getDrmType() != null) {
this.drmProps.setDrmUUID(Util.getDrmUuid(drmProps.getDrmType()));
}
I think above code could be moved inside the DrmProps.parse fn.
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.
I agree, but my problem with that is that I will have to import Utils from media3 in drmProp.kt. I really want to avoid including player specific code in the utils / data management classes ...
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.
I understand. but for that reason, it seems like parse function should be categorized in a different class. (for example, DRMUtils)
And I think removing dependencies from Utils seems hard to avoid because there's so much to prepare to implement as the SDK requires.🥲
If you worried deep dependencies, I recommend copying media3's implementation.
However, I'm not suggesting this because I think it's a serious issue, so you don't have to fix it.
Summary
Refactor DRM props into a dedicated class
Motivation
Keep code clean and modularized
Changes
Just move all DRM subProps to a dedicated class
Test plan
Can be tested with sample