Hmm, typically this happens when a file is served from a range request, but a data:// url should be considered fully buffered and thus shouldn't have this issue. Will take a look this week.

Hmm, seems to be working on 71+ (including 73) w/ macOS, can you provide some more details on your setup? 

Can you check chrome://media-internals and include the player log for this file when you hit the issue.

Right now I'm consistently reproducing on Windows 10 Google Chrome Version 73.0.3635.0. What else regarding my setup would you like to know?

I've attaching the log I've saved a few seconds after reproducing the issue. Hope it's helpful.

Deleted: media-internals.txt 9.1 KB

media-internals.txt 9.1 KB View Download

Does this happen on stable or only on 73? Thanks, log looks normal, no weird non-seekable issues reported there.

Just reproduced this on Google Chrome (Windows 10) Version 70.0.3538.110
Attached here are the Media Internals logs for that.
BTW I've seen this on Chrome/Android as well. If you want I can get you more details on that.

Deleted: media-internals.txt 8.9 KB

media-internals.txt 8.9 KB View Download

Thanks, will try to get it to happen. Are you able to record a quick screen capture of you reproducing the issue? I want to make sure I understand exactly what you're seeing.

Yea sure. See attached.
I couldn't get the audio to be in-sync on the recording so I dropped it but essentially after I make the seeking jump I hear the audio from the beginning of the track.

The reason why in this issue I've added more steps to reproducing this than what you see in the video is because I recalled that sometimes I wasn't able to reproduce this with a single step) but right now I'm reproducing this consistently with just the action you see in the video.

Thank you

Deleted: 2018-12-11_01-49-18.mp4 163 KB

	2018-12-11_01-49-18.mp4 163 KB View Download

Ahhh, I see the issue, you're seeking before playback begins. I wonder if seeks are broken while in the suspended state currently...

+sandersd, tmathmeyer, possibly resume while a seek is pending isn't resuming at the seek target... What do you expect to happen in the pipeline when this occurs Dan?

I'm not sure what you mean by that but in the video above you can clearly see that by the time I press the cursor down at the end of the seek bar the player has already begun playing as
1. it's already at 0:02.
2. The audio playing icon on the chrome tab is visible.

Hmm, yeah I can now reproduce without it paused and on 71. Not sure what's happening here, will debug tomorrow. So probably not suspend/resume related. Instead seems like the seek isn't taking affect for some reason.

Can't get it to reproduce w/ file:/// URL, so perhaps something specific to data://

+Blink>Loader in case this sounds familiar.

Hmm, solved it here https://chromium-review.googlesource.com/c/chromium/src/+/1373020 but two things are unclear:
1. Why data:// URLs aren't working with range requests? Blink>Loading folks, can you chime in? Has this never worked?

2. Why MultiBuffer isn't working with these resources, they are returning 200 OK and treated as fully buffered, but part of how we handle these is to force range request support, so ultimately this may go back to 1?

+horo in case he knows why or who to route the question in #1 to.

Sorry I don't know.
+yhirano@: Do you know?

+mmenke@ for net::DataURL (see #12).

Range requests are handled for data URLs that make it to the network stack layer by URLRequestDataJob, a consumer of net::DataURL.  Many data URLs are handled in blink, and there's a new network service path (Which does not send data URLs to the network stack), neither of which I'm familiar with, so can't comment on them.

Do you know who we can cc? Or have advice on narrowing the issue one way or another?

I'm seeing 200 responses to a data URL request. Each time the full resource is being returned. So I'm guessing one of these new paths is broken in regards to range requests for data.

[+jam]:  John, I don't suppose you either know where the network service data URL code is, or who ported that code to worth with the network service?  Unclear if this is a network service issue or not, but a pointer would give us a place to start.

I assume someone on the loading team would know how blink internally handles data URLs - I'd have no idea where to start there, other than digging my way back up the stack using breakpoints.  I suspect digging down the stack from where the media code makes requests to see where they end up would be easier.

@Matt: ProfileNetworkContextService::CreateNetworkContextParams always sets
network_context_params->enable_data_url_support = true;
so data URLs end up going to the network process and reusing the net/ code.

Does enabling/disabling network-service in about:flags change the repro? I'm a slightly confused by the repro steps above, but it seems that I can repro this on trunk without network service.

btw I should also add:

for navigations, we'll always go to the network process. see comment around IsURLHandledByDefaultLoader in navigation_url_loader_impl.cc.

For subresources, the common case which this should hit stays in process, see WebURLLoaderImpl::Context::Start's CanHandleDataURLRequestLocally.

Thanks for the details folks. I'll keep digging based on this and see what I can figure out.

@horo/yhirano: Are data:// URLs subject to CORS restrictions in the context of media? I don't think so, but want to double check before I land a bypass of the loading stack for them. See CL in c#12.

data:// URLs are always considered as CORS-same-origin, as specified.

Thanks! Will land the workaround and finish debugging why things stopped working.

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

commit 4841c71bfd6966584d0e7f8e96fb769c36f34e50
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Thu Dec 13 18:14:05 2018

Don't use MultiBufferDataSource for data:// URLs.

Using the network based path just increases memory usage and causes
worse performance since all reads are asynchronous. It also seems like
data:// URLs don't support range requests, so each read pulls in the
entire data stream again and again.

I'm not sure if data:// URLs not supporting range requests is a new
thing, or if they should be supporting this. Will ask loading team.

It's also unclear why MultiBuffer is breaking in this case, it's not
efficient, but it shouldn't be broken, so there's still some minor
investigation left to do there.

BUG= 913681 
TEST=linked bug plays correctly.

Change-Id: I3183ca0c5d8f3ecf09304cdcd1c77e55825a98d6
Reviewed-on: https://chromium-review.googlesource.com/c/1373020
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616364}
[modify] https://crrev.com/4841c71bfd6966584d0e7f8e96fb769c36f34e50/media/base/data_source.cc
[modify] https://crrev.com/4841c71bfd6966584d0e7f8e96fb769c36f34e50/media/base/data_source.h
[modify] https://crrev.com/4841c71bfd6966584d0e7f8e96fb769c36f34e50/media/blink/multibuffer_data_source.cc
[modify] https://crrev.com/4841c71bfd6966584d0e7f8e96fb769c36f34e50/media/blink/multibuffer_data_source.h
[modify] https://crrev.com/4841c71bfd6966584d0e7f8e96fb769c36f34e50/media/blink/multibuffer_data_source_unittest.cc
[modify] https://crrev.com/4841c71bfd6966584d0e7f8e96fb769c36f34e50/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/4841c71bfd6966584d0e7f8e96fb769c36f34e50/media/blink/webmediaplayer_impl.h
[modify] https://crrev.com/4841c71bfd6966584d0e7f8e96fb769c36f34e50/media/blink/webmediaplayer_impl_unittest.cc
[modify] https://crrev.com/4841c71bfd6966584d0e7f8e96fb769c36f34e50/media/filters/memory_data_source.cc
[modify] https://crrev.com/4841c71bfd6966584d0e7f8e96fb769c36f34e50/media/filters/memory_data_source.h

This has been broken since M52 when we enabled multibuffer, so there is no new regression here and this is now fixed by avoiding Multibuffer.

mmenke: The reason things don't work is the URLRequestDataJob does not support range requests. Should it?

https://cs.chromium.org/chromium/src/net/url_request/url_request_data_job.cc?l=21

dalecurtis:  It does in fact support range requests.  It subclasses URLRequestSimpleJob, which handles them using its GetData method.

The linked code shows that method is overridden?

Yes, because URLRequsetSimpleJob gets the data it provides via GetData, as opposed to the generic URLRequestJob::ReadRawData method (Or something like that).

Ah, sorry I misunderstood your wording. I read "its GetData" to be URLRequestSimpleJob's, will dig into this further to see what's going on.

Hmm, GetData is never called, only BuildResponse.

It's actually the code that calls GetData that does all the heavy lifting (Which isn't exactly all that heavy) - URLRequestSimpleJob::ReadRawData.

Ah, which is due to Blink eating the load before it goes to net:

https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/loader/fetch/resource_fetcher.cc?l=851
https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/loader/fetch/resource_fetcher.cc?l=544
https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/network/network_utils.cc?l=68

So my earlier question should have been directed to yhirano, horo: Should blink support range requests for data:// URLs?