Age | Commit message (Collapse) | Author |
|
Change-Id: I3f74418f07c2dfdd7725a5b4a8ef5c5f4aca6289
|
|
|
|
Change-Id: I79576920efb7f3f6f197d386727409759d8bda8d
|
|
https://gerrit.chromium.org/gerrit/#/c/70162/"
|
|
The final goal is eventually to get rid of both itxm_add and fwd_txm4x4.
This patch does it in the decoder.
Change-Id: Ibb3db57efbcbb1ac387c6742538a9fcf2c6f24a5
|
|
|
|
https://gerrit.chromium.org/gerrit/#/c/70162/
Change-Id: I797be6a4b21460de6d791125fc20d2be3a35364f
|
|
The current decode_tiles decodes the frame one tile by one tile
and then loopfilter the whole frame or use another worker thread to
do loopfiltering.
|------|------|------|------|
|Tile1-|Tile2-|Tile3-|Tile4-|
|------|------|------|------|
For example, if a tile video has one row and four cols, decode_tiles
will decode the Tile1, then Tile2, then Tile3, then Tile4.
And during decode each tile, decode_tile will decode row by row in
each tile.
For frame parallel decoding, decode_tiles will decode video in row order
across the tiles. So the order will be:
"Decode 1st row of Tile1" -> "Decode 1st row of Tile2"
-> "Decode 1st row of Tile3" -> "Decode 1st row of Tile4"
-> "Decode 2nd row of Tile1" -> "Decode 2nd row of Tile2"
-> "Decode 2nd row of Tile3" -> "Decode 2nd row of Tile4"-> "loopfilter 1st row"
Change-Id: I2211f9adc6d142fbf411d491031203cb8a6dbf6b
|
|
|
|
Change-Id: I9ef40f3d95ab8f94f69e92ea25678a40956bc1ce
|
|
vp9_decoder.c
vp9_dthread.c
Change-Id: Iaafe941545db98e9e3559096a955894646084ac2
|
|
|
|
This change is mainly for a follow CL that will refactor the
decode_tiles.
Change-Id: I52de6f8dbada75a64d9a94ebb5975136ed0960b4
|
|
Change-Id: I831fe91dfadf4e89f5bbba6ab7a9917d8dd2ed55
|
|
Change-Id: I0315cea6a5e58182bc2556e9825ec2ef0b1480c3
|
|
Change-Id: I7675f23150404913f4b457add69fb846f6921997
|
|
|
|
Inline loopfilter has been already handled in vp9_decode_frame().
Collecting all similar code in one place now.
Change-Id: I358a0280fc7c2b27cca520bc1e8c16c4eb6491dd
|
|
Change-Id: I910c437b80af90c50831e1fbff75842d4276a027
|
|
|
|
Fixes the idecoder in the case where:
cm->error_resilient_mode == 0, and
cm->frame_parallel_decoding_mode == 0, but
new_fb->corrupted == 1.
The assert in debug_check_frame_counts fails to
take into account the case of a corrupt frame.
Change-Id: Idf318a68458cc88d65d6f3f408a10d8ffe87e43f
|
|
We only used two members from that struct: max_threads and inv_tile_order.
Moving them directly to VP9Decoder struct.
Change-Id: If696a4e5b5b41868a55f3cc971e1d7c1dd9d5f69
|
|
|
|
Don't update the stats if we have a corrupted frame.
Change-Id: I65a13adc50e0389b4201d3b671f0225195dfaff4
TODO: Test case that shows this problem.
|
|
Change-Id: I6dc9741cdcd700f5c4a387f58da7feb58dd4bbda
|
|
That code is not used, we could easily return it back using vpx_img_write()
function.
Change-Id: Id107875c6feab6ad245a518f6b437b6ed4b1246d
|
|
Change-Id: I88f86c8ff9af34e0b6531028b691921b54c2fc48
|
|
Actually, it would be great to have two separate enums INTRA_MODES and
INTER_MODES in future.
Change-Id: I6c4147cf0002853da9c1e03fe9514eab876f01c8
|
|
Change-Id: I0f2592ecfc5197dfb94975260cb2f862315e7895
|
|
Change-Id: I9677aab1c7bb0ca9e989cb21348a3a2c926d8f5a
|
|
|
|
|
|
Change-Id: If33087462293605f79d9281af133091fff33a876
|
|
|
|
Change-Id: I039474b34863bc3db9c6cda82485c32826a1b5d1
|
|
This reverts commit 22a3e30790d141033778e430a47ba7d558237362
Change-Id: I460d905edf5fb2006da58c18fbe02c04d0c631bb
|
|
|
|
|
|
Change-Id: I7a5230852cb24ce22bfe85ea2608cdb4619b5200
|
|
|
|
|
|
Adds some high-level hooks for profile 2 before further
progress on the implementation.
According to the definitiion in this patch:
1. Profile 2 only supports 10 or 12 bit color but not 8
2. Profile 2 supports all color sampling modes: 444, 422 and 420,
and alpha plane.
3. Profile 3 is currently undefined.
Please consider the definition carefully and suggest modifications
to the definition as needed.
Change-Id: I5b284fc679e54ac5aee171af72fa7994cfd28995
|
|
There was a bug with the decoder that if you started the decoder
with more threads than the first frame had tile columns. Afterwards
tried to decode a frame with more tile columns than the first frame,
the decoder would hang. E.g. run vpxdec --threads=4. The first frame
had two tile columns, then the next key frame had 4 tile columns, the
decoder would hang. If you started with 4 tiles and switched to 2
tiles the decoder would be fine. The issue is that the worker the thread
loop is using is stale.
I added a test vector "vp90-2-14-resize-848x480-1280x720.webm" that
exhibited the bug.
Change-Id: I7bdd47241a52ac0fe1c693a609bc779257e94229
|
|
Change-Id: Ieb9b455b8aaef9884391021b7f640ef24c554687
|
|
Change-Id: Iad4002d7aecaae0e25d88e286bacde7e6cd7264f
|
|
Change-Id: Ib4e31ba74c4b882bd93942ef743f4a189892738d
|
|
|
|
No need to check pbi->common.frame_to_show again.
Change-Id: I572ea4afd0d8b6000c0bb7575b7023d75cad5a4e
|
|
Now interp_kernel is obtained when it is really required (based on
mbmi->interp_filter value).
Change-Id: I4c7a93c179d1045eba16e7526c293d02c9b8b47e
|
|
Change-Id: I88e018442c527cf21eac791f0768e805dda244f1
|