* commit '89a13998a1b5074411dff5a461dce3837057b0b8':
svq3: rip out the svq3-relevant parts of pred_motion() out of h264
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '527bf5f7c6890664b0f1dccd42397f4d204659fe':
svq3: move the pred mode variables to SVQ3Context
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit 'e481458bc308ee838deaeacac51929514762e7a7':
h264: factor out pred weight table parsing into a separate file
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '90ed6c5cf7f236bc9efb47c97b40358c666d1386':
h2645_parse: compute the actual data length, without trailing paddding
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '8229eff4b7a98ae5d85bb75f3bb072781b4a8ebe':
h2645_parse: add a function for uninitializing the packet
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Functionality used before didn't widen the values from limited to
full range. Additionally, now the decoder uses BT.709 where it
should be used according to the video resolution.
Default for not yet set colorimetry is BT.709 due to most observed
HDMV content being HD.
BT.709 coefficients were gathered from the first two parts of BT.709
to BT.2020 conversion guide in ARIB STD-B62 (Pt. 1, Chapter 6.2.2).
They were additionally confirmed by manually calculating values.
Fixes#4637
* commit 'cdb1665f70def544ddab3e3ed3763ef99c8b3873':
aarch64: Make transpose_4x4H do a regular transpose
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '159323897f545e7405fb9db234e0ba123e174376':
intrax8: Add a local BlockDSPContext and initialize it
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '8072345e9f86d88fbc4a15c17cb03f1e4701c9a5':
intrax8: Keep a reference to the GetBitContext reader
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '65f14128c4bcf8fcd9d3ba1e20b7a22057c9cfb0':
intrax8: Use a constant buffer instead of a ScratchpadContext
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit 'eaeba6f241e0de0e797be10f8fda967ef8489e64':
intrax8: Pass the output frame to the decoding function
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '577393321c389ad2973bec6168a8045c94a9e099':
intrax8: Carry over the loopfilter value in ff_intrax8_decode_picture
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '68127e1bf8037a6e0acd6401cc8c5da950e3fa0a':
intrax8: Keep a reference to the context idctdsp
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '65127450add50c3bca307edc0517d2e8382717a0':
intrax8: Make x8_init_block_index not use mpegvideo fields
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit 'a7da517f6a5c472f46f67dd33bb6b95ccc919923':
h264data: Move all data tables from a header to a .c file
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Until now, the decoding API was restricted to outputting 0 or 1 frames
per input packet. It also enforces a somewhat rigid dataflow in general.
This new API seeks to relax these restrictions by decoupling input and
output. Instead of doing a single call on each decode step, which may
consume the packet and may produce output, the new API requires the user
to send input first, and then ask for output.
For now, there are no codecs supporting this API. The API can work with
codecs using the old API, and most code added here is to make them
interoperate. The reverse is not possible, although for audio it might.
From Libav commit 05f66706d182eb0c36af54d72614bf4c33e957a9.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Fixes out of array read
Fixes: mozilla bug 1266129
Found-by: Tyson Smith
Tested-by: Tyson Smith
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
