4 ms·

> What about addressing the problem from the HTTP-side of things: have a simple video tag (just defining the viewport and an endpoint) and a host response provi

by d2wa 5y ago

> What about addressing the problem from the HTTP-side of things: have a simple video tag (just defining the viewport and an endpoint) and a host response providing options, which may be selected by the browser situationally? HTTP Client Hints spec can send the viewport size and pixel ratio and even a low-bandwidth preference as HTTP request headers. It’s only supported in Chrome and requires extra round trips. The other browser vendors have been unwilling to implement the spec.

masswerk 5y ago
IMHO, this (client hints) is still not the right way to do it. Any hints (as for preferred quality levels etc) should be part of the tag. Any available options with specific qualifiers should be transparently and extensively provided by the host response (preferably in a human maintainable manifest format). The browser should then select the optimum for the situation, based on any preferences expressed in the tag and available options as provided in the host response. A browser should be also able to adjust situationally (e.g., as network bandwidth, scaling, or orientation changes) and select the new optimum without further negotiations (using standard time offsets).
- d2wa 5y ago
  That’s what the article argues for.
  - masswerk 5y ago
    No, the article argues for a very complex tag, which still doesn't provide enough information (like data rate specifications) for a browser to make an educated guess for the available optimum. Note that these are totally diferrent concerns: defining the viewport (which belongs to the tag) and its endpoint, on the one hand, and technical specificity of available media on the other hand. (Putting all information in the tag is a bit, as if we were to define in an image tag, whether the image was encoded progressive or not, what size the color pallet is, etc. However, we can't put this in a video header, as this comes too late, as we decided for a specific source already. But there's the 300 "Multiple Choices" response, maybe, we may build on this.) Edit: What really matters to an editor of an embedding document is selecting an endpoint (like "example.com/videos/cute-cat1") and defining its visual properties, probably responsively and by means of CSS. An editor is not concerned with quality levels and bit rates vs bandwidth, actual display size, etc. The editor even isn't in any position to make a suitable decision for every situation beforehand. Available options should be advertised by the endpoint and the browser should select adaptively the optimum to fill the viewport on its own behalf (and not by delegating this to the providing host by means of a handshake, which makes things not only unnecessarily complex, but also leaks information).
- vagrantJin 5y ago
  > The browser should then select the optimum for the situation I like the idea of a human readable manifest to select for preffered quality based on the browser environment. That would be much preffered over loading the tag. Maybe just a quality attribute and point it to the manifest. A man can dream.

by d2wa 5y ago

masswerk 5y ago

IMHO, this (client hints) is still not the right way to do it. Any hints (as for preferred quality levels etc) should be part of the tag. Any available options with specific qualifiers should be transparently and extensively provided by the host response (preferably in a human maintainable manifest format). The browser should then select the optimum for the situation, based on any preferences expressed in the tag and available options as provided in the host response. A browser should be also able to adjust situationally (e.g., as network bandwidth, scaling, or orientation changes) and select the new optimum without further negotiations (using standard time offsets).

d2wa 5y ago
That’s what the article argues for.
- masswerk 5y ago
  No, the article argues for a very complex tag, which still doesn't provide enough information (like data rate specifications) for a browser to make an educated guess for the available optimum. Note that these are totally diferrent concerns: defining the viewport (which belongs to the tag) and its endpoint, on the one hand, and technical specificity of available media on the other hand. (Putting all information in the tag is a bit, as if we were to define in an image tag, whether the image was encoded progressive or not, what size the color pallet is, etc. However, we can't put this in a video header, as this comes too late, as we decided for a specific source already. But there's the 300 "Multiple Choices" response, maybe, we may build on this.) Edit: What really matters to an editor of an embedding document is selecting an endpoint (like "example.com/videos/cute-cat1") and defining its visual properties, probably responsively and by means of CSS. An editor is not concerned with quality levels and bit rates vs bandwidth, actual display size, etc. The editor even isn't in any position to make a suitable decision for every situation beforehand. Available options should be advertised by the endpoint and the browser should select adaptively the optimum to fill the viewport on its own behalf (and not by delegating this to the providing host by means of a handshake, which makes things not only unnecessarily complex, but also leaks information).
vagrantJin 5y ago
> The browser should then select the optimum for the situation I like the idea of a human readable manifest to select for preffered quality based on the browser environment. That would be much preffered over loading the tag. Maybe just a quality attribute and point it to the manifest. A man can dream.