New issue
Advanced search Search tips

Issue 592465 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 398141
Owner:
Closed: Mar 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature



Sign in to add a comment

Unable to playback DASH stream in DashIf Reference Player due to MEDIA_ERR_DECODE

Reported by hi.a...@gmail.com, Mar 7 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Firefox/44.0

Example URL:
http://dashif.org/reference/players/javascript/v2.0.0/samples/dash-if-reference-player/index.html

Steps to reproduce the problem:
1. Go to url http://dashif.org/reference/players/javascript/v2.0.0/samples/dash-if-reference-player/index.html
2. In the stream textbox enter media url http://dash.edgesuite.net/dash264/TestCases/2b/qualcomm/2/MultiRes.mpd and click 'Load'
3. Check for content playback

What is the expected behavior?
The DASH stream should playback

What went wrong?
No video playback. In console logs there is an error
[streamController] Video Element Error: MEDIA_ERR_DECODE

In chrome://media-internals/ the logs show the following error
00:00:00 180	error	video frame with PTS 0us has negative DTS -83333us after applying timestampOffset, handling any discontinuity, and filtering against append window
00:00:00 180	error	Append: stream parsing failed. Data size=131072 append_window_start=0 append_window_end=inf
00:00:00 180	pipeline_error	pipeline: decode error

Did this work before? N/A 

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? Yes 

Chrome version: 49.0.2623.75 (64-bit)  Channel: stable
OS Version: OS X 10.11
Flash Version: Shockwave Flash 20.0 r0

I analyzed the stream segments using mp4dump tool, and do not see anything unusual. Here is the dump of the first non-init video fragment for quick reference.
$ mp4dump --verbosity 3 BBB_768_1440K_video_0.mp4
[styp] size=8+16
[sidx] size=12+32
  reference_ID = 1
  timescale = 12288
  earliest_presentation_time = 0
  first_offset = 0
  entry 0000 = reference_type=0, referenced_size=1031915, subsegment_duration=61440, starts_with_SAP=1, SAP_type=1, SAP_delta_time=0
[moof] size=8+560
  [mfhd] size=12+4
    sequence number = 1
  [traf] size=8+536
    [tfhd] size=12+4, flags=20000
      track ID = 1
    [tfdt] size=12+4
      base media decode time = 0
    [trun] size=12+492, flags=205
      sample count = 120
      data offset = 576
      first sample flags = 0
      entry 0000 = sample_size:1669
      entry 0001 = sample_size:11
      entry 0002 = sample_size:11
      entry 0003 = sample_size:11
      entry 0004 = sample_size:1253
      entry 0005 = sample_size:3075
-----
 

Comment 1 by hi.a...@gmail.com, Mar 7 2016

Pls ignore the mp4dump above, it is for a different stream. Here is the relevant one
$ mp4dump --verbosity 3 BBB_768_1440K_video_1.mp4
[styp] size=8+16
[sidx] size=12+32
  reference_ID = 1
  timescale = 12288
  earliest_presentation_time = 1024
  first_offset = 0
  entry 0000 = reference_type=0, referenced_size=1021890, subsegment_duration=61440, starts_with_SAP=1, SAP_type=1, SAP_delta_time=0
[moof] size=8+1040
  [mfhd] size=12+4
    sequence number = 1
  [traf] size=8+1016
    [tfhd] size=12+4, flags=20000
      track ID = 1
    [tfdt] size=12+4
      base media decode time = 0
    [trun] size=12+972, flags=a05
      sample count = 120
      data offset = 1056
      first sample flags = 0
      entry 0000 = sample_size:839, sample_composition_time_offset:1024
      entry 0001 = sample_size:575, sample_composition_time_offset:2560
      entry 0002 = sample_size:56, sample_composition_time_offset:1024
      entry 0003 = sample_size:19, sample_composition_time_offset:0
      entry 0004 = sample_size:58, sample_composition_time_offset:512
      entry 0005 = sample_size:889, sample_composition_time_offset:1536
      entry 0006 = sample_size:710, sample_composition_time_offset:512
      entry 0007 = sample_size:1901, sample_composition_time_offset:1024
      entry 0008 = sample_size:5546, sample_composition_time_offset:1024
Labels: -Type-Bug -Pri-2 -OS-Mac OS-All Pri-3 Type-Feature
Components: -Internals>Media Internals>Media>Source
Owner: wolenetz@chromium.org
Status: Assigned (was: Unconfirmed)
matt, can you confirm if this bug is a duplicate of 398141? if it is, what's our plan for 398141?
FYI, this bug NOT repro on safari. 

With Chrome 49.0.2623.75, I confirmed repro (thanks hi.ansh@ for providing chrome://media-internals logs : those are very helpful in this case).

To see if this is a precise duplicate of  bug 398141 , I'll get some further log detail to see if timestampOffset is being used by the app. If not, this could be a different scenario that results in the same decode error.
Mergedinto: 398141
Status: Duplicate (was: Assigned)
Yes, this is a precise duplicate of  bug 398141 .
Logs show the player is explicitly updating SourceBuffer.timestampOffset:

SourceBuffer::setTimestampOffset 0x3bd1c0f8de40 offset=-0.083333

Then, though the first parsed video frame has PTS 0.083333 and DTS 0, once timestampOffset is applied, PTS becomes 0 and DTS becomes -0.083333, triggering the bug.

I'll update  bug 398141  with current status.

Sign in to add a comment