DVK: Reducing the codec development costs (part 1)
This article is a continuation of my previous articles about the codec industry's situation and what the DVK is, where I explain the usage of "helper tools", especially DVK. Here I want to clarify how DVK works with the focus on the streams and the encoder.
Part of VVC DVK cross-coverage report
Few words about DVK / What is DVK?
DVK is a bitstream and software toolchain for the Decoder IP design and compliance validation. It is a must-have tool for chip RTL design, target appliance integration (such as a smartphone, smart TV, Set Top Box), software stack verification before shipment to the customer. It is carefully structured to become as compact as possible, address maximum coverage and minimize validation time during the design process.
- analytic tools (will be explained in detail in a separate article)
Entire DVK workflow: from original yuv to coverage report
Workflow: how to use streams (usage case example)
Content of the usual VVC DVK package
- analytic tools — tools to review and visualize streams coverage (Win/Lin);
- coverage — html reports;
- decoder — reference and instrumented decoder, instrumented decoder needed to grab syntax coverage;
- docs — detailed documents how to use tools and technical description of the streams with detailed description which coding tools and value ranges are covered by each bitstream;
- encoder — special encoder
random_encoderbased on reference, which generates streams based on parfiles;
- parfiles — special configuration files which fully specify generated streams;
- streams — streams grouped by profiles and color spaces (or by customer request);
- yuv — VicueSoft source yuvs. User can use any yuvs he wants. It needs only to use the same file naming convention;
- readme.txt — contains basic package info and the changelog;
- vvc_cmds.txt — source cmds to reproduce generation of the delivered
"Parfiles" are special configuration files that fully specify generated streams. They give full description for the
random_encoder as to which syntax elements should be used in a particular stream; in other words, they enable certain video technologies and blocks of certain syntax elements, which are defined by the official specification of the codec.
Some parfiles for VVC streams, each focused on particular elements
Any user can easily create or change the existing parfiles because they are standard json files.
A part of the config file for VVC
Each syntax element name has the same naming as in the standard specification (or almost the same because there are rare cases when the committee renamed an element in the specification). The number of values is the same as in the specification too. How to manage the parfile?
Hard code element value:
"pred_mode_flag": 0,— enables inter flag
"pred_mode_flag": 1,— enables intra flag
Set up the distribution for the element:
"pps_init_qp_minus26": [-10,10],— enables uniform distribution for values from -10 to 10
"inter_pred_idc": [40,40,20],— the probability value for each element of the array, the first — 40%, the second — 40% and the last — 20%.
A random encoder is based on the reference encoder with the capability to read parfiles mentioned above to override encoding decisions.
The random encoder has some parameters, too, for example:
- bit depth
- chroma format
The help of random encoder for VVC VTM-13:
vvc_random_encoder.exe --help ViCue Decoder Validation Kit 0.13.0 for VVC VTM-13.0, sha1 274e8fc7705e567b9c9adbc69469d95bb8a70745 Copyright (c) 2019-2021, ViCue Soft LLC. All rights reserved. Usage: vvc_random_encoder.exe -i <input.yuv> -o <output.vvc> -w <width> -h <height> [-p <config.json> -s <seed> -r <reconstruct.yuv>] [-f <# of frames to process>]Options: -i STRING, --input=STRING input file (raw yuv) -o STRING, --output=STRING output vvc bitstream -w INT, --width=INT width of input yuv -h INT, --height=INT height of input yuv -f INT, --frames=INT number of frames to process -r STRING, --recon=STRING output file for encoder's reconstruct (optional) --store-input=STRING input file after possible bit-depth and chroma-format resampling (optional) -p STRING, --parfile=STRING json file with distribution parameters (optional) -s INT, --seed=INT seed for random generator (optional) --input-bitdepth=CHOICE input YUV file bitdepth --output-bitdepth=CHOICE output bitstream bitdepth --input-chromaformat=CHOICE input YUV file chroma format --output-chromaformat=CHOICE output bitstream chroma format. By default is the same as input chroma format --TraceFile=STRING tracing file --TraceRule=STRING tracing rule (format as in VVC software). Example: --TraceFile=trace.txt --TraceRule="D_CABAC,D_HEADER:poc>=0" --help output this message --ext_trial=STRING extend trial with specified serial number --activate=STRING activate by using a specified serial number for a single-user license --deactivate deactivate a single-user license
DVK has pre-generated streams based on all parfiles. They are immediately ready to use. Usually, they are sorted by profile, bit depth, and color format. Inside the folder, user can see the listing as below:
*.vvc — stream;
*.vvc.ccstats.json — raw data needed to grab cross-coverage by analytic tools (it will be described in a separate article);
*.vvc.rec.yuv.md5 — md5 sum of reconstruct for the user’s check;
*.vvc.stats.csv — used elements statistics also needed for the analytic tools. What does naming of the stream mean? Let’s explain on the basis of the file VVC_Main10_8b400_24x72_transform_lfnst_cbf_00_v0.13.0.vvc:
VVC_Main10_8b400_24x72_transform_lfnst_cbf_00_v0.13.0.vvc — codec
VVC_Main10_8b400_24x72_transform_lfnst_cbf_00_v0.13.0.vvc — bit depth
VVC_Main10_8b400_24x72_transform_lfnst_cbf_00_v0.13.0.vvc — color space
VVC_Main10_8b400_24x72_transform_lfnst_cbf_00_v0.13.0.vvc — resolution
VVC_Main10_8b400_24x72_transform_lfnst_cbf_00_v0.13.0.vvc — parfile name on the basis of which this stream is generated
VVC_Main10_8b400_24x72_transform_lfnst_cbf_00_v0.13.0.vvc —version of the codec standard
Part of VVC main10–8bit-400 streams
Also, each DVK's "Syntax" stream is focused on a particular syntax element or block defined by the official codec specification. They are very small. This approach speeds up the testing process.
Parfile for a particular block
A "Syntax" stream generated from the parfile above. See? It is very focused, only 17kB!
Types of streams: - Syntax streams are low-resolution bitstreams with a small number of frames that maximize coverage of each syntax element and cross-coverage of essential pairs. These streams are designed to test a specific subset of features, for example, all the intra-prediction modes or all loop-filter-related parameters. One stream tests the smallest possible coding block in the decoder, allowing an independent design of each block. This type of streams is suitable for the initial RTL design; - Stress bitstreams are extended from the pool of Syntax streams with higher resolution and a larger number of frames. Stress streams include all the features covered by the bucket, so they are helpful for smoke testing: if a decoder passes the Stress stream, it is likely to pass all the Syntax streams from the bucket. Stress streams are good for the mature stage of the decoder design; - Performance bitstreams test speed capabilities of the decoder’s hardware. They are good for final validation to prove compliance with the codec Level requirements; - Error resilience subset includes not fully compliant bitstreams, which test the decoder's robustness to errors and recovery ability. They are suitable for final validation to deliver a viable end-user product.
DVK-supported codecs (2021)
The DVK's overview is finished in this article. The following article will be dedicated to analytic tools. So the user of the DVK package can:
- use streams for CI/validation testing purposes;
- use streams for the compliance check
- use them for debug of the decoder;
- edit or create new streams with the help of the random encoder;
- analyze and create syntax&code coverage reports on any set of streams (from DVK or any other source) or optimize a set of streams with the help of analytic tools.
DVK improves the efficiency of codec testing by doing it "smarter" and improving its execution speed. As a bonus, it offers instruments for reviewing and optimizing the syntax/code coverage.
PS: Of course, each stream can be reviewed and analyzed in VQ Analyzer!