[x265] multi-rate feature
Schroeder, Damien
damien.schroeder at tum.de
Thu Aug 11 15:04:29 CEST 2016
Hi,
No, no particular reason why I used CQP for the analysis-mode comparison. I guess I just started with CQP tests when I did these few first tests. I agree ABR and CRF would make more sense. I’ll try to do this when I find some time.
BR,
Damien
Von: x265-devel [mailto:x265-devel-bounces at videolan.org] Im Auftrag von Kavitha Sampath
Gesendet: Donnerstag, 11. August 2016 13:13
An: Development for x265 <x265-devel at videolan.org>
Betreff: Re: [x265] multi-rate feature
Hello,
The result of your multi-rate feature for x265 looks interesting.
I see that you speedup RDO by sharing depth from high quality to low quality encodings.
I also see that you compare multi-rate's efficiency against analysis-mode, encoding with CQP.
Is there any reason why you have not used ABR/CRF modes to compare results? I would imagine those are more commonly-used modes for encoding instead of fixed-QP encoding for real world use-cases
On Wed, Aug 10, 2016 at 6:42 PM, Schroeder, Damien <damien.schroeder at tum.de<mailto:damien.schroeder at tum.de>> wrote:
Hello,
I recently implemented a „multi-rate“ feature for x265 based on the latest x265 version. The target application is adaptive HTTP streaming, where you need the same video encoded at different representations. Basically, if you need to encode the same video at different bitrates (different qualities), the multi-rate method allows you to pass some analysis info from a high-quality reference encoding to lower quality dependent encodings, which is then used to constrain the RDO (and thus, this leads to a speed-up).
This is similar to the analysis-mode option already existing in x265. However, this analysis-mode option is not targeted at encodings at different qualities (the rate-distortion performance is degraded if you use this option across different qualities).
I put my code on github for the moment: https://github.com/damjeux/multi-rate-x265
When mr-mode is 1, the CU structure of each CTU is stored in an external file called analysisData.bin
When mr-mode is 2, analysisData.bin is loaded and the loaded CU structure is used to constrain the RDO by stopping the recursion in the different compressInterCU and compressIntraCU functions in analysis.cpp
I have posted some results in a blog post: https://damienschroeder.wordpress.com/2016/08/10/multi-rate-hevc-with-x265-for-adaptive-http-streaming/
The implemented method performs better for high rd-levels (--rd 5 and 6), because the compressInterCU_rd0_4() function already constrains the CTU quadtree by using a minDepth.
For example, with --rd 6, I get an average reduction in encoding time of 10% with no rate-distortion performance decrease (BD-rate -0.002%) in the case where I encode four representations with fixed QP 22, 27, 32, and 37.
With crf 22, 27, 32, and 37, I get an average encoding time reduction of 19% and the rate-distortion performance is slightly degraded (BD-rate 0.9%).
Not sure if there is interest to include such a feature in the official x265, but I thought I should mention this.
Best regards,
Damien Schroeder
Dipl.-Ing. Damien Schroeder
Technische Universität München
Lehrstuhl für Medientechnik
Chair of Media Technology
Arcisstr. 21, 80333 München
Building 9, Room 1934
Phone: +49 89 289 23507
Fax: +49 89 289 23523
Email: damien.schroeder at tum.de<mailto:damien.schroeder at tum.de>
Web: www.lmt.ei.tum.de<http://www.lmt.ei.tum.de/>
_______________________________________________
x265-devel mailing list
x265-devel at videolan.org<mailto:x265-devel at videolan.org>
https://mailman.videolan.org/listinfo/x265-devel
--
Regards,
Kavitha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20160811/c161b0ec/attachment-0001.html>
More information about the x265-devel
mailing list