I like the use of short 2-5 second videos instead of pictures. They did it tastefully and made it useful.
I never thought I'd see a good use case for auto playing videos. (It kind of reminds me of Harry Potter too)
I never thought I'd see a good use case for auto playing videos. (It kind of reminds me of Harry Potter too)
Sadly I won't be reading any of the content because even after five minutes it's killing my browser. To the spark.io blogging team, please don't assume unlimited wads of broadband. Let the reader decide whether they want to play your videos, and you know, I can only watch one video at a time on that page, so why start them all playing at once? This is no better etiquette than CNN or MSNBC or an adware farm where they start playing videos at you upon arrival. It's very rude.
Maybe using whatever https://mediacru.sh/ returns instead will help.
For no real reason either time. I'm not sure what's going there.
https://blog.mediacru.sh/2013/10/31/Add-media-hosting-to-you...
I'm sure YMMV depending upon OS, browser, underlying installed codecs handling the video (and their associated gpu acceleration or lack thereof), etc.
Edit: This is with crummy AMD FirePro 2270 graphics. Chrome 34.0.1789.0 canary was very smooth on the same box!
$('video').each(function() { this.pause(); })
Now i'm thinking about upgrading and all that... :P
Not sure what the others guy are talking about. Works fine on my MacBook Pro...not issues at all?
As I mentioned in another post, it works fine in Chrome 34 on the same hardware that it struggles dramatically with in Chrome 32. Both of them have hardware decoding enabled, and so on. The Chrome 32 instance has no problems at all playing video anywhere else.
Indeed, on that same line, the videos don't load at all on Chrome on the Nexus 5. The N5 of course supports h264, and has no problem on any other site that I've ever discovered. Maybe their server is now overloaded (EDIT: Okay they're using S3....going to be an ugly bandwidth bill from that...and it's fully responsive), but it also doesn't load on the iPad 3rd generation running iOS 7. Again just black boxes.
EDIT: I wonder if it's because they're (s3) setting the content type to octet-stream, rather than video/mp4. Some clients seem to be going on alternate decode paths or are refusing to display it because of that.
e.g.
Content-Length:6915107 Content-Range:bytes 0-6915106/6915107 Content-Type:application/octet-stream
There's a lesson in here somewhere.
It's sad to find out that they ignored that mp4 isn't supported by all browsers. I know: HTML5 video is just a PITA, and that's indeed a reason why so many still rely on gifs.
I hope this project grows, and that they will care a bit more than they did here.
I utterly disliked it. It made my browser slow and so I didn't read their page.
Opening the page via eww in EMACS made it readable since it doesn't load videos if I don't ask it to.
Having said that, an h264 source can have magnitudes more complexity for playback, and generally the greater the compression the higher the playback complexity. Having five or so high profile multi-MB decorative videos autoplaying on a page is excessive.
They shouldn't use autoplay. They shouldn't even initialize until scrolled into view. They shouldn't all play at once. Their bandwidth usage is going to be enormous from this HNing, a single page impression pushing 15MB+ (EDIT: I hadn't really delved into it at the time given the display issues, however I grossly underestimated when I said 15MB).
Poor degradation to those of us running NoScript, there.