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

Failure to play content with 8-byte IV after playing content with 16-byte IV #6982

Closed
sruditsky opened this issue Feb 16, 2020 · 1 comment
Closed
Assignees
Labels

Comments

@sruditsky
Copy link

sruditsky commented Feb 16, 2020

Issue description

Playing 8-byte IV content after 16-byte IV content on a single instance of ExoPlayer results in a garbled video.

Reproduction steps

Let's assuming we have 2 DASH content items: one with 16-byte IV and the second with 8-byte IV.
Create an instance of ExoPlayerImpl and play both items in order on a single ExoPlayerImpl instance.
I.e.
a) prepare the 16-byte IV item
b) play it
c) stop
d) prepare the 8-byte IV item
Here the playback breaks.

Link to test content

Was observed on a proprietary content.

A full bug report captured from the device

N/A

Version of ExoPlayer being used

2.9.4 and 2.10.6

Device(s) and version(s) of Android being used

Was observed on many devices. For example on FireTv 4K stick.

NOTE: Location of the issue in the code:

The com.google.android.exoplayer2.source.SampleQueue.readEncryptionData()
method allocates buffer.cryptoInfo.iv if one is not already allocated.

However, if buffer.cryptoInfo.iv is already allocated and contains an old IV, the array is not cleaned.
So, if ivSize in readData(offset, buffer.cryptoInfo.iv, ivSize) is smaller than it was for the previous IVs
we get a wrong value for IV

@ojw28 ojw28 self-assigned this Feb 16, 2020
icbaker pushed a commit that referenced this issue Feb 17, 2020
CryptoInfo.iv length is always 16. When the actual initialization vector
is shorter, zero out the trailing bytes.

Issue: #6982
PiperOrigin-RevId: 295575845
@ojw28
Copy link
Contributor

ojw28 commented Feb 17, 2020

Thanks for the clear issue report. This has always been broken (!), so I guess your use case isn't a particularly common one :). It should be fixed by the change above; please let us know if you still see any issues.

@ojw28 ojw28 closed this as completed Feb 17, 2020
ojw28 added a commit that referenced this issue Feb 18, 2020
CryptoInfo.iv length is always 16. When the actual initialization vector
is shorter, zero out the trailing bytes.

Issue: #6982
PiperOrigin-RevId: 295575845
@google google locked and limited conversation to collaborators Apr 18, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants