How to add Timed Events to Exoplayer2

[trckashyap]

Hi,
Need API to add timed events to Exoplayer2
I have 3 events in a video of duration (03:00), I need to get timed event when the time stamp crosses(00:45, 01:50 & 02:30). What should be done to add these events.

Thanks And Regards,
Kashyap Tadikonda

[trckashyap]

I have captionslist where each caption contains title, startTime & endTime. how to add these to Exoplayer/embed to subtitle view.
Similarly I have slide events to display slides.

Please help in integrating them to Exoplayer and I need to get time event.

[ojw28]

What format are the subtitles provided in? If they're in a standard subtitle format that we support, you can just use ExoPlayer's built in subtitle support.

[ojw28]

Marking this as a general enhancement to support triggers are certain positions in the media. It's unclear whether that's really what the original poster wants, but request was never clarified.

[mapsver]

do u know if is this being worked on for an upcoming release ?

[tonihei]

It's being worked on. But not for the upcoming 2.6 release. More likely the next one.

[mapsver]

Thank you ! Meanwhile, Is there an example that uses a custom renderer for this purpose (or something similar). I couldn't find anything relevant online or in the demo (could only find usage of SimpleExoPlayer)

[tonihei]

While working on this feature, we came across some edge cases where it's unclear how the new feature should work:

• What happens when the player plays the same position twice (e.g. when repeating, or after seeking back). Should the event be fired again or only once?
• What happens when the player seeks to a position behind the callback position. Should the event still be triggered or only when the playback naturally progresses over the callback position.
• Should the event be triggered on an app callback thread (slower, but does not block playback) or on the internal playback thread (direct, but blocks playback)?

Please let us know which version would fit your requirements best.

[mapsver]

Im not the OP.. but Ill add my 2cents worth.

What happens when the player plays the same position twice (e.g. when repeating, or after seeking back). Should the event be fired again or only once?
The event should be fired every time it hits that position. Having the event fire only the first time would be a special case, for which the observer can always write logic to check and ignore. Depending on how its implemented, the logic can be to unregister the event listener after the first time.

What happens when the player seeks to a position behind the callback position. Should the event still be triggered or only when the playback naturally progresses over the callback position.
The event should only trigger during forward playback (either in original speed or otherwise), but not when seeking forward or backward past the event position.

Should the event be triggered on an app callback thread (slower, but does not block playback) or on the internal playback thread (direct, but blocks playback)?
My preference would be on an separate thread. With this approach, blocking/allowing playback to continue is controlled by the caller.

Sorry to bug.. but like Id asked earlier, is there an example that uses a custom renderer that I can use to workaround this.

[andrewlewis]

@mapsver One way to do this is to subclass NoSampleRenderer and return it from a custom RenderersFactory which you pass to newSimpleInstance. There are a few things to be aware of:

• You can access the player's internal position in the render method of your custom renderer, but please note that this value will be offset by the last value passed to the onRendererOffsetChanged, so you'll need to override that method too to keep track of the offset, then subtract it in render.
• After subtracting the offset you'll get a period position in microseconds, rather than a window position in milliseconds which is what's exposed by player.getCurrentPosition. Read the documentation of Timeline for more information.
• render is called on the player's internal thread, so you may need to communicate with another thread that actually handles the event. It's important not to block the player's internal thread.