libvpx (and ffvp8) implementations are completely skipping the deblocking
step if loop_filter_level is 0, which is _not_ equivalent to performing
the loop-filtering with a 0 value for loop_filter_level. In the latter case
(which we followed), few pixels were modified here and there and you could
observe off-by-1 errors on few places.
This patch will reconcile the 3 implementations (since the difference
is minor, skipping the deblocking step will save CPU for virtually
no visible difference).
The spec will be made clearer about the expected behaviour:
* if the global loop_filter_level is 0, turn deblocking off.
* if it's not 0 but the local loop_filter_level ends up being 0 for whatever
reason (lf_delta, mode delta, ref delta, etc.) on a particular
macroblock, skip the deblocking too.
Change-Id: I157f1f8de463b8a76caddb3f347b7fbc7bd527d2
This will make the decoder skip the filtering process if needed,
resulting in speed-up, but also non-compliant (blocky?) output
+ Add a versioning check for VP8InitIo(), since we've adding a field to VP8Io
+ add some more error checks while at it
Change-Id: I4e9899edc24ecf8600cbb27aa4038490b7b2cef3
we'll always encode using absolute value, not relative ones.
Both methods use the same number of bits, so we'll go for the
simpler and most robust one.
+ add some extra checks about pic->u/v being NULL.
Change-Id: I98ea01a1a6b133ab3c816c0fbc50e18269bd2098
converts PNG & JPEG to WebP
This is an experimental early version, with lot of room
of later optimizations in both speed and quality.
Compile with the usual `./configure && make`
Command line example is examples/cwebp
Usage:
cwebp [options] -q quality input.png -o output.webp
where 'quality' is between 0 (poor) to 100 (very good).
Typical value is around 80.
More encoding options with 'cwebp -longhelp'
Change-Id: I577a94f6f622a0c44bdfa9daf1086ace89d45539
For very very short partitions, the initial GetByte() could
set eof_ to 1, whereas some bits were available but unread yet.
So we set eof_ to 0 last.
Change-Id: Ic6b68271bc72efa4de4e64e1f57307d1d8fb613c
by processing two rows at a time.
The [9 3 3 1] weights are decomposed as
[1 1 1 1] + [0 2 2 0] + [8 0 0 0] for better
reuse of sub-expressions, too.
Change-Id: I87ab549048ed249d38add73bb3241dfa0c583328
We only need to know _if_ there's some non-zero coeffs at all,
not the exact number of these.
+ code-style nits clean-up
Change-Id: Ice9acf00aef999d70affe4629cb56ae7709140ab
just flushing the pile:
- get rid of Put4 in dsp.c
- move LD4 enum value
- move more fields and code under the ONLY_KEYFRAME_CODE compile flag
- update test_ref.ppm reference (now with FANCY_UPSCALER)
- simplify VP8GetSignedValue()
- use HE and VE naming for prediction mode instead of H and V
- some missing c89 fixes
- code style nits
all test vectors still passing
not super-elegant, but should work without
having to go into deeper hacking (like: creating
an endian.h file, etc.)
Change-Id: I43100ec67a22393c87e11357078efffc750060f5
When FANCY_UPSCALING is defined, use a smoothing filter for upscaling
the U/V chroma fields. The filter used is a separable t[1 3 3 1] x [1 3 3 1]
filter. It can be easily changed in macros MIX_*.
The upscaling code reside on the thing shell between user and core
decoding (in webp.c), and not in the core decoder. As such, this smoothing
process can still be offloaded to GPU in some future and is not integral
part of the decoding process.
Coincidentaly: changed the way data is tranfered to user. For profile 2 (no
filtering), it used to be on a per-block basis. Now, for all profiles, we
emit rows of pixels (between 8 and 24 in height) when they are ready.
This makes the upscaling code much easier.
Will update the test vectors MD5 sums soon (as they'll be broken
after this change)
Change-Id: I2640ff12596cb8b843a4a376d7347447d9b9f778
nmake /F Makefile.vc9 cfg=release-static
objdir=h:\projects\webp\repo\build\libwebp ARCH=x64
given that you are in x64 mode, this command will build libwebp in
the <objdir>\release-static
Change-Id: I42e1849f5cdb7638db3b79d3658e2852d3969cc2
