Apple needs to improve the image stabilization on live photos. I like live photos a lot now, but I had disabled them until I discovered Google's Motion Stills app.
Yeah, this is a feature I've been using and enjoying since they added it a while back. I was under the impression that Google created the iOS "Motion Stills" app to add similar functionality to Apple's built-in Live Photos and turn then into stabilized animated GIFs so you can get them off your iPhone in a more widely supported format.
Interesting - I like the shaky nature of it. I think it genuinely adds to the experience. Motion stills are nice but I don't feel like live photos should be polished, it feels better with the quality issues.
The Windows Phone app allowed you to select areas to loop, would attempt a seamless loop and did stabilization. Pity Microsoft never ported it away from that platform.
Is this why Apple won't allow WebM on iOS? It's like they want to pull the web apart, stick it behind a private API, then sell it back to you piece by piece.
What is this even supposed to be beyond webm/gifv anyways?
No. That doesn't even make sense. WebM is a video format, it competes with h.264/h.265.
Further it's incorrect that they don't allow webm, what they don't is implement and support it — I assume because they already have hardware-accelerated codecs which they're invested in and thus have little use for webm — third-party video players can support webm just fine (VLC supports it AFAIK)
> What is this even supposed to be beyond webm/gifv anyways?
It's metadata-information on a picture, the main media is a regular photograph (in full quality) and the "live" part is surrounding information (in lower video-level quality) and really quite nice, it provides a loop of live context (the "live" video is 1.5s before and after) for the picture.
There's nothing special at the technical level, it's just a video file next to or embedded in the picture file.
>No. That doesn't even make sense. WebM is a video format, it competes with h.264/h.265.
Yes, it makes plenty of sense. If WebM were available on iOS, this new "feature" would not exist. There would be a million 3rd party apps already doing this. Apple simply wants to lock things down purely for profit.
>It's metadata-information on a picture, the main media is a regular photograph (in full quality) and the "live" part is surrounding information (in lower video-level quality) and really quite nice, it provides a loop of live context (the "live" video is 1.5s before and after) for the picture.
> Yes, it makes plenty of sense. If WebM were available on iOS, this new "feature" would not exist.
It would exist in the exact same way. Again, webm is a video codec, it competes with h.264/h.265 which is only a sub-component of a "live photo".
> There would be a million 3rd party apps already doing this.
There could already be a million 3rd party apps doing this using h.264. Hell there could already have been a million 3rd party apps doing this before 2015.
Yet there are not.
> You've just described WebM
Only if you are either completely addled or thoroughly dishonest.
Which can then be converted to "Why would they implement hardware-accelerated WebM, what is the value proposition for Apple?"
Keep in mind that you need enough value gain for them to invest the engineering and silicon in hardware webm decoding rather than everything else they're doing.
>The main reason they don't allow WebM is because only H.264/H.265 are hardware accelerated on iOS devices.
And the only reason they don't support VP8/VP9 is because they can't lock it down like H.264. It's the same reason webGL support in iOS Safari took forever. Apple didn't like the idea of developers being able to create and distribute really advanced hardware accelerated 3D games on the iPhone outside of the official app store ecosystem. They need to support open standards for the sake of developers.
The two things you cited are completely unrelated.
edit: the parent replied to me but deleted their post by the time I finished my response; since I spent the time to write it, I guess I'll put it here:
> My point is that Apple repeatedly resists open web standards for the sake of maintaining their walled garden. This new 'feature' is just another example of that.
> What is this even supposed to be beyond webm/gifv anyways?
WebM is a standard for video.
"gifv" is not a standard or even a format; it's just what imgur puts in their URLs for pages that play looping silent videos, simulating the GIF experience. You can only watch "gifv" on imgur, though of course any site can play a looping silent video.
"Live Photos" is a broadly similar concept to "gifv", in the sense that both are basically just a proprietary brand for a basic UI on top of a video player, not anything with deep technical content. However, the UX is somewhat different. Live Photos combine a high-resolution photo with a lower-quality video, and the video doesn't play until you mouse over. (The actual photo and video are just JPG and MP4, respectively.)
In theory, the idea of treating a photo-video pair like a photo could be standardized, but it's not any less standard than gifv, and at least when it comes to display on websites (as opposed to, e.g., photo gallery apps), it's a simple enough concept that there doesn't seem to be much benefit in standardization. Apple released a small bit of code, for anyone to use on their own website, to do the job of drawing the UI and transitioning between the photo and video; of course, this is implemented on top of open web standards. Not sure why you want to crucify them over that.
Could just be my browser, but it doesn't seem to play very nicely for me ( Firefox on debian jessie ).
First time I tried to hover, it didn't do anything at all, I think it might have still been loading ( or waiting to load the 'live' version until I hover over ).
When I got it to actually go 'live' they didn't seem smooth at all, stuff was jumping all over the place. Though, after watching them both fully, repeat playbacks seemed fine.
didn't get either of these issues in chrome on the same machine.
Actually, to transition between a photo and a video when you hover over a specific-looking badge, which is also animated to show loading progress.
It's not a huge piece of code, but if the question is how much code you need to put in a npm module to justify its existence… well, it's a lot bigger than left-pad!
Live Photos pose another problem for me – peer mockery. Here how it goes:
— Press on the pic and it moves. It's magic. It even starts half a second before the press.
— OMG it looks like journals in Harry Potter!!! Send the Gif to me!
— Nope, can't, not a Gif
— What!? Hahaha! So you neither have proper earphones nor a way to back up your Live photos!?
I bought the iPhone 7 for the secure enclave and for Tim's standoff against the FBI, and Safari's reading mode is a bonus against ads, but the social standing of owning an iPhone is not what it used to be...
GIFs are too heavily compressed, with too few colors, etc.
Technically GIFs can have as many colors as you like. Each frame can have its own 256 color palette, and any transparent pixels are left the color of the pixel from the previous frame, so you can build up a full color image over time. This is silly and you'd never actually do it, but still, it is possible.
"GIF" on web forums these days usually (thanks to gfycat and friends) means "WebM". So just do that: send me a WebM of that live photo.
Oh, that's right, iOS doesn't even support WebM let alone let you export Live Photos as WebM (or MP4 for that matter). That you need a third-party app to share Live Photos with anything other than another iOS device is pretty shameful.
not "still" but "already". They also include headphones in the box. And they also include adapter for those willing to use non-bt non-lightning headphones.
I played around with this, but had some trouble removing the audio stream from the MOV file using ffmpeg.
There's a third data stream in the file, and ffmpeg doesn't know how to handle it, so it either gets removed or replaced with dummy data. The javascript framework seems to need this third stream to work, which is pretty annoying...
I'd love to do something with this, but without a simple (and preferably scriptable) way to remove the audio I probably won't...
Ah, you see, a HTML5 video tag with a webm and `poster` image doesn't have the blurry transition when switching between the still image and the video as well as when looping the video. Also of course iOS doesn't support WebM and HTML5 video on iOS is not intended to be used for anything other than full-screen videos because Apple knows best and actually supporting HTML5 media properly would ruin performance (as would supporting WebM without the same optimisations Apple made for H.264).
Also of course Live Photos are totally different because they're from Apple, not based on any of those cruddy and boring "open standards".
--
But to be serious for a moment: the main difference is that iOS treats them as a thing (unlike a plain "video plus image" combo), so the entire user experience surrounding them is different from recording to sharing them. And technically the still image is higher res whereas the video is lower res (with video+image the image is generally a still frame so res tends to be the same).
Live Photos combine two things: the 3s video capture (1.5s before and 1.5s after you take the picture) at relatively low resolution, and the actual photo that is taken at full camera resolution. GIFs are missing the latter, and are more flexible in terms of length and what have you. This particular presentation also sticks to Apple's standard presentation of Live Photos: as a static high-res photo with an encircled play button (in some cases including the world LIVE) that triggers the associated low-res video.
EDIT: No idea what you're asking about re: an Apple site. This is Apple releasing JS to make it easy to display a Live Photo on any site.
You should probably be asking what differentiates it from a video file. GIF is horrible - it's limited to 256 colors, and it sucks at compression compared to MP4, let alone HEVC.
Nobody coming up with these GIF killers gets what made GIF popular - it's simple as hell. A gif will play on anything, and you can easily save it the same way you'd save a photo. Life's good.
Now try to save a gif on Twitter without resorting to scripts or developer tools. Try to right click and save an Imgur gifv, then upload that back to imgur again.
GIFs are simple. You save an image file. You're done. Video is complex. You can't just have an mp4 (well, x264) file because that's patent-troubled. You can't just have a webm file because that's not supported by Apple devices.
Even these live photos are difficult. You need to add Apple JavaScript to your page, and the live photos themselves are made up of two files:
>Your Live Photo will be stored as a pair of files: a JPG file and a MOV file.
Yeah, GIF itself is a bad format, but simplicity is why it's still around.
It's not simplicity. It's browser support. PNG wasn't around until it was supported by most browsers, even if it's simple format. You can't find BMP now in web, it was replaced by PNG (or JPEG). GIFs will be replaced by proper video files, when support will be good. They are not more complex than GIFs from the user perspective.
However I don't think apple ever intended Live Photos to be a replacement for gifs. They're just a fun little feature that works well within the context of taking photos with a cell camera.
Only because gifs got a headstart in a time content creators mostly weren't aware of the patent situation. There was a huge push for a replacement once the situation became widely known. Gifs only had a massive renaissance _after_ the patent expired.
While GIF was gaining popularity as a video format (YTMND and all) in 2004 when the patents expired, I think it was later that it really exploded, with sites like Reddit appearing, and social media gaining steam in general.
Could this be a sign that Apple is beginning to 'get' web services? Their new maps in 3d is industry leading, but is missing a web api, and you still need an AppleId to view it.
Apple 'gets' web services. They run some of the largest web services platforms in the world i.e. iCloud, Messages, iTunes Store, Apple Online Store.
They just choose not to release an advertising supported Maps platform because (a) advertising goes against their strong privacy/security message and (b) it doesn't offer anything unique or valuable to the market. To be honest I don't think they would've even gone into Maps if Google hadn't played hard ball during the iPhone 1 days.
None of that is the web though. Why can't the open up Apple Maps and the App Store so you can browse it on a laptop (and initiate remote app installs like with Google Play)? That has nothing to do with ads.
If you're asking why they don't open them up to non-macOS computers, that's Apple's long-standing strategy of making the software part of the selling point of the hardware.
iCloud, iTunes Store and Apple Online Store all have public facing web sites. And web services does not mean web sites. It means having APIs exposed (internally or externally) over web protocols i.e. HTTP which they all do.
And you can use Apple Maps on a laptop. Just that it has to be a Mac.
While I'm not interested in getting into a semantic argument around something arbitrary like what "getting the web" means, unless I'm missing something (which is absolutely possible!) I don't think it's fair to compare the Apple App Store (https://itunes.apple.com/us/genre/ios/id36?mt=8) to the Google Play Store (https://play.google.com/store/apps?hl=en). One of these is clearly baked for the web, and one of these is not.
Also, as an aside, if I have missed something and there is a better app store experience for Apple please let me know - I just chose the top result searching for "Apple App Store".
Apple optimizes their app stores for devices that are able to actually install these apps. I don't think it's as convoluted as you seem to think it is. I have one Apple device (MBA) and I have never agreed to the iTunes TOS and never opened it. I have no interest in the App Store except when nagged for updates. Homebrew and SSH to my linux desktop fulfill my needs, and after 4+ years I get ~6hrs battery life.
The web has really gone down hill, and one thing I actually like about Apple is they embrace more of the internet than just the web/advertising.
"Apple optimizes their app stores for devices that are able to actually install these apps."
Right, yes, we agree on that. And I don't find anything at all convoluted about it, I'm not sure why you would think that - there is nothing particularly complex about any of this.
My only point is that, in my personal opinion, it's a far nicer experience to explore apps for potential install on an Android phone, via the play store website, then it is for an Apple phone, via this...listing page - when you're not on the device itself. It's possible I'm simply in the minority here but when I'm chilling on the couch thinking I need a new (insert application here), I'd rather use the screen with more real estate.
> is a better app store experience for Apple please let me know
It's definitely no Google Play Store, but as a general App Store search alternative I like https://fnd.io/ as it's a bit more web friendly. Unfortunately, you still need to jump into the App Store/iTunes to actually download anything.
Apple doesn't care about running in other platforms unless it's for profit, so Web technologies are very low priority.
As for services, their iTunes platform is really 1950s technology, but it works.
I don't know how a company that makes the world's most used Internet service in transactions per second (Apple Push Notifications Service), which works very well, may be "bad".
This concern plus the fact that the license they use is by no means a common OS license. I also think that is a way to make some side cash but live photos didn't take that much over in the popular culture.
I definitely didn't suggest average broke-ass Joe. I was thinking more along the lines of media/news websites whose developers haphazardly leverage the format without considering patent implications.