Add original emsg properties to the MetadataOutput.onMetadata callback or as properties into the eventMessage object

[villagra]

We're trying implementing a feature into our player where I need to get the original presentation time or presentation time delta & sampleTimeUs (https://aomediacodec.github.io/id3-emsg/) for these event messages.

Currently, I'm adding an analyticsListener and handling the onMetadata(eventTime: AnalyticsListener.EventTime?, metadata: Metadata?) method, but I can't find a way to get the original presentation time from the eventtime, and the metadata object doesn't contain this property neither.

I have also tried adding a MetadataOutput but here, I only get the Metadata object without any time associated.

In other players (like the mediaplayer in windows), the original emsg properties come as a dictionary in the onMetadata event:

Is there any other way to get the presentation time for emsg type 1 or the delta+salmple time for emsg type 0?
In our case, it would be also fine if I can match the metadata to the video chunk assoaciated and get the original url for that video chunk, but I haven't yet found the way to do that neither.

Thanks.

[icbaker]

Thanks for filing - I just want to make sure I've understood your requirement.

I can't find a way to get the original presentation time from the eventtime.

If I understand correctly, you can't derive the info you need from EventTime because the timestamps in there relate to ExoPlayer's playback position and not the timestamps of the underlying media? (this can happen if the media timestamps don't start at zero and is very common/inevitable for live streams)

In that case I don't think adding a timestamp parameter to MetadataOutput#onMetadata will help you - because that timestamp would also be using the same playback position (anything else would be a very surprising API imo).

So it seems like adding the info into EventMessage makes more sense for this use-case (since it's emsg specific). We'll have to think about how to represent v0 vs v1, because of the delta vs absolute time.

[villagra]

You got it right @icbaker
Yep, I also think it makes more sense to add it into the EventMessage itself.
A dictionary like the windows mediaplayer with the extra properties would do the trick...
For V0:

• presentation_time_delta
• earliest_presentation_time
• timescale

V1:

• presentation_time
• timescale

Thanks!

[icbaker]

Given the other fields are strongly-typed 'normal' fields on EventMessage, I think it would be inconsistent to use a Map<String, String> for the time-based ones.

We could introduce a class hierarchy (not sure about the unscaled suffix, but the point was to distinguish from durationMs):

abstract class EventMessage {
  public final String schemeIdUri;
  public final String value;
  public final long timescale;  // new field
  public final long durationMs;
  public final long durationUnscaled;  // new field
  public final long id;
  public final byte[] messageData;
}

class EventMessageV0 extends EventMessage {
  public final long presentationTimeDeltaUnscaled;
  public final long earliestPresentationTimeUnscaled;
}

class EventMessageV1 extends EventMessage {
  public final long presentationTimeUnscaled;
}

[villagra]

That's great 👍