Used with --framestats=file.csv. Currently prints raw codec QP (not
internal 0-63 range) and bytes per frame.
Change-Id: Ifbb90129c218dda869eaf5b810bad12a32ebd82d
A past patch made it so that every frame that had a decode error
caused a corrupted frame to be counted. Unfortunately it was possible
to get both a decode error and a corrupt frame for the same frame
and thus double count an error. This code makes that impossible.
Change-Id: Iea973727422a3bf093ffda72fa358a285736048b
A failure to decode is most likely equivalent to a corrupt
frame for the purpose of returning a failure.
Change-Id: Ie53db2b8130b40b725841f5f7a299d63aa56913d
the --enable-postproc-visualizer configure option remains as a no-op as
do the control names and values for compatibility
+ remove the corresponding debug flags from vpxdec: --pp-*
Change-Id: I4a001cd9962b59560d7d6bda6272d4ff32b8d37c
development has moved to the nextgenv2 branch and a snapshot from here
was used to seed aomedia
BUG=b/29457125
Change-Id: Iedaca11ec7870fb3a4e50b2c9ea0c2b056a0d3c0
The name "display_*" (or "d_*") is used for non-compatible information
(that is, the cropped frame dimensions in pixels, as opposed to the
intended screen rendering surface size). Therefore, continuing to use
display_* would be confusing to end users. Instead, rename the field
to render_*, so that struct vpx_image can include it.
Change-Id: Iab8d2eae96492b71c4ea60c4bce8121cb2a1fe2d
CONFIG_VP9_HIGHBITDEPTH is currently used by both vp9 and vp10, but in
many place outside vp9/vp10, the macro was used in conjunction of
CONFIG_VP9. This created a dependency on vp9 for vp10 to build. This
commit removes the dependency by use CONFIG_VP9_HIGHBITDEPTH only in
these places.
Change-Id: I8cc007fc9cf132394c6498ce6759e606b64a6ad0
Because the call to vpx_codec_control at line 928 is now guarded by
!frame_parallel, 'corrupted' may not be set.
Change-Id: Id166bd8a8cdb5e5120fca1640011a3545f6e178a
this function may return an error if no frame is available; --keep-going
is meant to test decoder resilience, so simply warn in this case.
Change-Id: I6e6aed3e78eca21cca80d7d8a06a1a244685ba29
Libvpx was memseting every external frame buffer before decode. This
was to work around a valgrind issue in our C loop filter. Most of
the time this was not needed and we have noticed some significant
performance loss on some platforms. Now we require the application to
zero out the buffers if it is using external frame buffers.
Change-Id: I7330d00a315e65137ed30edd5f813e8929b76242
Adds config parameter vp9_highbitdepth, to support highbitdepth profiles.
Also includes most vpx level high bit-depth functions. However
encode/decode in the highbitdepth profiles will not work until
the rest of the code is in place.
Change-Id: I34c53b253c38873611057a6cbc89a1361b8985a6
the parsing of this flag was mistakenly put in a CONFIG_VP8_DECODER
conditional block in:
95853db vpxdec: add --keep-going option
Change-Id: Ie83ca0399fd3f3d4b0a9d03b7ca5536b310e1f02
Reinstates an assignment to prevent an asan failurere on google3.
Not sure why the failure happens. This was removed in a recent patch
https://gerrit.chromium.org/gerrit/#/c/71068/.
Change-Id: Ifd9ccffd4c2164f4de38b21821ffb28bd779b0f3
Adds support for raw yuv inputs in 422/444 sampling for use
in profiles 1 and 3.
New options added to vpxenc are:
--i422 and --i444, which are to be used in conjunction with
--width, --height, and --fps for proper raw yuv handling.
A new option is added to vpxdec:
--rawvideo, which enforces raw yuv video output for the
bit-stream decoded irrespective of 420, 422 or 444 sampling.
The existing options --i420 and --yv12
are specialized for use only for 420 content.
Change-Id: I2e3028380709afa673bf2e2c25ad5e271a626055
Sets the bit-depth field as default 8 in the image structure in vp8.
Generalizes yuv read in preparation for support for reading 422/444
for 8-bit and 10/12-bit.
Change-Id: I560c13c348b122fd028e408431156376b895058c
The y4m extension used is the same as the one used in ffmpeg/x264.
The patch is adapted from the highbitdepth branch.
Also adds unit tests for y4m header parsing and md5 check
of the raw frame data, as well as y4m writing.
[build fix for Mac/VS by not using tuples with strings]
Change-Id: I40897ee37d289e4b6cea6fedc67047d692b8cb46
