[Bug 11984] <video>: Figure out the story with respect to honouring Content-Type headers vs sniffing content

https://www.w3.org/Bugs/Public/show_bug.cgi?id=11984

--- Comment #59 from Philip Jägenstedt <philipj@opera.com> ---
(In reply to Ian 'Hixie' Hickson from comment #54)
> Adrian: We shouldn't have any bugs. I think we're agreed on this. Just like
> decoding should be reliable everywhere, recognising the stream should be
> reliable everywhere.
> 
> I'm not sure why you consider it a layering violation. It's exactly
> correctly layered: the network layer would be marking the stream as being
> the type that the specs say it should be treated as. This seems quite
> appropriate.
> 
> However, if what you're saying is that you won't change, then let's turn to
> foolip. Is there any change Blink could get fixed to follow the Content-Type
> header and not sniff?

This is actually handled in the Chromium code and not in Blink, and
unfortunately some platforms (Android) use a separate network stack for media,
which makes the situation similar to what IE has with Media Foundation.
However, I believe the long term goal is to at least use the same network stack
on all platforms. Since sniffing is just rewriting the Content-Type, regardless
of the outcome of this spec issue what one needs for interop is the ability to
say to the media engine "here is the data, try to decode it as this type."

As for changing to honor Content-Type, I don't think it would be very
responsible of me to champion this. In Presto I ended up removing the
Content-Type check because we had customers who (rightfully) thought it was
annoying that their content wouldn't play, and I don't see why they would be
any less annoyed today.

However, I'm still new in Blink/Chromium, I'll post on blink-dev to see if
anyone has thoughts on this.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 21 January 2014 03:45:20 UTC