I just launched my revised company site, which has several videos because film production is my biz.
On mobile the videos stutter, either because the file size is too large or it’s not optimized for streaming - or both. I don’t want to use YT, Vimeo or any other content hosting service at this time, so that’s not an option.
I’m going to re-compress the videos using iPhone settings in Compressor (Handbrake was suggested, but I don’t know if it’s any better at doing that than Compressor) and see what happens.
Are there any Sparkle or server-side tricks that can be used to better optimize the streaming for mobile? I’m on a shared hosting plan with HostGator.
Hi @producerguyaz
HandBrake has a setting for “web optimized” videos and for progressive download.
But I think Compressor should have a setting like that as well …
HandBrake is free, so you could experiment with it …
1 Like
Yep, Handbrake is by far the best app for web-optimizing videos. Problem solved.
Thx.
Web optimized is a very simple “trick” of front loading the video track metadata in the file, this allows the web browser player to read it right away, instead of having to seek to the end of the file and potentially download the whole video file.
Inexplicably Adobe’s Media Encoder doesn’t have this option. I’m not familiar with Compressor but assume it doesn’t either.
We’d like to do more with video, but the mp4 video container format, the h264 codec and the mpeg 2 “ts” format used in HLS are all patent encumbered, making them hard for us to deal with.
A better solution would be to add support for HLS and DASH, which would cover 99% of the streaming uses, and let the user do video compression and upload autonomously. This is actually on our (ginormous) list.
2 Likes
No, Apple’s Compressor doesn’t seem to have the specific side-chain coding for http use, but Handbrake does apparently.
For other video publishers:
Final Cut Pro X, Davinci Resolve, Premiere Pro, Avid etc… all of their compression routines are based on making final encodes based on the frame size, frame-rate and codec you want for the final output.
For example, FCPX has a wonderful built-in feature for “sharing” to Apple devices, like the iPhone, and when I made the encode specifically for mobile from FCPX the file was really small and looked fantastic. But, Firefox couldn’t play the file even though Safari liked it no problem.
When I re-encoded in Handbrake for the same size it was able to put in the required code and MIME type that Firefox likes and, voila! A great-looking vid that plays nicely on mobile too.
Keep in mind that video editors and their associated compressors are designed for film, video and broadcast outputs, not for web players. For Apple users Handbrake would be the best option, not sure what Windows options there are.
@producerguyaz
Good to hear you found a solution that works for you! 
That’s how I do it as well: Export from Final Cut Pro X to a “Master File” (that’s usually a bit overkill, but what the heck … 
) and then optimise it with HandBrake. I think that works best for web use …
BTW … HandBrake is available for Windows and Linux as well.
There still seems to be an issue with playback, even with an optimized file. A friend just told me that on his iPhone the videos are playing in full-screen and have to load fully before they play. I re-checked HB settings and the “web optimized” tick box was checked.
What could be causing this behavior? User error? (maybe he’s inadvertently selecting full-screen?) Or should I change how the video is played - in-browser vs. in-video as selectable in Sparkle?
Disregard: I had him clear his cache and re-try after uploading the Handbrake files. Not perfect but way better.
I use ff-Works on macOS (http://www.ffworks.net) for most of my ‘mastering’-style encoding.
It definitely supports “write Moov Atom at start” optimization for streaming; also, it’s worth trying different encoding rates and encoded pixel dimensions to see what works best, if you have the time to experiment.
Results can look very good at relatively high CRF rates (confusingly, this corresponds to lower overall quality level); also, generating a smaller pixel-dimension file may not end up looking worse than sizing to HD formats or to accommodate the 2X, 3X (and beyond) pixel densities of today’s smartphones and tablets … subjective quality will be highly dependent on source material.
