EventMessageEncoder/Decoder doesn't work well with Long values

[jankowskib]

Issue description

I have EventMessages with a large presentation time value e.g. '<Event presentationTime="16122561404240"'. Unfortunately EventMessageEncoder stores this big values using writeUnsignedInt instead of writeUnsignedLong and the part of its value is discarded. So when EventMessageDecoder tries to decode message from inputBuffer the value is totally incorrect.

Reproduction steps

1. Init ExoPlayer with https://gist.githubusercontent.com/jankowskib/92a5e955d2bf94b45721f4783ec22206/raw/738dc7443071cd8c5e5bf880ecb8ca2666bff02f/scte35.mpd
2. Set breakpoint on onMetaData
3. presentationTimeUs value is incorrect

Link to test content

Provide a link to media that reproduces the issue. If you don't wish to post it
publicly, please submit the issue, then email the link to
dev.exoplayer@gmail.com using a subject in the format "Issue #1234".

Version of ExoPlayer being used

2.9.1

[ojw28]

We're currently misusing the presentation_time_delta Event field to store absolute presentation timestamps. This doesn't work properly for large timestamps, because the field is only 32 bits. We don't actually need to pass the presentation timestamps through the binary representation of EventMessage, so we'll push a fix that stops doing this.

[jankowskib]

Thank you for quick reply. I temporarily extended serialized field to 64 bit and it works fine. Here's the commit if interested (jankowskib@8d02b75)
@ojw28 Do you suggest to add presentationTime as an argument to EventMessageEncoder.decode(...) in the same way as timescale? I could do a PR with such fix

[ojw28]

Extending the serialized field to 64 bit will break parsing of in-band (i.e. embedded in FMP4) emsg atoms. Which may or may not be a problem for your use case. There's no need for EventMessage to contain presentation timestamp at all. We will push a change to fix this problem sometime today or tomorrow.

[jankowskib]

OK. It's no longer issue for me

[ojw28]

Reopening to track landing a fix. It's still a bug ;).