Hello, thank you for releasing MLVC and the accompanying benchmarking tools.
I would like to clarify how the encoding and decoding FPS reported in the paper were measured.
When running the official benchmark, I obtained results in the following format:
Benchmark results:
+------------------+-------------+--------+-----------+
| Timer name | Median (ms) | FPS | Share (%) |
+------------------+-------------+--------+-----------+
| MLVCEncoderTotal | ............ | ............ | 2.2 % |
| MLVCDecoderTotal | ............ | ............ | 1.7 % |
| MLVCEncoderPart1 | ............ | ............ | 1.8 % |
| MLVCEncoderPart2 | ............ | ............ | 0.4 % |
| MLVCDecoder | ............ | ............ | 1.7 % |
| FrameLoopTotal | ............ | ............ | 100.0 % |
+------------------+-------------+--------+-----------+
From the implementation, it seems that MLVCEncoderTotal is the sum of the inference times of MLVCEncoderPart1 and MLVCEncoderPart2, while MLVCDecoderTotal similarly represents the neural-network inference time of the decoder.
In contrast, FrameLoopTotal appears to include the complete per-frame processing flow, including split_model.encode(), split_model.decode(), reference management, entropy coding/decoding, and metric calculation.
Therefore, I would like to confirm:
For the Enc FPS and Dec FPS reported in the paper, were the values calculated from MLVCEncoderTotal / MLVCDecoderTotal?
Or were they based on the complete encoding/decoding latency, including entropy coding/decoding and bitstream generation/parsing?
Does FrameLoopTotal correspond to the end-to-end codec processing time used in any of the performance results reported in the paper?
4. In my benchmark on an NVIDIA RTX 4090 at 1080p, FrameLoopTotal reaches approximately 142.2 ms per frame, while MLVCEncoderTotal and MLVCDecoderTotal account for only a relatively small portion of this time. Most of the runtime therefore appears to be spent on codec operations outside the neural-network inference. Is this expected behavior in the current implementation? If so, is the additional runtime mainly caused by entropy coding/decoding, data conversion, reference management, or other operations?
This clarification would be very helpful for reproducing the reported real-time performance on NVIDIA and embedded platforms.
Thank you!
Hello, thank you for releasing MLVC and the accompanying benchmarking tools.
I would like to clarify how the encoding and decoding FPS reported in the paper were measured.
When running the official benchmark, I obtained results in the following format:
Benchmark results:
+------------------+-------------+--------+-----------+
| Timer name | Median (ms) | FPS | Share (%) |
+------------------+-------------+--------+-----------+
| MLVCEncoderTotal | ............ | ............ | 2.2 % |
| MLVCDecoderTotal | ............ | ............ | 1.7 % |
| MLVCEncoderPart1 | ............ | ............ | 1.8 % |
| MLVCEncoderPart2 | ............ | ............ | 0.4 % |
| MLVCDecoder | ............ | ............ | 1.7 % |
| FrameLoopTotal | ............ | ............ | 100.0 % |
+------------------+-------------+--------+-----------+
From the implementation, it seems that MLVCEncoderTotal is the sum of the inference times of MLVCEncoderPart1 and MLVCEncoderPart2, while MLVCDecoderTotal similarly represents the neural-network inference time of the decoder.
In contrast, FrameLoopTotal appears to include the complete per-frame processing flow, including split_model.encode(), split_model.decode(), reference management, entropy coding/decoding, and metric calculation.
Therefore, I would like to confirm:
For the Enc FPS and Dec FPS reported in the paper, were the values calculated from MLVCEncoderTotal / MLVCDecoderTotal?
Or were they based on the complete encoding/decoding latency, including entropy coding/decoding and bitstream generation/parsing?
Does FrameLoopTotal correspond to the end-to-end codec processing time used in any of the performance results reported in the paper?
4. In my benchmark on an NVIDIA RTX 4090 at 1080p, FrameLoopTotal reaches approximately 142.2 ms per frame, while MLVCEncoderTotal and MLVCDecoderTotal account for only a relatively small portion of this time. Most of the runtime therefore appears to be spent on codec operations outside the neural-network inference. Is this expected behavior in the current implementation? If so, is the additional runtime mainly caused by entropy coding/decoding, data conversion, reference management, or other operations?
This clarification would be very helpful for reproducing the reported real-time performance on NVIDIA and embedded platforms.
Thank you!