-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple Event/Emsg-related problems #3429
Comments
|
Update on 1. Seems to be related to wrong/no usage of the presentationTimeOffset when calculating the presentation time. This should be fixed in dash.js. |
Hi Daniel, thanks for looking into this. I compared our stream with the stream from MISB https://www.mistandards.org/demo/cmaf/data/H264/cmafsample.mpd and it appears that while each emsg box from the MISB stream has got a distinct presentation_time value, in our stream I can find examples where multiple emsg boxes have got the same presentation_time value, which can explain problem 2. I think we need to fix it and see if it changes the behaviors on problems 3. and 4. The MISB stream can be interesting as a comparison point on problem 1. too. They have a dash.js-based player (https://www.mistandards.org/demo/cmaf/cmaf-viewer/) where the stream plays fine the |
Actually it looks like the fact that emsg boxes reuse the same id value across segments is the main problem for live streaming, now that we have verified all the other points in our implementation. When receiving a new emsg box, the player treats it as an update, as the emsg id already exists in the timeline/memory. Hence this question: do the emsg box id (or the equivalent event stream id after parsing of the emsg boxes) stay forever in the player memory, or are the events flushed out when the timeshift buffer depth is reaching its limit? |
The events are flushed out either after being expired or after being triggered. This includes:
Regarding updating/replacing existing events: This is only the case for inline events. Inband events which are already exist (same id) are ignored: Inline : Replacing existing events
Inband: : Ignoring event updates
I sent a longer mail to the Event TF which includes exactly this question: Are we supposed to replace existing inband events which have not been started? Or do we ignore them? In my opinion the behavior for inline and inband events should be consistent. I haven't received any responses on my questions yet, will try to bring this up in the next Event TF call. |
@dsilhavy Thanks for the insight, this is as complex as I was expecting. Apparently we have hit another player rule, which is the single execution per event id (unless this is the inband event updates that are ignored), but that's clearly because our ids repeat over time, and this is not spec compliant. See Gary's (MISB) diagnosis below: As the ids need to be unique as long as they are in the playback window, there is no reason why the inline and inband updates should behave differently. Allowing updates in both cases (if the event.presentationTime hasn't been reached yet) seems to be the safest approach as you can always meet cases where the first message is erroneous and an update is sent to fix it. As regards problem 1. (VOD and no usage of PTO), the best I can do in terms of VOD sample stream is to propose this live URL with time parameters that actually generates a VOD manifest: https://c4af3793bf76b33c.mediapackage.us-west-2.amazonaws.com/out/v1/769dc73e096b47b290bfc3f7278f28f9/index.mpd?start=2020-12-02T15:30:00-07-00&end=2020-12-02T15:35:00-07-00 |
@nicoweilelemental I did some changes to the event timing model in dash.js in #3471 . They should be reflected in the nightly branch: http://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html I can see events being dispatched using your Live to VoD sample from above. Can you confirm that the timing is correct? Sidenote: I feel like a high amount of events can crash the player. We might need to find a less resource consuming way to manage and dispatch them. |
@dsilhavy Thanks for the fix, the flow of events looks good. I'll need to get the nightly library integrated into a partner player to verify the KLV display, as there is a specific processing library to use for that. Regarding the amount of events: did you manage to trigger a crash or is it just an assumption? |
I saw playback stalling when printing events to the developer console. However, it worked fine when closing the developer console. Looking forward to the findings of your partner |
@dsilhavy Quick clarification question: if I send two different emsg boxes with the same 'id' field value but not the same 'value' field value, it will result in two different events, and not in an overwrite operations of a single event, right? |
@nicoweilelemental No, the event will only be handled once if the id field value is the same. However, it seems you are right this should be different. From 23009-1:
We need to consider the scope here (scheme_id + value). We will fix this, thanks for pointing it out. |
@nicoweilelemental The problem with events using the same id fields and overwriting each other despite different value fields should be fixed in #3504. It was merged into the nightly build |
Thanks @dsilhavy , much appreciated! |
@nicoweilelemental Do you think we can close this issue? Or did your tests show additional issues? |
HI @dsilhavy I think we can close it. I need to run additional tests once we will have modified our implementation for KLV. Will open a new ticket if I find further problems. Thanks |
Hi @nicoweilelemental |
Environment
Steps to reproduce
Please provide clear steps to reproduce your problem
Load stream in dash.js or load Crafter player for more debugging capability (https://videosuite.craftercms.org)
If the bug is intermittent, give a rough frequency if possible
Problems are permanent
Observed behaviour
We are injecting KLV metadata in emsg boxes v1 (one emsg box per KLV message). This is done as per the MISB ST 1910 spec. The data rate can be as high as one KLV message per video frame.
Emsg don't trigger stream event in VOD
When a VOD extract of the live stream is played, no event is triggered like with the live stream.
https://c4af3793bf76b33c.mediapackage.us-west-2.amazonaws.com/out/v1/769dc73e096b47b290bfc3f7278f28f9/index.mpd?start=2020-10-12T14:30:00-07-00&end=2020-10-12T14:35:00-07-00
We suspect that there might be a problem with events management in VOD streams.
Multiple emsg boxes content are aggregated inside a single event payload
This is visible in the Crafter player. The left counter ("emsg messages") is the number of events received and the right counter is the number of KLV samples found inside the events. The two counters should have the same value if each emsg box was treated as a single event.
This can be further shown by typing "printKlvEvents=1" in the javascript console of the Crafter player. It will show the detail of the received messages. The number of lines in the messageData section of each Event wil show how many emsg boxes are contained in a single event: one emsg box is 2 lines of data, and the Events including 3 emsg boxes have 6 lines of data.
We suspect that there might be an aggregation of multiple emsg boxes contents into a single event messageData.
Segment duration influences extracted events rate
Same stream but with 30s segments shows a much higher number of events being extracted
https://c4af3793bf76b33c.mediapackage.us-west-2.amazonaws.com/out/v1/e0c840c123cb48429edca086064d299f/index.mpd
We suspect that this is correlated to the previous point, meaning that the events signaling cycle seems to not be based on the number of emsg boxes present in the segments, but on a timing logic that is specific to the player.
Emsg boxes v1 don't seem to be supported
We use emsg boxes v1 (and not v0). But when we look at the details of the Events (using the "printKlvEvents=1" console command in the Crafter player), we see that the Events have got a presentationTime: NaN field value. We suspect that this is either the result of the concatenation of multiple emsg boxes content into a single Event, or caused by a lack of support for emsg boxes v1, where the data fields are not ordered the same way in the payload.
A diagnosis would be highly appreciated. Thanks!
The text was updated successfully, but these errors were encountered: