New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 694346 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Feb 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Videos fail to play when served by serviceworker with MediaEvent PIPELINE_ERROR

Reported by xus...@gmail.com, Feb 20 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

I have found some very weird behavior in regards to service workers and videos. Videos served by service workers are only playable under very specific circumstances. I first came across this behavior in the "Service Worker Sample: Cache Video Sample" found here https://googlechrome.github.io/samples/service-worker/prefetch-video/.

Steps to reproduce the problem:
1) Open a new incognito window
2) Navigate to https://googlechrome.github.io/samples/service-worker/prefetch-video/ . This site has a video tag with two sources. First a webm then a mp4 source.
3) Play the video while monitoring the Network tab in the dev tools. The request should not be intercepted by the service worker yet. You should see that the webm source is the one being streamed since it appears before the mp4 source as expected.
4) After the service worker has finished installing, refresh the page so it is loaded from the service worker. While monitoring the network requests, you should see a request for the webm source. At around this time, chrome logs a MediaEvent PIPELINE_ERROR to chrome_debug.log. Then since the webm source didn't work for the browser, the mp4 version is requested and the video plays fine.

This scenario is one of the few scenarios where the playback works even though the error happened. If the video tag has only one source (either the mp4 or webm) then the video consistently fails to play with a MediaEvent PIPELINE_ERROR when served by the service worker, but works just fine if it's not served by the service worker. Also if the order of the sources are switched so that the mp4 source comes first then the video also fails to play when served by the service worker with a MediaEvent PIPELINE_ERROR

I'm not sure why, but I've been able to reproduce this consistently in incognito mode but not normal mode. I have also tested this with different mp4 files with the same result.

The full error - [92599:775:0219/141417.306944:ERROR:render_media_log.cc(25)] MediaEvent: PIPELINE_ERROR pipeline: read error

I decided to dig a little deeper into this and found some weirder results.

I served these files with Express, but any http server with RANGE header and ETAG support should work. I did find using incognito mode to be more reliable in reproducing these issues.

gbike.webm: https://prefetch-video-sample.storage.googleapis.com/gbike.webm

index.html
```
<!doctype html>
<html>
<head>
  <meta charset="utf-8">
  <title>Demo</title>
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <script>navigator.serviceWorker.register('/sw.js')</script>
</head>
<body>
  <video controls>
    <source src="gbike.webm" type="video/webm">
  </video>
</body>
</html>
```

sw.js (v1):
```
addEventListener('fetch', function (event) {
  event.respondWith(fetch(event.request))
})
```

gbike.webm consistently fails to play with a MediaEvent PIPELINE_ERROR when served from the service worker.

Changing the service worker file so it ignores 'If-Match' headers fixes the problem and videos play great!

sw.js (v2):
```
addEventListener('fetch', function (event) {
  let headers = new Headers(event.request.headers)
  headers.delete('If-Match')
  let request = new Request(event.request.url, {headers: headers})
  event.respondWith(fetch(request))
})
```

But this only works when the Response object is the one created by fetch(). Creating a Response with the same body, headers, status, etc doesn't work and the video fails to play a PIPELINE_ERROR.

sw.js (v3):
```
addEventListener('fetch', function (event) {
  let headers = new Headers(event.request.headers)
  headers.delete('If-Match')
  let request = new Request(event.request.url, {headers: headers})

  event.respondWith(fetch(request)
  .then(response => {
    return new Response(response.body, {
      headers: response.headers,
      status: response.status,
      statusText: response.statusText
    })
  }))
})
```

Did this work before? No 

Does this work in other browsers? Yes

Chrome version: 56.0.2924.87  Channel: stable
OS Version: OS X 10.11.6
Flash Version: Shockwave Flash 24.0 r0

This is my first reported issue so I'm still new to this! If there is anything I can do to provide clarity or be of help just let me know!

 
Cc: krajshree@chromium.org
Labels: Needs-Feedback
Tested this issue on Mac 10.12.2 using chrome reported version #56.0.2924.87 and latest canary #58.0.3018.0.

Attached a screencast for reference.

Steps followed to reproduce the issue are as follows:
-----------
1. Opened a new incognito window using chrome version #56.0.2924.87.
2. Navigated to https://googlechrome.github.io/samples/service-worker/prefetch-video/
3. Opened network tab in dev tools and played video.
4. Waited for service worker to finish installing and then refreshed the page.
5. Observed that the video stopped playing.

Note: Performed similar steps from 1 to 3 in latest canary #58.0.3018.0. But while performing step 4, the page got crashed after refreshing the page.

xuset1@ - Could you please verify the screencast and please let us know if anything missed from our side.

Thanks...!!
694346.mp4
10.9 MB View Download

Comment 2 by xus...@gmail.com, Feb 21 2017

Thanks for looking into this krajshree! Looking at the screencast I saw that before the sw took control, the page was playing the webm source then afterwards was playing the mp4 source, and I also saw that the webm and mp4 sources were requested despite only needing one which is what I was experiencing. Weirdly, I'm not able to reproduce this behavior anymore, the webm source plays fine now when served from the serviceworker and the MediaEvent PIPELINE_ERROR is no longer logged. Maybe you can still reproduce it, but since it works now, it appears that it isn't related to video failing to play when using the service workers I originally posted above. Admittedly it was bad to group these two different sources of code together, but I thought they were related to the same bug.

I think what's best at least for now is to close this issue since it is scattered and the steps to reproduce no longer seem to be related with the bug I was experiencing. I'll open a new issue with a more clear and concise steps to reproduce the actual problem once I get the info and code together. Thanks krajshree and sorry for wasting your time!
Status: WontFix (was: Unconfirmed)
As per comment #2 closing this issue as won't fix.

Thanks...!!

Sign in to add a comment