DVK: Reducing 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.
What is the 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)
- 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 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.
Any user can easily create or change the existing parfiles because they are standard json files.
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:
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
-p STRING, --parfile=STRING
json file with distribution parameters (optional)
-s INT, --seed=INT seed for random generator (optional)
input YUV file bitdepth
output bitstream bitdepth
input YUV file chroma format
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:
--help output this message
--ext_trial=STRING extend trial with specified serial number
--activate=STRING activate by using specified serial number for single
--deactivate deactivate 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 —profile
- 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
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.
Types of streams:
- Syntax streams are low resolution bitstreams with a small number of frames which maximize coverage of each syntax element and cross-coverage of essential pairs. These streams are designed to test a certain 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 good 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 useful 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 a mature stage of the decoder design;
- Performance bitstreams test speed capabilities of the decoder’s hardware. They are good for final validation to proof compliance to the codec Level requirements;
- Error resilience subset includes not fully compliant bitstreams which test the decoder’s robustness to errors and ability to recover. They are good 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!