Issue is introduced when user configs log2_max_frm_num.
1. use MppEncH264HwCfg instead of hw_poc_type.
2. slice_write can only use corresponding hardware config.
Signed-off-by: xueman.ruan <xueman.ruan@rock-chips.com>
Change-Id: Id5f3622512075eedc1e9dc99636c3f0dff43d6f1
Add prepare function to hal interface.
NOTE: The hal prepare function is the hal hook on user control.
When user config is changed hal can process some cfg before enc_impl
updated the config through syntax in task.
Also when encoder is in low delay mode the user control should not be
processed if the current frame is not finished.
Change-Id: Ie287e05daff0d139cf04d93d97246fa176d14d53
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
1. Add MppDev output for all encoder.
2. Update HalInfo to MppDev on each header update.
Change-Id: I8fce811dda7232740042917c9738bc11253ee672
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
1. Move sps / pps / slice / dpb definition to there own header.
2. Prepare to add new h264e syntax struct for hal.
Change-Id: I95e884afcf08fa51bdeb6f1e6571c264d9a609ec
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Fix stride definition to compatible to both pixel stride and byte
stride.
In MPI the stride is defined to byte stride. But vepu requires 8 pixel
aligned pixel stride.
So we add more code to adapt to both case and check 8 pixel alignment.
From opengles definition:
Stride means bytes in a row of pixels including padding. So an image
could be 510 pixels in width and rounded up to 512 pixels. The stride
would be 512 * bit depth of the image's format. You could also have
stride in pixels in which case the stride would be 512 pixels
Pitch is a little more vague, but typically could be interchangeable
with stride. Considering your reference is specifying in bytes, it's
likely safe to assume they're not measuring in pixels. So the reference
likely means the number of bytes in a row + padding, the only
alternative would be number of bytes without padding e.g. image width *
bit depth.
Change-Id: I20acf71e2a6bea2eb08b41fe7df531154ebef897
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
vepu h264 input stride must be aligned to 8 for vepu limitation.
If it is not 8 aligned some buffer conversion preprocess should be done
before the buffer is sent encoder.
1. The hor_stride in vepu hardware is in pixel unit not byte unit.
2. The hor_stride in vepu must be 8 pixels aligned.
3. The YUV420P should be 16 pixels aligned for chroma.
4. Fix log print when hor_stride != width 8align
Change-Id: If30136a4673399c3be40a41a055e832db4c321d5
Signed-off-by: sayon.chen <sayon.chen@rock-chips.com>
1. Prefix nal is setup in h264e_api and send to hal by syntax.
2. Hal receives prefix config and writes prefix nal before each slice.
3. Add vepu1 / vepu2 prefix implement. vepu541 is not implemented yet.
4. Add max temporal layer id check to enable prefix nal.
Change-Id: I8bc40af12b9d9cedd64c1aa6a2666d3ffe7bf694
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
New reference frame config interface will be added.
Change-Id: I5766cefde12237561bbc20c905e47ed2d3e90011
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
1. hw_length should be only updated by hardware real stream length.
2. hw_length can be updated multi-times by slice encoding.
3. When reenc found the hw_length should be subtracted from total task
stream length.
Change-Id: I1c3f6affcc5dc90ad548a42efed0237c60b98f08
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Hardware output stream length includes the 64-bit header aligned length.
So we need to subtract aligned length to get the real hardware length.
Change-Id: I78f16afa02bc4428613cafcca9b8bde9241ba997
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
On kernel 4.19 the send registers and recv registers can be different.
But due to compatibility kernel 4.4 the register copy is needed.
Change-Id: I1af7bbf8c27671627bda1679283693ec7eb4b0b5
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
1. Update OSD palette config API. User must specify palette is default
or user defined.
2. OSD palette config will go through control and OSD data (region)
config will go through meta data in each frame.
3. Remove unused code.
4. Add mpi_enc_utils for mpi_enc_test cases
Change-Id: Ib4aeb60789a3e999446212841508e604533efb3c
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
1. Add mpp_rc_api and mpp_rc_defs for open rc module to external users.
2. Add RcImplApi registration and setup function.
3. Separate RC module from the encoder implement.
4. Use EncFrmStatus and EncRcTaskInfo to control work flow.
5. proc_rc and update_rc function in enc_impl are removed.
6. Use rc_frm_start and rc_hal_start to process rate control.
7. Add more RcCfg setup in mpp_enc_v2.cpp.
8. Use rc_task to replace all the frame status and rc config transmit.
EncFrmStatus is for encoder flow control.
EncRcTaskInfo is for communication between rc / hal / hardware
Change-Id: Ia72b0e0804bfca13963c2b2a5887983fd9b5bcbf
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Signed-off-by: sayon.chen <sayon.chen@rock-chips.com>
When user does not use GET_EXTRA_INFO to get encoded header stream the
encoder should add the header stream before the hardware output stream.
NOTE: Only vepu2 is fixed.
Change-Id: Idf5c07127ef68bb6553f9fb6550f993f3a29ea63
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
1. Move mpp_rc_api.h to rc_api.h
2. Add rc base module from mpp_rc.
3. Add rc api and empty rc model.
RC module design:
Rate control is a highly user defined module. So we perfer to open the
interface and let users add their frame-level rate control model.
In order to limit the user behavior the API input and output is
restricted. User can use the provide rc base components to define their
own model.
Change-Id: I72c251e7807f675e973bc80ea55683cd57070b00
Signed-off-by: sayon.chen <sayon.chen@rock-chips.com>
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
New hal api will change interface to the following functions:
1. get_task - receive one task from encoder and process hw rate control.
2. gen_regs - generate register set according to different hardware.
3. start - start the hardwara.
4. wait - wait hardware process one task.
5. ret_task - return the processed task back to encoder.
NOTE: change some function to v2 to avoid linker conflict.
NOTE: vepu2_v2 status
1. Add svc and gop ref implement.
2. Without rc config. The QP is fixed.
Change-Id: I5fa890e8e23c0abbc5abb5ce44111c8a10ea1817
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
