Log inTry for free
< Back to blog

DVK: reducing the codec development costs (part 1)

#DVK#VVC#Encoder
Alexander Dydychkin
Written byAlexander Dydychkin

This article is a continuation of my previous articles about the codec industry's situation and what the DVK is, where I explathe 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.

DVK contains:

  • parfiles
  • random_encoder
  • streams
  • 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)

DVK package

Content of the usual VVC DVK package

Content description:

  • 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_encoder based 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 streams folder.

Parfiles

"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
  • Arrays: "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%.

Random encoder

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

Streams

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
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)

  • VVC
  • AV1
  • VP9
  • HEVC
  • AVS3

Conclusion

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!