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

PIPELINE_ERROR_INVALID_STATE error when using Playready/Dash stream (mixed encrypted/unecrypted content) #1403

Open
adamtatur opened this issue Mar 13, 2024 · 10 comments

Comments

@adamtatur
Copy link

Hi,

We noticed an issue when integrating avod functionality with Playready/DASH streams. When provided manifest contains both encrypted and unencrypted periods player doesn't work properly.

  • use case 1: (unencrypted periods are played -> transition to encrypted periods)
    When trying to download new segments that are encrypted, the player returns the error:
    The player stopped because of an error MediaError: MediaError (MEDIA_ERR_DECODE) PIPELINE_ERROR_INVALID_STATE: MediaFoundationRenderer error: kCdmProxyReceivedInInvalidState (Error (0x13D) while retrieving error. (0x8004FA03)

  • use case 2: (encrypted periods are played -> transition to unencrypted periods)
    In this case, the player continues to play but the video turns green.

We checked both scenarios using Widevine/DASH configuration and everything works fine. The only thing that caught my eye was that the license fetching logic runs a few seconds before going to the encrypted parts than is the case with Playready/DASH.

Issue is presented using:

  • latest 3.x.x and 4.x.x player version
  • Microsoft Edge 122.0.2365.80
  • Win 10/11

Is there any know solution to circumvent this problem using the appropriate player configuration?

@peaBerberian
Copy link
Collaborator

peaBerberian commented Mar 19, 2024

Hi,

Interesting, we've heard by looking around some time ago of this type of problem when going from encrypted to unencrypted and vice-versa on PlayReady devices, but we've never really were able to reliably reproduce it (maybe it's also content-dependent?)

We have some old work we still maintain (we last rebased it last week) that create fake encryption metadata for initialization segments of clear Representation (408191e#diff-5182788b34332efc49b4a47fcd7ffa0af9e5698d8da035c5e8cade8e95b920ce) which is a trick we've for example seen on the shaka-player (we've never merged that development on our side as we've never really been able to reproduce the issue).

With a little work, I can make an RxPlayer version including it to see if that fixes the issue, then if it fixes this issue and seen as non-problematic with enough testing we might be able to include it in a future version.

@adamtatur
Copy link
Author

Hi,

Thanks. If this is not a problem we could check it on our side with provided RxPlayer version.

@peaBerberian
Copy link
Collaborator

peaBerberian commented Apr 23, 2024

Hi,

If it's still possible for you I updated and tested the fix/create-fake-encryption-init-segment branch. You can depend on its latest commit (which includes our build to simplify dependency on it), you can set in your package.json something like:

    "rx-player": "https://github.com/canalplus/rx-player.git#a74239e129904970c5b6497020b3f7dc38b0cb0a",

This will depend on the commit a74239e, which is currently the last commit of the fix/create-fake-encryption-init-segment branch

Can you test it to see if unencrypted/encrypted transitions (and vice-versa) works with it?

@m-scheepers
Copy link

@adamtatur are we able to plan this on our side (with rxpalyer 4) or the custom branch for testing purposes.

@peaBerberian
Copy link
Collaborator

peaBerberian commented Jul 11, 2024

Following our conversation, I just re-checked, we have two builds made, both for the RxPlayer v3 and v4.

When relying on v3, you can put on your package.json:

    "rx-player": "https://github.com/canalplus/rx-player.git#
fd615528986ef67d4dc5e22d87670296d7180b48",

When relying on v4, set instead:

    "rx-player": "https://github.com/canalplus/rx-player.git#a74239e129904970c5b6497020b3f7dc38b0cb0a",

Those commits contain built RxPlayer, so you just need to perform a npm install / yarn following this edit.

Let me know if it fixes things.

@adamtatur
Copy link
Author

Hi,

Unfortunately, the error still occurs when it comes to the case of transition from unencrypted to encrypted periods. Player throws an error:
"PIPELINE_ERROR_INVALID_STATE: MediaFoundationRenderer error: kCdmProxyReceivedInInvalidState (Error (0x13D) while retrieving error. (0x8004FA03))"
In case transition from encrypted to unencrypted periods streams works fine this time.

Checked for both rxplayer fix versions.

@peaBerberian
Copy link
Collaborator

OK so if I get this correctly, there is an improvement for encrypted -> clear (the video does not turn green anymore), but there's still a fatal error for clear -> encrypted

@peaBerberian
Copy link
Collaborator

If you're calling rxPlayer.reload() as this error happens, does it plays the encrypted part?
It will lead to a temporary black screen on clear->encrypted transitions, but it could be a last resort just in case we don't find any work-around for the issue nor can we fix this content-side.

@adamtatur
Copy link
Author

Unfortunately, using reload didn't fix an issue for clear -> encrypted transitions

@peaBerberian
Copy link
Collaborator

peaBerberian commented Jul 25, 2024

Just to keep track of the attempts of work-arounds I've made, now only for clear -> encrypted transitions:

  1. "regular" case where we're creating the MediaKeys and attaching the HTMLMediaElement before any data is buffered and then creating session lazily as we begin to consider encrypted content:

    Result: we obtain a MEDIA_ERR_DECODE on Edge PlayReady if there was clear content in the buffer as soon as we call the generateRequest EME API, even if the encrypted data is not yet pushed to a SourceBuffer.

    -> This looks to me as if it fails if the CDM starts its encryption-related logic during playback of clear content, so I've tried many work-arounds which tries to communicate to PlayReady that we're gonna push encrypted content

  2. Relying on Widevine instead

    Result: it works without issue.

    -> This looks to be a PlayReady-specific issue

  3. adding a tenc ISOBMFF box with a 0x0 key id on initialization segment for clear content (reasoning: the CDM/browser is going to see it and start some encryption-related logic)

    Result: no effect

    I also tested that work-around with most of the other described below (a test without then a test with, it seems to never have an effect for clear -> encrypted transitions)

  4. Changing the clear portion of the stream with a random one from our demo page

    Result: no effect (same MEDIA_ERR_DECODE issue)

  5. calling the createSession + generateRequest EME API with dummy data (e.g. an inexistant key id for which we'll never do the license request anyway) BEFORE ANY data (clear or encrypted) is pushed to a SourceBuffer

    Result: It buffers indefinitely when encountering encrypted media, even after reload, and even if starting directly by the encrypted media data (no clear->encrypted transition, just encrypted). Because Edge+PlayReady is like it is, this may seemingly randomly lead or not lead (read: just keep being infinitely buffering instead) to a MEDIA_ERR_SRC_NOT_SUPPORTED after many seconds in that condition

    I also closed the fake session immediately after the generateRequest call, but no change

  6. Just calling the createSession EME API and let it dangling BEFORE ANY data (clear or encrypted) is pushed to a SourceBuffer

    Result: It seems to succeed to "transition" from the clear to the encrypted content when looking at metrics, but visually and audibly this is just visual green noise and audio noise (as if it's trying to decrypt with the wrong key? That's weird because we didn't ask for any key for the first session). Same result when directly beginning with the encrypted content.
    Note: calling the reload RxPlayer API (basically reloading the content at the same position it was before) while it reads that noise lead to actual real playback of the encrypted media.

    I also closed the fake session immediately after the createSession call, but no change

  7. calling the createSession + generateRequest EME API with a real key id that is not the one used later BEFORE ANY data (clear or encrypted) is pushed to a SourceBuffer.

    Result: Same visual green noise and audio noise than in the preceding check

peaBerberian added a commit that referenced this issue Aug 1, 2024
An application reported to us an issue where they couldn't play a
content of mixed clear and encrypted contents on PlayReady devices.

After a LOT of attempts at work-arounds, some of them described
[here](#1403), we didn't
succeed to actually find a good solution that would both allow smooth
transition between Periods and a mix of encrypted unencrypted content.

So I attempted to play the same content with other players:

  - dash.js didn't had a smooth transition between Periods here, it
    first loaded and played the clear content, then once finished loaded
    and played the encrypted content with a black screen and license
    request in-between.

  - The shaka-player failed to play the content, I tried to debug it but
    I did not succeed to make it play the content.

This is very probably an issue with PlayReady, yet they historically
haven't been quick to fix issues we reported, so we may have to provide
a perhaps-temporary solution here.

That's why I'm introducing the for-now undocumented (and experimental
feature?) `keySystems[].failOnEncryptedAfterClear` `loadVideo` option.

When set to `true`, we'll reload if an encrypted Period is encountered
after a clear Period has been played. The logic for now is not perfect
with very rare risks of false negatives.
peaBerberian added a commit that referenced this issue Aug 1, 2024
An application reported to us an issue where they couldn't play a
content of mixed clear and encrypted contents on PlayReady devices.

After a LOT of attempts at work-arounds, some of them described
[here](#1403), we didn't
succeed to actually find a good solution that would both allow smooth
transition between Periods and a mix of encrypted unencrypted content.

So I attempted to play the same content with other players:

  - dash.js didn't had a smooth transition between Periods here, it
    first loaded and played the clear content, then once finished loaded
    and played the encrypted content with a black screen and license
    request in-between.

  - The shaka-player failed to play the content, I tried to debug it but
    I did not succeed to make it play the content.

This is very probably an issue with PlayReady, yet they historically
haven't been quick to fix issues we reported, so we may have to provide
a perhaps-temporary solution here.

That's why I'm introducing the for-now undocumented (and experimental
feature?) `keySystems[].failOnEncryptedAfterClear` `loadVideo` option.

When set to `true`, we'll reload if an encrypted Period is encountered
after a clear Period has been played. The logic for now is not perfect
with very rare risks of false negatives.

NOTE: I also profited from this commit to add the `canFilterProtectionData`
option to the streams. Previously it was implicitly enabled when the
`drmSystemId` was defined.
peaBerberian added a commit that referenced this issue Aug 1, 2024
An application reported to us an issue where they couldn't play a
content of mixed clear and encrypted contents on PlayReady devices.

After a LOT of attempts at work-arounds, some of them described
[here](#1403), we didn't
succeed to actually find a good solution that would both allow smooth
transition between Periods and a mix of encrypted unencrypted content.

So I attempted to play the same content with other players:

  - dash.js didn't had a smooth transition between Periods here, it
    first loaded and played the clear content, then once finished loaded
    and played the encrypted content with a black screen and license
    request in-between.

  - The shaka-player failed to play the content, I tried to debug it but
    I did not succeed to make it play the content.

This is very probably an issue with PlayReady, yet they historically
haven't been quick to fix issues we reported, so we may have to provide
a perhaps-temporary solution here.

That's why I'm introducing the for-now undocumented (and experimental
feature?) `keySystems[].failOnEncryptedAfterClear` `loadVideo` option.

When set to `true`, we'll reload if an encrypted Period is encountered
after a clear Period has been played. The logic for now is not perfect
with very rare risks of false negatives.

NOTE: I also profited from this commit to add the `canFilterProtectionData`
option to the streams. Previously it was implicitly enabled when the
`drmSystemId` was defined.
peaBerberian added a commit that referenced this issue Aug 1, 2024
An application reported to us an issue where they couldn't play a
content of mixed clear and encrypted contents on PlayReady devices.

After a LOT of attempts at work-arounds, some of them described
[here](#1403), we didn't
succeed to actually find a good solution that would both allow smooth
transition between Periods and a mix of encrypted unencrypted content.

So I attempted to play the same content with other players:

  - dash.js didn't had a smooth transition between Periods here, it
    first loaded and played the clear content, then once finished loaded
    and played the encrypted content with a black screen and license
    request in-between.

  - The shaka-player failed to play the content, I tried to debug it but
    I did not succeed to make it play the content.

This is very probably an issue with PlayReady, yet they historically
haven't been quick to fix issues we reported, so we may have to provide
a perhaps-temporary solution here.

That's why I'm introducing the for-now undocumented (and experimental
feature?) `keySystems[].failOnEncryptedAfterClear` `loadVideo` option.

When set to `true`, we'll reload if an encrypted Period is encountered
after a clear Period has been played. The logic for now is not perfect
with very rare risks of false negatives.

NOTE: I also profited from this commit to add the `canFilterProtectionData`
option to the streams. Previously it was implicitly enabled when the
`drmSystemId` was defined.
peaBerberian added a commit that referenced this issue Aug 1, 2024
An application reported to us an issue where they couldn't play a
content of mixed clear and encrypted contents on PlayReady devices.

After a LOT of attempts at work-arounds, some of them described
[here](#1403), we didn't
succeed to actually find a good solution that would both allow smooth
transition between Periods and a mix of encrypted unencrypted content.

So I attempted to play the same content with other players:

  - dash.js didn't had a smooth transition between Periods here, it
    first loaded and played the clear content, then once finished loaded
    and played the encrypted content with a black screen and license
    request in-between.

  - The shaka-player failed to play the content, I tried to debug it but
    I did not succeed to make it play the content.

This is very probably an issue with PlayReady, yet they historically
haven't been quick to fix issues we reported, so we may have to provide
a perhaps-temporary solution here.

That's why I'm introducing the for-now undocumented (and experimental
feature?) `keySystems[].failOnEncryptedAfterClear` `loadVideo` option.

When set to `true`, we'll reload if an encrypted Period is encountered
after a clear Period has been played. The logic for now is not perfect
with very rare risks of false negatives.

NOTE: I also profited from this commit to add the `canFilterProtectionData`
option to the streams. Previously it was implicitly enabled when the
`drmSystemId` was defined.
peaBerberian added a commit that referenced this issue Aug 5, 2024
An application reported to us an issue where they couldn't play a
content of mixed clear and encrypted contents on PlayReady devices.

After a LOT of attempts at work-arounds, some of them described
[here](#1403), we didn't
succeed to actually find a good solution that would both allow smooth
transition between Periods and a mix of encrypted unencrypted content.

So I attempted to play the same content with other players:

  - dash.js didn't had a smooth transition between Periods here, it
    first loaded and played the clear content, then once finished loaded
    and played the encrypted content with a black screen and license
    request in-between.

  - The shaka-player failed to play the content, I tried to debug it but
    I did not succeed to make it play the content.

This is very probably an issue with PlayReady, yet they historically
haven't been quick to fix issues we reported, so we may have to provide
a perhaps-temporary solution here.

That's why I'm introducing the for-now undocumented (and experimental
feature?) `keySystems[].failOnEncryptedAfterClear` `loadVideo` option.

When set to `true`, we'll reload if an encrypted Period is encountered
after a clear Period has been played. The logic for now is not perfect
with very rare risks of false negatives.

NOTE: I also profited from this commit to add the `canFilterProtectionData`
option to the streams. Previously it was implicitly enabled when the
`drmSystemId` was defined.
peaBerberian added a commit that referenced this issue Aug 29, 2024
An application reported to us an issue where they couldn't play a
content of mixed clear and encrypted contents on PlayReady devices.

After a LOT of attempts at work-arounds, some of them described
[here](#1403), we didn't
succeed to actually find a good solution that would both allow smooth
transition between Periods and a mix of encrypted unencrypted content.

So I attempted to play the same content with other players:

  - dash.js didn't had a smooth transition between Periods here, it
    first loaded and played the clear content, then once finished loaded
    and played the encrypted content with a black screen and license
    request in-between.

  - The shaka-player failed to play the content, I tried to debug it but
    I did not succeed to make it play the content.

This is very probably an issue with PlayReady, yet they historically
haven't been quick to fix issues we reported, so we may have to provide
a perhaps-temporary solution here.

That's why I'm introducing the for-now undocumented (and experimental
feature?) `keySystems[].failOnEncryptedAfterClear` `loadVideo` option.

When set to `true`, we'll reload if an encrypted Period is encountered
after a clear Period has been played. The logic for now is not perfect
with very rare risks of false negatives.

NOTE: I also profited from this commit to add the `canFilterProtectionData`
option to the streams. Previously it was implicitly enabled when the
`drmSystemId` was defined.
peaBerberian added a commit that referenced this issue Sep 4, 2024
An application reported to us an issue where they couldn't play a
content of mixed clear and encrypted contents on PlayReady devices.

After a LOT of attempts at work-arounds, some of them described
[here](#1403), we didn't
succeed to actually find a good solution that would both allow smooth
transition between Periods and a mix of encrypted unencrypted content.

So I attempted to play the same content with other players:

  - dash.js didn't had a smooth transition between Periods here, it
    first loaded and played the clear content, then once finished loaded
    and played the encrypted content with a black screen and license
    request in-between.

  - The shaka-player failed to play the content, I tried to debug it but
    I did not succeed to make it play the content.

This is very probably an issue with PlayReady, yet they historically
haven't been quick to fix issues we reported, so we may have to provide
a perhaps-temporary solution here.

That's why I'm introducing the for-now undocumented (and experimental
feature?) `keySystems[].failOnEncryptedAfterClear` `loadVideo` option.

When set to `true`, we'll reload if an encrypted Period is encountered
after a clear Period has been played. The logic for now is not perfect
with very rare risks of false negatives.

NOTE: I also profited from this commit to add the `canFilterProtectionData`
option to the streams. Previously it was implicitly enabled when the
`drmSystemId` was defined.
peaBerberian added a commit that referenced this issue Sep 4, 2024
An application reported to us an issue where they couldn't play a
content of mixed clear and encrypted contents on PlayReady devices.

After a LOT of attempts at work-arounds, some of them described
[here](#1403), we didn't
succeed to actually find a good solution that would both allow smooth
transition between Periods and a mix of encrypted unencrypted content.

So I attempted to play the same content with other players:

  - dash.js didn't had a smooth transition between Periods here, it
    first loaded and played the clear content, then once finished loaded
    and played the encrypted content with a black screen and license
    request in-between.

  - The shaka-player failed to play the content, I tried to debug it but
    I did not succeed to make it play the content.

This is very probably an issue with PlayReady, yet they historically
haven't been quick to fix issues we reported, so we may have to provide
a perhaps-temporary solution here.

That's why I'm introducing the for-now undocumented (and experimental
feature?) `keySystems[].failOnEncryptedAfterClear` `loadVideo` option.

When set to `true`, we'll reload if an encrypted Period is encountered
after a clear Period has been played. The logic for now is not perfect
with very rare risks of false negatives.

NOTE: I also profited from this commit to add the `canFilterProtectionData`
option to the streams. Previously it was implicitly enabled when the
`drmSystemId` was defined.
peaBerberian added a commit that referenced this issue Oct 8, 2024
An application reported to us an issue where they couldn't play a
content of mixed clear and encrypted contents on PlayReady devices.

After a LOT of attempts at work-arounds, some of them described
[here](#1403), we didn't
succeed to actually find a good solution that would both allow smooth
transition between Periods and a mix of encrypted unencrypted content.

So I attempted to play the same content with other players:

  - dash.js didn't had a smooth transition between Periods here, it
    first loaded and played the clear content, then once finished loaded
    and played the encrypted content with a black screen and license
    request in-between.

  - The shaka-player failed to play the content, I tried to debug it but
    I did not succeed to make it play the content.

This is very probably an issue with PlayReady, yet they historically
haven't been quick to fix issues we reported, so we may have to provide
a perhaps-temporary solution here.

That's why I'm introducing the for-now undocumented (and experimental
feature?) `keySystems[].failOnEncryptedAfterClear` `loadVideo` option.

When set to `true`, we'll reload if an encrypted Period is encountered
after a clear Period has been played. The logic for now is not perfect
with very rare risks of false negatives.

NOTE: I also profited from this commit to add the `canFilterProtectionData`
option to the streams. Previously it was implicitly enabled when the
`drmSystemId` was defined.
peaBerberian added a commit that referenced this issue Nov 15, 2024
An application reported to us an issue where they couldn't play a
content of mixed clear and encrypted contents on PlayReady devices.

After a LOT of attempts at work-arounds, some of them described
[here](#1403), we didn't
succeed to actually find a good solution that would both allow smooth
transition between Periods and a mix of encrypted unencrypted content.

So I attempted to play the same content with other players:

  - dash.js didn't had a smooth transition between Periods here, it
    first loaded and played the clear content, then once finished loaded
    and played the encrypted content with a black screen and license
    request in-between.

  - The shaka-player failed to play the content, I tried to debug it but
    I did not succeed to make it play the content.

This is very probably an issue with PlayReady, yet they historically
haven't been quick to fix issues we reported, so we may have to provide
a perhaps-temporary solution here.

That's why I'm introducing the for-now undocumented (and experimental
feature?) `keySystems[].failOnEncryptedAfterClear` `loadVideo` option.

When set to `true`, we'll reload if an encrypted Period is encountered
after a clear Period has been played. The logic for now is not perfect
with very rare risks of false negatives.

NOTE: I also profited from this commit to add the `canFilterProtectionData`
option to the streams. Previously it was implicitly enabled when the
`drmSystemId` was defined.
peaBerberian added a commit that referenced this issue Nov 15, 2024
An application reported to us an issue where they couldn't play a
content of mixed clear and encrypted contents on PlayReady devices.

After a LOT of attempts at work-arounds, some of them described
[here](#1403), we didn't
succeed to actually find a good solution that would both allow smooth
transition between Periods and a mix of encrypted unencrypted content.

So I attempted to play the same content with other players:

  - dash.js didn't had a smooth transition between Periods here, it
    first loaded and played the clear content, then once finished loaded
    and played the encrypted content with a black screen and license
    request in-between.

  - The shaka-player failed to play the content, I tried to debug it but
    I did not succeed to make it play the content.

This is very probably an issue with PlayReady, yet they historically
haven't been quick to fix issues we reported, so we may have to provide
a perhaps-temporary solution here.

That's why I'm introducing the for-now undocumented (and experimental
feature?) `keySystems[].failOnEncryptedAfterClear` `loadVideo` option.

When set to `true`, we'll reload if an encrypted Period is encountered
after a clear Period has been played. The logic for now is not perfect
with very rare risks of false negatives.

NOTE: I also profited from this commit to add the `canFilterProtectionData`
option to the streams. Previously it was implicitly enabled when the
`drmSystemId` was defined.
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

No branches or pull requests

3 participants