summaryrefslogtreecommitdiff
path: root/libhwjpeg
AgeCommit message (Collapse)Author
2023-04-10Fix formatting when _FILE_OFFSET_BITS=64Colin Cross
_FILE_OFFSET_BITS=64 can change off_t to be larger than a long. Cast to intmax_t and print with %jd or switch to ptrdiff_t and print with %td. Bug: 275601166 Test: builds Change-Id: I011cc53f108aaa7f773b0d09511728864f602429
2023-03-09libhwjpeg: allow writing APP2 segment in EXIFMichelle Yang
Bug: 269280197 Test: atest liblyric.controllers_jpeg_compressor_whi_jpeg_compressor_test Change-Id: Iec4217f56a9f34296893ac19a3e03651fd5c676e
2023-03-06libhwjpeg: Add advisory lockMichelle Yang
Libhwjpeg is not thread safe. This can generally be worked around via a mutex managed by the caller. However, if multiple processes use libhwjpeg, an exclusive lock managed by the library is necessary to ensure that all operations required to configure & encode an image is completed together. Bug: 269642082 Test: m libhwjpeg Change-Id: If805a79ac7c3290cd224c862f258c56fc3d8958f
2023-02-28libhwjpeg: fix formattingMichelle Yang
Ran formatter over files. Whitespace changes only. Bug: 265156558 Test: m libhwjpeg Change-Id: Ie12eea3fbba1a5dce31f0d823aa0968faf08a274
2023-02-27libhwjpeg: include videodev2.h headerMichelle Yang
Test: m libhwjpeg Bug: 265156558 Change-Id: If7ab5e1185c4486d703a2bd1181a8d3c7dffc2d4
2023-02-07libhwjpeg: Fix out of bounds readMichelle Yang
Bug: 253425396 Test: m libhwjpeg Change-Id: Id60053e21c2b30e68bf7c763810bbbe94f4c5a46
2023-01-25libhwjpeg: add support for setting custom horizontal padding per planeMichelle Yang
Input buffers may already have horizontal padding applied (see ImageFormat.YV12 for example). pa/2371678 and pa/2375202 adds functionality to set horizontal padding in pixels through VIDIOC_S_EXT_CTRLS. This CL updates V4L2 library. Bug: 265156559 Test: checked output image when applying ag/20576841 Change-Id: I432dcdfd4103222c7df10c7a974ab2ebd0afbbfd
2022-11-10Add google_hal_headers to exported headersMichelle Yang
Test: m libhwjpeg Bug: 257084044 Change-Id: Iebcdbffecde6d808a051fca05f96b2694deaff71
2021-03-02Convert libhwjpeg to Android.bp.Krzysztof Kosiński
Required to reference the library from Lyric code, as Soong->Make dependencies are not supported. Bug: 167426135 Test: m libhwjpeg Change-Id: I1566af1858650e5b67d4750fb05c236947f484a3
2021-03-01[LSC] Add LOCAL_LICENSE_KINDS to hardware/google/graphics/commonBob Badour
Added SPDX-license-identifier-Apache-2.0 to: Android.bp libacryl/Android.bp libacryl/Android.mk libgscaler/Android.mk libhwc2.1/Android.mk libhwjpeg/Android.mk libion/Android.bp libion/test/Android.bp libmemtrack/Android.mk libscaler/Android.mk libv4l2/Android.mk Bug: 68860345 Bug: 151177513 Bug: 151953481 Test: m all Exempt-From-Owner-Approval: janitorial work Change-Id: I0a3746b35fd8d476ae1a51ef89b27c6797e51de9
2020-05-14libhwjpeg: move thunbmail scaler messageCho KyongHo
Showing "Thumbnail scaler is not available. No thumbnail is embedded" every encoding causes misreading. So move the message to the constructor. Bug: 156553294 Signed-off-by: Cho KyongHo <pullip.cho@samsung.com> Change-Id: I15f4cfdbcf329269946a154a6936a3f7f04c9b13
2020-03-05libhwjpeg: know earlier about thumbnail scalerCho KyongHo
If thumbnail scaler is not available due to some problem with configuration or file system, libhwjpeg handles the problem after starting compression but we know that before compression. If it is found before processing EXIF, we can gracefully handle the exception. Signed-off-by: Cho KyongHo <pullip.cho@samsung.com> Change-Id: I7844216c672f7b3aafc790758088487a0a20a5b0
2020-02-20libhwjpeg: use buffer length given by the scaler driverSeungchul Kim
Whne libhwjpeg uses v4l2 sclaer, libhwjpeg uses buffer length of src&dst buffer given by the scaler driver Change-Id: Ic314c7e7fe3030af89b8eda9a9e57d5bb3826395 Signed-off-by: Seungchul Kim <sc377.kim@samsung.com>
2020-02-20libhwjpeg: fix incorrect name to v4l2 portsCho KyongHo
Change-Id: Ib7d7c150581c516385006ba788845484ee65eaf7 Signed-off-by: Cho KyongHo <pullip.cho@samsung.com>
2020-02-20libhwjpeg: fix stop streaming before reqbufs(0)Cho KyongHo
Change-Id: I2e3d54b12441b9645112f487ff888f2bcdbff09e Signed-off-by: Cho KyongHo <pullip.cho@samsung.com>
2020-02-20libhwjpeg: introduce polymorphic thumbnail scalerCho KyongHo
LibScalerForJpeg is the only thumbnail scaler implemented with the legacy V4L2 MSCL driver. But we may need to use another types of thumbnail scaler that runs with different H/W or different API. Therefore abstract calss, ThumbnailScaler is introduced and the concrete object of the thumbnail scaler is created with ThumbnailScaler::createInstance(). All the implementation details and differences between products are handled in createInstance(). Change-Id: Ibef2693ca6ea9e23f8993c9e525e58ac54a22333 Signed-off-by: Cho KyongHo <pullip.cho@samsung.com>
2020-02-20libhwjpeg: add device object for thunbmail scalerCho KyongHo
Redundancies in LibScalerForJpeg is introduced by repeated calls to V4L2 API. Device class provides simple functions that replaces V4L2 API for LibScalerForJpeg and hides redudancies. Change-Id: Ic56b157e61617a6f34a312dfac7eedbfa6c4b635 Signed-off-by: Cho KyongHo <pullip.cho@samsung.com>
2020-02-20libhwjpeg: use buffer size instead of payloadCho KyongHo
ExynosJpegEncoderForCamera has the lengths of mage buffers to LibScalerForJpeg but it does not get informed about the lengths. Instead LibScalerForJpeg feeds VIDIOC_QBUF the required payloads of images studied by VIDOC_S_FMT as the buffer length which is not the length of the buffer. Change-Id: Id51f3a6e4f701fdb5f33bf84d17045448ab5f97a Signed-off-by: Cho KyongHo <pullip.cho@samsung.com>
2020-02-20libhwjpeg: delegate qbuf to each portCho KyongHo
If v4l2_buffer instances are the members of LibScalerForJpeg, it is hard to understand where each field of the instances is initialized. So, it had better allocate a v4l2_buffer instance in the stack and initialze it everytime we need to call V4L2_QBUF and V4L2_DQBUF. This change introduces extra overhead for initializing all fields of the instance but makes LibScalerForJpeg simpler. The overhead is very small compared to the overhead by other tasks performed by LibScalerForJpeg. Change-Id: Icb13c16f0f880ecd572d3461a2b71dcb321d1fb8 Signed-off-by: Cho KyongHo <pullip.cho@samsung.com>
2020-02-20libhwjpeg: delegate driver init to each portCho KyongHo
V4L2 API call sequence in LibScalerForJpeg is deviced by the APIs for both of the ports including output and capture: s_fmt(output) & s_fmt(capture) -> reqbufs(output) & reqbufs(capture) -> qbuf(output) & qbuf(capture) -> dqbuf(output) & dqbuf(capture). But LibScalerForJpeg should revert the success of an API call for output if the following the same API call for capture is failed for the next try. Now we can choose the better way: (s_fmt(output)->reqbufs(output))&(s_fmt(capture)->reqbufs(capture)) -> qbuf(output) & qbuf(capture) We do not need to revert an API call for output even though its following API call for capture.o We also moved parameters of LibScalerForJpeg::Set[Src|Dst]Image() about image buffers to LibScalerForJpeg::RunStream() because image dimension and format seldom change while buffers can be changed every frame. This change helps the better design. We do not need to hold the buffer information confirued by LibScalerForJpeg::Set[Src|Dst]Image() until LibScalerForJpeg::RunStream() is called. Change-Id: I4af0750975068b22055c1c2eafc53ce76d366479 Signed-off-by: Cho KyongHo <pullip.cho@samsung.com>
2020-02-20libhwjpeg: refactor format handling in LibScalerCho KyongHo
LibScalerForJpeg stores the last format setting in v4l2_format structures which are member variables of LibScalerForJpeg class. v4l2_format is very huge structure and keeping it as a member variable just for buffer size and buffer count is just a waste of space. Change-Id: I8aef5a95bc6e9d64aaf6b509ab8df29966424ca4 Signed-off-by: Cho KyongHo <pullip.cho@samsung.com>
2020-02-20libhwjpeg: refactor Set[Src|Dst]Image()Cho KyongHo
The LibScalerForJpeg is the thumbnail image generator for libhwjpeg and the image and buffer types to LibScalerForJpeg does not vary. Unnecessary flexibility increases the complexity of a module. So, we should discard the support for userptr in SetDstImage(). In addition, LibScalerForJpeg requires unnecessary type casting to libhwjpeg for SetSrcImage and SetDstImage for the historical reasion. However, it is no longer needed because we can decide our API now. Change-Id: Ie8eebc38bf4f09889cc001e673f128570fb642c1 Signed-off-by: Cho KyongHo <pullip.cho@samsung.com>
2020-02-20libhwjpeg: remove redundant debug logCho KyongHo
SC_LOGD(...) is redundant definition. Instead we should use ALOGD. However, the only remained use of SC_LOGD is just printinig simple success on a API function call which is not informative. Change-Id: I7579c3815d6caa52bd20826c7ca7d3acb2732c50 Signed-off-by: Cho KyongHo <pullip.cho@samsung.com>
2020-02-20libhwjpeg: change the order of quantization tableCho KyongHo
ExynosJpegEncoder::setQuality() allows users to specify two quantization tables for Luma and Chroma planes. It requires the quantizers in the talble shoud be specified in raster-scan order when it is first instroduced because it is natural to human. But CHWJpegCompressor::SetQuality() requires the quantization table to be specified in zigzag scan order because it is natural to the people familiar with HWJPEG and the JPEG specifications (ITU-t81). The DQT in JPEG also specifies the quantizers in zig-zag scan order. Now we decided to change the arrangement of quantizers to ExynosJpegEncoder::setQuality() not to confuse the users of libhwjpeg. Both ExynosJpegEncoder::setQuality() and CHWJpegCompressor::SetQuality() now need the quantizers to be specified in zig-zag scan order. Change-Id: I284f36d9dcc1f5af0dec92fdc0e1a3430e09e3a2 Signed-off-by: Cho KyongHo <pullip.cho@samsung.com>
2020-02-20libhwjpeg: support the multiple APPX segmentsSeungchul Kim
libhwjpeg is modified to support the multiple APPX segments. For example, libhwjpeg can now update the multiple APP4 segments to the JPEG file. Change-Id: If494db0ba54a885469a161651198e08e9a41ab66 Signed-off-by: Seungchul Kim <sc377.kim@samsung.com>
2020-02-20libhwjpeg: fix APP1 size calculationCho KyongHo
libhwjpeg calculate the length of APP1 before writing data to resereve the space for embedded thumbnail jpeg. However the calcluation logic does not consider the data that can be stored in both of offset field and separate data area. For example, if an ASCII entry has 3-byte data, it should be written in offset field. The size of the field and its data should be 12 bytes but libhwjpeg treats it as 15 bytes which consists of 12-byte entry and 3-byte data written after its IFD. If the calculation is not correct, libhwjpeg consequently updates the length of APP1 segment incorrectly by CAppMarkerWriter::UpdateAPP1Size(). Change-Id: I661a208ae415aa53150c93d8f0bb1204c38f9e92 Signed-off-by: Cho KyongHo <pullip.cho@samsung.com>
2020-01-30Fix include path for videodev2{,_exynos_media}.hDaniel Mentz
The UAPI headers videodev2.h and videodev2_exynos_media.h are located under linux/. Change-Id: Icb8e5aec8d7643ca5bd146e7e0cdd01686e361fc
2019-09-18Add initial source codeHyunKyung Kim
Change-Id: I285a55c44c9fd5d3a8abaa781ef9dc8d9d39f53a Signed-off-by: HyunKyung Kim <hk310.kim@samsung.com>
generated by cgit v1.2.3 (git 2.25.1) at 2025-10-03 05:49:05 +0000