[FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
christophe.gisquet at gmail.com
Fri Jan 22 18:32:46 CET 2016
2016-01-22 14:29 GMT+01:00 John Cox <jc at kynesim.co.uk>:
>>This is a big slowdown on Win64 and UHD-bluray like sequences, but
>>that can be switched off in that case.
> I'm a bit surprised that it generated a big slowdown - some cache must
> be running just on the edge, but yes if you normally have hi-bitrate
> stuff then it isn't wanted. On my test streams the bitrates were
> normally quite low - quite unlike what I would expect from blu-ray
Initial (4 sequences):
6553 decicycles in g, 8387110 runs, 1498 skips
5916 decicycles in g,33546118 runs, 8314 skips
5028 decicycles in g,67101499 runs, 7365 skips
4729 decicycles in g,33548420 runs, 6012 skips
4746 decicycles in g,16774296 runs, 2920 skips
5373 decicycles in g,33545629 runs, 8803 skips
4141 decicycles in g,67098928 runs, 9936 skips
3869 decicycles in g,33544593 runs, 9839 skips
But I see the first one surprisingly having half the iterations (but
this has almost converged at this point).
I think it has more to do with cache pressure, both code, which
increases from 8 to 9.5KB, and data, with already "large" tables in a
loop that may need to tight.
> Default it to off on x86 but on on ARM?
Yes, I think so.
More information about the ffmpeg-devel