Search Results for "JVET-AE0180"
Found 9 document(s)
Search documents
Use number, keyword, author, or MPEG number. Filter by meeting when needed.
Not signed in yet.
Abstract
This document provides an ECM SW memory consumption analysis. It also proposes a straightforward non-normative ECM SW modification that losslessly reduces ECM memory consumption worst case for about 2 GiB under CTC.
Loading full meeting notes...
JVET-AE0180 On ECM SW memory consumption [R. Chernyak, S. Liu (Tencent), Y. Yasugi, T. Ikai (Sharp)]
This document provides an ECM SW memory consumption analysis. It also proposes a straightforward non-normative ECM SW modification that losslessly reduces ECM memory consumption worst case for about 2 GiB under CTC.
It was found that larger memory is consumed by covariance matrices in ALF, and memory allocation for wraparound MC, even if the latter is not used in the ECM CTC.
It was commented that this is a step in the right direction, but much more effort would be necessary for reduction of memory consumption. It was further suggested that it would be good if proponents would be enforced to report (in the excel sheet) the additional memory consumption of the proposal.
One expert commented that covariance matrices consume a maximum which is lower than reported here.
It was commented that a similar analysis for decoder would also be useful.
Decision (SW): Adopt the change of unnecessary memory allocation for wraparound MC in cases where the tool is disabled (for ECM, and to the discretion of SW coordinators to also be implemented in VTM and NNVC).
It was further agreed that reporting the additional memory usage of a new element proposed will be made mandatory (e.g., by adding a corresponding column to the excel sheet). It is understood that this is purely informative and not meant as a mechanism to reject a proposal, but rather identify newly added elements that cause excessive additional memory consumption, such that a solution for possible reduction can be sought by a...
Cited:
Decisions
It was commented that a similar output for the decoder would be desirable, which would require an implementation in the ECM.
Citation
Abstract
This document reports the crosschecking results of JVET-AE0180. Results over ECM-9.0 are crosschecked. Available partial results show that BD-rate points perfectly matched with the results provided from the proponents. Significant ECM SW memory reduction is observed.
Loading full meeting notes...
JVET-AE0192 Crosscheck JVET-AE0180 (On ECM SW memory consumption) [C.-W. Kuo, X. Xiu (Kwai)] [late]
References:
Decisions
JVET-AE0192 Crosscheck JVET-AE0180 (On ECM SW memory consumption) [C.-W. Kuo, X. Xiu (Kwai)] [late]
Citation
Abstract
This report summarizes the activities of the AhG3 on Test model software development that has taken place between the 31st and 32nd JVET meetings.
Loading full meeting notes...
JVET-AF0003 JVET AHG report: Test model software development (AHG3) [F. Bossen, X. Li, K. Sühring (co-chairs), E. François, Y. He, K. Sharman, V. Seregin, A. Tourapis (vice chairs)]
The software model versions prior to the start of the meeting were:
- VTM 22.0 (Sept. 2023)
- HM-18.0 (Apr. 2023)
- HM-16.21+SCM-8.8 (Mar. 2020)
- SHM 12.4 (Jan. 2018)
- HTM 16.3 (Jul. 2018)
- JM 19.1 (Apr. 2023)
- JSVM 9.19.15
- JMVC 8.5
- 3DV ATM 15.0 (no version history)
- HDRTools 0.24 (March 2023)
Software for MFC and MFCD is only available as published by ITU-T and ISO/IEC. It is planned to create repositories with the latest versions available in ITU-T H.264.2 (02/2016). All development history is lost.
Software development
Development was continued on the GitLab server, which allows participants to register accounts and use a distributed development workflow based on git.
The server is located at:
https://vcgit.hhi.fraunhofer.de
The registration and development workflow are documented at:
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/wikis/VVC-Software-Development-Workflow
Although the development process is described in the context of the VTM software, it can be applied to all other software projects hosted on the GitLab server as well.
VTM related activities
The VTM software can be found at
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/
The software development continued on the GitLab server. VTM versions 20.1 and 20.2 were tagged on May 8, and VTM version 21.0 was tagged on Jul. 9. VTM 21.1 is expected during the 31st JVET meeting.
VTM 21.1 was tagged on July 21, 2023. Changes include:
- JVET-AD0057...
ARCHIVE
:
._.DS_Store
._HM-18.0_VTM-22.0_HDR_idc.xlsm
._JVET-AF0003-v1.docx
._VTM-21.0_vs_VTM-22.0_HDR_idc.xlsm
._VTM-21.2_vs_VTM-22.0.xlsm
._VTM-22.0_vs_VTM-21.0_RExt_HighBitDepth.xlsm
.DS_Store
HM-18.0_VTM-22.0_HDR_idc.xlsm
JVET-AF0003-v1.docx
VTM-21.0_vs_VTM-22.0_HDR_idc.xlsm
VTM-21.2_vs_VTM-22.0.xlsm
VTM-22.0_vs_VTM-21.0_RExt_HighBitDepth.xlsm
Decisions
The software coordinators expressed thanks to experts who diligently delivered implementations of HLS related software in a timely fashion.
Citation
Abstract
This report summarizes the activities of the AHG14 on NNVC software development that have taken place between the 31st and 32nd JVET meetings.
Loading full meeting notes...
JVET-AF0014 JVET AHG report: NNVC software development (AHG14) [F. Galpin (chair), Y. Li, Y. Li, J. Shingala, L. Wang, Z. Xie (vice chairs)]
Software development
Location
NNVC repository is located at https://vcgit.hhi.fraunhofer.de/jvet-ahg-nnvc/VVCSoftware_VTM
NNVC software is based on VTM-11.0 with enabled MCTF including the update from JVET-V0056, GOP32, and enabling deblocking in the RDO.
NNVC-6.0 anchor at https://vcgit.hhi.fraunhofer.de/jvet-ahg-nnvc/VVCSoftware_VTM is used for NNVC performance evaluation.
Software changes
Several commits were merged in the NNVC repository.
The following changes were integrated:
HOP related
JVET-AE0191 HOP models
JVET-AE0289 HOP stage 3 training process
JVET-AE0291 HOP stage 3 dataset
JVET-AE0214 SADL v6
clarify documentation
naive quantization script
fixes:
training hyper-parameters
3 issues related to residual scaling in HOP (available in NNVC-6...
Decisions
merged
The AHG recommended to:
Continue to develop NNVC software.
Improve the software documentation.
Encourage people to report all (potential) bugs that they are finding using GitLab Issues functionality https://vcgit.hhi.fraunhofer.de/jvet-ahg-nnvc/VVCSoftware_VTM/-/issues
Encourage people to submit merge requests fixing identified bugs.
It was commented that at some point it might again be useful to test combinations of ECM and NNVC tools.
Project development (23)
Citation
Abstract
This document contains the draft text for changes under consideration for future extensions to the versatile supplemental enhancement information messages for coded video bitstreams (VSEI) standard (Rec. ITU-T H.274 | ISO/IEC 23002-7) to modify existing SEI messages or specify additional SEI messages.
Loading full meeting notes...
JVET-AE2032 Technologies under consideration for future extensions of VSEI (draft 1)
The following 7 documents were produced as WG 5 documents only:
WG 5 N 217 Request for ISO/IEC 14496-10 11th edition
WG 5 N 219 Disposition of comments received on ISO/IEC 23002-7:2022 DAM 1
WG 5 N 220 Text of ISO/IEC FDIS 23002-7:202x Versatile supplemental enhancement information messages for coded video bitstreams (3rd edition)
WG 5 N 222 Disposition of comments received on ISO/IEC CDTR 23002-9
WG 5 N 225 Request for ISO/IEC 23008-2:202x/Amd.1
WG 5 N 227 Disposition of comments received on ISO/IEC 23090-3:2022 DAM 1
WG 5 N 228 Text of ISO/IEC FDIS 23090-3:202x Versatile video coding (3rd edition)
The following 5 draft revised ITU-T Recommendations were forwarded by JVET and Q6/16 for ITU-T Consent:
TD169/Plen ITU-T H.265 (V9) "High efficiency video coding" (Rev.)
TD171/Plen ITU-T H.266 (V3) "Versatile...
Decisions
As a primary goal, the JVET meeting reviewed the work that was performed in the interim period since the thirtieth JVET meeting in producing the following documents:
The meeting was closed at 1215 CEST on 2023-07-19.
Citation
Abstract
This document defines common test conditions and software reference configurations for testing of enhanced compression tools beyond VVC. These conditions and configurations are recommended for use in applicable technical contributions to JVET meetings.
Loading full meeting notes...
JVET-AE2017 Common test conditions and evaluation procedures for enhanced compression tool testing
JVET-AE2017 Common test conditions and evaluation procedures for enhanced compression tool testing [M. Karczewicz, Y. Ye] (2023-08-04)
This is to include a modified Excel sheet, and mention the requirement of documenting memory consumption (see discussion under JVET-AE0180).
Remains valid – not updated: JVET-AA2018 Common test conditions for high bit depth and high bit rate video coding [A. Browne, T. Ikai, D. Rusanovskyy, X. Xiu, Y. Yu]
Decisions
JVET-AE2017 Common test conditions and evaluation procedures for enhanced compression tool testing
Remains valid – not updated: JVET-AA2018 Common test conditions for high bit depth and high bit rate video coding [A. Browne, T. Ikai, D. Rusanovskyy, X. Xiu, Y. Yu]
Citation
Abstract
This report summarizes the activities of the AHG7 on ECM tool assessment that has taken place between the 30th and 31th JVET meetings.
Loading full meeting notes...
JVET-AE0007 JVET AHG report: ECM tool assessment (AHG7) [X. Li (chair), L.-F. Chen, Z. Deng, J. Gan, E. François, H.-J. Jhu, X. Li, H. Wang (vice-chairs)]
Group off tests
Test settings and crosschecking
Based on the discussion in the previous meeting, the same four groups were used in this meeting cycle.
Group 1: Inter template matching tools
Group 2: Coding tools that interleave the (merge/skip/AMVP/subblock/IBC/etc) list derivation with the intra prediction/reconstruction process
Group 3: Intra and IBC template matching (with search) related tools
Group 4: Tools that require more processing on the neighbouring reconstructed samples than VVC
Accordingly, five group-off tests were performed and crosschecked on top of ECM-9.1. The two anchors are ECM 9.0 and VTM-11ECM9.0. The cfg files used are also attached with this AHG report.
The testers and crosscheckers are summarized in the table b...
ARCHIVE
:
ECM-9-vs-VTM-11ecm9-vs-ECM-8.1.xlsm
ECM-9-vs-VTM-11ecm9-vs-ECM-9.1-g1-4off.xlsm
ECM-9-vs-VTM-11ecm9-vs-ECM-9.1-g1off.xlsm
ECM-9-vs-VTM-11ecm9-vs-ECM-9.1-g2off.xlsm
ECM-9-vs-VTM-11ecm9-vs-ECM-9.1-g3off.xlsm
ECM-9-vs-VTM-11ecm9-vs-ECM-9.1-g4off.xlsm
ECM-9-vs-VTM-11ecm9-vs-ECM-9.1.xlsm
JVET-AE0007_v1.docx
offgroup1-4.cfg
offgroup1.cfg
offgroup2.cfg
offgroup3.cfg
offgroup4.cfg
summary.xlsx
xCheck-ECM-9-vs-VTM-11ecm9-vs-ECM-9.0-3f6ca8e0-off-g1.xlsm
xCheck-ECM-9-vs-VTM-11ecm9-vs-ECM-9.0-3f6ca8e0-off-g1234.xlsm
xCheck-ECM-9-vs-VTM-11ecm9-vs-ECM-9.0-3f6ca8e0-off-g2.xlsm
xCheck-ECM-9-vs-VTM-11ecm9-vs-ECM-9.0-3f6ca8e0-off-g3.xlsm
xCheck-ECM-9-vs-VTM-11ecm9-vs-ECM-9.0-3f6ca8e0-off-g4.xlsm
xCheck2-ECM-9-vs-VTM-11ecm9-vs-ECM-9.0-3f6ca8e0-off-g1234.xlsm
Decisions
The AHG recommended to:
Continue and improve tool assessment
Report memory usage ratio in the ECM CTC spread sheet, as suggested in the BoG report in JVET-AD0401
Resolve identified software issues related to the tool assessment
Review all the input contributions
It was commented that recording the run times with two digits after decimal point may not be useful in assessing complexity.
Citation
Abstract
This document reports the work of the JVET ad hoc group on enhanced compression beyond VVC capability (AHG12) between the 30th meeting in Antalya, TR, 21–28 April 2023, and the 31st meeting in Geneva, CH, 11–19 July 2023.
Loading full meeting notes...
JVET-AE0012 JVET AHG report: Enhanced compression beyond VVC capability (AHG12) [M. Karczewicz, Y. Ye, L. Zhang (co-chairs), B. Bross, R. Chernyak, X. Li, K. Naser, H. Yang (vice-chairs)]
Activities
The Common Test Conditions were updated (JVET-AD2017). The run time precision in the reporting template has been increased to 1 digit after decimal point. The primary activity of the AHG was the “Exploration experiment on enhanced compression beyond VVC capability” (JVET-ACD024). The combined improvements of the ECM-9.0 over VTM-11.0ecm8.0 anchor for AI, RA and LB configurations are:
All Intra Main 10
Y
U
V
EncT
DecT
Class A1
-9.67%
-21.16%
-28.19%
827.7%
406.4%
Class A2
-15.77%
-27.44%
-30.55%
813.4%
405.9%
Class B
-10.06%
-25.61%
-23.82%
773.3%
423.4%
Class C
-10.27%
-15.86%
-16.33%
783.1%
442.4%
Class E
-13.65%
-23.55%
-22.06%
759.1%
481.4%
Overall
-11.59%
-22.66%
-23.71%
788.5%
430.8%
Cla...
Decisions
The AHG recommended to:
To review all the related contributions.
It was pointed out that the gain gap between luma and chroma became again larger with ECM 9. It was however asserted to be careful shifting gain from chroma to luma without careful study, e.g. in terms of visual impact and rate dependency.
Citation
Abstract
In the current GDR design in VVC/ECM [1,2], an initial refreshed area starts on the left of a GDR picture and gradually expends over the associated recovering pictures. The most meaningful content information of a video sequence, however, may not necessarily always be in the left part of pictures. This contribution proposes a flexible GDR, where an initial refreshed area can be in any location in a GDR picture. To support such flexible GDR, each virtual boundary in GDR/recovering picture is assigned a flag (new syntax element), specifying which side of the virtual boundary is in refreshed area. The proposed flexible GDR is implemented in ECM-9.0. Simulations were conducted for the flexible GDR with an initial refreshed area starting from the left, the middle and the center of GDR pictures. The middle/center GDR present interesting content information much earlier than the left GDR. The overall BD rate of the middle/center GDR over the left GDR are x% and y%, respectively.
Loading full meeting notes...
JVET-AE0145 AHG 12: Flexible GDR [L. Wang, S. Hong, K. Panusopone (Nokia)]
In the current GDR design in VVC/ECM, an initial refreshed area starts on the left of a GDR picture and gradually expends over the associated recovering pictures. The most meaningful content information of a video sequence, however, may not necessarily always be in the left part of pictures. This contribution proposes a flexible GDR, where an initial refreshed area can be in any location in a GDR picture. To support such flexible GDR, each virtual boundary in GDR/recovering picture is assigned a flag (new syntax element), specifying which side of the virtual boundary is in refreshed area. The proposed flexible GDR is implemented in ECM-9.0. Simulations were conducted for the flexible GDR with an initial refreshed area starting from the left, the middle and the center of GDR pictures. The middle/center GDR present...
Cited:
Decisions
No action was taken on this.
Citation