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

Interpreting EMSG events #698

Closed
sanbornhilland opened this issue Feb 15, 2017 · 2 comments
Closed

Interpreting EMSG events #698

sanbornhilland opened this issue Feb 15, 2017 · 2 comments
Assignees
Labels
status: archived Archived and locked; will not be updated type: docs Improvements or fixes to documentation type: enhancement New feature or request
Milestone

Comments

@sanbornhilland
Copy link
Contributor

I'm looking for clarification on how to interpret the EMSG events being sent by Shaka, specifically, the timing info.

Shaka sends an event that looks roughly like this:

const mockShakaEmsgEvent = {
      type: 'emsg',
      timestamp: 168271.6,
      detail: {
        messageData: [88, 89, 90 ....],
         eventDuration: 0,
         id: 1000300,
         presentationTimeDelta: 0,
         schemeIdUri: "urn:foo:bar:id3:2016",
         timescale: 48000
         value:"0"
      }
    };

Does the mockSkakaEmsgEvent.timestamp refer to the timestamp of the event stream event? Meaning if you take ( timestamp / timescale ) - presentationTimeDelta it will give the presentation time of the start of the event?

I think my confusion is resulting from several things. The timescale property docs say:

Provides the timescale, in ticks per second, for the time and duration fields within this box.

There is an eventDuration field on the event.detail object so I assume that the timescale applies to that property. But there is no time property on the event.detail object so it's unclear to me which time the timescale applies to. Do I need to parse the messageData or does the timescale apply to the timestamp property?

Part of my confusion also is coming from the fact that I am getting different emsg timestamps for the same sample content from the Chromecast MPL library than I am from the Shaka player.

@TheModMaker
Copy link
Contributor

The timestamp field is the time the event was created, so has no use here. presentationTimeDelta represents the time (in units of timescale) that the event starts. This is relative to the segment that it is embedded in. eventDuration represents the duration (in units of timescale) that the event lasts.

So the presentation times would be:

startTime = segmentStartTime + (presentationTimeDelta / timescale);
endTime = startTime + (eventDuration / timescale);

We should update the docs to be explicit about these fields. Currently there is no way to get the start time of the segment. The reason is that the parsing of the emsg box is done as a network response filter, which doesn't have access to the segment info it came from. We should consider providing this info somehow (e.g. parsing the sidx).

Do you have a public manifest that has emsg boxes?

@sanbornhilland
Copy link
Contributor Author

Okay thanks that makes things a lot clearer.

You can use this test stream: http://demo.yospace.com/quickplay/dash/vod.mpd

@TheModMaker TheModMaker self-assigned this Feb 16, 2017
@TheModMaker TheModMaker added type: bug Something isn't working correctly type: docs Improvements or fixes to documentation labels Feb 16, 2017
@TheModMaker TheModMaker added this to the v2.1.0 milestone Feb 16, 2017
@TheModMaker TheModMaker added type: enhancement New feature or request and removed type: bug Something isn't working correctly labels Feb 16, 2017
@shaka-project shaka-project locked and limited conversation to collaborators Mar 22, 2018
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated type: docs Improvements or fixes to documentation type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants