Re: Why base WebP off VP8 and not VP9?

162 views
Skip to first unread message

Pascal Massimino

unread,
May 25, 2013, 4:43:30 PM5/25/13
to WebP Discussion
Hi Justin,

On Sat, May 25, 2013 at 1:51 AM, Joiseystud <justi...@gmail.com> wrote:
In the Google IO video they discuss that the WebP format is based on a keyframe from VP8.  Is this being updated to be a keyframe from VP9 since VP9 seems to be twice as good as VP8?

Right now, there's no plan to use vp9 for WebP mainly because:
  * vp9 is still a video codec, and a lot of the improvements made are related to inter-frames coding, more than intra-frame [1]. So, while the impact of using vp9 is certainly positive, it would take quite some research and experiments to ascertain to what extent exactly (and at which cost).
  * vp9 is still in flux, while vp8 and webp are stabilized at codec level. It wouldn't be a good idea to change horse mid-stream. While adding new features is manageable (reasonably), changing the existing ones in-flight (like vp8->vp9) is very slippery.
  * some of the needs for webp  (_if_ we were to break bitstream compat) are not covered by vp9 novelties (mainly because, as said, vp9 targets moving pictures whereas WebP is about static images).
  * vp8 hardware is already available, likely to help webp support.
  * vp9 is quite more complex than vp8.
The underlying idea is that, while pure compression efficiency is the primary driving force, it also isn't the only
variable in the equation. Algorithm complexity, implementation simplicity [2], timing, ease of implementation, etc.
also come into play.

skal

[1] although larger-sized blocks and other tools would be nice to try, for sure.
[2] if you were following this mailing list, you might remember the discussion and experiments surrounding the choice of alpha-channel lossless
compression. The situation was somehow similar: we had an alternate format ("tcoder") implemented that was better in some cases, but more
complex and involved. We dropped it in favor of re-using the regular argb lossless compression, trading few extra % of compression efficiency
against simplicity and coherency.

Reply all
Reply to author
Forward
Message has been deleted
0 new messages