1447821 - Regression Playing Dash DRM protected content with AAC Profile 5 in Firefox 59 - (via Shaka Player)

Status: VERIFIED FIXED

(Core :: Audio/Video: Playback, defect)

Description

[john.bowers]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce:

Attempt to play any of the Verizon Assets in the Shaka Player AppSpot Demo.  These assets are all Widevine Protected.  Here is a link to easily reproduce the issue:

https://shaka-player-demo.appspot.com/demo/#asset=https://content.uplynk.com/847859273a4b4a81959d8fea181672a4.mpd?pr.version=2&pr.playenabler=B621D91F-EDCC-4035-8D4B-DC71760D43E9&pr.securitylevel=150;lang=en-US;build=uncompiled



Actual results:

Shaka Error MEDIA.VIDEO_ERROR (3,,NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - void mozilla::EMEDecryptor::AttemptDecode(mozilla::MediaRawData *): Failed to convert encrypted AAC sample to ADTS)

I believe this might have something to do with the AAC Profile.  If i use an internal player I see the same error, but if I hack the AAC Profile to 2 in the Muxer before I copy the content to the HTML5 Source Buffers playback seems to work with version 59 as well. 


Expected results:

I reverted to version 57.0.4 and playback of this and all the Verizon Assets works fine.  I would expect successful playback, and the content still plays fine on Chrome.  I am currently using the MacOS version of chrome and Firefox for this testing.

Comment 1

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=63fe40a76a252775c0a24bc65f64a479d8a5946e&tochange=1142fe8c0a2e61a2ee73e70bb805bfeaac44d595

Regressed by: 
1142fe8c0a2e	Chris Pearce — Bug 1433344 - Convert encrypted AAC to ADTS before decryption. r=jya

@Chris Pearce
Your patch seems to cause the regression. Can you look into this?

Comment 2

[Chris Pearce [:cpearce (Not reading bugmail)]]

Bryce: can you look at this? It sounds like it the issue jya pointed out in https://bugzilla.mozilla.org/show_bug.cgi?id=1433344#c7 . We're clamping the AAC profile value to 4 here [1], we probably need to save and restore the original profile value if that's not already happening somehow.

[1] https://searchfox.org/mozilla-central/rev/c217fbde244344fedfd07b57a740c694a456dbca/dom/media/platforms/agnostic/eme/EMEDecoderModule.cpp#38

Thanks!

Comment 3

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Looks like we've had other regressions before now with Bug 1415809. Then we fixed it up in Bug 1426773. And now we've regressed again. Initially though thought there may be some relation between these, but looking deeper I'm thinking not.

For this issue it looks like the profile is set to 0, so we fail the check here[0] during conversion. If I comment out the lower bounds check there, media works again. I think the regression here is caused by us doing a check, which we previously would not have done.

Will update our clamping to include the lower end of the range, and while I'm here put in place the value restoration (unless it causes pain).

[0] https://searchfox.org/mozilla-central/source/dom/media/platforms/agnostic/bytestreams/Adts.cpp#45

Comment 4

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d5b401316021a37ce478abab1eaeb56cb21094a5

Comment 5

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Could I get a clarification as to why we have a limit on the profile in our ADTS conversion[0]? It seems like this could be somewhat simplified by having that conversion be more relaxed in its checks if certain values are still valid profiles.

[0]: https://searchfox.org/mozilla-central/source/dom/media/platforms/agnostic/bytestreams/Adts.cpp#45

Comment 6

[Jean-Yves Avenard [:jya]]

ADTS can only include profile value of up 4 (3-1) (the profile number is encoded on 2 bits only). Hence why we cap the value, look two lines down how it is stored:
https://searchfox.org/mozilla-central/source/dom/media/platforms/agnostic/bytestreams/Adts.cpp#52
((aProfile - 1) << 6)
aProfile is a byte, shift it by 6 bits, and only 2 bits remain.

We used to pass raw AAC to widevine CDM, which caused failures in some cases as it would incorrectly interpret data something else than AAC.

Muxing the content into ADTS is what chrome does. My guess is that we could set the profile to anything, it wouldn't matter, so long that once we get the data back we set the right profile again.

:cpearce is the one who did this modification, passing the blame onto him :)

Comment 7

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

I think I follow enough. This issue can at least be fixed by clamping at the lower end of our range. It appears the CDM is not that fussy about the profile in my testing.

I don't think I understand the need for profile reverting here. After we revert from ADTS are our samples not stripped of their headers? So they no longer have a profile attached that needs to be reset? The original profile will be maintained in the AudioInfo associated with stream.

Comment 8

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Attachment: Bug 1447821 - Update EMEDecoderModule to handle profile values < 1.

Update EMEDecoderModule to be more tolerant of AAC streams with null (0) MPEG-4
Audio Object Type. Some streams fail to set a correct type, but since the CDM
is tolerant provided we can feed it ADTS, we fudge the type to allow conversion
to ADTS.

Review commit: https://reviewboard.mozilla.org/r/231218/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/231218/

Comment 9

[Jean-Yves Avenard [:jya]]

Comment on attachment 8962357 [details]
Bug 1447821 - Update EMEDecoderModule to handle profile values < 1.

https://reviewboard.mozilla.org/r/231218/#review236670

::: commit-message-5bc91:4
(Diff revision 1)
> +Bug 1447821 - Update EMEDecoderModule to clamp profile values < 1 to 1. r?jya
> +
> +Update EMEDecoderModule to be more tolerant of AAC streams with null (0) MPEG-4
> +Audio Object Type. Some streams fail to set a correct type, but since the CDM

they do not have a null Audio Object Type, they have a type of 5.

The demuxer sets the value of Profile to 0 and the value of ExtendedProfile is to be used instead.

https://searchfox.org/mozilla-central/source/dom/media/mp4/DecoderData.cpp#94

So it's not a matter of tolerance, but that the wrong value is used

::: dom/media/platforms/agnostic/eme/EMEDecoderModule.cpp:40
(Diff revision 1)
>  public:
>    explicit ADTSSampleConverter(const AudioInfo& aInfo)
>      : mNumChannels(aInfo.mChannels)
>      // Note: we clamp profile to 4 so that HE-AACv2 (profile 5) can pass
> -    // through the conversion to ADTS and back again.
> +    // through the conversion to ADTS (which has 2 bits for profile) and
> +    // back again. Clamp to 1 to be tolerant of bad streams with 0 profile.

they are not bad streams.. it's just the demuxer set the profile to 0 and set ExtendedProfile to the full value.

please remove

Comment 10

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Comment on attachment 8962357 [details]
Bug 1447821 - Update EMEDecoderModule to handle profile values < 1.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/231218/diff/1-2/

Comment 11

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Comment on attachment 8962357 [details]
Bug 1447821 - Update EMEDecoderModule to handle profile values < 1.

https://reviewboard.mozilla.org/r/231218/#review236670

> they do not have a null Audio Object Type, they have a type of 5.
> 
> The demuxer sets the value of Profile to 0 and the value of ExtendedProfile is to be used instead.
> 
> https://searchfox.org/mozilla-central/source/dom/media/mp4/DecoderData.cpp#94
> 
> So it's not a matter of tolerance, but that the wrong value is used

If values > 4 result in the profile being set to 0, why are we ceiling to 4? Should we not have always needed to floor to 1?

Comment 12

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Attachment: Bug 1447821 - Add logging to ADTSSampleConverter ctor.

Add logging to aid in debugging of our ADTS conversion path.

Review commit: https://reviewboard.mozilla.org/r/231298/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/231298/

Comment 13

[Jean-Yves Avenard [:jya]]

Comment on attachment 8962357 [details]
Bug 1447821 - Update EMEDecoderModule to handle profile values < 1.

https://reviewboard.mozilla.org/r/231218/#review236670

> If values > 4 result in the profile being set to 0, why are we ceiling to 4? Should we not have always needed to floor to 1?

yes... profile can never be more than 4 to start with...
if you want to clamp, then use ExtendedProfile rather than profile.

Comment 14

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Comment on attachment 8962357 [details]
Bug 1447821 - Update EMEDecoderModule to handle profile values < 1.

https://reviewboard.mozilla.org/r/231218/#review236670

> yes... profile can never be more than 4 to start with...
> if you want to clamp, then use ExtendedProfile rather than profile.

Once we're clamping we're trusting the CDM to do the right thing despite that we're giving a fudged value. Does it matter if we clamp from either profile if we're giving it something bogus? I can log the extended profile for debugging, but do we benefit from clamping extended down to 4 more than from clamping profile up to 1?

Comment 15

[Jean-Yves Avenard [:jya]]

Comment on attachment 8962357 [details]
Bug 1447821 - Update EMEDecoderModule to handle profile values < 1.

https://reviewboard.mozilla.org/r/231218/#review236670

> Once we're clamping we're trusting the CDM to do the right thing despite that we're giving a fudged value. Does it matter if we clamp from either profile if we're giving it something bogus? I can log the extended profile for debugging, but do we benefit from clamping extended down to 4 more than from clamping profile up to 1?

up to you.
seeing we're providing an likely invalid valid, I would always use 2 personally and see how that go.

Comment 16

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Comment on attachment 8962357 [details]
Bug 1447821 - Update EMEDecoderModule to handle profile values < 1.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/231218/diff/2-3/

Comment 17

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Comment on attachment 8962471 [details]
Bug 1447821 - Add logging to ADTSSampleConverter ctor.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/231298/diff/1-2/

Comment 18

[Jean-Yves Avenard [:jya]]

Comment on attachment 8962471 [details]
Bug 1447821 - Add logging to ADTSSampleConverter ctor.

https://reviewboard.mozilla.org/r/231298/#review236772

::: dom/media/platforms/agnostic/eme/EMEDecoderModule.cpp:48
(Diff revision 2)
>      // safety. 2 is used as a fallback value, though it seems the CDM doesn't
>      // care what is set.
>      , mProfile(aInfo.mProfile < 1 || aInfo.mProfile > 4 ? 2 : aInfo.mProfile)
>      , mFrequencyIndex(Adts::GetFrequencyIndex(aInfo.mRate))
>    {
> +    EME_LOG("ADTSSampleConvertor(): aInfo.mProfile=%" PRIi8

You'll likely need to include the header for PRIi8 (inttypes)

Comment 19

[Jean-Yves Avenard [:jya]]

Comment on attachment 8962357 [details]
Bug 1447821 - Update EMEDecoderModule to handle profile values < 1.

https://reviewboard.mozilla.org/r/231218/#review236774

::: commit-message-5bc91:4
(Diff revision 3)
> +Bug 1447821 - Update EMEDecoderModule to handle profile values < 1. r?jya
> +
> +Update EMEDecoderModule to use 2 as profile number when the given profile is
> +less than 1 or greater than 2. The CDM doesn't appear to care what values are

Or greater than 4

Comment 20

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Comment on attachment 8962357 [details]
Bug 1447821 - Update EMEDecoderModule to handle profile values < 1.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/231218/diff/3-4/

Comment 21

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Comment on attachment 8962471 [details]
Bug 1447821 - Add logging to ADTSSampleConverter ctor.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/231298/diff/2-3/

Comment 22

[Jean-Yves Avenard [:jya]]

Comment on attachment 8962471 [details]
Bug 1447821 - Add logging to ADTSSampleConverter ctor.

https://reviewboard.mozilla.org/r/231298/#review236986

::: dom/media/platforms/agnostic/eme/EMEDecoderModule.cpp:24
(Diff revision 3)
>  #include "nsAutoPtr.h"
>  #include "nsClassHashtable.h"
>  #include "nsServiceManagerUtils.h"
>  #include "DecryptThroughputLimit.h"
>  #include "ChromiumCDMVideoDecoder.h"
> +#include <inttypes.h>

system include are to be added at the top of the include list

https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#CC_practices

Includes are split into three blocks, and sorted alphabetically in each block:

    The main header: #include "Foo.h" in Foo.cpp
    Standard library includes: #include <map>
    Mozilla includes: #include "mozilla/dom/Element.h"

Comment 23

[stress_tn]

Hello, we have the same error Telecom Italia dash live content fail with Shaka Player. Please fix it as soon as possible. Soon we will have very important match translation...

Best regards,
Stanislav

Comment 24

[stress_tn]

Here is my ticket with the same problem. Even video not started
https://bugzilla.mozilla.org/show_bug.cgi?id=1448246

Comment 26

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Comment on attachment 8962471 [details]
Bug 1447821 - Add logging to ADTSSampleConverter ctor.

https://reviewboard.mozilla.org/r/231298/#review236986

> system include are to be added at the top of the include list
> 
> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#CC_practices
> 
> Includes are split into three blocks, and sorted alphabetically in each block:
> 
>     The main header: #include "Foo.h" in Foo.cpp
>     Standard library includes: #include <map>
>     Mozilla includes: #include "mozilla/dom/Element.h"

System includes were appearring at the end of the list previously (as of the prior changeset), but I've updated this to be closer to linked convention.

Comment 27

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Comment on attachment 8962471 [details]
Bug 1447821 - Add logging to ADTSSampleConverter ctor.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/231298/diff/3-4/

Comment 28

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

I'm seeing a phantom issue on reviewboard which is preventing me from autolanding. I see 4 issues for the first changeset in various places in the UI, but only 3 elsewhere. As I cannot resolve the 4th issue I am requesting manual checking.

Comment 29

[tomica.gril]

Hello,

one additional vote to fix this and release it ASAP.
Our customer that runs OTT service across multiple countries is also affected.
They have live and VOD content with HE-AAC (mp4a.40.5) and it stopped working with Firefox 59.
A workaround that fixes it is switching to AAC-LC (mp4a.40.2) but this can be only temporary solution and it can be applied only to live content. VOD is still not working.
Removing DRM protection is not an option due to content rights.

Best regards,
Tomica

Comment 30

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bf78f178cc7f
Update EMEDecoderModule to handle profile values < 1. r=jya
https://hg.mozilla.org/integration/autoland/rev/0c1f66e827e8
Add logging to ADTSSampleConverter ctor. r=jya

Comment 31

[Jean-Yves Avenard [:jya]]

(In reply to Bryce Van Dyk (:bryce) from comment #26)
> System includes were appearring at the end of the list previously (as of the
> prior changeset), but I've updated this to be closer to linked convention.

this happens if you pushed a new review via git/hg at right at the same time you modified via the web interface to solve issue.

There's a potential race happening there, it has hit me several times.

Comment 32

[Jean-Yves Avenard [:jya]]

Bryce, please nominate for uplift... thanks

Comment 33

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Comment on attachment 8962357 [details]
Bug 1447821 - Update EMEDecoderModule to handle profile values < 1.

Requesting for beta and release (as possible ridealong).

Approval Request Comment
[Feature/Bug causing the regression]: Bug 1433344 added a check which inadvertently lead to bustage of decryption for exended AAC profiles (notably HE-AAC v2).
[User impact if declined]: Playback will be broken for users attempting to play encrypted video assets that make use of encrypted HE-AAC v2. Paid content playback is likely to be affected. This is a new and recent regression.
[Is this code covered by automated tests?]: No, as this involves the CDM (which we do not control) and related components such as licensing servers, we do not have the ability to run tests in CI.
[Has the fix been verified in Nightly?]: Verified locally. Waiting for another nightly to ship then will verify there also.
[Needs manual test from QE? If yes, steps to reproduce]: Yes, steps to repro in bug can be used to test the fix.
[List of other uplifts needed for the feature/fix]: None, the other changeset in the chain adds logging and thus is not needed.
[Is the change risky?]: Low to medium risk.
[Why is the change risky/not risky?]: The change code change is a single line and has been manually tested, however it deals with a component that has broad impact.
[String changes made/needed]: None.

Comment 34

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/bf78f178cc7f
https://hg.mozilla.org/mozilla-central/rev/0c1f66e827e8

Comment 35

[stress_tn]

Will this fix be added into 59 version? It's really critical at the moment.

Comment 36

[Julien Cristau [:jcristau]]

Comment on attachment 8962357 [details]
Bug 1447821 - Update EMEDecoderModule to handle profile values < 1.

the link from comment 0 seems to work in nightly now.  beta60+, should be in 60.0b8.

Comment 37

[Ryan VanderMeulen [:RyanVM]]

What can we do to improve test coverage around this code?

Comment 38

[Jean-Yves Avenard [:jya]]

I'm afraid we can't...

Comment 39

[Ryan VanderMeulen [:RyanVM]]

Given that, I wouldn't be very inclined to spin another 59 dot release for this bug. With such sparse test coverage, getting proper Beta exposure feels like an important step.

Comment 40

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

I've manually tested this now that it's in nightly and see the test cases mentioned here now working, as well as no regressions in other sites.

Regarding better test coverage, I'm going to hold the ni and ponder if there is any thing we can do. We've previously tried automated testing of external sites, but with highly variable results due to all the external factors, which led to it being too unreliable.

Comment 41

[Jean-Yves Avenard [:jya]]

due to the nature of the fix, there can't be regression on site that used to work as the value stored in the ADTS packet would stay the same for those..

it's only for videos that will now error that the change is effective, and it will fix it for them (or not, in which case the issue isn't worse anyway)

Comment 42

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Indeed, but it gives me comfort to verify none the less.

Comment 43

[Chris Peterson [:cpeterson]]

Here is the Shaka Player bug report:

https://github.com/google/shaka-player/issues/1371

Comment 44

[Liz Henry (:lizzard) (relman/hg->git project)]

Bryce or jya, How common is encrypted HE-AAC v2 for Firefox users? Is there telemetry that would tell us?

Comment 45

[Liz Henry (:lizzard) (relman/hg->git project)]

Is there any workaround we can tell users to try, in the meantime?

Comment 46

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

None of the sites I've tested outside of those mentioned on this bug have required HE-AAC v2. This may be that they can fallback to other audio streams with different profiles or that they are not using HE-AAC v2. I am not aware of telem that specifically breaks out HE-AAC v2, jya, are you aware of any?

I think mitigation for this would need to be done server side, in that a different audio stream would need to be used. I don't think we can workaround this on the client.

Comment 47

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

On testing we are limited due to the nature of the CDM, the licensing surrounding it, and the technical setups required to support these systems. However, there are some things I think can be done:

- Telemetry: we could benefit from more information on failures to decrypt so that we can get ahead of issues like this.
- More rigorous manual testing.
- Unit testing/gtests: we could unit test some of our components involved here. My concern would be unknown unknowns such as this catching us.

My personal opinion is that we could benefit most from putting in place telemetry, though it doesn't help here, we could prevent situations such as this arising in future.

Comment 48

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/0db4e4e9ce11
https://hg.mozilla.org/releases/mozilla-beta/rev/a125dbf21643

Comment 49

[Chris Pearce [:cpearce (Not reading bugmail)]]

I tested the regressing changeset on a bunch of sites that use Widevine, but I couldn't find one which used the particular combination of settings here.

Most sites playing DRM streams tend to not use HEAAC-v2 as that codec is optimized for low bitrates, and premium video tends to be on the other end of the quality/bitrate spectrum. Obviously, there are sites that do use it irrespective of that however.

The external media tests wouldn't have found this, as they didn't test sites that ran this combination.

This bug is in the long tail of combinations of settings; we can't test the entire internet every time we land a patch. But we may have been able to catch this before release if we'd had more detailed telemetry which may have detected a spike in failures to play back. We'd need to think carefully about how to structure such telemetry in order to discern where in our code the failures were however.

The patch looks safe to uplift to release to me; the patch should only affect behaviour for profile 5 AAC streams; streams which are 1-4 should not have a behaviour change, so this should only affect invalid streams and profile 5 streams that aren't working and not valid streams that are working. I think we should include this patch in the next dot release. 

We can't test DRM playback in our automation as it requires downloading and installing the CDM (we could potentially do that if we installed a proxy and hosted the CDM inside our test harness) and it also requires access to a DRM license server. That second one is hard.

Comment 50

[Camelia Badau [:cbadau], Desktop Test Engineering]

The bug was reproduced on Firefox 59.0.2 using the steps from comment 0.

We verified the issue on Windows 10 x64, Windows 8.1 x64, Ubuntu 16.04 x86 and macOS 10.13 using Firefox 60 Beta 8.

Comment 51

[stress_tn]

Hello everyone.
Today I have made some tests with Night and Standart Firefox browsers:
Standart Firefox - 59.0.2 (64-bit): not work (the same error);
Firefox Nightly - 61.0a1 (2018-04-02) (64-bit): now playback is working fine;

Question is:
When this update will be included into standard Firefox version? It's very critical for us

Comment 52

[Liz Henry (:lizzard) (relman/hg->git project)]

We don't have another 59 release scheduled yet, but if we do one, it sounds ok to include this from comment 49 and 50.    If we don't release a 59.0.3, then the fix will be in Firefox 60 (May 9 release date)

Comment 53

[Bogdan Maris, Desktop Test Engineering]

We also verified the fix on Windows 10 64bit, macOS 10.13.4 and Ubuntu 16.04 32bit using Latest Nightly 61.0a1.

Comment 54

[kdevarakonda]

Following stream exhibits symptoms that may be related to this bug.

MPD: https://dai.google.com/ondemand/dash/content/2474151/vid/tosr2-widevine/manifest.mpd

License URL: https://proxy.uat.widevine.com/proxy

Tested browsers: Firefox 60 Beta & Firefox Nightly (firefox-61.0a1.en-US.linux-x86_64)

This stream works on latest nightly of dash.js player on both beta & nightly version of Firefox but it won't play on Shaka player on either browser versions. The underlying error from Shaka playback failure is: "FFmpeg audio error: -1094995529".

Full media log collected with https://addons.mozilla.org/en-US/firefox/addon/devtools-media-panel/ from Firefox 60:

Media Info : [

    0 : {
        url : "https://shaka-player-demo.appspot.com/demo/#asset=https://dai.google.com/ondemand/dash/content/2474151/vid/tosr2-widevine/manifest.mpd;license=https://proxy.uat.widevine.com/proxy;lang=en-US;build=uncompiled"
        mediaElements : [...] 1 item
    }

]

[
  {
    "url": "https://shaka-player-demo.appspot.com/demo/#asset=https://dai.google.com/ondemand/dash/content/2474151/vid/tosr2-widevine/manifest.mpd;license=https://proxy.uat.widevine.com/proxy;lang=en-US;build=uncompiled",
    "mediaElements": [
      {
        "currentSrc": "blob:https://shaka-player-demo.appspot.com/8284250c-f695-4d73-80de-027dde6b1bf3",
        "currentTime": 40.1468,
        "readyState": 4,
        "error": " error: 3 (NS_ERROR_DOM_MEDIA_DECODE_ERR (0x806e0004) - virtual mozilla::MediaResult mozilla::FFmpegAudioDecoder<57>::DoDecode(mozilla::MediaRawData*, uint8_t*, int, bool*, mozilla::MediaDataDecoder::DecodedData&): FFmpeg audio error:-1094995529)",
        "videoPlaybackQuality": {
          "ratio": "100%",
          "droppedVideoFrames": 0,
          "corruptedVideoFrames": 0
        },
        "bufferedRanges": [
          {
            "start": 9.009,
            "end": 30.03
          },
          {
            "start": 30.172333,
            "end": 48.157684
          }
        ],
        "mozMediaSourceObject": [
          {
            "sourceBuffers": [
              {
                "start": 8.359183,
                "end": 48.157684
              }
            ]
          },
          {
            "sourceBuffers": [
              {
                "start": 9.009,
                "end": 30.03
              },
              {
                "start": 30.172333,
                "end": 48.172333
              }
            ]
          }
        ],
        "debugInfo": {
          "Container Type": "MediaSource",
          "Audio Decoder(audio/mp4a-latm)": "ffmpeg audio decoder",
          "Audio Frames Decoded": "1600",
          "Audio State": "ni=0 no=0 wp=0 demuxr=0 demuxq=0 decoder=0 tt=-1.0 tths=-1 in=1 out=0 qs=1 pending=0 wfd=0 eos=0 ds=0 wfk=0 sid=17",
          "Video Decoder(video/avc, 1920x1080 @ 30.00)": "ffmpeg video decoder",
          "Hardware Video Decoding": "disabled",
          "Video Frames Decoded": "1221 (skipped=0)",
          "Video State": "ni=0 no=0 wp=0 demuxr=0 demuxq=0 decoder=0 tt=-1.0 tths=-1 in=314 out=310 qs=4 pending:0 wfd=0 eos=0 ds=0 wfk=0 sid=19",
          "Dumping Data for Demuxer": "7fb2e44b9c00",
          "Dumping Audio Track Buffer(audio/mp4)": "mLastAudioTime=40.239680",
          "Audio Track Buffer Details": "NumSamples=1677 Size=1756289 Evictable=1393332 NextGetSampleIndex=1336 NextInsertionIndex=1677",
          "Audio Track Buffered": "ranges=[(8.359183, 48.157684)]",
          "Dumping Video Track Buffer(video/mp4)": "mLastVideoTime=40.672333",
          "Video Track Buffer Details": "NumSamples=1170 Size=11669642 Evictable=7166587 NextGetSampleIndex=944 NextInsertionIndex=1170",
          "Video Track Buffered": "ranges=[(9.009000, 30.030000), (30.172333, 48.172333)]",
          "Compositor dropped frame(including when element's invisible)": "1",
          "EME Info": "Key System=com.widevine.alpha SessionsInfo=(sid=A264ADB3F63343F74ADB1B601A9D203A(kid=647863379f4154108377e74c6ec0e3b8 status=usable)(kid=6d76f25cb17f5e16b8eaef6bbf582d8e status=usable)(kid=abba271e8bcf552bbd2e86a434a9a5d9 status=usable)(kid=f3c5e0361e6654b28f8049c778b23946 status=usable))",
          "MediaDecoder=7fb2e44c47a0": "channels=2 rate=44100 hasAudio=1 hasVideo=1 mPlayState=PLAYING",
          "MDSM": "duration=48157684 GetMediaTime=40146800 GetClock=40146800 mMediaSink=7fb2e4325500 state=DECODING mPlayState=3 mSentFirstFrameLoadedEvent=1 IsPlaying=1 mAudioStatus=idle mVideoStatus=idle mDecodedAudioEndTime=40146799 mDecodedVideoEndTime=40505666 mAudioCompleted=0 mVideoCompleted=0 mIsPrerolling=0",
          "VideoSink": "IsStarted=1 IsPlaying=1 VideoQueue(finished=0 size=11) mVideoFrameEndTime=40172333 mHasVideo=1 mVideoSinkEndRequest.Exists()=0 mEndPromiseHolder.IsEmpty()=0",
          "AudioSinkWrapper": "IsStarted=1 IsPlaying=1 AudioEnded=0"
        }
      }
    ]
  }
]

Comment 55

[kdevarakonda]

This is tested on "Debian GNU/Linux rodete"

Full media log collected with https://addons.mozilla.org/en-US/firefox/addon/devtools-media-panel/ from Firefox 61.0a1 (2018-04-12) (64-bit):

Media Info : [

    0 : {
        url : "https://shaka-player-demo.appspot.com/demo/#asset=https://dai.google.com/ondemand/dash/content/2474151/vid/tosr2-widevine/manifest.mpd;license=https://proxy.uat.widevine.com/proxy;lang=en-US;build=uncompiled"
        mediaElements : [
            0 : {
                currentSrc : "blob:https://shaka-player-demo.appspot.com/d55f92b1-8795-4d06-86be-c08d36ca46eb"
                currentTime : 40.1468
                readyState : 4
                error : " error: 3 (NS_ERROR_DOM_MEDIA_DECODE_ERR (0x806e0004) - virtual mozilla::MediaResult mozilla::FFmpegAudioDecoder<57>::DoDecode(mozilla::MediaRawData*, uint8_t*, int, bool*, mozilla::MediaDataDecoder::DecodedData&): FFmpeg audio error:-1094995529)"
                videoPlaybackQuality : {
                    ratio : "100%"
                    droppedVideoFrames : 0
                    corruptedVideoFrames : 0
                }
                bufferedRanges : [
                    0 : {
                        start : 9.009
                        end : 30.03
                    }
                    1 : {
                        start : 30.172333
                        end : 48.157684
                    }
                ]
                mozMediaSourceObject : [
                    0 : {
                        sourceBuffers : [
                            0 : {
                                start : 8.452063
                                end : 48.157684
                            }
                        ]
                    }
                    1 : {
                        sourceBuffers : [
                            0 : {
                                start : 9.009
                                end : 30.03
                            }
                            1 : {
                                start : 30.172333
                                end : 48.172333
                            }
                        ]
                    }
                ]
                debugInfo : {
                    Container Type : "MediaSource"
                    Audio Decoder(audio/mp4a-latm) : "ffmpeg audio decoder"
                    Audio Frames Decoded : "1597"
                    Audio State : "ni=0 no=0 wp=0 demuxr=0 demuxq=0 decoder=0 tt=-1.0 tths=-1 in=432 out=431 qs=1 pending=0 wfd=0 eos=0 ds=0 wfk=0 sid=9"
                    Video Decoder(video/avc, 1920x1080 @ 30.00) : "ffmpeg video decoder"
                    Hardware Video Decoding : "disabled"
                    Video Frames Decoded : "1221 (skipped=0)"
                    Video State : "ni=0 no=0 wp=0 demuxr=0 demuxq=0 decoder=0 tt=-1.0 tths=-1 in=314 out=310 qs=4 pending:0 wfd=0 eos=0 ds=0 wfk=0 sid=7"
                    Dumping Data for Demuxer : "7f7abd958c00"
                    Dumping Audio Track Buffer(audio/mp4) : "mLastAudioTime=40.170020"
                    Audio Track Buffer Details : "NumSamples=1675 Size=1755148 Evictable=1388989 NextGetSampleIndex=1331 NextInsertionIndex=1675"
                    Audio Track Buffered : "ranges=[(8.452063, 48.157684)]"
                    Dumping Video Track Buffer(video/mp4) : "mLastVideoTime=40.672333"
                    Video Track Buffer Details : "NumSamples=1170 Size=11669642 Evictable=7166587 NextGetSampleIndex=944 NextInsertionIndex=1170"
                    Video Track Buffered : "ranges=[(9.009000, 30.030000), (30.172333, 48.172333)]"
                    Compositor dropped frame(including when element's invisible) : "21"
                    EME Info : "Key System=com.widevine.alpha SessionsInfo=(sid=916702774C33D7A0BFED68BDA1739EA8(kid=647863379f4154108377e74c6ec0e3b8 status=usable)(kid=6d76f25cb17f5e16b8eaef6bbf582d8e status=usable)(kid=abba271e8bcf552bbd2e86a434a9a5d9 status=usable)(kid=f3c5e0361e6654b28f8049c778b23946 status=usable))"
                    MediaDecoder=7f7ac267ff20 : "channels=2 rate=44100 hasAudio=1 hasVideo=1 mPlayState=PLAYING"
                    MDSM : "duration=48157684 GetMediaTime=40146800 GetClock=40146800 mMediaSink=7f7abdeb89d0 state=DECODING mPlayState=3 mSentFirstFrameLoadedEvent=1 IsPlaying=1 mAudioStatus=idle mVideoStatus=idle mDecodedAudioEndTime=40146799 mDecodedVideoEndTime=40505666 mAudioCompleted=0 mVideoCompleted=0 mIsPrerolling=0"
                    VideoSink : "IsStarted=1 IsPlaying=1 VideoQueue(finished=0 size=11) mVideoFrameEndTime=40172333 mHasVideo=1 mVideoSinkEndRequest.Exists()=0 mEndPromiseHolder.IsEmpty()=0"
                    AudioSinkWrapper : "IsStarted=1 IsPlaying=1 AudioEnded=0"
                }
            }
        ]
    }

]

[
  {
    "url": "https://shaka-player-demo.appspot.com/demo/#asset=https://dai.google.com/ondemand/dash/content/2474151/vid/tosr2-widevine/manifest.mpd;license=https://proxy.uat.widevine.com/proxy;lang=en-US;build=uncompiled",
    "mediaElements": [
      {
        "currentSrc": "blob:https://shaka-player-demo.appspot.com/d55f92b1-8795-4d06-86be-c08d36ca46eb",
        "currentTime": 40.1468,
        "readyState": 4,
        "error": " error: 3 (NS_ERROR_DOM_MEDIA_DECODE_ERR (0x806e0004) - virtual mozilla::MediaResult mozilla::FFmpegAudioDecoder<57>::DoDecode(mozilla::MediaRawData*, uint8_t*, int, bool*, mozilla::MediaDataDecoder::DecodedData&): FFmpeg audio error:-1094995529)",
        "videoPlaybackQuality": {
          "ratio": "100%",
          "droppedVideoFrames": 0,
          "corruptedVideoFrames": 0
        },
        "bufferedRanges": [
          {
            "start": 9.009,
            "end": 30.03
          },
          {
            "start": 30.172333,
            "end": 48.157684
          }
        ],
        "mozMediaSourceObject": [
          {
            "sourceBuffers": [
              {
                "start": 8.452063,
                "end": 48.157684
              }
            ]
          },
          {
            "sourceBuffers": [
              {
                "start": 9.009,
                "end": 30.03
              },
              {
                "start": 30.172333,
                "end": 48.172333
              }
            ]
          }
        ],
        "debugInfo": {
          "Container Type": "MediaSource",
          "Audio Decoder(audio/mp4a-latm)": "ffmpeg audio decoder",
          "Audio Frames Decoded": "1597",
          "Audio State": "ni=0 no=0 wp=0 demuxr=0 demuxq=0 decoder=0 tt=-1.0 tths=-1 in=432 out=431 qs=1 pending=0 wfd=0 eos=0 ds=0 wfk=0 sid=9",
          "Video Decoder(video/avc, 1920x1080 @ 30.00)": "ffmpeg video decoder",
          "Hardware Video Decoding": "disabled",
          "Video Frames Decoded": "1221 (skipped=0)",
          "Video State": "ni=0 no=0 wp=0 demuxr=0 demuxq=0 decoder=0 tt=-1.0 tths=-1 in=314 out=310 qs=4 pending:0 wfd=0 eos=0 ds=0 wfk=0 sid=7",
          "Dumping Data for Demuxer": "7f7abd958c00",
          "Dumping Audio Track Buffer(audio/mp4)": "mLastAudioTime=40.170020",
          "Audio Track Buffer Details": "NumSamples=1675 Size=1755148 Evictable=1388989 NextGetSampleIndex=1331 NextInsertionIndex=1675",
          "Audio Track Buffered": "ranges=[(8.452063, 48.157684)]",
          "Dumping Video Track Buffer(video/mp4)": "mLastVideoTime=40.672333",
          "Video Track Buffer Details": "NumSamples=1170 Size=11669642 Evictable=7166587 NextGetSampleIndex=944 NextInsertionIndex=1170",
          "Video Track Buffered": "ranges=[(9.009000, 30.030000), (30.172333, 48.172333)]",
          "Compositor dropped frame(including when element's invisible)": "21",
          "EME Info": "Key System=com.widevine.alpha SessionsInfo=(sid=916702774C33D7A0BFED68BDA1739EA8(kid=647863379f4154108377e74c6ec0e3b8 status=usable)(kid=6d76f25cb17f5e16b8eaef6bbf582d8e status=usable)(kid=abba271e8bcf552bbd2e86a434a9a5d9 status=usable)(kid=f3c5e0361e6654b28f8049c778b23946 status=usable))",
          "MediaDecoder=7f7ac267ff20": "channels=2 rate=44100 hasAudio=1 hasVideo=1 mPlayState=PLAYING",
          "MDSM": "duration=48157684 GetMediaTime=40146800 GetClock=40146800 mMediaSink=7f7abdeb89d0 state=DECODING mPlayState=3 mSentFirstFrameLoadedEvent=1 IsPlaying=1 mAudioStatus=idle mVideoStatus=idle mDecodedAudioEndTime=40146799 mDecodedVideoEndTime=40505666 mAudioCompleted=0 mVideoCompleted=0 mIsPrerolling=0",
          "VideoSink": "IsStarted=1 IsPlaying=1 VideoQueue(finished=0 size=11) mVideoFrameEndTime=40172333 mHasVideo=1 mVideoSinkEndRequest.Exists()=0 mEndPromiseHolder.IsEmpty()=0",
          "AudioSinkWrapper": "IsStarted=1 IsPlaying=1 AudioEnded=0"
        }
      }
    ]
  }
]

Comment 56

[Jean-Yves Avenard [:jya]]

This is most puzzling, it appears to be an EME session, yet ffmpeg decoders are in use.

Comment 57

[kdevarakonda]

If it matters first period, which is 30 seconds, in the MPD is clear content and then it transitions to encrypted content in the 2nd period.

Similar issue is observed on Mac OS X (High Sierra) as well.

Comment 58

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Jean-Yves Avenard [:jya] from comment #56)
> This is most puzzling, it appears to be an EME session, yet ffmpeg decoders
> are in use.

The CDM only contains a video decoder, not an audio decoder. So we can use the CDM to decrypt audio, but it gets decoded by the platform's decoder. The EMEDecryptor wraps the platform decoder, and manages the decryption and then uses the wrapped decoder to decode decrypted samples. It returns the wrapped decoder's description, not its own, which is why you're seeing the audio decoder identify as the wrapped decoder, not an EME decoder:

https://searchfox.org/mozilla-central/rev/9f3da81290054c5b8955bb67ff98cae66676f745/dom/media/platforms/agnostic/eme/EMEDecoderModule.cpp#277

Comment 60

[Jean-Yves Avenard [:jya]]

(In reply to Chris Pearce (:cpearce) from comment #58)
> (In reply to Jean-Yves Avenard [:jya] from comment #56)
> > This is most puzzling, it appears to be an EME session, yet ffmpeg decoders
> > are in use.
> 
> The CDM only contains a video decoder, not an audio decoder. So we can use
> the CDM to decrypt audio, but it gets decoded by the platform's decoder. The
> EMEDecryptor wraps the platform decoder, and manages the decryption and then
> uses the wrapped decoder to decode decrypted samples. It returns the wrapped
> decoder's description, not its own, which is why you're seeing the audio
> decoder identify as the wrapped decoder, not an EME decoder:
> 
> https://searchfox.org/mozilla-central/rev/
> 9f3da81290054c5b8955bb67ff98cae66676f745/dom/media/platforms/agnostic/eme/
> EMEDecoderModule.cpp#277

sure...
but I was referring to the video: we have the ffmpeg video decoder in use here. yet it's EME

Comment 61

[Jean-Yves Avenard [:jya]]

I can reproduce the error https://shaka-player-demo.appspot.com/demo/#asset=https://dai.google.com/ondemand/dash/content/2474151/vid/tosr2-widevine/manifest.mpd;license=https://proxy.uat.widevine.com/proxy;lang=en-US;build=uncompiled with the latest nightly...

Comment 62

[Julien Cristau [:jcristau]]

Comment on attachment 8962357 [details]
Bug 1447821 - Update EMEDecoderModule to handle profile values < 1.

we're about to build 60rc, too late for 59.