EventMessageEncoder encoding wrong duration

[Reevn]

Hi there!

This problem is not specific to any platform or ExoPlayer version.

Problem

I've encountered a problem with how the duration of EventMessages (such as DASH EventStream events) is parsed. Per DASH spec it is valid to omit the duration of an MPD event, which means that the duration is unknown. In that case, this is the current workflow as far as I understand it:

• C.TIME_UNSET is set as the duration when parsing the manifest, which is of type long and a negative value.
• This is then encoded as an unsigned int when encoding the EventMessage in the EventMessageEncoder
• Later it is read as an unsigned int in the EventMessageDecoder, leading to an actual "random" duration when decoded, even though the duration is unknown in the MPD.

This leads to the following values:

// current behaviour
decodedEventMessage.durationMs // 2481536660

// behaviour I would expect
decodedEventMessage.durationMs // C.TIME_UNSET

For emsg boxes inside the media container the duration is already encoded, but the decoding step does not check if the encoded duration is the value for "unknown duration".

Proposal

The DASH spec section 5.10.3.3.4 says the following:

event_duration provides the duration of event in media presentation time. The timescale is indicated in the timescale field. The value 0xFFFF indicates an unknown duration.

To me it seems that two things need to be adjusted

• When parsing the MPD, encode a missing duration in MPD events as 0xFFFF/65536 instead of C_TIME_UNSET
• When decoding an EventMessage, set EventMessage.durationMs to C_TIME_UNSET if the encoded duration is 0xFFFF/65536

With these two changes both In-band and Out-of-band events would work in the same way and expose an unknown duration as C.TIME_UNSET. I guess this can be seen as a breaking change for In-band events or a bug fix for both In-band and Out-of-band events.

I am happy to open up a PR if the proposal makes sense.

[icbaker]

Thanks for reporting this.

EventMessage{De,En}coder use a custom serialization scheme, it's not intended to be compatible with the in-band bytes representation (since 97183ef and a08b537).

So I think the easiest solution is to just encode durationMs as a 64-bit int, instead of an unsigned 32-bit int. I'll make that change (and change id too while I'm at it).