The W3C is at it again!




  • Discourse touched me in a no-no place

    This is just begging for a PLAYTYPE_NOT_FOUND joke.



  • Idiots. They should have returned the likelihood as a percent.


  • Discourse touched me in a no-no place

    @cartman82 said:

    They should have returned the likelihood as a range of likely percentages.

    FTFY.
    <post can fucking well be empty



  • The worst thing is, I can kind of see the logic. Since the definitive negative is the only one falsy, you can do something like

    if (canPlayType("video/webm")) {
        playType(...);
    }
    

    And if you need more information, you can inspect the helpful string....
    ...
    ...
    I can't. I just can't.



  • The canPlayType() method can return one of the following values:

    • "probably" - the browser most likely supports this autio type
    • "maybe" - the browser might support this audio type
    • "occasionally" - the browser occasionally supports this audio type
    • "notToday" - the browser does not support this audio type today
    • "ifIFeelLikeIt" - the browser will support this audio type if it feels lke it
    • "wellIDon'tKnow" - the browser is unsure whether it supports this audio type
    • "honeyI'mOnMyPeriod" - the browser might support this audio type in a few days
    • "" - (empty string) the browser is tired of your shit and will not support this audio type


  • For those of you who are wondering, this is part of the HTML5 spec.



  • Better yet, a double between 0 and 1


  • Fake News

    You forgot one:

    - "letsJustBeFriends" - the browser is unlikely to support this audiotype until you clean up your act, or possibly never.


  • :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf: :wtf:



  • This... just can't be real.
    I mean, it's right there. It looks official.
    But it just can't be real.
    Right?
    Please?



  • Nothing the W3C does can surprise me anymore.



  • And "AskFortuneTeller" - you need to ask a fortune teller whether the browser can play your media.

    Use this response when the browser decided not to support this query.



  • @cartman82 said:

    The worst thing is, I can kind of see the logic.

    Video codecs is such a can of Worms. Not being able to tell for sure if playback works, before trying fits all too well into my understanding of they "work" .



  • You also forgot:

    "canIWatchToo" - for high skin tone content


  • Winner of the 2016 Presidential Election

    The funniest part is that HTTP solved the same problem years ago and that solution is 150 times better. But, of course, since every web page has to be a single-page Javascript application these days, they had to invent an inferior, client-side API that is one huge WTF.



  • No. HTTP is for transfer of data so it can be handled that way. To play a media file, like what swayde said you need to ensure the corresponding audio and video codec exist, which cannot be done unless you've opened and read the file header.

    So at best the browser can just say "probably", and for "webm" to say "maybe" because there could be future revision of the codec.



  • @cheong said:

    HTTP is for transfer of data so it can be handled that way. To play a media file, like what swayde said you need to ensure the corresponding audio and video codec exist, which cannot be done unless you've opened and read the file header.

    Can. You said it.

    GET /some-video
    Accept: video/webm, video/h264, video/avi, video/dixv3.1
    

    Something like this.

    Then the server inspect the header and sends some-video.webm or some-video.mp4 or whatever. Apache already supports this, as long as your mime types match.



  • I think you cited the wrong (or rather, missing) RFC. Take a look on RFC 2361 as that addresses the issue more directly.

    I found it because your reply includes video/avi but I know AVI itself does not specify what codec it needs. In this specification, it suggests the correct entry be sent as:

    video/vnd.avi; codec=XXX

    Although I still think it lacks the specification on the audio codec. There is no good to claim you can play the movie unless you can also play the sound (except when there is no sound, of course).



  • Maybe this is meant to transcend the silly binary logic computers and begin implementing support for some future, general-purpose quantum computers?

    Although, there might be better places to start the quantum revolution than JavaScript.


  • Notification Spam Recipient

    There finally is a use-case for a boolean enum



  • So the problem is they named the file types after their container format, completely ignoring the codecs, thus making them useless?

    And they seriously cannot think of a way to solve this super complicated problem? Come on.


  • BINNED

    @JBert said:

    "letsJustBeFriends" - the browser is unlikely to support this audiotype until you clean up your act, or possibly most likely never.

    FTFY



  • I'm sure the server end can use its magic to determine the codec in the container.
    If the client can't pass in the supported audio codecs then that would be a new RFC needed.
    This W3C change is just going to make client have a lot of ugly if/else if statements along with pages serving up dozens of video formats rather than have the client request the best matching.



  • @Nprz said:

    I'm sure the server end can use its magic to determine the codec in the container.

    I presume it opens the way to have serverless HTML solutions, like Chrome Apps or something.



  • @superjer said:

    This... just can't be real.

    It isn't. It is string.

    @Zemm said:

    GET /some-video
    Accept: video/webm, video/h264, video/avi, video/dixv3.1

    Not good. Too logical.

    @ashkante said:

    Although, there might be better places to start the quantum revolution than JavaScript.

    Is this the first attempt at creating QuantumScript?

    (If only the answer wasn't in Pandora Schrödinger's Box)

    @Nprz said:

    I'm sure the server end can use its magic to determine the codec in the container.

    Is there any standard to request only the stuff before the actual payload of the media file?



  • @PWolff said:

    Is there any standard to request only the stuff before the actual payload of the media file?

    HTTP 1.1 has a "Range Request" feature that could be used to request a portion of the file for inspection.


  • Discourse touched me in a no-no place

    But which range of the file to request? Different container formats put the critical metadata in different places. (Of course. Doing otherwise would make life Too Easy.)



  • Oh, I found another reponse:

    "triggered" - The browser must return "triggered" if requesting whether it can play a media type means that your cis-shitlord ass caused it to be triggered. Once you recieve "triggered" you must check your privilege with the server again. Trying to force playback of any type after the Browser returns "triggered" must crash the browser



  • If your browser doesn't know where the metadata is for a given container format, then your browser doesn't support that container, so it won't have to request anything. If your browser can't figure out the container format, then it wasn't going to be able to play the media anyways.


  • 🚽 Regular

    I'm not an expert on container formats, but I figure containers may contain a variable number of streams each with variable lengths. Are you sure all stream metadata is always at a fixed offset inside a given container format?



  • @Zecc said:

    Are you sure all stream metadata is always at a fixed offset inside a given container format?

    Nope. But the container will have a way to locate the beginning of each stream. If the container is supported, then the streams can be located. I'm pretty sure when a media player opens a local file it doesn't have to read the entire file to determine which codec to load.



  • Look, if a file format specifies the container but not the codecs, then it's not a format. It's shit. So don't request that, don't use that as file extension, don't use that as MIME type, and don't ask the browser if it supports it. It's stupid. You might as well ask if the browser supports "binary".

    A "format" should define everything necessary to actually use the file.


  • Discourse touched me in a no-no place

    @Jaime said:

    But the container will have a way to locate the beginning of each stream.

    Sure, but that doesn't mean that you can get the metadata about that stream (like WTF is the codec used in it) without reading (typically) the beginning of that stream. Or perhaps reading an entirely separate embedded stream in the file (the metadata stream). Plus some smartass might've decided that the metadata needs to be semantically annotated. Because raisins.


  • Discourse touched me in a no-no place

    MAY, MUST et alia MUST be rendered in all caps...



  • These words are often capitalized.

    RFC 2119!?

    I'm triggered you lowercase-ist


  • Discourse touched me in a no-no place

    @PJH said:

    ```html
    MUST

    
    Like the fancy quotes! :tropical_drink:

  • Discourse touched me in a no-no place

    Ah, that's what went wrong...



  • @Jaime said:

    I'm pretty sure when a media player opens a local file it doesn't have to read the entire file to determine which codec to load.

    Iirc this actually is the case in legacy AVI containers when several not-quite compatible streams have been shoe-horned into the container.

    Interestingly, it's probably those kind of degenerate use-cases with not-quite-compliant streams that are the reason for the 'quirky' playback enumeration values "probably" and "maybe", because they don't allow for a-priori 100% confidence that a file can be played back correctly.

    From http://www.w3.org/TR/html5/embedded-content-0.html#dom-navigator-canplaytype

    The `canPlayType(type)` method must return the empty string if type is a type that the user agent knows it cannot render or is the type `"application/octet-stream"`; it must return `"probably"` if the user agent is confident that the type represents a media resource that it can render if used in with this audio or video element; and it must return `"maybe"` otherwise. Implementors are encouraged to return `"maybe"` unless the type can be confidently established as being supported or not. Generally, a user agent should never return `"probably"` for a type that allows the codecs parameter if that parameter is not present.

    The whole reason we're in this bloody mess is because a number of prominent stakeholders (notably; the browser vendors) were unable to settle on a core set of containers and codecs (and encoding profiles) that must always be supported. Namely; Apple demanded H264; Mozilla demanded an open-source container without submarine patents attached; and Google wanted to push its WebM format as an alternative.

    Though there's plenty of other stuff you're free to shit on the W3C as an organization for, this isn't one of them. If anything; blame the stubborn-headed browser vendors and the people responsible for the lack of sane standards for reading back video and audio codec support in general. (The most bulletproof method on Windows is iirc still to just try to play back a file into a null audio/video output and monitor the pins to see if any failed to render. Obviously that doesn't work well with stream format selection...)



  • The W3C was going to include OGG in the standard but Apple and Nokia killed it.



  • Actually, I see KLite codec pack come with tool for check whether the video and audio codec is installed for particular media file, so I'll assume at least on Windows, it can somehow be done (because those codecs have to be usable by Windows Media Player, it have to somehow offer standard way to expose it's presence).

    Not sure if there's agreed way exist on *nix (Apple and Linux) side.



  • @anonymous234 said:

    The W3C was going to include OGG in the standard but Apple and Nokia killed it.

    Why the fuck.
    Vorbis and Theora are basically about as patent free as you can get in a codec these days. And Vorbis kicks MP3's ass in terms of quality versus space.



  • What Nokia wants

    The position paper that Nokia submitted to the W3C touches on a variety of topics and mentions Ogg only briefly. The paper's arguments can be summarized as follows:

    1. W3C shouldn't make any standards relating to codecs. Leave that to other standards bodies like ITU-T and ISO/IEC.

    But if it's going to be part of HTML5, doesn't that kind of put it in their purview? Or are we saying that multimedia should not be part of HTML5 and we're doomed to another few years of using Flash?

    2. There are over a billion PCs in the world today, many connected to the web, but these numbers are tiny compared to traditional video playback devices like DVD players.

    Great forward-thinking there! How many of these "traditional" devices are going to be consuming HTML5, anyhow?

    3. This industry is used to paying license fees and royalties for video codecs like MPEG-2.

    This industry is used to being bent over and pegged with a strapped-on cactus. Clearly, since this situation is the status quo, this situation is the best possible situation and there is no room for improvement whatsoever.

    4. This industry is used to making money, and it doesn't care about keeping things free.

    See #3. I also don't see why such mercenary aims would preclude using a codec where the technology in question does not require licensing fees.

    5. Web codec standards should be either free or low-cost to implement.

    It's harder to get lower cost than free.

    6. Web codec standards should support DRM to placate Hollywood, but DRM implementations should be optional.

    Aside from the fact that everything can be copied, they are free to use any of the other supported codecs.

    7. H.264 for video and AAC for audio would be Nokia's recommendations for codecs.

    So we can only have one of each?

    Based on some of these arguments, I'm surprised that we aren't using GIF for everything today.


  • Discourse touched me in a no-no place

    @Groaner said:

    See #3 the third #1.

    FTFDiscourse.



  • @dkf said:

    FTFDiscourse.

    I was going to comment on that, but I figured by now that we were all aware and tired of Disconumbering.



  • Time for retro HTML 3 - when things were so simple, methinks. :trollface:



  • HTML5 should not have been called HTML5, it's should be something like BBPM :trollface:



  • @Masaaki_Hosoi said:

    Why the fuck.

    Two reasons:
    Firstly, because H.264 and AAC have hardware decoding chips in lots of existing Apple and Nokia hardware and those are both more cost-efficient to produce (or buy from a third-party) and more energy-efficient for the end-user's phone than having to build and use a new implementation in software that has no dedicated hardware backing it.

    Secondly, if I recall correctly, both Apple and Nokia have or had an arrangement that weasels them out of having to pay the full license fees to the MPEG group, which gives them a monetary advantage over competitors in the mobile smartphone/tablet market.



  • @Groaner said:

    Based on some of these arguments, I'm surprised that we aren't using GIF for everything today.

    You mean the same GIF that used LZW internally and that Unisys was suing over up until the patent for LZW expired?

    (Yes, I'm ignoring the whole 256 color thing as it wasn't on your list.)



  • I don't get why the MNG format never took off.


Log in to reply