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

How can I query for the active codec and bandwidth being played in a mixed-codec, multi-period manifest? #6725

Open
willdharris opened this issue May 31, 2024 · 8 comments · May be fixed by #6825
Assignees
Labels
priority: P3 Useful but not urgent type: enhancement New feature or request
Milestone

Comments

@willdharris
Copy link
Contributor

Have you read the Tutorials?
Yes

Have you read the FAQ and checked for duplicate open issues?
Yes

If the question is related to FairPlay, have you read the tutorial?

N/A

What version of Shaka Player are you using?
4.9.0 and main

What browser and OS are you using?
Chrome Version 125.0.6422.113 (Official Build) (arm64)
macOS Ventura 13.6

Please ask your question

My question is related to Shaka's period flattening and representation matching. During playback, when a variant has multiple codecs that it could change between, is there a way to query for the true codec and bandwidth being played?

  • I have a DAI manifest (DASH, static, multi-period) with representations of different video codecs per period.
  • When Shaka flattens the periods, it matches representations from each period and creates a single outputStream.
  • The single outputStream could include multiple different codecs and bandwidths that could be played.
  • That outputStream eventually becomes a variant track with a single video codec and bandwidth value.
  • The alternate, matched representations that the variant could be playing are obfuscated.

During playback, is there a way to access the obfuscated representations during the periods in which they are being played?

Example

  • My manifest has 3 periods: pre-roll-1-ad-1, pre-roll-1-ad-2, 0.
  • Periods pre-roll-1-ad-1 and pre-roll-1-ad-2 only have hev and avc representations, they do not have dvhe representations.
  • Period 0 has dvhe representations.
  • I want to play the Dolby Vision version of the content, so I configure the player with preferredVideoCodes = ['dvhe'].
  • Since the pre-roll periods do not contain dvhe representations, I see hev representations from the pre-roll periods have been matched to the dvhe outputStreams as the alternate representations.
    dvhe-matches
  • During playback of the pre-rolls, if I query for the active variant track player.getVariantTracks().find((track) => track.active), I will see that a dvhe codec variant is playing. I know that is not accurate because the manifest does not have dvhe representations in the pre-roll periods. If I inspect the network for the segments being download and buffered, I can confirm that it's the hev segments being played.

In the case of the above screenshot, depending on the presentation time, this variant labeled with a dvhe codec could be playing an hev codec with a bandwidth of 4.2mb or it could be playing the actual dvhe codec with a bandwidth of 5.8mb. Is there a way to access the true codec and bandwidths being played?

@willdharris willdharris added the type: question A question from the community label May 31, 2024
@avelad
Copy link
Collaborator

avelad commented Jun 3, 2024

@theodab Since you did this part, I'll let you answer the question.

@shaka-bot
Copy link
Collaborator

@willdharris Does this answer all your questions? If so, would you please close the issue?

@shaka-bot shaka-bot added the status: waiting on response Waiting on a response from the reporter(s) of the issue label Jun 7, 2024
@avelad avelad removed the status: waiting on response Waiting on a response from the reporter(s) of the issue label Jun 7, 2024
@shaka-bot
Copy link
Collaborator

@willdharris Does this answer all your questions? If so, would you please close the issue?

@shaka-bot shaka-bot added the status: waiting on response Waiting on a response from the reporter(s) of the issue label Jun 11, 2024
@avelad avelad removed the status: waiting on response Waiting on a response from the reporter(s) of the issue label Jun 11, 2024
@theodab
Copy link
Collaborator

theodab commented Jun 14, 2024

There is no built-in way to check this. You could use shaka.Player.getManifest to determine this from the manifest, but relying on that player method is not suggested as the manifest structure is not part of the public interface and might change between versions.
So I'll just write a player method for it, I guess.

@theodab theodab added type: enhancement New feature or request and removed type: question A question from the community labels Jun 14, 2024
theodab added a commit to theodab/shaka-player that referenced this issue Jun 14, 2024
@theodab theodab linked a pull request Jun 14, 2024 that will close this issue
@shaka-bot shaka-bot added this to the Backlog milestone Jun 14, 2024
@caridley
Copy link
Contributor

I think the mediaqualitychanged events have the information that you are looking for

    interface MediaQualityInfo {
      audioSamplingRate?: number;
      bandwidth: number;
      codecs: string;
      contentType: string;
      frameRate?: number;
      height?: number;
      mimeType?: number;
      channelsCount?: number;
      pixelAspectRatio?: string;
      width?: number;
    }

@caridley
Copy link
Contributor

but the solution in #6825 looks cleaner

@willdharris
Copy link
Contributor Author

Thanks @caridley. I hadn't looked at the mediaqualitychanged event for this yet, that looks helpful.

@theodab The proposed getCurrentPlaybackInfo method would be great to have. Thanks for working on that!

@avelad avelad added the priority: P3 Useful but not urgent label Jun 19, 2024
@avelad
Copy link
Collaborator

avelad commented Jun 20, 2024

@caridley It seems that mediaqualitychanged has many shortcomings... It only works for MP4 with initialization segments and only for DASH.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: P3 Useful but not urgent type: enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants