google / google/ExoPlayer

DASH: Improve handling of EMSG tracks

Open
#9,563 3 comments 0 reactions 1 assignee Assigned to @icbaker View on GitHub
bug
Dominant language
Java
Stars
21.9k
Forks
6k
PR merge metrics
No merged PRs in 30d

Description

Hello,

Our project has a requirement to report some 3rd party ID3 metadata contained within our DASH streams.
This metadata is in the format of `` XML tags inside audio `` of our manifests in addition to emsg atoms in the fMp4.

Example from manifest:
``
``
``

For the majority of the streams, everything works as expected and we are able to see EMSG output from `EventLogger` (eg `MetadataOutput.onMetadata()` is called from `MetadataRenderer` ):
`com.google.android.exoplayer2.demo D/EventLogger: EMSG: scheme=www.3rd-party.com:id3:v1, id=0, durationMs=728, value=1`

However for some streams, `MetadataOutpout.onMetadata()` is not fired and no EMSG output is observed in the logs. We are unsure whether it is a problem with our streams, or a problem with some ExoPlayer logic. Hence, we are opening this issue as a question rather than a bug or feature request until root cause has been identified.

We are leaning toward some ExoPlayer issue, as our web devs have reported that the Shaka player is able to output the events from the same streams as expected. Additionally, as stated in this issue's title, ExoPlayer's `FragmentedMp4Extractor` successfully encodes the `EventMessage` with appropriate messageData when processing the mp4:
`EventMessage eventMessage = new EventMessage(schemeIdUri, value, durationMs, id, messageData);`
`ParsableByteArray encodedEventMessage = new ParsableByteArray(eventMessageEncoder.encode(eventMessage));
`

From debugging the ExoPlayer source code, the main difference in behavior we see is that inside `MetadataRenderer.read()` function, the call to `readSource()` never returns `C.RESULT_BUFFER_READ` for the streams that do not fire this event, and so no `pendingMetadata` is set. But since there are no warnings or errors, it is difficult to understand where and why things are going wrong. We are currently on ExoPlayer version 2.14.2, and have tried the latest version 2.15.1 as well as the previous version we were on, 2.12.3. We can reproduce this behavior using the same streams within the ExoPlayer demo app.

I have sent sample streams to dev.exoplayer@gmail.com that demonstrate expected vs problematic behavior.
Any insight would be greatly appreciated.
Thank you for your time.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.