Skip to content
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

Merged
merged 22 commits into from
Jun 10, 2024

Conversation

freeboub
Copy link
Collaborator

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

freeboub and others added 15 commits May 5, 2024 21:06
…ideo

# Conflicts:
#	android/src/main/java/com/brentvatne/exoplayer/ReactExoplayerViewManager.java
#	src/Video.tsx
…fix/avoidVideoResizingFlickering

# Conflicts:
#	.github/ISSUE_TEMPLATE/bug-report.yml
}
DRMProps drmProps = DRMProps.parse(drm);
if (drmProps != null) {
videoView.setDrm(drmProps);
Copy link
Collaborator

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)

Copy link
Collaborator

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.

Copy link
Collaborator Author

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 !

Copy link
Member

@KrzysztofMoch KrzysztofMoch left a 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

freeboub added 2 commits May 30, 2024 10:40
…ideo into chore/refactorDrmProps

# Conflicts:
#	android/src/main/java/com/brentvatne/exoplayer/ReactExoplayerView.java
#	android/src/main/java/com/brentvatne/exoplayer/ReactExoplayerViewManager.java
}
DRMProps drmProps = DRMProps.parse(drm);
videoView.setDrm(drmProps);
videoView.setUseTextureView(false);
Copy link
Collaborator

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)

Copy link
Collaborator Author

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?

Copy link
Collaborator

@YangJonghun YangJonghun May 30, 2024

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🫡

Copy link
Collaborator Author

@freeboub freeboub May 31, 2024

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 !

Copy link
Collaborator Author

@freeboub freeboub May 31, 2024

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

Copy link
Collaborator

@YangJonghun YangJonghun Jun 1, 2024

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
@freeboub freeboub force-pushed the chore/refactorDrmProps branch from bb17e1b to 8b0e2a6 Compare June 7, 2024 13:08
this.drmProps = drmProps;
if (drmProps != null && drmProps.getDrmType() != null) {
this.drmProps.setDrmUUID(Util.getDrmUuid(drmProps.getDrmType()));
}
Copy link
Collaborator

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.

Copy link
Collaborator Author

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 ...

Copy link
Collaborator

@YangJonghun YangJonghun Jun 10, 2024

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.

@freeboub freeboub merged commit cfb5b1c into TheWidlarzGroup:master Jun 10, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants