DASH: Improve handling of EMSG tracks
- 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
Assessment
This issue has not been assessed yet.