In src/third_party/WebKit/Source/modules/media_controls/elements/MediaControlDownloadButtonElement.cpp,


  // Local files and blobs (including MSE) should not have a download button.
  if (url.IsLocalFile() || url.ProtocolIs("blob"))
    return false;

  // MediaStream can't be downloaded.
  if (HTMLMediaElement::IsMediaStreamURL(url.GetString()))
    return false;

  // MediaSource can't be downloaded.
  if (HTMLMediaSource::Lookup(url))
    return false;


Since MediaSource is already checked later, I think* we should remove the url.ProtocoloIs("blob").
We still need to figure out why downloading a video blob on Android fails though ;(

Note that I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=714126 for why downloading a blob fails on Android.

Sounds reasonable but we can't do this until  bug 714126  is fixed.

mlamouri@  bug 714126  is fixed.
Shall we address this current bug now?

CJ, is this something you would be interested to look at? :)

Hey just for clarification, should these videos actually have content? Right now I cant click play on them. Is that normal?

They do (for me at least).

They should contain 2 seconds of your camera stream.
Do you have a webcam? Do you see a prompt?

I do not have a webcam, nor do I see a prompt. I guess that would be required to fix this issue then? 

http://beaufortfrancois.github.io/sandbox/media/mse-blob-download.html doesn't show prompt because it is http not https. Please make sure you hit https://beaufortfrancois.github.io/sandbox/media/mse-blob-download.html

Here's attached what it should look like.

Also note that using the webcam is just a way for me to generate a video. The root issue is the fact that a video with a blob source should show download button if not MSE.

Deleted: Screenshot 2017-06-27 at 9.58.47 AM.png 70.7 KB

	Screenshot 2017-06-27 at 9.58.47 AM.png 70.7 KB View Download

It doesnt show the prompt whether http or https. I'll report back once I hook up this webcam I got. 

It looks like the video streams have an infinite duration and we will still not show the download button. Is there a way your test web page can mark the duration of the streams?

Array.from(document.querySelectorAll('video')).forEach(v => console.log(v.duration))

Infinity
1.895
1.895

First one is infinite but second and third videos are what we're looking for.

If we trace in src/third_party/WebKit/Source/modules/media_controls/elements/MediaControlDownloadButtonElement.cpp, we see that it hits the infinite duration case. Not sure why there is a mismatch between the javascript v.duration and the MediaElement.duration(), but thats what we are seeing.

Here's another page that does NOT use camera: https://beaufortfrancois.github.io/sandbox/media/mse-blob-download-alt.html

See Android results attached:
- Video MSE fails to download
- Video blob succeeded to download

Deleted: Screenshot_20170630-101610.png 483 KB

	Screenshot_20170630-101610.png 483 KB View Download

So interesting happenings. If I remove the url.ProtocolIs("blob") check, I get no button for both on the first link, and a button on each the second link. Will investigate further, but if there is something in particular with the site that might cause that, let me know, as I would not know such a thing.

To be honest, I don't see what could cause that.

First link: https://beaufortfrancois.github.io/sandbox/media/mse-blob-download.html


    const blob = new Blob(chunks, {type: 'video/webm'});
    videoBlob.src = URL.createObjectURL(blob);


    var mediaSource = new MediaSource();
    videoMse.src = URL.createObjectURL(mediaSource);



Second link: https://beaufortfrancois.github.io/sandbox/media/mse-blob-download-alt.html

    .then(response => response.blob())
    .then(blob => { videoBlob.src = URL.createObjectURL(blob); })


    .then(response => response.arrayBuffer())
    .then(data => {
      const mediaSource = new MediaSource();
      videoMse.src = URL.createObjectURL(mediaSource);

/me deleted previous comment to be more accurate.

For https://beaufortfrancois.github.io/sandbox/media/mse-blob-download.html,

This page uses MediaRecorder which causes duration to be infinite in that case.

mediaSource.duration = Infinity
videoBlob.duration   = Infinity
videoMse.duration    = Infinity

Webm files are not seekable by design. See https://bugs.chromium.org/p/chromium/issues/detail?id=599134 and https://bugs.chromium.org/p/chromium/issues/detail?id=642012#c25

-------------------

For https://beaufortfrancois.github.io/sandbox/media/mse-blob-download-alt.html,

I've changed video and added more logs to the page so that we can see video.duration and mediaSource.duration.

When I click first link (blob), I get a successful download.
When I click second link (mediaSource), I get a failed download.

I can reproduce same results on Android (63.0.3210.0) and Chrome OS (63.0.3212.0).


How can I help further?

Ok, just to reconfirm, because it has been a while, what is there versus what is wanted:

Link 1 Video 1 - Currently shows no button, should.
Link 1 Video 2 - Currently shows no button, should continue to show no button.
Link 2 Video 1 - Currently shows no button, should.
Link 2 Video 2 - Currently shows no button, should continue to show no button.

So when I remove the ProtocolIs("blob") check,

Link 1 Video 1 - Shows no button, stopped by the check against Infinity Duration. Can right click to save and succeeds.
Link 1 Video 2 - Shows a button, but fails the download. Probably shouldn't show a button.

Link 2 Video 1 - Shows a button, succeeds in download.
Link 2 Video 2 - Does not show a button. Cannot right click to save.

So it looks like that the suggested fix fixes the issues with the second link. I'll land that change and then continue to debug what is happening with the first link.

Also, I think I need to figure out what is going on with the failed MediaSource look up, because Link 1 Video 2 shouldn't really be getting a button. Will look into this for the current change as well.

The infinity issue might be a race condition, as I either get a button for Link 1 Video 2, or it hits the Infinity check. 

Something is Revoking the Object URL of Link 1 Video 2. Would you know why that could be?

Theory, can you make Link 1's video last 10 seconds?

In Link1, I revoke manually the objectURL of video2. See source:

    mediaSource.addEventListener('sourceopen', function(e) {
      URL.revokeObjectURL(videoMse.src); 
      ...

I don't do this in Link2.

I've changed Link1 and Link2 behaviours so that you can test this easily.

Link1 https://beaufortfrancois.github.io/sandbox/media/mse-blob-download.html                           => Does NOT revoke Object URL
Link1 https://beaufortfrancois.github.io/sandbox/media/mse-blob-download.html?shouldRevokeObjectUrl     => Revoke Object URL
Link2 https://beaufortfrancois.github.io/sandbox/media/mse-blob-download-alt.html                       => Does NOT revoke Object URL
Link2 https://beaufortfrancois.github.io/sandbox/media/mse-blob-download-alt.html?shouldRevokeObjectUrl => Revoke Object URL

You can also check if Link1's video length affects results now:

Link1 https://beaufortfrancois.github.io/sandbox/media/mse-blob-download.html?t=10                      => Record up to 10s of video
Link1 https://beaufortfrancois.github.io/sandbox/media/mse-blob-download.html?t=1                       => Record up to 1s of video

Default is still 2s.

I think* we shouldn't determine if a URL is a MediaSource with th LookUp method as revokeObjectURL removes that entry from the registry.

  // MediaSource can't be downloaded.
  if (HTMLMediaSource::Lookup(url))
    return false;


It may be as simple as exposing a new method hasMediaSource() on HTMLMediaElement and use it instead.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/54d44e5e0cd13e491d945d4034304c0d24a1bd6e

commit 54d44e5e0cd13e491d945d4034304c0d24a1bd6e
Author: CJ DiMeglio <lethalantidote@chromium.org>
Date: Wed Nov 08 01:07:50 2017

Updates download buttons to show up correctly during various situations.

This CL allow for blobs allow for a download button.
In enabling this, it was discovered that live videos with finite
duration were being mislabled to not have a download button, as their
duration was checked too early, and thus read as infinite.
It was also found that the check for MediaStreams was ineffective, as a
programmer may unregister the URL, causing a download button to show up
when there shouldn't be one.

Bug:  714117 
Change-Id: I6aa8cbe342021463dabedbb1b3a53c910166206c
Reviewed-on: https://chromium-review.googlesource.com/691155
Commit-Queue: CJ DiMeglio <lethalantidote@chromium.org>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Cr-Commit-Position: refs/heads/master@{#514692}
[modify] https://crrev.com/54d44e5e0cd13e491d945d4034304c0d24a1bd6e/third_party/WebKit/Source/core/html/media/HTMLMediaElement.h
[modify] https://crrev.com/54d44e5e0cd13e491d945d4034304c0d24a1bd6e/third_party/WebKit/Source/modules/media_controls/MediaControlsImpl.cpp
[modify] https://crrev.com/54d44e5e0cd13e491d945d4034304c0d24a1bd6e/third_party/WebKit/Source/modules/media_controls/MediaControlsImplTest.cpp
[modify] https://crrev.com/54d44e5e0cd13e491d945d4034304c0d24a1bd6e/third_party/WebKit/Source/modules/media_controls/elements/MediaControlDownloadButtonElement.cpp

Verified in Chromium 64.0.3263.0.
Thank you!