-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
MPD parser incorrectly treats @startNumber as a strictly positive integer value #10
Comments
This is definitely a bug in the MPD parser. Thanks for pointing this out. The fact that the 0th segment is not skipped is not a bug. If the video's playhead is at 0s, but there is no data in MediaSource for t=0s, then the video tag is in a "buffering" state. This is to be expected, since MediaSource allows for data to be inserted in an arbitrary order. You are right that timestamps need not begin at 0. In that case, though, the correct thing to do is to use SegmentTemplate@presentationTimeOffset to indicate where they do start. This is given in the timescale, so for the MPD you linked above, setting presentationTimeOffset="3000" for both SegmentTemplates allows playback to begin with firstSegmentNumber="1". We will get the @firstSegmentNumber parser bug fixed, though. Thanks! |
Closes b/19093388, #10. Change-Id: Ie05b1f337f4ffd6b24d3e56666663a2ecc284deb
I'm afraid that commit 5c7fca9 doesn't quite fix the problem. Also, there is a second occurrence of parsing @startNumber (in SegmentList), which suffers from the original problem of calling mpd.parsePositiveInt_ Here's an MPD with @startNumber=0: |
Thanks, Gilles. We'll take a look. |
Yes, 5c7fca9 is definitely not correct. However, after looking at the MPD spec. (ISO/IEC 23009-1:2014) more closely, it appears that The spec. indicates in section 5.3.9.5.3 that the |
It seems indeed that this clause would prevent @startNumber from ever having the value 0. -- Gilles On February 3, 2015 at 10:57:03 AM, tdrews ([email protected]) wrote: Yes, 5c7fca9 is definitely not correct. However, after looking at the MPD spec. (ISO/IEC 23009-1:2014) more closely, it appears that startNumber must be greater than zero. The spec. indicates in section 5.3.9.5.3 that the — |
We definitely see the point of view that We will revert |
MPEG has published a corrigendum to the spec, that fixes the muddy language around the computation of segment numbers. The new text (found in ISO/IEC 23009-1:2014/Cor.1:2014(E)), makes it possible for @startNumber to be 0. The problematic computation which would have led to a negative If @duration attribute is present, then the MPD start time of the Media Segment is determined as (Number-NumberStart) times the value of the attribute @duration with NumberStart the value of the @startNumber attribute, and Number the segment number (e.g. (k-1) + NumberStart). So #10 should be re-opened. -- Gilles On February 3, 2015 at 5:13:29 PM, Joey Parrish ([email protected]) wrote: We definitely see the point of view that xs:unsignedInteger implies the validity of 0, so thank you for following up on this with the DASH-IF. We will revert 5c7fca9 and consider @startNumber=0 to be invalid again until there is a clear correction to the spec one way or the other. Please reopen this issue if @startNumber=0 is clarified to be valid. — |
Thanks for the update. We will try to fix our code to reflect this
corrigendum.
|
I can't seem to locate the corrigendum (ISO/IEC 23009-1:2014/Cor.1:2014(E)) on the ISO site. Where is this document available from? Thanks. |
I think there's still a problem with the updated code. It still forces startNumber to be 1, even if the MPD specifies @startNumber = 0. From the spec: So if @startNumber == 0, $Number# for the first segment (i.e k=1) is 0 |
Our previous fix, as you pointed out, was insufficient. We reverted that change for now. As @tdrews pointed out in his comment earlier in the thread, it seems that the only way to interpret 23009-1:2014 to ensure that You mentioned a corrigendum, but it does not appear to be available in the list of publicly available standards on the ISO website. We are still unable to locate it this morning, not even on the corrigenda tab under 23009-1:2014. We'd love to resolve this in a way that is consistent with the latest amendments to the spec. Where can we find this corrigendum? |
It seems indeed that the latest corrigendum isn’t available on the IEC or ISO websites. That’s surprising, given that the final text for this doc was published on Oct 30 2014. -- Gilles On February 17, 2015 at 10:07:12 AM, Joey Parrish ([email protected]) wrote: Our previous fix, as you pointed out, was insufficient. We reverted that change for now. As @tdrews pointed out in his comment earlier in the thread, it seems that the only way to interpret 23009-1:2014 to ensure that You mentioned a corrigendum, but it does not appear to be available in the list of publicly available standards on the ISO website. We are still unable to locate it this morning, not even on the corrigenda tab under 23009-1:2014. We'd love to resolve this in a way that is consistent with the latest amendments to the spec. Where can we find this corrigendum? — |
I'm not comfortable making changes at this time based on a document that isn't open to the public. However, I'm reopening this issue so that we don't lose sight of it. When the updated standard is published, I will be happy to implement it. |
Hi, @joeyparrish. I was able to access the corrigendum document for free here. The ISO doc repository is a bit confusing, so here are the repro steps:
The text that @barbibulle refers to is on page 22. Can we get this implemented now? A customer of ours has come across the issue and it is blocking them b/c their video encoding provider always sets the startNumber == 0. Thanks-- |
Thanks for the link. I will take a look. |
The MPD parser expects the @startNumber attributes to be strictly positive (shaka.dash.mpd.SegmentList.prototype.parse and shaka.dash.mpd.SegmentTemplate.prototype.parse when computing firstSegmentNumber).
This is incorrect, as the DASH schema specifies:
<xs:attribute name="startNumber" type="xs:unsignedInt"/>
The default value is correctly set to 1, but values of 0 should be accepted.
Here's an example MPD with @startNumber=0:
http://www.bok.net/dash/tears_of_steel/cleartext/stream.mpd
(If the change is made to allow for 0, the stream plays correctly)
NOTE: I think this bug hides a second bug: if the stream is played starting from segment index 1 (instead of 0), as is the case when @startNumber=0 isn't accepted, the segments, starting from index 1, are correctly downloaded and sent as source buffers, but nothing is played. Instead, it would be expected that the video would play, except that the first segment (index 0) would be skipped.
It is likely that the player assumes that the media timestamps in the segments always start at 0, so starting with segment 1 (with a non-0 timestamp) is buffered but never starts playing (the decoder probably still waits for timestamp 0 to be sent).
However, it is perfectly legal for media segments to have timestamps that don't start at 0.
The text was updated successfully, but these errors were encountered: