5 ms·

This is on a fully-patched RHEL6 workstation: http://i.imgur.com/NleqJTD.png http://i.imgur.com/NleqJTD.png Another example of "use bleeding-edge tech or go f

by stonogo 12y ago

This is on a fully-patched RHEL6 workstation: http://i.imgur.com/NleqJTD.png http://i.imgur.com/NleqJTD.png Another example of "use bleeding-edge tech or go fuck yourself" from the modern web.

fixermark 12y ago
Support for mp4 isn't bleeding-edge tech on other operating systems / distributions, unfortunately. It's a couple of years old in terms of being supported by Chrome; it's supported in Firefox as of last August. At this point, desktop configurations that can't play mp4s are at risk of being considered "broken."
- callahad 12y ago
  Is it really that difficult to supply a free format like WebM in addition to patent-encumbered H.264? If you only supply H.264, you're cutting out Firefox on OS X, Chromium, and Opera.
  - garblegarble 12y ago
    It does mean you need to transcode and store twice as many files, which can be a serious pain if you've got a number of different bitrate H.264 assets. It can be a big pain if your software assumes there'll only be a single media file. Not insurmountable but painful for small operations (and for large operations, where there may be a back-catalogue to worry about) I'm with you in spirit, but in practice I think we can all understand why people often just go for H.264
    - kibibu 12y ago
      This is a new feature launched by one of the biggest web brands there is, so presumably theres no back catalogue.
  - xooyoozoo 12y ago
    Interestingly, the gif->mp4 in the source link uses Constrained Baseline H264, the only profile that's supported by Cisco's BSD-licensed OpenH264[1]. The MPEG-LA patent fees are already covered, so that small projects can freely use the decoder/encoder. [1] https://github.com/cisco/openh264 https://github.com/cisco/openh264
  - cookiecaper 12y ago
    Yes, until we get client-side transcoding, it is that difficult. Video files, even files compressed with modern codecs, are really big, and the concepts are generally really hard for most people to grok. The knowledge is so arcane that if you have a basic grasp of ffmpeg you are already a wizard. Most people's eyes will glaze over the second you start talking about how they should use a different container, or codec, or whatever. That's why GIFs (for sub-one-minute videos) and Flash (for long videos and/or videos with sound) became the universal language of video; there was no more "Here's this video, but you have to install WMP/RealPlayer/QuickTime/Bonzai Buddy to see it!" In fact, Flash probably became the standard because it did such a good job at integrating with the rest of the browser and didn't shove obtrusive branding in the user's face. The tl;dr is that the support needs to very near universal for this to work, and no one is interested in WebM. Google probably could've forced the issue with YouTube, and they initially claimed they were going to, but they chickened out for some reason. I've heard it's because VP8 didn't live up to expectations and that they'll renew the push when VP9 is done, but whatever the motive, the reality is that if you want HTML 5 video to work, you must use H.264, as even Mozilla has been forced to admit.
    - callahad 12y ago
      > Video files, even files compressed with modern codecs, are really big, and the concepts are generally really hard for most people to grok. As the article points out, the video files are generally much smaller than the source gifs. Similarly, while there are real impediments to transcoding for many developers, I'm confident that the Twitter engineers in this specific case are capable of building a VP8 pipeline. After all, they built one for H.264. At that point, achieving universal support is as simple as having two <source> tags inside your <video> tag. It's not difficult at all: http://www.html5rocks.com/en/tutorials/video/basics/#toc-spec-sources http://www.html5rocks.com/en/tutorials/video/basics/#toc-spe...
      - cookiecaper 12y ago
        Yes, in this specific case, application-specific compression codecs are better for the storage of video, but that doesn't mean that video is small and that you can afford to transcode 4-8 different copies for every single image that would be uploaded (avail resolutions * formats * single piece of content), as that requires both a lot of CPU and a lot of disk space. It also doesn't mean any person around you has the expertise to figure out how to do this in a semi-reasonable manner, because as stated, most people don't understand the concepts used in modern video storage. You also assume that either WebM or H.264 will be supported by the user's browser. I don't think this is entirely correct, and in any case, it may always change, at which point the demand on the individual site becomes that much worse. I think the real solution is to automate this and allow the client to request on-the-fly transcodes to the formats the browser can support, similar to the way some UPnP servers work.
- deleted 12y ago
  [deleted]
- stonogo 12y ago
  Chrome on Mavericks is "broken?" How shall I upgrade this?
  - deleted 12y ago
    [deleted]
  - the_hangman 12y ago
    Chrome supports mp4 on Mavericks (as well as on older versions of OS X).
- cliveowen 12y ago
  Actually I'm on Chrome/Mavericks and I get the same thing.
  - CountSessine 12y ago
    Chrome + Mavericks here - I see the video just fine. Did you mean Chromium?
- jasonlotito 12y ago
  This is what modern support gets you with this method: http://imgur.com/Qr3tohD http://imgur.com/Qr3tohD http://imgur.com/Qr3tohD,8okaMlP#1 http://imgur.com/Qr3tohD,8okaMlP#1 So... Flash. This has the added bonus of stealing focus if you click on it, making the "GIF" a UX nightmare.
_delirium 12y ago
It does weird things on some mobile devices that do support it, too, mostly interrupting the audio player (on some devices, movie playback grabs the audio).
mutagen 12y ago
I suspect some implementation issues rather than a GFY attitude, it doesn't work on FF or Chrome on OSX 10.9. Safari works though.
- chc 12y ago
  I'm looking at it right now in Chrome on Mavericks. Are you sure you checked with the right browser?
  - adregan 12y ago
    I'm using Chrome 35 on Mavericks and I also get the message. Clicking through to Twitter will display the video.
- xooyoozoo 12y ago
  I recall reading on gfycat's subreddit that desktop Chrome's H264 support is occasionally spotty, so they chose to force on VP8/WebM in Chrome. The upside is that users get a reliable experience. the downside is that laptop Chrome users get a reliably lower battery life, as VP8 isn't typically hardware accelerated.
- CountSessine 12y ago
  Chrome on OSX 10.9 works just fine. I'm looking at the example video now.
kintamanimatt 12y ago
You choose not to use the appropriate software to experience what is being offered. This is akin to riding a decrepit horse on a racetrack while whining about how everyone else that is riding a healthy horse is going faster and having a better experience than you. Just upgrade.
- stonogo 12y ago
  Your analogy is stupid and your comments are not helpful. I'm not modifying 3,600 workstations because some web programmer decided to mangle user-uploaded content without doing fundamental work to ensure graceful degradation.
  - deleted 12y ago
    [deleted]
  - lfuller 12y ago
    But that's your choice, as was Twitter's choice to make a modification compatible with the majority of its users.
  - viggity 12y ago
    you're seeing that because they wanted to show you what it looked like as an MP4. My understanding was that twitter would ship you the GIF if your browser didn't support MP4.
nilved 12y ago
This is very far from bleeding-edge; we're talking technology between five and 10 years old. Set up gstreamer already; it's time to move past gifs.
- stonogo 12y ago
  WebM works fine on this machine. mp4 does not. This is why there was a bit of scuffle, as you may recall, about video formats on the web.
  - chc 12y ago
    Are you saying that WebM, a file format introduced in 2010, is less bleeding-edge than H.264 MP4, a file format introduced in 2003? What definition of "bleeding-edge" are we using here?
    - smackfu 12y ago
      The introduction date of the format doesn't seem very relevant, since what we are talking about is native inline browser support.
      - chc 12y ago
        Same story. Most browsers supported H.264 first (because it was dominant before WebM was even born). Internet Explorer, Safari and MobileSafari still do not support WebM. I don't see any reasonable way to say that WebM is well-established and H.264 is not.
thathonkey 12y ago
What percentage of Twitter's users do you think use Linux for browsing? Much less RHEL. Anyway, this is purely a front-end enhancement mostly for the benefit of mobile users. Also lol @ mp4 being "bleeding edge" tech. It certainly is not. Even in the Linux community.
- stonogo 12y ago
  Changing the fundamental format of the content is a 'front-end enhancement' now? If it's for mobile users, why not present it just to mobile users? also lol @ your opinion about technology. even in the "linux community"
  - thathonkey 12y ago
    It is an enhancement for the benefit of front-end performance. I'd like to hear how you think that is not true? Anyway, that is why I asked the loaded question about how many users you think there are that browse Twitter.com on their RHEL box? Hint: HN is not a good sample to answer this. And how is a ~14-year old technology (that has been ubiquitous now for at least 6 years) considered bleeding edge?
Fuzzwah 12y ago
Strangely I get that same message on my win7 machine running current chrome as well as my lubuntu machine running chromium. On both when I click the "click to view on original site" link it works fine.
lfuller 12y ago
mp4 is "bleeding-edge"?
mikeash 12y ago
More like, "stop using technology from the late 80s or go fuck yourself". GIF is awful and nobody should reasonably expect sites to accommodate it anymore.
- enneff 12y ago
  Huh? HTML is older than GIF images. Should we stop accommodating that too?
  - mikeash 12y ago
    Huh yourself? HTML dates from 1993, GIF dates from 1987.
    - enneff 12y ago
      Okay, so take my question and s/HTML/hierarchical file systems/ or s/HTML/C/ or make any other substitution. Why ditch something just because it's old?
      - mikeash 12y ago
        Well, there's a reason for the second half of my comment. GIF isn't bad because it's old, it's bad and old, and it's unreasonable to expect it to continue to be supported because that's a nasty combination. If something sucks but is still the standard technique in recent years then it's reasonable to think it should be supported. Similarly, if something is old but great, it's reasonable to think it should be supported. But GIF is old and crappy and there's no reason to expect support for something old and crappy to continue indefinitely. I'd also note that your other examples have received substantial revisions over the years that have improved them enormously. I'd happily say the same thing about not supporting 1987-era C or filesystems.
        cratermoon 12y ago
        GIF itself is not so bad, for its intended purpose and time, but the animated GIF bit is a serious hack that was a bad idea from the start.
mackal 12y ago
I get this on Chromium despite embedded h.264 working everywhere else :P

by stonogo 12y ago

This is on a fully-patched RHEL6 workstation: http://i.imgur.com/NleqJTD.png http://i.imgur.com/NleqJTD.png Another example of "use bleeding-edge tech or go fuck yourself" from the modern web.

fixermark 12y ago

Support for mp4 isn't bleeding-edge tech on other operating systems / distributions, unfortunately. It's a couple of years old in terms of being supported by Chrome; it's supported in Firefox as of last August. At this point, desktop configurations that can't play mp4s are at risk of being considered "broken."

callahad 12y ago
Is it really that difficult to supply a free format like WebM in addition to patent-encumbered H.264? If you only supply H.264, you're cutting out Firefox on OS X, Chromium, and Opera.
- garblegarble 12y ago
  It does mean you need to transcode and store twice as many files, which can be a serious pain if you've got a number of different bitrate H.264 assets. It can be a big pain if your software assumes there'll only be a single media file. Not insurmountable but painful for small operations (and for large operations, where there may be a back-catalogue to worry about) I'm with you in spirit, but in practice I think we can all understand why people often just go for H.264
  - kibibu 12y ago
    This is a new feature launched by one of the biggest web brands there is, so presumably theres no back catalogue.
- xooyoozoo 12y ago
  Interestingly, the gif->mp4 in the source link uses Constrained Baseline H264, the only profile that's supported by Cisco's BSD-licensed OpenH264[1]. The MPEG-LA patent fees are already covered, so that small projects can freely use the decoder/encoder. [1] https://github.com/cisco/openh264 https://github.com/cisco/openh264
- cookiecaper 12y ago
  Yes, until we get client-side transcoding, it is that difficult. Video files, even files compressed with modern codecs, are really big, and the concepts are generally really hard for most people to grok. The knowledge is so arcane that if you have a basic grasp of ffmpeg you are already a wizard. Most people's eyes will glaze over the second you start talking about how they should use a different container, or codec, or whatever. That's why GIFs (for sub-one-minute videos) and Flash (for long videos and/or videos with sound) became the universal language of video; there was no more "Here's this video, but you have to install WMP/RealPlayer/QuickTime/Bonzai Buddy to see it!" In fact, Flash probably became the standard because it did such a good job at integrating with the rest of the browser and didn't shove obtrusive branding in the user's face. The tl;dr is that the support needs to very near universal for this to work, and no one is interested in WebM. Google probably could've forced the issue with YouTube, and they initially claimed they were going to, but they chickened out for some reason. I've heard it's because VP8 didn't live up to expectations and that they'll renew the push when VP9 is done, but whatever the motive, the reality is that if you want HTML 5 video to work, you must use H.264, as even Mozilla has been forced to admit.
  - callahad 12y ago
    > Video files, even files compressed with modern codecs, are really big, and the concepts are generally really hard for most people to grok. As the article points out, the video files are generally much smaller than the source gifs. Similarly, while there are real impediments to transcoding for many developers, I'm confident that the Twitter engineers in this specific case are capable of building a VP8 pipeline. After all, they built one for H.264. At that point, achieving universal support is as simple as having two <source> tags inside your <video> tag. It's not difficult at all: http://www.html5rocks.com/en/tutorials/video/basics/#toc-spec-sources http://www.html5rocks.com/en/tutorials/video/basics/#toc-spe...
    - cookiecaper 12y ago
      Yes, in this specific case, application-specific compression codecs are better for the storage of video, but that doesn't mean that video is small and that you can afford to transcode 4-8 different copies for every single image that would be uploaded (avail resolutions * formats * single piece of content), as that requires both a lot of CPU and a lot of disk space. It also doesn't mean any person around you has the expertise to figure out how to do this in a semi-reasonable manner, because as stated, most people don't understand the concepts used in modern video storage. You also assume that either WebM or H.264 will be supported by the user's browser. I don't think this is entirely correct, and in any case, it may always change, at which point the demand on the individual site becomes that much worse. I think the real solution is to automate this and allow the client to request on-the-fly transcodes to the formats the browser can support, similar to the way some UPnP servers work.
deleted 12y ago
[deleted]
stonogo 12y ago
Chrome on Mavericks is "broken?" How shall I upgrade this?
- deleted 12y ago
  [deleted]
- the_hangman 12y ago
  Chrome supports mp4 on Mavericks (as well as on older versions of OS X).
cliveowen 12y ago
Actually I'm on Chrome/Mavericks and I get the same thing.
- CountSessine 12y ago
  Chrome + Mavericks here - I see the video just fine. Did you mean Chromium?
jasonlotito 12y ago
This is what modern support gets you with this method: http://imgur.com/Qr3tohD http://imgur.com/Qr3tohD http://imgur.com/Qr3tohD,8okaMlP#1 http://imgur.com/Qr3tohD,8okaMlP#1 So... Flash. This has the added bonus of stealing focus if you click on it, making the "GIF" a UX nightmare.

_delirium 12y ago

It does weird things on some mobile devices that do support it, too, mostly interrupting the audio player (on some devices, movie playback grabs the audio).

mutagen 12y ago

I suspect some implementation issues rather than a GFY attitude, it doesn't work on FF or Chrome on OSX 10.9. Safari works though.

chc 12y ago
I'm looking at it right now in Chrome on Mavericks. Are you sure you checked with the right browser?
- adregan 12y ago
  I'm using Chrome 35 on Mavericks and I also get the message. Clicking through to Twitter will display the video.
xooyoozoo 12y ago
I recall reading on gfycat's subreddit that desktop Chrome's H264 support is occasionally spotty, so they chose to force on VP8/WebM in Chrome. The upside is that users get a reliable experience. the downside is that laptop Chrome users get a reliably lower battery life, as VP8 isn't typically hardware accelerated.
CountSessine 12y ago
Chrome on OSX 10.9 works just fine. I'm looking at the example video now.

kintamanimatt 12y ago

You choose not to use the appropriate software to experience what is being offered. This is akin to riding a decrepit horse on a racetrack while whining about how everyone else that is riding a healthy horse is going faster and having a better experience than you. Just upgrade.

stonogo 12y ago
Your analogy is stupid and your comments are not helpful. I'm not modifying 3,600 workstations because some web programmer decided to mangle user-uploaded content without doing fundamental work to ensure graceful degradation.
- deleted 12y ago
  [deleted]
- lfuller 12y ago
  But that's your choice, as was Twitter's choice to make a modification compatible with the majority of its users.
- viggity 12y ago
  you're seeing that because they wanted to show you what it looked like as an MP4. My understanding was that twitter would ship you the GIF if your browser didn't support MP4.

nilved 12y ago

This is very far from bleeding-edge; we're talking technology between five and 10 years old. Set up gstreamer already; it's time to move past gifs.

stonogo 12y ago
WebM works fine on this machine. mp4 does not. This is why there was a bit of scuffle, as you may recall, about video formats on the web.
- chc 12y ago
  Are you saying that WebM, a file format introduced in 2010, is less bleeding-edge than H.264 MP4, a file format introduced in 2003? What definition of "bleeding-edge" are we using here?
  - smackfu 12y ago
    The introduction date of the format doesn't seem very relevant, since what we are talking about is native inline browser support.
    - chc 12y ago
      Same story. Most browsers supported H.264 first (because it was dominant before WebM was even born). Internet Explorer, Safari and MobileSafari still do not support WebM. I don't see any reasonable way to say that WebM is well-established and H.264 is not.

thathonkey 12y ago

What percentage of Twitter's users do you think use Linux for browsing? Much less RHEL. Anyway, this is purely a front-end enhancement mostly for the benefit of mobile users. Also lol @ mp4 being "bleeding edge" tech. It certainly is not. Even in the Linux community.

stonogo 12y ago
Changing the fundamental format of the content is a 'front-end enhancement' now? If it's for mobile users, why not present it just to mobile users? also lol @ your opinion about technology. even in the "linux community"
- thathonkey 12y ago
  It is an enhancement for the benefit of front-end performance. I'd like to hear how you think that is not true? Anyway, that is why I asked the loaded question about how many users you think there are that browse Twitter.com on their RHEL box? Hint: HN is not a good sample to answer this. And how is a ~14-year old technology (that has been ubiquitous now for at least 6 years) considered bleeding edge?

Fuzzwah 12y ago

Strangely I get that same message on my win7 machine running current chrome as well as my lubuntu machine running chromium. On both when I click the "click to view on original site" link it works fine.

lfuller 12y ago

mp4 is "bleeding-edge"?

mikeash 12y ago

More like, "stop using technology from the late 80s or go fuck yourself". GIF is awful and nobody should reasonably expect sites to accommodate it anymore.

enneff 12y ago
Huh? HTML is older than GIF images. Should we stop accommodating that too?
- mikeash 12y ago
  Huh yourself? HTML dates from 1993, GIF dates from 1987.
  - enneff 12y ago
    Okay, so take my question and s/HTML/hierarchical file systems/ or s/HTML/C/ or make any other substitution. Why ditch something just because it's old?
    - mikeash 12y ago
      Well, there's a reason for the second half of my comment. GIF isn't bad because it's old, it's bad and old, and it's unreasonable to expect it to continue to be supported because that's a nasty combination. If something sucks but is still the standard technique in recent years then it's reasonable to think it should be supported. Similarly, if something is old but great, it's reasonable to think it should be supported. But GIF is old and crappy and there's no reason to expect support for something old and crappy to continue indefinitely. I'd also note that your other examples have received substantial revisions over the years that have improved them enormously. I'd happily say the same thing about not supporting 1987-era C or filesystems.
      - cratermoon 12y ago
        GIF itself is not so bad, for its intended purpose and time, but the animated GIF bit is a serious hack that was a bad idea from the start.

mackal 12y ago

I get this on Chromium despite embedded h.264 working everywhere else :P