- 28 Mar, 2016 30 commits
-
-
Anton Khirnov authored
-
Anton Khirnov authored
Instead of handling the problem inside NAL decoding code, add a higher level wrapper function. This should be more robust against future changes (and easier to read).
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
Use the SVQ3Context variable instead
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
Remove now unnecesary call to ff_h264_alloc_tables()
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
This will allow removing the H264Context dependency in the future.
-
Anton Khirnov authored
It is shared with svq3.
-
Anton Khirnov authored
This will allow removing the H264Context dependency in the future.
-
Anton Khirnov authored
This function depends on the h264 internals and is so tiny that just copying the code out is the simplest replacement.
-
Anton Khirnov authored
Stop using the H264Context ones, to allow removing the H264Context dependency.
-
Anton Khirnov authored
There is no need for them to be extern anymore.
-
Anton Khirnov authored
-
Anton Khirnov authored
The ~100 lines of shared code is not worth the pain of svq3 messing with h264 internals.
-
Anton Khirnov authored
This will allow decoupling the parser from the decoder.
-
Anton Khirnov authored
This is required by h264.
-
Anton Khirnov authored
-
Anton Khirnov authored
This should make it more clear that it is not supposed to be used for anything except logging.
-
Anton Khirnov authored
-
Anton Khirnov authored
This code will be shared with h264.
-
- 26 Mar, 2016 1 commit
-
-
Martin Storsjö authored
Previously, ff_h264_idct_add_neon (originally in the arm version) used a non-regular transpose in order to be able to use more instructions that deal with registers as 128 bit register pairs. The aarch64 translation doesn't do it to the same extent, but brought along the same structure since it was a straight translation. This reshuffles ff_h264_idct_add_neon, bringing it closer to the C implementation, making the transpose_4x4H macro do a regular transpose, usable for other algorithms as well. Previously, the third and fourth output from transpose_4x4H were swapped, and prior to cc29d96d, the same inputs as well. In addition to just swapping the outputs, also renumber the intermediate registers for better readability (making the register order match transpose_4x8B). This runs with the same number of cycles as before. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 25 Mar, 2016 9 commits
-
-
Ico Doornekamp authored
The problem is that the argument 'q' is of the type uint8_t. According to the JPEG standard, if 1 <= q <= 50, the scale factor 'S' should be 5000 / Q. Because the create_default_qtables() reuses the variable 'q' to store the result of this calculation, for small values of q < 19, q wil subsequently overflow and give wrong results in the calculated quantization tables. Instead, use a new variable 'S' (same name as in RFC2435) with the proper range to store the result of the division. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Vittorio Giovara authored
Helps in decoupling this code from mpegvideo.
-
Vittorio Giovara authored
It will be needed to initialize BlockDSP in the next commit.
-
Vittorio Giovara authored
Helps in decoupling this code from mpegvideo.
-
Vittorio Giovara authored
The size of the block is fixed (8x8 plus padding).
-
Vittorio Giovara authored
Helps in decoupling this code from mpegvideo.
-
Vittorio Giovara authored
Helps in decoupling this code from mpegvideo.
-
Vittorio Giovara authored
Use it instead of the embedded mpegvideo one. Update init function signature to load it directly from the callers.
-
Vittorio Giovara authored
-