3 ms·

Agreed. I had to open the source and see what they were using. Native video elements...I like it. I figured it was a nice GIF or something. Not sure what the o

by ddoolin 13y ago

Agreed. I had to open the source and see what they were using. Native video elements...I like it. I figured it was a nice GIF or something. Not sure what the others guy are talking about. Works fine on my MacBook Pro...not issues at all?

selectodude 13y ago
Same with Safari 7 on my MacBook Pro. Worked a treat, was a super cool concept. I'm surprised to see all the complaints with Chrome, I always took that browser to have the best support for this kind of stuff.
- ddoolin 13y ago
  I'm using Chrome and it works just fine. I'm actually quite curious what's causing the negative experience across equally capable machines.
  - simoncion 13y ago
    Me too! I'm using Chromum 31 and Chrome 32 on Linux with old open-source Radeon-HD drivers, and ran that page without issue. shrug
  - corresation 13y ago
    A different video card, codec chain, and on and on, can yield a very experience. Being an early adopter of many Harry Potter-esque moving pictures can yield nice content, but it will invariably cause client issues. 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.
- asdashopping 13y ago
  In my experience Safari is generally much smoother and uses less power than Chrome on OSX. Chrome frequently makes my MBP uncomfortably hot on websites that Safari doesn't break a sweat on (like Flash videos on Youtube, although Chrome's built-in Flash could be causing problems). It's unfortunate.

by ddoolin 13y ago

selectodude 13y ago

Same with Safari 7 on my MacBook Pro. Worked a treat, was a super cool concept. I'm surprised to see all the complaints with Chrome, I always took that browser to have the best support for this kind of stuff.

ddoolin 13y ago
I'm using Chrome and it works just fine. I'm actually quite curious what's causing the negative experience across equally capable machines.
- simoncion 13y ago
  Me too! I'm using Chromum 31 and Chrome 32 on Linux with old open-source Radeon-HD drivers, and ran that page without issue. shrug
- corresation 13y ago
  A different video card, codec chain, and on and on, can yield a very experience. Being an early adopter of many Harry Potter-esque moving pictures can yield nice content, but it will invariably cause client issues. 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.
asdashopping 13y ago
In my experience Safari is generally much smoother and uses less power than Chrome on OSX. Chrome frequently makes my MBP uncomfortably hot on websites that Safari doesn't break a sweat on (like Flash videos on Youtube, although Chrome's built-in Flash could be causing problems). It's unfortunate.