Performance Analysis of Optimized Versatile Video Coding Software Decoders on Embedded Platforms

Anup Saha, Wassim Hamidouche, Miguel Chavarrías, Guillaume Gautier, Fernando Pescador, Senior Member, IEEE,, Ibrahim Farhat
Anup Saha, Miguel Chavarrías and Fernando Pescador were with CITSEM at Universidad Politécnica de Madrid, Madrid, Spain, e-mail: (anup.saha; miguel.chavarrias<EMAIL_ADDRESS>
Wassim Hamidouche, Guillaume Gautier and Ibrahim Farhat were with Univ. Rennes, INSA Rennes, CNRS, IETR - UMR 6164, Rennes, France, e-mail: (wassim.hamidouche; guillaume.gautier<EMAIL_ADDRESS>This work was supported by both the Energy Efficient Enhanced Media Streaming (3EMS) project funded by the Brittany Region and TALENT project (PID2020-116417RB-C41), funded by the Spanish Ministerio de Ciencia y Innovación.

IEEE Transactions on Consumer Electronics, paper under review
Shell et al.: Bare Demo of IEEEtran.cls for IEEE Journals

In recent years, the global demand for high-resolution videos and the emergence of new multimedia applications have created the need for a new video coding standard. Hence, in July 2020 the vvc standard was released providing up to 50% bit-rate saving for the same video quality compared to its predecessor hevc. However, this bit-rate saving comes at the cost of a high computational complexity, particularly for live applications and on resource-constraint embedded devices. This paper presents two optimized vvc software decoders, named OpenVVC and vvdec, designed for low resources platforms. They exploit optimization techniques such as data level parallelism using simd instructions and functional level parallelism using frame, tile and slice-based parallelisms. Furthermore, a comparison in terms of decoding run time, energy and memory consumption between the two decoders is presented while targeting two different resource-constraint embedded devices. The results showed that both decoders achieve real-time decoding of fhd  resolution over the first platform using 8 cores and hd real-time decoding for the second platform using only 4 cores with comparable results in terms of average consumed energy: around 26 J and 15 J for the 8 cores and 4 cores platforms, respectively. Regarding the memory usage, OpenVVC showed better results with less average maximum memory consumed during run time compared to VVdeC.

VVC, SIMD, embedded systems, decoder, multicore, real-time.

§ INTRODUCTION

Anew era of information and communication technologies is emerging, where video communication plays an essential role in internet traffic. In particular, the significant increase in video traffic supported by the COVID19 global health situation and the emerging video formats and applications have lead to the development of a new video coding standard, named vvc/H.266. This latter was standardized in July 2020 by the jvet of the VCEG working group of ITU-T and the MPEG working group of ISO/IEC JTC 1/SC 29 [1]. vvc enables bit-rate savings of up to 50% [2] with respect to the previous standard hevc/H.265 [3] for the same video quality. However, this achievement comes at the cost of $10\times$ and $2\times$ more complexity compared to hevc for the encoder and decoder contexts, respectively [4]. In this scenario, the main challenge is to develop real-time vvc codecs that take into account resource-constrained consumer devices frequently used in consumer electronics based on embedded platforms.

Each coding standard is released with a reference software implementation available for the scientific community. These solutions incorporate all the basic features of the standard but offer a very limited speed performance. In the case of vvc, the reference software is the vtm [5]. Taking this as a starting point, research groups and companies develop their own real time software and hardware solutions. Depending on the targeted architecture, these solutions mainly exploit the intrinsic parallelism of the algorithms, both at the data and functional levels, to enhance their performance in terms of speed and energy consumption. In the first case, some data operations included in the source code are optimized by using simd type instructions [6]. Here, vectorized operations are used to perform mathematical operations with more than one operator using a single processor instruction. The other potential optimisation route is to take advantage of the intrinsic parallelism of independent processing of pictures [7], or smaller parts of the picture, such as slices [8] or tiles [9]. In the latter case, it is necessary that the coding is done by activating these normative tools that break dependencies between adjacent regions.

In this work, two open source vvc decoders are presented and compared against each other. These solutions, named OpenVVC [12, 11] and vvdec [13] decoders, are optimized using data and functional level parallelism techniques. In this paper, we evaluate their performance in terms of decoding run time, power consumption and memory usage targeting two different embedded platforms. The results showed that both decoders have achieved 15 to 34 fps for uhd sequences with qp 27 and 37, and achieved real-time decoding of fhd and hd sequences over the first target platform using 8 cores. Furthermore, 16 to 28 fps have been obtained for fhd sequences with qps 27 and 37, and real-time  decoding has been reached for all hd sequences by OpenVVC and vvdec when targeting the second embedded platform with 4 cores. In terms of energy consumption and maximum memory usage, the experimental results showed that vvdec has consumed $\times 2$ more memory with respect to the consumption of OpenVVC over both target platforms. On the other hand, OpenVVC consumed the same energy as vvdec on the esoc1 platform with 8 cores and around 1.25$\times$ vvdec's energy consumption when targeting esoc2 embedded platform with 4 cores.

The rest of the paper is structured as follows. Section <ref> give a short introduction to the vvc standard. Section <ref> describes the optimizations included in the vvc decoders using specific parallelization techniques along with the state-of-the-art of vvc decoders. Section <ref> details the proposed optimizations techniques included in the OpenVVC decoder. The obtained results and comparison between OpenVVC and vvdec performance are provided in Section <ref>. Finally, Section <ref> concludes the paper.

§ INTRODUCTION TO VVC

Similar to its predecessors, vvc was designed based upon a hybrid coding scheme using intra/inter-prediction coding and transform coding. In Figure <ref>, the decoding process scheme of vvc is presented. Here, the encoded bit-stream is the input, the decoded video is the output, and each decoding phase is presented by one block.

§.§ Entropy decoding
Bit-stream decoding begins with this process integrated with similar but advanced cabac [14] with respect to hevc. Here, an updated multihypothesis probability estimation model was adapted and the computed look-up table was eliminated for enhancing the accuracy. The coefficient coding has been improved by allowing 1$\times$16, 2$\times$8, 8$\times$2, 2$\times$4, 4$\times$2, and 16$\times$1 coefficients group size for transform block size.

Block diagram of a vvc decoder.

§.§ Inverse quantization and transform

The spatial domain coefficients are retrieved from the frequency domain by inverse quantization and inverse transformation. vvc introduces mts [15] tool used to encode the residual inter and intra coding blocks. mts allows three transforms of the rectangle blocks with the height and width of $\leq64$ for dct-II, $\leq32$ for dct-VIII and dst-VII. Moreover, the coefficients of high frequency are zeroed when the height and or width is equal to 64 for dct-II and 32 for dct-VIII and dst-VII. In addition, lfnst [16] is used on the low frequency coefficients of the transform domain after dct-II for further signal decorrelation.

§.§ Intra prediction

In vvc intra-prediction module, 32 additional directional intra-prediction modes were added with respect to hevc. Moreover, it allows a wide-angle intra modes for rectangular blocks, which improves the prediction accuracy. In addition, the matrix weighted intra-prediction tool was used a new intra prediction mode by taking above and left neighbouring lines of the prediction block. Besides, vvc adapted cross-component linear model [17] tool, which applied to the prediction of chroma components from the luma components.

§.§ Inter prediction

Inter-prediction takes advantage of the temporal redundancy of the video by removing the correlation in the temporal domain [18]. Here, the motion compensation estimates the current coding unit samples according to the samples recorded in the decoded picture buffer. In addition, 8-tap filter is used to luma samples for creating motion-compensated prediction and 4-tap filter is used to chroma samples for interpolation [19]. Furthermore, vvc achieved improved prediction accuracy using decoder-side motion vector refinement[20] and bi-directional optical flow prediction refinement [21].

§.§ Luma mapping with chroma scaling

Forward lmcs is a new tool introduced in vvc and comes after inter-prediction stage. It has two parts: lmp, used to modify luma predicted samples, and csp, used to modify chroma residues. lmp makes the most use of the range of luma code values and provides an efficient reallocating process of luma code values in the coding domain. Therefore, csp changes the value of the chroma residual samples in the chroma coding block for mitigating the defect coming from the interaction between luma and luma corresponding chroma signals [22].

§.§ In-loop Filters

vvc in-loop filters consist of inverse ilmcs [23], df, sao filter and alf. First, ilmcs is a new addition to vvc which enhances the decoding performance by inverse mapping the luma code to the reconstructed block. df and sao in vvc are very similar to hevc [24]. df is used to detect and filter the artifacts of the pixels at the block boundaries and sao is used to minimize sample distortion over the pixels filtered by df. In addition, unlike hevc, vvc includes alf [23] for reducing mean-squared error of the decoded pixels. Therefore, undesired artifacts obtained by the previous decoding modules including blurring, blocking, flickering, ringing, and colour shift are mitigated using in-loop filters and the decoded video is obtained.

§ OPTIMIZED AND REAL TIME SOFTWARE DECODERS

There are three levels of parallelism that can be exploited to speedup the video decoding process: data-level, frame-level and high-level. In this section we first describe these three levels of parallelism, then we give a brief description of existing optimised decoders with an introduction to the recent software and real time vvc decoders including OpenVVC and vvdec.

§.§ Task level parallelism

§.§.§ Single instruction multiple data

simd is a data-level parallel processing technique that loads multiple data in single register to operate with. The x86-based architectures offer sse and avx based simd intrinsics. egpp based platforms support ARM Neon suite instead of sse and avx based simd intrinsic. ARM Neon is an advanced simd technology designed for mobile devices that support up to 128-bit register. Neon-based simd technology can be used following 4 ways [25]: a) using Neon intrinsics, b) Neon-enabled libraries, c) compiler auto-vectorization, and d) hand-coded Neon assembler.

§.§.§ Frame-level parallelism

Simultaneous processing of multi-frames is performed in frame-level parallelism while dependencies of the motion compensation are also satisfied. The length of the motion vector is, in this case, the deterministic factor [8]. Video sequences with large motion would imply large dependencies between frames which may create a major disadvantage for frame-level parallelism. Hence, sequences in all intra configuration are the most benefited by frame-level parallelism due to the fact that there are no motion compensation dependencies. Moreover, in frame-level parallelism, additional picture buffer and local buffers should be stored for each thread used to decode in parallel. As a result, it demands higher memory than sequential decoding.

§.§ High level parallelism

§.§.§ Wave-front parallel processing

wpp allows virtual picture partitioning into ctu rows [8]. In wpp, the coding dependency is kept unchanged during the picture partitioning while the entropy engine is initialized at the start of each ctu line. Therefore, at the beginning of each ctu row, the cabac context is re-intialized and it depends at least on the data from first ctu of the previous row. As a result, the decoding of rows could not completed at the same time and slightly limits parallelisation efficiency of wpp.

§.§.§ Tiles parallelism

vvc supports tiles of rectangular shape consisting of ctus [26]. An example of tile partition is shown in Fig. <ref>. Here, four tiles are labelled with A, B, C, and D. Tiles are separated by boundaries, which eliminates the prediction dependencies. Therefore, for all the tiles, the entropy encoding step is reinitialized, which allows to decode tiles independently. It allows decoding a picture concurrently using multiple threads. However, the in-loop filtering process can only be carried out at the tile boundaries when pixels are reconstructed from both sides.

Illustration of tile partitioning in VVC decoder.

§.§ Codec optimisations

Various parallelization methods have been used to accelerate video codecs on cpu, gpu, and combination of both based architectures. Yan et al. accelerated a hevc decoder by $\times4$ compared to HM 4.0 using simd technologies over a x86 processor in [27]. Authors in [28] and [29] proposed gpu-based implementation of hevc that satisfied real-time requirements for the decoding of uhd 4k sequences. S. Gudumas et al. in [8] discussed various optimization techniques to implement vvc using multiple cpu cores on heterogeneous platforms with the purpose of achieving real-time decoding [8]. Here, the decoding tasks were redesigned and parallelized with task parallelization based on load balancing and data parallelization, at the level of ctu. The authors in [30] presented a gpu-based motion compensation system to accelerate the vvc decoder that exploits the partition of the different cu and proper thread organisation. Furthermore, Wieckowski et al. in [2] described an optimized vvc decoder that achieved real-time decoding on general purpose cpus. Here, simd operations-based optimisation and multi-threading based optimisation were adapted. The authors in [31] demonstrated an optimized real-time vvc decoder that takes advantage of simd instruction extensions on x86 based cpu. Moreover, the authors discussed the implementation of frame, ctu, sub-ctu, and task level parallelization. An optimized vvc software decoder on mobile platforms is presented in [18],. The presented decoder was generated from vtm-11.0 reference software. Here, the decoder achieved real-time decoding for HD video sequences using simd and multi-threading on ARM [24] based platform.

There are a handful of software open-source decoders available that are compliant with the vvc standard. Firstly, the already mentioned reference vvc test model, or vtm. Secondly, vvdec [13], an implementation proposed by Fraunhofer Institute, is an optimized decoder based on vtm. It includes simd and multi-threads parallelisation for an optimal performance. Thirdly, O266dec [32], a real time decoder proposed by Tencent Media Lab. O266dec also uses the simd and multithreading parallelisation techniques. Unfortunately this decoder has not been updated in the last 14 months. Finally, OpenVVC is a lightweight open source software decoder that is available in [11]. It is designed to target different operating systems and hardware architectures. Similar to vvdec and O266dec, OpenVVC uses data and functional level parallelism to optimize the decoding performance. For more details on vvc codecs, Sullivan
[10] provides a complete list of available vvc encoder and decoder implementations.

§.§.§ Introduction to OpenVVC

OpenVVC is an open source software vvc decoder written in C programming language. It is compiled as a cross-platform library and is compatible with most-used operating systems and optimized for x86 and ARM processors. The last version of the decoder is compliant with vvc Main profile. In addition, it is integrated with VLC [33], GPAC [34], and FFplay [35] video players. OpenVVC provides high decoding speed by using as little memory as possible. It exploits tiles and frames paralelization based on multi-CPU cores, and simd optimisations for accelerating the decoding process. The decoding process of OpenVVC starts by parsing the parameters of the sequence. Therefore, reconstruction tasks consisting of tx, lmcs, ep and ip decoding blocks, are performed at the cu level. Then, df is performed immediately after the reconstruction process is completed at the level of ctu. This approach helps to optimize memory usage by avoiding massive storage of quantization parameter map and cu dimension that is essential for the df process. Finally, alf is applied after the sao at the level of ctu line and this process delivers the decoded frame as output.

§.§.§ Introduction to Versatile Video Decoder

vvdec [13] is an open source software vvc decoder optimized for x86 architectures and developed by Fraunhofer Institute for Telecommunications, Heinrich Hertz Institute, HHI. Unlike OpenVVC, vvdec has been developed from vtm reference software [36]. It supports vvc Main 10 profile and it is capable to decode all conformance vvc bitstreams [37]. In addition, vvdec comes with simd optimisations and multi-threading parallelisation over x86 architectures. The parallelisation of vvdec decoding begins by parsing multiple frames concurrently. Therefore, in the reconstruction process, tasks are split based on ctu lines and ctus. Here, a stage is given to each ctu for tracking the following stage and process tasks in parallel after the dependencies are satisfied. It allows task coordination where a task worker is assigned to each ctu. Task workers are scanned by a thread-pool for assigning the available task. vvdec has achieved decoding time reduction up to 90% [2] with respect to vtm.

§ DECODER OPTIMIZATIONS

This section describes the implementation of frames, tiles, and Neon-based simd parallelisms in OpenVVC over egpp-based platforms.

§.§ Frames and Tiles parallelization in OpenVVC

In frame-level parallelism of OpenVVC, a main thread is used to parse the psp, sps, picture/slice header and schedule decoding threads with a thread pool. Then, the main thread provides the data and updates the internal structure of the available threads in the thread-pool for decoding the frame. Therefore, motion compensation synchronisation between threads is performed for sequences with inter-coding configuration after starting the decoding process. In fact, this latter is the most challenging step in frame-level parallelism, where the available thread has to wait for motion compensation before starting the pixels processing. When pixels are ready, the available thread is able to perform the decoding process. This process is applied at the ctu line level since OpenVVC performs decoding and in-loop filtering at ctu line basis. Once the decoding process is completed, the decoding threads signal their availability to the main thread and return to the thread-pool.

On the other hand, tiles level parallelism is applied at a portion of a frame. In fact, every frame is decomposed into rectangular regions of the picture containing multiple ctu [26]. The main challenge of tile level parallelism is that tiles could have different run time complexities. Therefore, the time required to finish one frame is the time to finish the longest tile. In this case, at a certain processing time, some threads are free, without a task, waiting to finish processing the current frame. For more details about this issue, a quality-driven dynamic frame partitioning for efficient parallel processing is explained by Amestoy et al. in [38]. A dynamic tile and rectangular slice partitioning solution enables the best partitioning configuration that minimizes the trade-off between multi-thread encoding time and quality loss. This is performed by taking into account both spatial texture of the content and encoding times of previously encoded frames. Experiments prove that the proposed solution, compared to uniform partitioning, significantly decreases multi-thread encoding time, with slightly better quality.

The proposed solution integrated in OpenVVC aims to efficiently activating all threads at all times. In order to do so, it applies thread pipelining technique that overlooks frames and focuses only on tiles. Figure <ref> illustrates tile pipelining. The tile partitioning forms a 2$\times$2 grid. They are labeled  A, B, C and D for the first frame and A', B', C' and D' for the second frame and delimited by the thicker black lines. Prediction dependencies across tile boundaries are broken and entropy encoding state is reinitialized for each tile. These restrictions ensure that tiles are independently decoded, allowing several threads to decode simultaneously the same picture. As it can be observed, regardless of the tile position, as soon as a thread is available from the thread pool, the tile is processed. Thread 2 for example does not work on any tiles of the second frame since it took the entire time working on tile D of the first frame. This fact does not restraint threads 0 and 1 from working on the tiles of the second frame. However, adopting this technique creates some sort of a combination between frame and tile parallelism, as a result, dependencies between frames for inter prediction and motion compensation should be taken into account. This latter is handled by OpenVVC. Moreover, since OpenVVC processes tiles independently of their frame affiliation, tile size and load optimization at the encoder side do not actually impact the performance of OpenVVC. At the end, tiles are pipelined regardless of their size or load without waiting to finish processing the current frame.

Illustration of tile pipelining in OpenVVC decoder.

§.§ SIMD optimisation in OpenVVC

In this study, ARM Neon-based simd optimisations were adapted to accelerate OpenVVC targeting egpp-based platforms. First, the x86 architecture-based simd intrinsics used in OpenVCC are replaced by the ARM Neon-based simd intrinsics. Therefore, additional adjustment was adapted due to the fact that Neon-based intrinsics are not as powerful and complete as compared to sse or avx intrinsics. In particular, for some cases, one simd instruction for x86-based was replaced with multiple Neon-based simd instructions. For instance, two Neon intrinsics vmull_s16 for multiply operation and vpaddq_s32 for add operation are needed to replace madd_epi16.

esocs used in this study support up to 128-bit simd registers. A 128-bit register can be loaded with 16 8-bit, 8 16-bit, 4 32-bit, or 2 64-bit data. This fact allows concurrent data processing to achieve a theoretical speedup of up to $\times16$ on 8-bit data. In this study, Neon-based simd instructions are used to optimize the high computational demanding vvc decoder modules presented in Table <ref> by adapting the simd [39] library. Here, dst-VII, dct-II, dct-VIII, inter-component transform and lfnst module of tx block of vvc decoder was accelerated using simd registers. tx involves several matrix operations including matrix multiplication for the inverse transformations. These matrix operations were tackled using simd intrinsics based on logical and mathematical operations: vand, veor, vadd, and vmul. The most benefiting modules of ep block by simd parallelisation are luma 8-tap filters, chroma 4-tap filters, bi-directional optical flow, decoder side motion vector refinement, and prediction refinement with optical flow. These functions contain various mathematical and clipping operations which were handled by vadd, vsub, vmin, and vmax instructions. In addition, loading and storing data in larger simd registers helped to accelerate ep, because the prediction information of the pixels is needed multiple times in different ep functions. Then, the pixel prediction inside the picture of ip block was effectively managed by storing masks, clipped, and offset value using simd intrinsics. Further, the edge and band filter of sao use vceq, vadd, and vsub instructions to handle mathematical operations. Finally, alf filters are parallelized by concurrently storing filter parameters using shuffle intrinsic. Moreover, it exploits the full capacity of simd register of 128 bit using load and store intrinsic instructions.

Main functions optimized with simd.

vvc Block                                                                      1cModule
3*TX                                                            DST-VII, DCT-II, DCT-VIII

Inter-component transform

Low-frequency non-separable transform
5*IP                                                            Luma 8-tap filters

Chroma 4-tap filters

Bi-directional optical flow

Decoder side motion vector refinement

Prediction refinement with optical flow
3*EP                                                            DC, Planar

Cross-component linear model

Matrix-based intra prediction module
filters     Edge and band filter of SAO

ALF 7$\times$7 diamond shape filters for the luma component

ALF 5$\times$5 diamond shape filters for the chroma component

Block classification of ALF

§ EXPERIMENTAL RESULTS

In this section, the experimental setup, test bench used in this study and the experimental results obtained are presented for two open source optimized decoders vvdec V1.3 and OpenVVC V1.0 on two egpp-based embedded platforms.

§.§ Experimental Setup

This study focuses on low-cost mobile embedded heterogeneous platforms. Therefore, two esoc platforms, esoc1 [40] and esoc2 [41] have been used. esoc1 processor consists of eight egpp cores running with a maximum clock speed of 2.26 GHz and 512 embedded gpu (Egpu) cores running with a maximum clock speed of 1.37 GHz. In addition, esoc1 has 8MB of L2 cache memory, 4MB of L3 cache memory and 32GB 256-Bit random access memory with 137 GB/s speed. esoc2 has 4 egpp cores and 128 Egpu cores running with a maximum clock speed of 1.48GHz and 0.92GHz, respectively. Moreover, it has 2MB L2 cache memory and 4MB 64 bit random access memory with 25.6 GB/s speed. This work is only based on egpp cores and gpu cores could be used in future works to further speedup the decoder. In both platforms a gcc compiler version 7.5 with -O3 flag activated and Cmake version 3.16.5 have been used alongside an Ubuntu 18.04 operating system.

§.§ Test video sequences

Table <ref> presents the different features of the fifteen jvet common test sequences [42] used in this study. The following sequences, grouped by resolution classes, have been encoded by the vtm-11.0 reference software with 10-bit random access and $3\times3$ tile configuration at two qp 27 and 37. Three hd sequences from class E are used: FourPeople, Johnny, and KristenAndSara alongside six fhd sequences of class B: MarketPlace, RitualDance, Cactus, BasketballDrive, BQTerrace, and ArenaOfValor. We also considered six uhd sequences from class A1: Tango2, FoodMarket4, and Campfire and class A2: CatRobot1, DaylightRoad2, and ParkRunning3.

Features of the considered vvc test sequences.

Class                   Sequence     Resolution       # Frames     Bitdepth     Framerate
3*A1     Tango2          3840$\times$2160     294     10    60

FoodMarket4          3840$\times$2160     300     10    60

Campfire          3840$\times$2160     300     10    30
3*A2     CatRobot1          3840$\times$2160     300     10    60

DaylightRoad2          3840$\times$2160     300     10    60

ParkRunning3          3840$\times$2160     300     10    50
6*B      MarketPlace          1920$\times$1080     300     10    60

RitualDance          1920$\times$1080     300     10    60

Cactus          1920$\times$1080     300     10    50

BasketballDrive          1920$\times$1080     300     10    50

BQTerrace          1920$\times$1080     300     10    60

ArenaOfValor          1920$\times$1080     300     10    60
3*E      FourPeople          1280$\times$720      300     10    60

Johnny          1280$\times$720      300     10    60

KristenAndSara          1280$\times$720      300     10    60

§.§ Results and analyses

Since this study focuses on analysing the decoding performance over embedded platforms, the average energy consumption and the maximum memory usage have been also measured. To do so,  two open source optimized vvc decoders: vvdec and OpenVVC over the two already mentioned platforms have been used.

§.§.§ Decoding performance

Firstly, the decoding performance of OpenVVC has been studied for four combinations of frame-tile parallelization by taking advantage of the 8 physical cores integrated in the esoc1 architecture:

* 1-frame and 8-tile per frame in parallel (f1/t8).

* 2-frame and 4-tile per frame in parallel (f2/t4).

* 4-frame and 2-tile per frame in parallel (f4/t2).

* 2-frame and 8-tile per frame in parallel (f2/t8).

This study has been performed to do a fair comparison between the best configuration of OpenVVC and VVdeC.

Fig.<ref> shows the average decoding performance in frames per second (fps) for HD and FHD test sequences with QP27 and QP37 on ESoC1 using OpenVVC decoder.

[   title=ESoC1,
ymin=0, ymax=430,

grid style=dashed,
ylabel=Decoding frame rate (fps),ylabel style=xshift=-60pt,yshift=-15pt,anchor=west,
xlabel=Threading configuration,
tick label style=font=,
bar width=7pt,

legend style=at=(0.5,-0.36),
anchor=north,legend columns=-1,

symbolic x coords=f1/t8, f2/t4, f4/t2, f2/t8,
nodes near coords,
every node near coord/.append style=rotate=90, xshift=0cm, yshift=0cm, anchor=west,font=,
nodes near coords align=vertical,
coordinates (f1/t8, 202.1) (f2/t4, 243.1) (f4/t2, 258.1) (f2/t8, 219.4);
coordinates (f1/t8, 242.5) (f2/t4, 293.3) (f4/t2, 308.5) (f2/t8, 264.0);
coordinates (f1/t8, 75.5) (f2/t4, 99.2) (f4/t2, 106.4) (f2/t8, 89.6);
coordinates (f1/t8, 79.7) (f2/t4, 104.8) (f4/t2, 111.3) (f2/t8, 94.0);

HD-QP27, HD-QP37, FHD-QP27, FHD-QP37

Average decoding performance (fps) of OpenVVC for QP 27 and 37 sequences on the ESoC1 platform.

It can be seen from Fig.<ref> that the least performing configuration is f1/t8 and the best performing configuration is f4/t2 for all qps, hd, and fhd sequences. f4/t2 configuration has achieved in average $\times 1.4$ and $\times 1.3$ fps compared to the f1/t8 configuration for fhd and hd sequences, respectively.
These results mainly illustrate the gain brought considering both frame and tile parallelism compared to only frame parallelism which is constrained by the inter coding dependency.

Fig.<ref> presents the average decoding performance in fps obtained over esoc2 for hd sequences using both qps. esoc2 has four physical cores. For this reason, only three combinations of frame-title parallelization have been studied:

* 1-frame and 4-tile per frame in parallel (f1/t4).

* 2-frame and 2-tile per frame in parallel (f2/t2).

* 2-frame and 4-tile per frame in parallel (f2/t4).

[   title=ESoC2,
ymin=0, ymax=100,

grid style=dashed,
ylabel=Decoding frame rate (fps),ylabel style=xshift=-60pt,yshift=-15pt,anchor=west,
xlabel=Thread configuration,
tick label style=font=,

legend style=at=(0.5,-0.36),
anchor=north,legend columns=-1,
symbolic x coords=f1/t4, f2/t2, f2/t4,
nodes near coords,
every node near coord/.append style=rotate=90, xshift=0cm, yshift=0cm, anchor=west,font=,
nodes near coords align=vertical,
coordinates (f1/t4, 55.6) (f2/t2, 62.6) (f2/t4, 59.7);
coordinates (f1/t4, 65.2) (f2/t2, 74.5) (f2/t4, 70.6);

HD-QP27, HD-QP37

Average decoding performance (fps) of the OpenVVC decoder for QPs 27 and 37 sequences on the ESoC2 platform.

In this case, and as shown in Fig.<ref>, the f2/t2 configuration has achieved 62.6 fps for qp27 and 74.5 fps for qp37, which is higher in average by  8.1 fps and 3.4 fps than f1/t4 and f2/t4 configurations for hd sequences, respectively.

The decoding performance and speedup of vvdec and f4/t2 configuration of OpenVVC decoders for qps 27 and 37 over esoc1 are presented in Table <ref> for all considered video sequences. It can be seen that the obtained decoding speed by both vvdec and OpenVVC decoders are close to real-time for uhd sequences and achieve real-time for all fhd and hd sequences over esoc1 using 8 cores. Therefore, the experiment for fhd and hd sequences are presented in the following part of this study that achieves real-time over esoc1. Moreover, it can be noticed that vvdec has obtained slightly better fps than OpenVVC on single core configuration for all sequences at different quantification parameters QPs. However, speedup shows that OpenVVC has provided better parallelism compared to vvdec when the number of threads has increased, which compensates the first limitation.

Decoding performance (fps) for the considered test sequences at QP27 (top) and QP37 (bottom) on the ESoC1 platform with 1, 2, 4, 6 and 8 cores.

Seq.:QP        5c|VVdeC (fps)/speedup          5cOpenVVC (fps)/speedup
# cores     1        2         4         6         8         1        2         4         6         8
Tango2:27         3.3/1.0      6.3/1.9       12.4/3.8      18.1/5.6      22.8/7.0      3.1/1.0      6.1/2.0       12.1/3.9      17.9/5.8      22.7/7.4

FoodMarket4:27         3.3/1.0      5.9/1.8       12.4/3.8      18.2/5.6      23.0/7.0      3.0/1.0      6.1/2.0       12.0/4.0      17.6/5.8      22.6/7.5

Campfire:27         3.7/1.0      6.8/1.9     13.6/3.7      19.5/5.3      24.0/6.5      3.5/1.0     7.5/2.1       14.7/4.2      21.7/6.2      27.3/7.8

Average         3.4/1.0     6.4/1.9      12.8/3.8      18.6/5.5     23.3/6.8     3.2/1.0    6.6/2.0    12.9/4.0    19.0/6.0    24.2/7.6
CatRobot1:27         3.3/1.0      6.4/1.9       12.7/3.8      18.5/5.5      23.3/7.0      3.2/1.0      6.3/2.0     12.4/3.9      18.1/5.7      22.9/7.2

DaylightRoad2:27         3.1/1.0      6.0/1.9       11.7/3.8      17.2/5.5      21.5/7.0      2.8/1.0      5.7/2.0       11.2/4.0      16.4/5.9      20.9/7.5

ParkRunning3:27         2.4/1.0      4.3/1.8       8.5/3.6       12.4/5.2      15.7/6.7      2.1/1.0      4.1/2.0       8.1/3.9       11.9/5.7      15.1/7.3

Average          2.9/1.0     5.6/1.9      11.0/3.7      16.0/5.5     20.2/6.9     2.7/1.0    5.3/2.0    10.5/3.9    15.5/5.8    19.7/7.3
MarketPlace:27         12.5/1.0     23.8/1.9      46.0/3.7      66.5/5.3      82.7/6.6      11.1/1.0     21.8/2.0      43.2/3.9      63.3/5.7      79.6/7.2

RitualDance:27         13.9/1.0     26.3/1.9      51.3/3.7      73.2/5.2      91.0/6.5      13.0/1.0     25.2/1.9      49.8/3.8      73.7/5.7      90.4/7.0

Cactus:27         16.6/1.0     30.7/1.8      59.0/3.6      85.1/5.1      103.0/6.2     15.4/1.0     29.6/1.9      57.9/3.8      82.6/5.4      94.3/6.1

BasketballDrive:27       12.2/1.0     22.5/1.8      43.7/3.6      63.5/5.2      77.5/6.4      11.1/1.0     21.5/1.9      42.8/3.9      63.2/5.7      79.6/7.2

BQTerrace:27         12.9/1.0     24.3/1.9      47.4/3.7      68.7/5.3      82.6/6.4      11.7/1.0     23.1/2.0      45.7/3.9      67.4/5.8      85.2/7.3

ArenaOfValor:27         15.5/1.0     28.5/1.8      55.0/3.6      79.2/5.1      96.8/6.3      14.0/1.0     27.3/1.9      53.8/3.8      78.9/5.6      96.8/6.9

Average         13.9/1.0     26.0/1.9      50.4/3.6      72.7/5.2     88.9/6.4     12.7/1.0     24.7/1.9    48.9/3.8    71.5/5.6    87.6/6.9
FourPeople:27         52.2/1.0     98.7/1.9      185.5/3.6     257.1/4.9     271.0/5.2     45.8/1.0     88.8/1.9      175.4/3.8     252.1/5.5     285.7/6.2

Johnny:27         54.3/1.0     104.4/1.9     196.7/3.6     272.2/5.0     288.2/5.3     48.9/1.0     92.6/1.9      180.7/3.7     238.1/4.9     252.1/5.2

KristenAndSara:27      52.0/1.0     97.3/1.9      184.0/3.5     257.5/5.0     294.4/5.7     47.6/1.0     89.6/1.9      177.5/3.7     250.0/5.3     272.7/5.7

Average        52.8/1.0     100.1/1.9      188.8/3.6    262.3/5.0     284.5/5.4     47.5/1.0     90.3/1.9    177.9/3.7    246.7/5.2    270.2/5.7
Tango2:37         4.1/1.0      8.2/2.0       16.0/3.9      23.2/5.6      29.7/7.2      4.1/1.0      8.2/2.0       15.1/3.7      23.7/5.8      30.0/7.3

FoodMarket4:37         4.0/1.0      7.9/2.0       15.8/3.9      22.9/5.7      29.2/7.2      3.9/1.0      7.8/2.0       15.3/3.9      22.5/5.7      28.2/7.2

Campfire:37         4.8/1.0      9.0/1.9       17.8/3.7      25.8/5.4      31.9/6.7      4.7/1.0      9.7/2.0       19.0/4.0      28.1/5.9      34.3/7.2

Average         4.3/1.0     8.4/1.9      16.5/3.8      24.0/5.6     30.3/7.0     4.3/1.0     8.6/2.0      16.5/3.9      24.8/5.8     30.8/7.2
CatRobot1:37         4.1/1.0      8.2/2.0       16.1/3.9      23.3/5.7      29.4/7.1      4.2/1.0      8.3/2.0       16.2/3.9      23.8/5.7      30.0/7.2

DaylightRoad2:37         4.1/1.0      8.0/2.0     16.0/3.9      23.4/5.7      29.6/7.2      3.8/1.0      7.8/2.0       15.4/4.0      22.6/5.9      28.5/7.4

ParkRunning3:37         3.0/1.0      5.8/1.9      11.5/3.8      16.9/5.6      21.3/7.1      2.8/1.0      5.5/2.0       10.8/3.9      16.1/5.8      20.6/7.4

Average         3.8/1.0     7.3/2.0      14.5/3.9      21.2/5.6     26.8/7.1     3.6/1.0     7.2/2.0      14.2/3.9      20.8/5.8     26.4/7.3
MarketPlace:37         16.9/1.0     33.2/2.0      64.3/3.8      92.6/5.5      109.9/6.5     16.0/1.0     31.0/1.9      61.2/3.8      89.8/5.6      107.1/6.7

RitualDance:37         18.0/1.0     34.9/1.9      67.2/3.7      97.0/5.4      119.8/6.6     16.6/1.0     32.4/1.9      64.7/3.9      95.8/5.8      117.2/7.0

Cactus:37         21.7/1.0     40.3/1.9      77.3/3.6      111.0/5.1     133.0/6.1     20.5/1.0     39.5/1.9      76.9/3.8      111.1/5.4     124.0/6.0

BasketballDrive:37         14.7/1.0     28.1/1.9      55.0/3.7      79.6/5.4      98.2/6.7      13.7/1.0     26.6/1.9      52.9/3.9      77.5/5.6      97.1/7.1

BQTerrace:37         15.8/1.0     30.6/1.9      59.7/3.8      87.4/5.5      104.1/6.6     15.5/1.0     30.3/2.0      60.1/3.9      88.2/5.7      109.1/7.0

ArenaOfValor:37         19.9/1.0     38.5/1.9     74.4/3.7      106.6/5.4     128.7/6.5     19.1/1.0     37.9/2.0      74.6/3.9      108.3/5.7     130.4/6.8

Average        17.8/1.0     34.3/1.9      66.3/3.7      95.7/5.4     115.6/6.5     16.9/1.0     33.0/1.9      65.1/3.8      95.1/5.6     114.2/6.7

FourPeople:37         59.2/1.0     116.7/2.0     219.1/3.7     299.4/5.1     314.5/5.3     55.5/1.0     108.3/2.0     211.3/3.8     306.1/5.5     344.8/6.2

Johnny:37         64.2/1.0     123.2/1.9     231.5/3.6     319.5/5.0     355.0/5.5     57.8/1.0     113.2/2.0     219.0/3.8     297.0/5.1     319.1/5.5

KristenAndSara:37         60.0/1.0     115.4/1.9     217.5/3.6     302.1/5.0     338.2/5.6     52.9/1.0     103.8/2.0     204.1/3.9     294.1/5.6     322.6/6.1

Average        61.1/1.0     118.4/1.9      222.7/3.6      307.0/5.0     335.9/5.5     55.4/1.0     108.4/2.0      211.4/3.8      299.1/5.4     328.9/5.9

In Table <ref>, the decoding performance of vvdec and OpenVVC (f2/t2 configuration) decoders for all considered fhd and hd sequences with qps 27 and 37 over esoc2 platform is shown. Here, both vvdec and OpenVVC decoders have achieved real-time for hd sequences over esoc2 using 4 cores. Therefore, in the upcoming part of this study, the results are presented for hd sequences over esoc2.

Decoding performance (in fps) for the considered HD and FHD test sequences at QP27 (top) and QP37 (bottom) on the ESoC2 platform with 1, 2, 3 and 4 cores.

Seq.:QP        4c|VVdeC (fps)     4cOpenVVC (fps)
# cores     1          2          3         4         1          2         3         4
MarketPlace:27         4.6        8.8        12.9      16.5      4.3        8.2       12.0      15.5

RitualDance:27         5.4        10.0       14.6      18.7      5.0        9.7       14.1      18.2

Cactus:27         6.4        11.6       17.0      21.5      5.8        11.3      16.4      21.0

BasketballDrive:27         4.6        8.6        12.5      16.2      4.3        8.5       12.4      16.1

BQTerrace:27         4.8        9.0        13.2      17.1      4.6        8.9       13.0      16.7

ArenaOfValor:27         6.0        10.9       15.9      20.1      5.5        10.7      15.7      20.0

Average         5.3     9.8      14.3     18.4     4.9     9.6     13.9      17.9
FourPeople:27         21.3       39.0       56.4      69.4      18.3       35.4      50.9      64.4

Johnny:27         21.9       40.4       57.9      71.4      18.1       34.7      50.5      63.2

KristenAndSara:27         20.7       38.1       55.1      68.3      18.0       34.8      50.3      64.0

Average         21.3     39.2      56.5      69.7     18.1     34.9     50.6    63.8
MarketPlace:37         6.3        12.1       17.6      22.5      5.9        11.5      16.9      21.7

RitualDance:37         7.0        13.1       17.7      24.5      6.4        12.4      18.0      23.1

Cactus:37         8.2        15.4       22.5      28.4      7.7        14.9      21.4      27.6

BasketballDrive:37         5.6        10.7       15.7      20.3      5.2        10.3      14.9      19.2

BQTerrace:37         5.9        11.4       16.6      21.4      5.8        11.4      16.6      21.4

ArenaOfValor:37         7.8        14.7       21.4      26.1      7.5        14.5      21.0      26.7

Average         6.8     12.9      18.6      23.9     6.4     12.5     18.1      23.3
FourPeople:37         24.8       46.2       65.7      80.9      21.8       42.1      61.0      77.3

Johnny:37         25.6       48.1       68.6      83.6      21.9       42.3      60.9      76.9

KristenAndSara:37         23.8       44.5       63.8      77.9      20.6       39.6      57.0      72.6

Average         24.7     46.2      66.0      80.8     21.4     41.3     59.6    75.6

ymin=0, ymax=350,
xlabel=Number of cores,
ylabel=Decoding frame rate (fps),
y label style=at=(0.04,0.5),
xmin=1, xmax=8,

legend style=at=(0.24,0.98), anchor=north, nodes=scale=0.7, transform shape,
grid style=dashed,

[color=brown, mark=halfcircle*, mark options=solid, mark size = 1.5pt]coordinates (1,47.45)(2,90.30)(3,134.35)(4,177.89)(5,213.79)(6,246.73)(7,268.46)(8,270.18);
[line width=0.35mm, color=brown, dotted, nodes near coords align=horizontal, mark=triangle, mark options=solid, mark size = 2pt]coordinates (1,18.12)(2,34.94)(3,50.56)(4,63.83);
[color=brown, dashed, nodes near coords align=horizontal, mark=square, mark options=solid, mark size = 1.5pt]coordinates (1,12.72)(2,24.74)(3,36.75)(4,48.86)(5,60.45)(6,71.53)(7,81.04)(8,87.64);

[color=black, mark=halfcircle*, mark options=solid, mark size = 1.5pt]coordinates (1,52.81)(2,100.15)(3,144.99)(4,188.77)(5,227.63)(6,262.27)(7,294.09)(8,284.53);
[line width=0.35mm, color=black, dotted, nodes near coords align=horizontal, mark=triangle, mark options=solid, mark size = 2pt]coordinates (1,21.31)(2,39.18)(3,56.48)(4,69.74);
[color=black, dashed, nodes near coords align=horizontal, mark=square, mark options=solid, mark size = 1.5pt]coordinates (1,13.94)(2,26.01)(3,38.26)(4,50.42)(5,61.73)(6,72.72)(7,83.19)(8,88.94);

[color=blue, mark=halfcircle*, mark options=solid, mark size = 1.5pt]coordinates (1,55.39)(2,108.44)(3,161.13)(4,211.44)(5,255.01)(6,299.09)(7,327.55)(8,328.85);
[line width=0.35mm, color=blue, dotted, nodes near coords align=horizontal, mark=triangle, mark options=solid, mark size = 2pt]coordinates (1,21.43)(2,41.34)(3,59.62)(4,75.63);
[color=blue, dashed, nodes near coords align=horizontal, mark=square, mark options=solid, mark size = 1.5pt]coordinates (1,16.92)(2,32.95)(3,49.12)(4,65.08)(5,80.59)(6,95.14)(7,107.65)(8,114.15);

[color=red, mark=halfcircle*, mark options=solid, mark size = 1.5pt]coordinates (1,61.14)(2,118.44)(3,173.04)(4,222.72)(5,269.30)(6,307.00)(7,345.15)(8,335.90);
[line width=0.35mm, color=red, dotted, nodes near coords align=horizontal, mark=triangle, mark options=solid, mark size = 2pt]coordinates (1,24.72)(2,46.25)(3,66.04)(4,80.78);
[color=red, dashed, nodes near coords align=horizontal, mark=square, mark options=solid, mark size = 1.5pt] coordinates (1,16.66)(2,34.28)(3,50.57)(4,66.32)(5,81.43)(6,95.71)(7,109.50)(8,115.62);

[draw,fill=white,inner sep=0pt, yshift=-3.6cm, above right]

$QP27$     $QP37$

<ref>     <ref>     $OpenVVC:ESoC1-HD$

<ref>     <ref>     $OpenVVC:ESoC2-HD$

<ref>     <ref>     $OpenVVC:ESoC1-FHD$

<ref>     <ref>     $VVdeC:ESoC1-HD$

<ref>     <ref>     $VVdeC:ESoC2-HD$

<ref>     <ref>     $VVdeC:ESoC1-FHD$

Average decoding performance (in fps) of OpenVVC, in brown QP 27 and blue QP 37, and VVdeC, in black QP27 and red QP37, for 1 to 8 number of cores.

The average decoding performance with respect to the number of cores is presented in the Fig. <ref>. Here, the decoding frame rates have been recorded for OpenVVC and vvdec decoders over esoc1 and esoc2. For both qps, the average results in fps of OpenVVC and vvdec are similar for one to four cores over esoc2. Moreover, vvdec has achieved up to $\times 1.08$ fps with respect to OpenVVC on esoc1 and it has reached the saturation point with 7 cores for hd sequences. However, for fhd sequences, the performance results of OpenVVC and vvdec are comparable on esoc1. The performance results follow the same pattern for both considered qps.

[   title=ESoC1,

grid style=dashed,
xtick=data, ymax=460,
tick label style=font=,
xlabel=Thread configuration,
ylabel=Memory (MB),ylabel style=xshift=-35pt,yshift=-12pt,anchor=west,
bar width=6pt,

legend style=at=(0.5,-0.36), anchor=north,legend columns=-1,

symbolic x coords=OpenVVC: f1/t8, f2/t4, f4/t2, f2/t8, VVdeC,
nodes near coords,
every node near coord/.append style=rotate=90, xshift=0cm, yshift=0cm, anchor=west,font=,
nodes near coords align=vertical,
coordinates (OpenVVC: f1/t8, 55.1) (f2/t4, 59.5) (f4/t2, 68.0) (f2/t8, 81.2) (VVdeC, 172.7);
coordinates (OpenVVC: f1/t8, 55.9) (f2/t4, 60.1) (f4/t2, 67.1) (f2/t8, 80.9) (VVdeC, 176.2);
coordinates (OpenVVC: f1/t8, 93.2) (f2/t4, 101.4) (f4/t2, 117.4) (f2/t8, 122.9) (VVdeC, 338.8);
coordinates (OpenVVC: f1/t8, 91.7) (f2/t4, 100.7) (f4/t2, 118.4) (f2/t8, 123.3) (VVdeC, 329.1);

HD-QP27, HD-QP37, FHD-QP27, FHD-QP37

[   title=ESoC2,
ymin=0, ymax=220,

grid style=dashed,
tick label style=font=,
xlabel=Thread configuration,
ylabel=Memory (MB),ylabel style=xshift=-35pt,yshift=-12pt,anchor=west,

legend style=at=(0.5,-0.36), anchor=north,legend columns=-1,

symbolic x coords=OpenVVC: f1/t4, f2/t2, f2/t4, VVdeC,
nodes near coords,
every node near coord/.append style=rotate=90, xshift=0cm, yshift=0cm, anchor=west,font=,
nodes near coords align=vertical,
coordinates (OpenVVC: f1/t4, 44.3) (f2/t2, 48.6) (f2/t4, 59.5) (VVdeC, 143.8);
coordinates (OpenVVC: f1/t4, 44.2) (f2/t2, 47.9) (f2/t4, 59.9) (VVdeC, 141.7);

HD-QP27, HD-QP37

Average maximum memory (in MB) used for QPs 27 and 37 sequences over ESoC1 (top) and ESoC2 (bottom).

§.§.§ Memory usage

Memory usage is one of the most limiting factors and a likely bottleneck for video decoding over resource-constrained embedded hardware. This part of the study presents the maximum memory (in MB) consumed by OpenVVC and vvdec over esoc1 and esoc2 for the fhd/hd sequences with two qps (27, 37). In Fig. <ref>, the average maximum memory usage for different OpenVVC configurations and vvdec is shown. Here, for both fhd and hd sequences, f1/t8 and f2/t8 configurations have used the least and the most memory, respectively. These behavior is expected that with the increase of the number of frames decoded in parallel, the memory usage increases since the large part memory of the decoder is related to the decoded frame. However, vvdec requires in average $\times2.1$ more memory for hd sequences and $\times2.7$ more memory for fhd sequences than the OpenVVC f2/t8 configuration over esoc1. In addition, the scenario is the same over esoc2 platform where f2/t4 configuration requires in average a maximum memory of 59.7MB for hd sequences. Moreover, vvdec requires in average $\times2.4$ more memory for hd sequences than the OpenVVC f2/t4 configuration on esoc2 platform. It can be concluded from the results that OpenVVC requires notably less memory compared to vvdec. Therefore, OpenVVC provides a great advantage and thus suitable for resource-constrained embedded platforms.

[   title=ESoC1,
ymin=0, ymax=65,

grid style=dashed,

tick label style=font=,
xlabel=Thread configuration,
ylabel=Energy (Joule),
ylabel style=xshift=-35pt,yshift=-15pt,anchor=west,
bar width=5.5pt,

legend style=at=(0.5,-0.36),
anchor=north,legend columns=-1,
symbolic x coords=OpenVVC: f1/t8, f2/t4, f4/t2, f2/t8, VVdeC,
nodes near coords,
every node near coord/.append style=rotate=90, xshift=0cm, yshift=0cm, anchor=west,font=,
nodes near coords align=vertical,
coordinates (OpenVVC: f1/t8, 13.1) (f2/t4, 13.0) (f4/t2, 12.8) (f2/t8, 12.8) (VVdeC, 14.7);
coordinates (OpenVVC: f1/t8, 11.8) (f2/t4, 11.3) (f4/t2, 11.4) (f2/t8, 11.2) (VVdeC, 13.6);
coordinates (OpenVVC: f1/t8, 45.2) (f2/t4, 43.2) (f4/t2, 42.9) (f2/t8, 43.9) (VVdeC, 45.9);
coordinates (OpenVVC: f1/t8, 33.9) (f2/t4, 33.5) (f4/t2, 33.4) (f2/t8, 34.1) (VVdeC, 33.6);

HD-QP27, HD-QP37, FHD-QP27, FHD-QP37

[   title=ESoC2,
ymin=0, ymax=21,

grid style=dashed,
tick label style=font=,
bar width=8pt,
xlabel=Thread configuration,
ylabel=Energy (Joule),ylabel style=xshift=-35pt,yshift=-15pt,anchor=west,
xlabel=Thread configuration,
legend style=at=(0.5,-0.36),
anchor=north,legend columns=-1,

symbolic x coords=OpenVVC: f1/t4, f2/t2, f2/t4, VVdeC,
nodes near coords,
every node near coord/.append style=rotate=90, xshift=0cm, yshift=0cm, anchor=west,font=,
nodes near coords align=vertical,
coordinates (OpenVVC: f1/t4, 16.4) (f2/t2, 16.1) (f2/t4, 16.5) (VVdeC, 13.4);
coordinates (OpenVVC: f1/t4, 14.4) (f2/t2, 14.1) (f2/t4, 14.5) (VVdeC, 11.6);

HD-QP27, HD-QP37

Average energy (J) consumed for QP 27 and 37 sequences on ESoC1 (top) and ESoC2 (bottom) platforms.

§.§.§ Energy consumption

Energy consumption is another important factor for video processing operation over embedded platforms. In this study, the energy consumption was calculated as follows: 1) the power consumption is taken (in mW) after decoding each frame using the built-in power monitor of both esoc, 2) the average power consumption of the entire sequence is multiplied by the total time in second spent for decoding the sequence, and 3) convert the energy consumption to Joule. The average energy consumption in J with different configurations of OpenVVC and vvdec decoders is shown in Fig. <ref>. Here, OpenVVC and vvdec have consumed comparable average energy over esoc1 for all configurations. vvdec has consumed on average $\times 1.17$ higher energy for hd sequences and $\times 1.04$ higher energy for fhd sequences with respect to the f4/t2 configuration of OpenVVC consumption on esoc1 platform. Similar to the implementation over esoc1, the f2/t2 configuration has used the least amount of average energy over esoc2. Moreover, the average energy consumption of OpenVVC is slightly higher than vvdec consumption over esoc2.

§.§.§ Comparison between OpenVVC and VVdeC decoders

Both open-source optimized video decoders OpenVVC and vvdec have reached real-time for fhd and hd sequences over esoc1 using 8 cores. In addition, both solutions present results near to real-time performance for uhd sequences on esoc1 platform. Moreover, OpenVVC and vvdec decoders achieved an average of 22 fps for qp27 and 28.5 fps for qp37 using 8 cores. Table <ref> and Table <ref> show the average performance (in fps) of OpenVVC and vvdec using different number of threads on esoc1 and esoc2, respectively. The complexity overhead of OpenVVC with respect to  vvdec is around 3% for uhd, 5% for fhd and 12% for hd sequences in both platforms.

Average performance (fps) of OpenVVC and VVdeC decoders on ESoC1 platform with 1 and 8 cores.

2cVVdeC (fps)     2|cOpenVVC (fps)     2|cVVdeC/OpenVVC
# cores          1              8              1              8              1                    8
UHD:QP27     3.17           21.72          2.94           21.95          108%                 99%

UHD:QP37     4.02           28.52          3.93           28.59          102%                 100%
FHD:QP27     13.94          88.94          12.72          87.64          110%                 101%

FHD:QP37     16.66          115.62         16.92          114.15         98%                101%
HD:QP27       52.81          284.53         47.45          270.18         111%                105%

HD:QP37       61.14          335.90         55.39          328.85         110%                102%

Average performance (fps) of OpenVVC and VVdeC decoders on ESoC2 platform with 1 and 4 cores.

2cVVdeC (fps)     2|cOpenVVC (fps)     2|cVVdeC/OpenVVC
# cores          1              4              1              4              1                     4
UHD:QP27     1.20           4.29           1.15           4.20           104%                  102%

UHD:QP37     1.51           5.49           1.49           5.43           101%                  101%
FHD:QP27     5.29           18.36          4.93           17.92          107%                  102%

FHD:QP37     6.81           23.85          6.43           23.31          106%                  102%
HD:QP27       21.31          69.74          18.12          63.83          118%                 109%

HD:QP37       24.72          80.78          21.43          75.63          115%                 107%

To summarize, there are three important parameters to take into consideration to select a video decoder for an embedded platform with limited hardware resources: the performance (fps), the energy consumed to decode a video and the memory used. The performance of the decoders compared in this paper (vvdec and OpenVVC) is very similar and only a small improvement is achieved in vvdec while the number of cores remains low. The energy consumed to decode a sequence is also very similar between both decodes. Finally, OpenVVC consumes less memory than vvdec with a factor higher than $\times 2.11$. This significant reductions makes OpenVVC decoder as the best option to implement a VVC video decoder conformance in a multi core platform with limited resources.

§ CONCLUSION

This paper presents two open source vvc decoders: OpenVVC and vvdec, optimized for low-cost resource-constrained embedded platforms. Here, OpenVVC and vvdec have been optimized at the level of data processing using simd operations. In addition, tile and frame based parallelizations have been implemented in OpenVVC. Both decoders have achieved 15 to 34 respectively fps for uhd sequences with qp 27 and 37, and achieved real-time decoding for all configurations of fhd and hd sequences over esoc1 using 8 cores. Furthermore, 16 to 28 fps have been obtained for fhd sequences for qps 27 and 37, and real-time  decoding has been obtained for all hd sequences by OpenVVC and vvdec on esoc2 using 4 cores.
Moreover, the experimental results for the two most important factors of the embedded platform: the average energy consumption and maximum memory usage by both decoders were presented for esoc1 and esoc2. vvdec has consumed on average $\times 2.74$ and $\times 2.96$ memory compared to the OpenVVC f4/t2 configuration on esoc1 and the f2/t2 configuration on esoc2, respectively. For average energy usages, vvdec consumed on average $\times 1.11$ energy with respect to the OpenVVC f4/t2 configuration on esoc1 and $\times 0.83$ energy with respect to the OpenVVC f2/t2 configuration on esoc2.

[1]
"Fraunhofer HHI is proud to present the new state-of-the-art in global video coding: H.266/VVC brings video transmission to new speed," [Online]. Available: <https://newsletter.fraunhofer.de/-viewonline2/17386/465/11/14SHcBTt/V44RELLZBp/1>.

[2]
A. Wieckowski et al., "Towards A Live Software Decoder Implementation For The Upcoming Versatile Video Coding (VVC) Codec," 2020 IEEE International Conference on Image Processing (ICIP), 2020, pp. 3124-3128.

[3]
"High Efficiency Video Coding," Recommendation ITU–T H.265; 2013.

[4]
C. Feldmann, "Versatile Video Coding hits major milestone," [Online]. Available: <https://bitmovin.com/compression-standards-vvc-2020>.

[5]
"VVC test model," [Online]. Available:

[6]
C. C. Chi, M. Alvarez-Mesa, B. Bross, B. Juurlink and T. Schierl, "SIMD Acceleration for HEVC Decoding," in IEEE Trans. on Circuits and Systems for Video Technology, vol. 25, no. 5, pp. 841-855, May 2015.

[7]
T. Amestoy, W. Hamidouche, C. Bergeron and D. Menard, "Quality-Driven Dynamic vvc Frame Partitioning for Efficient Parallel Processing," 2020 IEEE International Conference on Image Processing (ICIP), 2020, pp. 3129-3133.

[8]
S. Gudumasu, S. Bandyopadhyay, and Y. He, "Software-based versatile video coding decoder parallelization," in Proceedings of the 11th ACM Multimedia Systems Conference (MMSys '20), Association for Computing Machinery, New York, NY, USA, 202–212, 2020.
[9]
Koziri, Maria and Papadopoulos, Panos K. and Tziritas, Nikos and Dadaliaris, Antonios N. and Loukopoulos, Thanasis and Khan, Samee U. and Xu, Cheng-Zhong, "Adaptive Tile Parallelization for Fast Video Encoding in HEVC," 2016 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), 2016, pp. 738-743.

[10]
Gary Sullivan, "Deployment status of the VVC standard," ISO/IEC JTC1/SC29/WG11 JVET document Y0021 (JVET-Y0021), Teleconference, January, 2022.

[11]
"OpenVVC software repository," [Online]. Available: <https://github.com/OpenVVC/OpenVVC>.

[12]
Thomas Amestoy, Pierre-loup Cabarat, Guillaume Gautier, Wassim Hamidouche and Daniel Menard, "OpenVVC: a Lightweight Software Decoder for the Versatile Video Coding Standard," arXiv preprint arXiv:2205.12217, 2022.

[13]
"Fraunhofer HHI VVdeC software repository," [Online]. Available: <https://github.com/fraunhoferhhi/vvdec>.

[14]
D. Karwowski, "Precise Probability Estimation of Symbols in VVC CABAC Entropy Encoder," in IEEE Access, vol. 9, pp. 65361-65368, 2021.

[15]
M. J. Garrido, F. Pescador, M. Chavarrías, P. J. Lobo, C. Sanz and P. Paz, "An FPGA-Based Architecture for the Versatile Video Coding Multiple Transform Selection Core," in IEEE Access, vol. 8, pp. 81887-81903, 2020.

[16]
Z. Hong, J. Lin, D. Jiang and J. Yin, "Improve the Efficiency of Low Frequency Non-Separable Secondary Transform Based on Implicit Multiple Transform Selection," 2019 International Conference on Artificial Intelligence and Advanced Manufacturing (AIAM), 2019, pp. 148-151.

[17]
R. Ghaznavi-Youvalari and J. Lainema, "Joint Cross-Component Linear Model For Chroma Intra Prediction," 2020 IEEE 22nd International Workshop on Multimedia Signal Processing (MMSP), 2020, pp. 1-5.

[18]
Y. Li et al., "An Optimized H.266/VVC Software Decoder On Mobile Platform," 2021 Picture Coding Symposium (PCS), 2021, pp. 1-5.

[19]
F. Bossen, K. Sühring, A. Wieckowski and S. Liu, "VVC Complexity and Software Implementation Analysis," in IEEE Transactions on Circuits and Systems for Video Technology, vol. 31, no. 10, pp. 3765-3778, Oct. 2021.

[20]
D. Fedorov. "Decoder-Side Motion Vector Refinement (DMVR) in VVC," July. 2021 [Online]. Available: <https://vicuesoft.com/blog/titles/DMVR_in_VVC/>.

[21]
D. fedorov. "Bi-directional Optical Flow (BDOF) Prediction Refinement in VVC," Oct. 2021 [Online]. Available: <https://vicuesoft.com/blog/titles/bi_directional_optical_flow_bdof_prediction_refinement_in_vvc/>.

[22]
T. Lu et al., "Luma Mapping with Chroma Scaling in Versatile Video Coding," 2020 Data Compression Conference (DCC), 2020, pp. 193-202.

[23]
M. Karczewicz et al., "VVC In-Loop Filters," in IEEE Transactions on Circuits and Systems for Video Technology, vol. 31, no. 10, pp. 3907-3925, Oct. 2021, doi: 10.1109/TCSVT.2021.3072297.

[24]
A. Saha, M. Chavarrías, F. Pescador, Á.M. Groba, K. Chassaigne, P.L. Cebrián, "Complexity Analysis of a Versatile Video Coding Decoder over Embedded Systems and General Purpose Processors," Sensors 2021, 21, 3320.

[25]
“ARM Developer, Neon,” [Online]. Available: <https://developer.arm.com/architectures/instruction-sets/simd-isas/neon>.

[26]
B. Bross et al., "Overview of the Versatile Video Coding (VVC) Standard and its Applications," in IEEE Transactions on Circuits and Systems for Video Technology, vol. 31, no. 10, pp. 3736-3764, Oct. 2021.

[27]
L. Yan, Y. Duan, J. Sun and Z. Guo, "Implementation of HEVC decoder on x86 processors with SIMD optimization," 2012 Visual Communications and Image Processing, 2012, pp. 1-6.

[28]
D. F. de Souza, A. Ilic, N. Roma and L. Sousa, "HEVC in-loop filters GPU parallelization in embedded systems," 2015 International Conference on Embedded Computer Systems: Architectures, Modeling, and Simulation (SAMOS), 2015, pp. 123-130.

[29]
D. F. de Souza, A. Ilic, N. Roma and L. Sousa, "GPU-assisted HEVC intra decoder," Journal of Real-Time Image Processing, 2016, vol. 12, Issue 2, pp. 531- 547.

[30]
X. Han, S. Wang, S. Ma and W. Gao, "Optimization Of Motion Compensation Based On GPU And CPU For VVC Decoding," 2020 IEEE International Conference on Image Processing (ICIP), 2020, pp. 1196-1200.

[31]
B. Zhu et al., "A Real-Time H.266/VVC Software Decoder," 2021 IEEE International Conference on Multimedia and Expo (ICME), 2021, pp. 1-6, doi: 10.1109/ICME51207.2021.9428470.

[32]
“Tencent O266dec decoder library,” [Online]. Available: <https://github.com/TencentCloud/O266player>.

[33]
"VLC media player: VideoLAN, a project and a non-profit organization," [Online]. Available: <https://www.videolan.org/>.

[34]
"GPAC: Multimedia Open Source Project," [Online]. Available: <https://gpac.wp.imt.fr/>.

[35]
"Ffmpeg: A complete, cross-platform solution to record, convert and stream audio and video," [Online]. Available: <https://ffmpeg.org/>.

[36]
J. Boyce, E. Alshina, F. Bossen, K. Kawamura, I. Moccagatta and W. Wan, "Conformance testing for versatile video coding (Draft 6)," Doc. JVET-U2008 of ITUT/ISO/IEC Joint Video Experts Team (JVET), 21st JVET meeting: January 2021.

[37]
A. Wieckowski, C. Lehmann, B. Bross, D. Marpe, T. Biatek, M. Raulet, and J. Le Feuvre, "A Complete End to End Open Source Toolchain for the Versatile Video Coding (VVC) Standard," 2021 Proceedings of the 29th ACM International Conference on Multimedia, Association for Computing Machinery, New York, NY, USA, 3795–3798.

[38]
T. Amestoy, W. Hamidouche, C. Bergeron and D. Menard, "Quality-Driven Dynamic VVC Frame Partitioning for Efficient Parallel Processing," 2020 IEEE International Conference on Image Processing (ICIP), 2020, pp. 3129-3133.
[39]
E. Nemerson, "Transitioning SSE/AVX code to NEON with SIMDe," [Online]. Available: <https://simd-everywhere.github.io/blog/2020/06/22/transitioning-to-arm-with-simde.html>.

[40]
"NVIDIA Jetson AGX Xavier Developer Kit, User Guide," DA_09403_003, December 17, 2019, [Online]. Available: <https://developer.nvidia.com/jetson-agx-xavier-developer-kit-user-guide>.

[41]
"NVIDIA Jetson Nano Developer Kit, User Guide," DA_09402_004, January 15, 2020, [Online]. Available: <https://developer.nvidia.com/embedded/dlc/Jetson_Nano_Developer_Kit_User_Guide>.

[42]
F. Bossen, J. Boyce, X. Li, V. Seregin, and K. Sühring, "JVET Common Test Conditions and Software Reference Configurations for SDR Video," Document JVET-N1010, JVET of ITU-T, Geneva, Mar 2019.


# Notes on the analytic solution of box model equations for gravity-driven
particle currents with constant volume.

Andrea Bevilacqua

###### Abstract

We summarize the physical equations and analytic solutions of three versions
of the box model equations, suitable for the integral formulation of
axisymmetric gravity-driven particle currents with constant volume. The first
model is based on a simple constant resisting stress, while the second and
third models assume flow dilution by particle deposition. The third model is
characterized by assuming an interstitial fluid lighter than the ambient
fluid. All the calculations are performed on a flat topography. Ambient fluid
entrainment and cooling effects are not considered. All particles are assumed
to deposit at the same velocity.

##  1 Introduction

The box model integral formulation for gravity-driven particle currents is
based on the pioneering work of Huppert and Simpson, (1980). The theory is
detailed in Bonnecaze et al., (1995); Hallworth et al., (1998). We assume
axisymmetric geometry and constant volume of the flow111this is not the
formulation adopted in Dade and Huppert, (1996), which assumed constant volume
flux.. We solve the equations over a flat topography, with no slope or
obstacles. Ambient fluid entrainment is neglected and thermal properties of
the flow remain constant222air entrainment and cooling effects are explored in
Bursik and Woods, (1996); Fauria et al., (2016).. In the second and third
model all the solid particles are assumed to deposit at the same velocity,
thus neglecting differences in particle size and shape.

##  2 Box model with constant resisting stress

This model is described in Dade and Huppert, (1998) and it is at the base of
the depth-averaged model in Kelfoun et al., (2009). We consider the work
$W(t)$ done by a constant resisting stress $\tau_{c}$ acting over the basal
area $A$ of the flow. We assume the flow geometry to be cylindrical, so
$A(r)=\lambda r^{2}$, where $r$ is the cylinder radius.
Let us consider the time interval $[0,t]$ and assume $L(0)=0$. We obtain:

$W(t)=\int_{0}^{L(t)}\tau_{c}\cdot A(r)dr=\int_{0}^{L(t)}\tau_{c}\cdot\lambda
r^{2}dr=\frac{\tau_{c}}{3}\lambda L(t)^{3}=\tau\lambda L(t)^{3},$

where $L(t)$ is the radial distance reached by the current at time $t$,
$\lambda$ is half-central angle of the cylindrical sector considered, and
$\tau:=\frac{\tau_{c}}{3}$ is the effective stress constant.
Let us also assume that the total energy of the flow at $t_{0}=0$ is:

$Q(t_{0})=gH\rho V,$

where $g$ is gravity, $\rho$ is the density of the flowing material, $H$ is
the height drop of the flow, and $V$ its volume. We finally assume that the
volume $V$ of the current is preserved.
Hence, the kinetic energy of the flow at time $t$ is given by:

$K(t)=gH\rho V-\lambda\tau L(t)^{3}.$

Assuming $K(t_{f})=0$ at the instant $t_{f}$ at which the runout distance
$L(t_{f})$ is reached, we obtain:

$V=\frac{\lambda\tau L(t_{f})^{3}}{gH\rho}.$

##  3 Box model with particle deposition

This model is described in Dade and Huppert, (1995) and it adopted in Neri et
al., (2015); Bevilacqua et al., (2017). Further description of this approach
is provided in Bevilacqua, (2016); Esposti Ongaro et al., (2016). We consider
the Von Kármán equation for density currents:

$\frac{dL}{dt}(t)=Fr\sqrt{h(t)g\frac{\rho_{c}(t)-\rho_{a}}{\rho_{a}}},$

where $L(t)$ and $h(t)$ are the radial distance reached by the current and its
height, at time $t$. In our notation $Fr$ is the Froude Number, $g$ is
gravity. We express the density of the current $\rho_{c}$ by:

$\rho_{c}(t)=\phi(t)\rho+\left[1-\phi(t)\right]\rho_{a}$

where $\rho$ is the density of the solid particles, and $\rho_{a}$ is the
density of ambient fluid. Finally, the equation

$\frac{d\phi}{dt}(t)=-w_{s}\frac{\phi(t)}{h(t)}$

defines the particle volume fraction $\phi(t)$ at time $t$.
Let us also assume that the volume $V$ of the current is preserved, and that
its geometry is cylindrical:

$V=L(t)^{2}h(t)\lambda=const,$

where $\lambda$ is half-central angle of the cylindrical sector considered
($\lambda=\pi$ in axisymmetric examples).
In summary:

$\left\\{\begin{array}[]{ll}\frac{dL}{dt}(t)=Fr\sqrt{h(t)\phi(t)g\frac{\rho-\rho_{a}}{\rho_{a}}},\\\
\\\ \frac{d\phi}{dt}(t)=-w_{s}\frac{\phi(t)}{h(t)},\\\ \\\ V\equiv
L(t)^{2}h(t)\lambda.\end{array}\right.$

###  3.1 Derivation of the equation for the volume V

Let us consider the formal expression:

$\frac{d\phi}{dL}(t)=\frac{d\phi}{dt}(t)\left[\frac{dL}{dt}(t)\right]^{-1},$

and so

$\frac{d\phi}{dL}(t)=-w_{s}\frac{\phi(t)}{h(t)}\left[Fr\sqrt{h(t)\phi(t)g_{p}}\right]^{-1},$

where we use the short notation $g_{p}:=g\frac{\rho-\rho_{a}}{\rho_{a}}$.
If we plug in the expression $h(t)=\frac{V}{\lambda L(t)^{2}}$, we obtain:

$\frac{d\phi}{dL}(t)=-w_{s}\phi^{1/2}(t)L(t)^{3}\left[Fr\
g_{p}^{1/2}\frac{V}{\lambda}^{3/2}\right]^{-1}.$

If we define

$\eta:=w_{s}\left(Fr\ g_{p}^{1/2}\frac{V}{\lambda}^{3/2}\right)^{-1},$

we can write:

$\phi(t)^{-1/2}d\phi=-\eta L^{3}dL.$

If we integrate the differential expression over $[0,t]$, assuming
$\phi(0)=\phi_{0}$ and $L(0)=0$, we get:

$\phi^{1/2}(t)=\phi_{0}^{1/2}-\frac{1}{8}\eta L(t)^{4}.$

Finally, assuming $\phi(t_{f})=0$ at the instant $t_{f}$ at which the runout
distance $L(t_{f})$ is reached, we obtain:

$L(t_{f})=\left(\frac{8\phi_{0}^{1/2}}{\eta}\right)^{1/4}=\left[8\frac{Fr\
\phi_{0}^{1/2}g_{p}^{1/2}(V/\lambda)^{3/2}}{w_{s}}\right]^{1/4},$

and so

$V=\lambda\left(\frac{L^{4}w_{s}}{8\phi_{0}^{1/2}g_{p}^{1/2}Fr}\right)^{2/3}=\lambda\frac{L^{8/3}w_{s}^{2/3}}{4\phi_{0}^{1/3}g_{p}^{1/3}Fr^{2/3}}.$

##  4 Two-phase box model (interstitial fluid + solid particles)

We consider the Von Kármán equation for density currents:

$\frac{dL}{dt}(t)=Fr\sqrt{h(t)g\frac{\rho_{c}(t)-\rho_{a}}{\rho_{a}}},$

where $L(t)$ and $h(t)$ are the radial distance reached by the current and its
height, at time $t$. In our notation $Fr$ is the Froude Number, $g$ is
gravity. We express the density of the current $\rho_{c}$ by:

$\rho_{c}(t)=\phi(t)\rho+\left[1-\phi(t)\right]\rho_{i}$

where $\rho$ is the density of the solid particles, and $\rho_{i}$ is the
density of interstitial fluid. We have that:

$\frac{\rho_{c}-\rho_{a}}{\rho_{a}}=\frac{\phi(t)\rho+\left[1-\phi(t)\right]\rho_{i}-\rho_{a}}{\rho_{a}}=\phi(t)\frac{\rho-\rho_{i}}{\rho_{a}}+\frac{\rho_{i}-\rho_{a}}{\rho_{a}}=\left[\phi(t)-\phi_{cr}\right]\frac{\rho-\rho_{i}}{\rho_{a}},$

where we called $\phi_{cr}:=\frac{\rho_{a}-\rho_{i}}{\rho-\rho_{i}}$.
Finally, the equation

$\frac{d\phi}{dt}(t)=-w_{s}\frac{\phi(t)}{h(t)}$

defines the particle volume fraction $\phi(t)$ at time $t$.
Let us also assume that the volume $V$ of the current is preserved, and that
its geometry is cylindrical333the analytic solutions in cartesian geometry are
provided in Esposti Ongaro et al., (2016).:

$V=L(t)^{2}h(t)\lambda=const,$

where $\lambda$ is half-central angle of the cylindrical sector considered
($\lambda=\pi$ in axisymmetric examples).
In summary:

$\left\\{\begin{array}[]{ll}\frac{dL}{dt}(t)=Fr\sqrt{h(t)\left[\phi(t)-\phi_{cr}\right]g\frac{\rho-\rho_{i}}{\rho_{a}}},\\\
\\\ \frac{d\phi}{dt}(t)=-w_{s}\frac{\phi(t)}{h(t)},\\\ \\\ V\equiv
L(t)^{2}h(t)\lambda.\end{array}\right.$

###  4.1 Derivation of the equation for the volume V

Let us consider the formal expression:

$\frac{d\phi}{dL}(t)=\frac{d\phi}{dt}(t)\left[\frac{dL}{dt}(t)\right]^{-1},$

and so

$\frac{d\phi}{dL}(t)=-w_{s}\frac{\phi(t)}{h(t)}\left[Fr\sqrt{h(t)\left[\phi(t)-\phi_{cr}\right]g_{c}}\right]^{-1},$

where we use the short notation $g_{c}:=g\frac{\rho-\rho_{i}}{\rho_{a}}$.
If we plug in the expression $h(t)=\frac{V}{\lambda L(t)^{2}}$, we obtain:

$\frac{d\phi}{dL}(t)=-w_{s}\frac{\phi(t)}{\sqrt{\phi(t)-\phi_{cr}}}L(t)^{3}\left[Fr\
g_{c}^{1/2}\frac{V}{\lambda}^{3/2}\right]^{-1}.$

If we define the function:

$\hat{\phi}(t)=\frac{\phi(t)}{\phi_{cr}},$

and the constant

$\eta:=w_{s}\left(Fr\ g_{c}^{1/2}\frac{V}{\lambda}^{3/2}\right)^{-1},$

we can write:

$\frac{d\hat{\phi}}{dL}(t)=-\eta\frac{\hat{\phi}(t)}{\phi_{cr}^{1/2}\left(\hat{\phi}(t)-1\right)^{1/2}},$

and then

$\frac{\phi_{cr}^{1/2}\left(\hat{\phi}(t)-1\right)^{1/2}}{\hat{\phi}(t)}d\hat{\phi}=-\eta
L^{3}dL.$

If we integrate the differential expression over $[0,t]$, assuming
$\hat{\phi}(0)=\hat{\phi}_{0}$ and $L(0)=0$, we get:

$F\left(\hat{\phi}(t)\right)=F\left(\hat{\phi}_{0}\right)-\frac{\eta}{4\phi_{cr}^{1/2}}L(t)^{4},$

where we defined the function:

$F(x):=2\left[\sqrt{x-1}-\arctan\left(\sqrt{x-1}\right)\right].$

Indeed:

$\int\frac{\sqrt{x-1}}{x}dx=\int\frac{2z^{2}}{z^{2}+1}dz=2\int
dz-2\int\frac{1}{z^{2}+1}dz=2\left[z-\arctan(z)\right]+c,$

where $z:=\sqrt{x-1}$. Finally, assuming $\hat{\phi}(t_{f})=1$ at the instant
$t_{f}$ at which the runout distance $L(t_{f})$ is reached, we obtain:

$L(t_{f})=\left(\frac{4\phi_{cr}^{1/2}\
F\left(\hat{\phi}_{0}\right)}{\eta}\right)^{1/4}=\left[\frac{8\phi_{cr}^{1/2}\left[\sqrt{\frac{\phi_{0}}{\phi_{cr}}-1}-\arctan\left(\sqrt{\frac{\phi_{0}}{\phi_{cr}}-1}\right)\right]g_{c}^{1/2}Fr\
(V/\lambda)^{3/2}}{w_{s}}\right]^{1/4},$

and so

$V=\lambda\left(\frac{L^{4}w_{s}}{4\phi_{cr}^{1/2}\
F\left(\hat{\phi}_{0}\right)\ g_{c}\
Fr}\right)^{2/3}=\lambda\frac{L^{8/3}w_{s}^{2/3}}{4\phi_{cr}^{1/3}\left[\sqrt{\frac{\phi_{0}}{\phi_{cr}}-1}-\arctan\left(\sqrt{\frac{\phi_{0}}{\phi_{cr}}-1}\right)\right]^{2/3}g_{c}^{1/3}Fr^{2/3}}.$

## References

  * Bevilacqua, (2016) Bevilacqua, A. (2016).  Doubly stochastic models for volcanic hazard assessment at Campi Flegrei caldera, volume 21 of Theses.  Edizioni della Normale, Birkhäuser/Springer.
  * Bevilacqua et al., (2017) Bevilacqua, A., Neri, A., Bisson, M., Esposti Ongaro, T., Flandoli, F., Isaia, R., Rosi, M., and Vitale, S. (2017).  The effects of vent location, event scale, and time forecasts on pyroclastic density current hazard maps at Campi Flegrei caldera (Italy).  Frontiers in Earth Science, 5:72.
  * Bonnecaze et al., (1995) Bonnecaze, R. T., Hallworth, M. A., Huppert, H. E., and Lister, J. R. (1995).  Axisymmetric particle-driven gravity currents.  Journal of Fluid Mechanics, 294:93 121.
  * Bursik and Woods, (1996) Bursik, M. and Woods, A. (1996).  The dynamics and thermodynamics of large ash flows.  Bulletin of Volcanology, 58(2):175–193.
  * Dade and Huppert, (1995) Dade, W. and Huppert, H. (1995).  Runout and fine-sediment deposits of axisymmetric turbidity currents.  Journal of Geophysical Research: Oceans, 100(C9):18597–18609.
  * Dade and Huppert, (1996) Dade, W. B. and Huppert, H. E. (1996).  Emplacement of Taupo ignimbrite.  Nature, 385:307–308.
  * Dade and Huppert, (1998) Dade, W. B. and Huppert, H. E. (1998).  Long-runout rockfalls.  Geology, 26(9):803–806.
  * Esposti Ongaro et al., (2016) Esposti Ongaro, T., Orsucci, S., and Cornolti, F. (2016).  A fast, calibrated model for pyroclastic density currents kinematics and hazard.  Journal of Volcanology and Geothermal Research, 327:257 – 272.
  * Fauria et al., (2016) Fauria, K., Manga, M., and Chamberlain, M. (2016).  Effect of particle entrainment on the runout of pyroclastic density currents.  Journal of Geophysical Research: Solid Earth, 121(9):6445–6461.
  * Hallworth et al., (1998) Hallworth, M., Hogg, A., and Huppert, H. (1998).  Effects of external flow on compositional and particle gravity currents.  Journal of Fluid Mechanics, 359:109 142.
  * Huppert and Simpson, (1980) Huppert, H. and Simpson, J. (1980).  The slumping of gravity currents.  Journal of Fluid Mechanics, 99(4):785 799.
  * Kelfoun et al., (2009) Kelfoun, K., Samaniego, P., Palacios, P., and Barba, D. (2009).  Testing the suitability of frictional behaviour for pyroclastic flow simulation by comparison with a well-constrained eruption at Tungurahua volcano (Ecuador).  Bulletin of Volcanology, 71:1057–1075.
  * Neri et al., (2015) Neri, A., Bevilacqua, A., Esposti Ongaro, T., Isaia, R., Aspinall, W. P., Bisson, M., Flandoli, F., Baxter, P. J., Bertagnini, A., Iannuzzi, E., Orsucci, S., Pistolesi, M., Rosi, M., and Vitale, S. (2015).  Quantifying volcanic hazard at Campi Flegrei caldera (Italy) with uncertainty assessment: 2. Pyroclastic density current invasion maps.  Journal of Geophysical Research: Solid Earth, 120(4):2330–2349.