For  issue 2 , I don't think we use the metadata thumbnail before play() happens.

cc dalecurtis@ to see look at the preloading issue.

> For  issue 2 , I don't think we use the metadata thumbnail before play() happens.

That doesn't seem to make sense. What is the thumbnail for then??
(note that the thumbnail in my test video turned out to be broken, so it's not a valid test case)

A more easy way to show an image before the playback starts is to use the poster attribute of <video>. Besides, I've seen other video websites using various hacks to show the image.

> A more easy way to show an image before the playback starts is to use 
> the poster attribute of <video>

That this is "more easy" is pretty questionable to start with. Suppose I have 100 videos and they already have a carefully choosen preview image in the metadata. Should I be forced to retrieve that image for every single video and save it as a separate image to use as the poster attribute? No way.

Anyway, if the poster attribute is not present, and the metadata contain an image preview, the browser must obviously show it (if the "preload" attribute is either "metadata" or "auto").

That people use workarounds doesn't mean that there isn't an issue. People usually don't sit there and wait for browsers to fix their behavior while in the meantime their wep page looks shitty.

teo8976@, in order to assess priority here, have you seen the behaviour you are looking for implemented by another browser? Reaching parity would obviously be higher priority than implementing a new feature that other browsers don't implement (thus would still require the workarounds).

As already stated in the report:
Firefox behaves as expected with regards to issue 1 (which, by the way, is an obvious bug, not a feature missing, so parity with other browsers shouldn't be of any relevance to set priority).

Regarding  issue 2 , I do observe it in Firefox with the example video I provided, but as I said, its thumbnail is actually broken so it's not a valid test case at all.

I don't have a video with a valid thumbnail to test, so I can't tell whether other browsers have the same bug. You should be able to test it by yourself.
This, too, is not a feature but an obvious requirement (show the thumbnail in the metadata if the video has one and if you are loading metadata), so again, whether or not other browsers have the same bug should be irrelevant. We are not talking about a feature.

Maybe a separate issue should be opened for the thumbnail issue (I am assuming that it is true that Chrome doesn't use it because you said it in comment 2). I thought the two issues were related because Chrome seems to unnecessarily load a huge portion of the file before it does anything at all with metadata, so I assumed the whole thing to be related to metadata, but apparently it is not. See  issue 625311 , probably related.

For the first problem you see, on Chrome 52 (current beta), I can't reproduce: if I load your test page, at best I can see one frame with the video rendered with a small size. The behaviour I see seems to match your expected behaviour. Also, on my setup, only 500Kb of the video are downloaded. Also, I don't need to press play for the proper size info to kick in.

Did you try Chrome 52? Also, is that on an official build or are you using a custom build?

Also, I think it would be better to open a second bug for the second issue because it's more a feature request than a proper bug and will unlikely be fixed at the same time as the bug you encountered.

Ok, let's focus on issue 1.

I have just tried the beta and I definitely do reproduce the issue in 52 beta, exactly like in 51, as described in the original report. Nothing has changed.

What OS are you testing on? I am on Ubuntu 15.10.

> Also, I don't need to press play for the proper size info to kick in

Me neither, never said you needed to.

Assigning to Dale for further triaging of the issue with downloading 4Mb to parse metadata.
I filed  Issue 629541  for the preview suggestion.

If your container is poorly muxed this is the result. Use Mp4box to fragment the mp4 such that it is properly muxed for web streaming:

https://bitmovin.com/mp4box-dash-content-generation-x264/

This will ensure that all pieces of metadata are at the front of the file and thus will not require large preload.

> If your container is poorly muxed this is the result.

Not necessarily. Which means, not true. 

You keep ignoring this fact: Firefox doesn't have this issue, hence it is avoidable.

Sure, that's fine, but there's a never ending list of atoms that can cause ffmpeg to need to load metadata later in the file. It's not productive to continuously add edge cases for media that is not properly muxed for the streaming distribution.

Specifically the MSE spec goes to great lengths to omit all the MP4 features that could cause such seeking to be required. Fragmented mp4 satisfies those requirements.

https://www.w3.org/2013/12/byte-stream-format-registry/isobmff-byte-stream-format.html

You can find an exact breakdown of the layout there.