Upgrade to the latest version of libvpx pulled from the webm project's git server.

latest commit pulled from git://review.webmproject.org/libvpx.git:
    82315be75d54d00ad5f2ea51f844f27f2d921dc0

Also enabled more optimizations in the neon build.

Change-Id: I744765d798471c30c2faf32af27161f772129516

1 files changed, 6 insertions, 6 deletions

diff --git a/usage.dox b/usage.dox
index 53808fd1b..0db080b00 100644
--- a/usage.dox
+++ b/usage.dox
@@ -25,7 +25,7 @@
     codec may write into to store details about a single instance of that codec.
     Most of the context is implementation specific, and thus opaque to the
     application. The context structure as seen by the application is of fixed
-    size, and thus can be allocated eith with automatic storage or dynamically
+    size, and thus can be allocated with automatic storage or dynamically
     on the heap.
 
     Most operations require an initialized codec context. Codec context
@@ -74,7 +74,7 @@
     the ABI is versioned. The ABI version number must be passed at
     initialization time to ensure the application is using a header file that
     matches the library. The current ABI version number is stored in the
-    prepropcessor macros #VPX_CODEC_ABI_VERSION, #VPX_ENCODER_ABI_VERSION, and
+    preprocessor macros #VPX_CODEC_ABI_VERSION, #VPX_ENCODER_ABI_VERSION, and
     #VPX_DECODER_ABI_VERSION. For convenience, each initialization function has
     a wrapper macro that inserts the correct version number. These macros are
     named like the initialization methods, but without the _ver suffix.
@@ -125,7 +125,7 @@
 
     The special value <code>0</code> is reserved to represent an infinite
     deadline. In this case, the codec will perform as much processing as
-    possible to yeild the highest quality frame.
+    possible to yield the highest quality frame.
 
     By convention, the value <code>1</code> is used to mean "return as fast as
     possible."
@@ -135,7 +135,7 @@
 
 /*! \page usage_xma External Memory Allocation
     Applications that wish to have fine grained control over how and where
-    decoders allocate memory \ref MAY make use of the e_xternal Memory Allocation
+    decoders allocate memory \ref MAY make use of the eXternal Memory Allocation
     (XMA) interface. Not all codecs support the XMA \ref usage_features.
 
     To use a decoder in XMA mode, the decoder \ref MUST be initialized with the
@@ -143,7 +143,7 @@
     allocate is heavily dependent on the size of the encoded video frames. The
     size of the video must be known before requesting the decoder's memory map.
     This stream information can be obtained with the vpx_codec_peek_stream_info()
-    function, which does not require a contructed decoder context. If the exact
+    function, which does not require a constructed decoder context. If the exact
     stream is not known, a stream info structure can be created that reflects
     the maximum size that the decoder instance is required to support.
 
@@ -175,7 +175,7 @@
     \section usage_xma_seg_szalign Segment Size and Alignment
     The sz (size) and align (alignment) parameters describe the required size
     and alignment of the requested segment. Alignment will always be a power of
-    two. Applications \ref MUST honor the aligment requested. Failure to do so
+    two. Applications \ref MUST honor the alignment requested. Failure to do so
     could result in program crashes or may incur a speed penalty.
 
     \section usage_xma_seg_flags Segment Flags