Flickr: PLEASE Improve your Video Compression Codec!
December 20, 2012Kiddo Trail Hiking is more fun with a Dog! a video by tadnkat on Flickr.
Ever since Flickr rolled out the feature to upload videos as well as photos, Flickr has been the first place I put up videos. Why? Most videos I take are part of the same stream as my photos – part of a set of vacation shots, or are usual daily uploads like this one – and I love being able to view them in the same context as the rest of my photos – instead of telling people to go to YouTube if they want to see video.
But, at this point, the video codec that Flickr is using is a straight-up embarrassment and due to the distractingly-bad compression artifacts, is so utterly contrary to the whole reason Flickr stated that they rolled out video to begin with.
See the above video. Now, granted, it is basically a worst-case scenario for a video compression codec, as with the leaves and trees and movement, you basically have 95% of the pixels of the frame changing from frame to frame. But still, the video quality is so bad that it’s painful to watch. It’s like it was compressed with Sorenson Spark, circa 2005, and made to be streamed to a first-generation color-screen cell phone.
I’m no stranger to the compute requirements of implementing a proper codec, the storage requirements of such, and the banks of new equipment that will probably have to be added in order to make it a reality.
But it’s the price to play in today’s market – and encoding on YouTube looks a million times better, even if it still has some distracting blurring.
Photo quality is most of the reason why I still have all of my photos here on Flickr. But with the fact that Picasa/G+ encodes all its video on Youtube, it basically starts tipping the scales away from my favorite platform.
Can someone please help?
I agree with everything you say, and do not understand why the people at Fickr have so much trouble correcting this fundamental problem.
I have not done exhaustive tests, but it seems that if a video exceeds a certain parameter limit, Flickr compresses it very aggressively, while if it is just below that limit, Flickr pretty much leaves it alone. For example, I was able to upload a 720p video without any obvious loss of quality, but the original 1080p version of the clip was compressed to be far smaller than the 720p version, and quality loss was obvious.
The trouble is, even if I took the time to find out what the parameter(s) is/are, Flickr keeps tinkering with almost every function, so I would soon have to do the tests again.
Whatever happened to Flickr’s policy of treating video clips as “long photos” with the implied same quality? I thought Flickr limited the length of video clips so that they could be displayed and downloaded at good quality like the photos.
Your last paragraph sums up my feeling PRECISELY. I have no problem at all with the 90-second limitation on video clips, provided we’re all treating them in the same spirit – that one’s going to add in a moving photo to the mix. And, for the most part, I would LOVE to be given the option of viewing someone’s clip at a much higher bitrate, even if it means a massive tradeoff in playback speed.
I’d also absolutely be willing to endure a much longer encoding queue – i.e. a low-bitrate version is available immediately, and a higher-bitrate version is encoded with a longer wait time. If it takes an hour before I can share it, fine. But at present, there’s no way for Flickr to properly display the work that comes out of my cell phone, never mind SLR.