This happened for serving dynamically transcoded content on fly (from propriety format to Ogg), which I send with "Transfer-Encoding: chunked", since the final length of the content can't be known. But when I served same content cached file and send Content-Length in HTTP header, then progress does indeed work as expected.

However Firefox continues to work properly with both "Transfer-Encoding: chunked" & Content-Length.

In dynamic content if we send accept ranges none, chrome ignores it and send the range header in next request.

Instead of this chrome should keep downloading the complete content and doesn't generate new request with accept range header.

this seems by design. Matt, do you have any thoughts?

Firefox behavior is different, when I pass content length, until the download completed no frame is rendered, but if I passed chunked then bytes are rendered as soon as its downloaded. 

While chrome rendered all the bytes that it downloaded with content length, but on chunked encoding it renders when as playback moves. This makes impossible to determine download progress for dynamically generated content.

My suggestion would be to follow Firefox behavior or at least render all bytes that has been downloaded rather than on playback. (no offense.. I love Chrome and want it to be used as default browser across my org)

To support dynamically generated content you also need to handle accept-range: none. Once the dynamic content is cached than next requests to same content can be served with accept-range: bytes which i am doing.

Our scenario is different then youtube where one video could have many views, therefore it make sense to transcode videos before hand. We on the other hand has many audio/video content and few viewers.. far less then the content been generated on daily basis. 

ping wolenetz@ again.matt, what's your thought?

Sorry - I missed this previously. This is not MSE, rather just regular src=.
This seems more related to ffmpeg and hubbe@'s multi-buffer datasource work.
Over to hubbe@ to triage further.

I'm not actually sure there is a bug here or, if this is more or less intended behavior.

Chrome today supports two modes of playback:

1) ranges are supported, seeking works and content is downloaded on demand.

2) ranges are not supported, seeking is disabled, and content is downloaded on demand.

There is no "download whole file and then play it" mode in chrome today. It's been discussed, but because it could take an arbitrary amount of memory or disk space, and it wouldn't be a very good user experience, nobody has implemented it. However, it is still possible for sites to implement this themselves using MSE, service workers and/or data: URLs.

In case (2) above, if we don't know the content length, progress is indeed not possible to calculate properly.

Also, in case (2) above, we will not make range requests to the site. UNLESS the site tries to serve a file format that requires seeking, like an MP4 file where all the audio has been placed in a chunk at the end of the file. If that happens, we will try a range request, even if the server said it doesn't support it.

hubbe@ I think you missed the point.

a. MSE doesn't support OGG in Chrome yet, neither I think if fits well for dynamic content. MP4 is not an option due to license cost cross pond to our volume.

b. Content is already downloaded 740KB but buffered range didn't updated to total time of playback which is 350 secs rather stick to closely currentTime.. see attachments. If the content-length is specified in response header than buffered range does report time correctly and updated to 350 secs on download complete.

c. Its possible to report progress using total playback time 350 seconds and buffered range time, when "transfer-encoding: chunked" and content length is not present. We are doing it in Firefox successfully.  

@#9 as an aside, would you be able to use Opus or Vorbis instead of raw ogg? If so, Chrome MSE does support Opus and Vorbis in a webm container. IIUC, transmuxing ogg to vorbis-in-webm might be something doable even in JS.

Yes, I think I am missing the point...

But first, for (a), service workers or data: urls can still work.

Let me paraphrase to see if I understand correctly:

o The total length of the generated contend is 740KB.
o While the data is downloading, the content length is not known and progress is not expected to be updated correctly.
o Once chrome reaches the end of the data, it can know the length and should be able to report progress properly, but does not.

wolenetz@ I am using OGG + Vorbis + Theora. I have tried implementing WebM interoperability in C# (our tech platform), but it turns out its not easy as was OGG, plus documentation is not helping me at all. 

hubbe@ 

a. Correct

b. Progress can be shown with help of buffered.end(0) divide by total duration of content which we already known before conversion.

c. We have up to 2hours long recordings and it takes time to transcode, and dump to http output stream as the same time. Firefox received new bytes from server, it updates its buffered.end(0) and also updated readyState to 3 for next available frame (readyState to 1->2->3). Please see the attachment screenshot of 00:50:10 long recording, where progress bar in timeline is reporting the downloaded content based on buffered.end(0), this content is dynamically generated and sent as http chunked.    

Deleted: 50mins-recording.png 22.8 KB

	50mins-recording.png 22.8 KB View Download

Do you have an example URL where I try this myself?
(It would make it significantly easier to fix it.)

hubbe@ Ok, I can't share project environment but let me create test project & share URL by Tuesday.

hubbe@,
I have create a separate project to simulate the behaviour, currently I am dumping OGG video in 10K buffer with 100 milliseconds sleep interval just to simulate large file trans-coding.

You can see the behavior different in Firefox/Chrome when HTTP encoding is chunked, also note to use Firebug in Firefox for network stats.

Project is also pushed on Github so you can look up whats going on the server side.

Url: <shared on email>

Project: https://github.com/mysteryjeans/ChromeAV

Thank you for the test page.
However, I have not been able to actually reproduce the problem.
As far as I can tell, chrome is reporting the amount of actually buffered data correctly.  I compared to firefox, and the difference between current time and the end of the buffer was larger, but that's because firefox chooses to preload more data I think. On a low-bitrate file, chrome chooses to preload a fairly small amount (2mb I think) and thus the end of the buffer will be ~2mb ahead of the current time instead of racing ahead towards the end.

Does this explain what you're seeing, or am I misunderstanding something again?

If you pause playback, chrome progress stops but Firefox continues to render all the frame that has been downloaded. 

Note that in network stats download will get completed but chrome still shows buffered to almost same as currentTime

Pausing does reveal some odd behavior: Not only does it stop reporting buffering progress even though it is still downloading, but it sometimes starts over from the beginning when I hit play, and sometimes not. I'll keep digging into it and see what I find.

It would seem that we get buffered ranges from two sources: The demuxer and the data buffering code.  The data buffering code knows better what is actually buffered, but that code doesn't currently do anything if we don't know how long the file is. The demuxer on the other than knows exactly how far we've played so far, but doesn't know how much extra data we have.

Now I just have to work out a way to fix it...

Great, thanks.

Second part of the problem is "accept-ranges: none" is not handle by Chrome, and sends ranged requests on pause/play or seek as you also have observed. 

On server side, I transcode in loop -> pull chunk of  data from audio/video file, transcode it and dumps to http output stream, if browser doesn't READ the dump from socket, then request is blocked, which is good and conserved resources. Chrome should resumes downloading from same connection to that cycle continues. However to avoid latency on network file storage I queued the NEXT chunk request (<3 C#) before transcoding the current read chunked & dumps into http output stream.

Please note that I am ignoring "Range: bytes=0-" as partial content request and considering it a full request.

Re #21; this is a separate problem and should have a separate bug report.
There are some things I don't understand about your description, but I'd much prefer to discuss that in a separate bug instead of here.

I tried implementing something that calculates buffered.end(0) by basically doing 

   buffer_end_bytes * current_playback_time / current_read_position

But the values fluctuates a lot, and it ends up returning values larger than the total content length quite often.

Not sure how to make this actually work.

A bug is already exists for "Accept-Ranges: none"

https://bugs.chromium.org/p/chromium/issues/detail?id=505707

hubbe@ can we expect it to be fixed in future?

I'd like to make this work better, but it's not high on my list of things to do and since the simple fix didn't work, it's not entirely clear to me how to fix it at this point.

What I'm trying to say is that I will try to get back to this, but I don't have any sort of ETA at this point, so it could take a while. Sorry.

I don't think we expect this to be fixed anytime soon.
While a fix would be nice, the obvious ideas didn't pan out.
Closing as wontfix.