[FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)

Michael Niedermayer michael at niedermayer.cc
Thu Jan 28 00:40:57 CET 2016


On Fri, Jan 22, 2016 at 05:54:30PM +0000, John Cox wrote:
> Hi
> 
> >Hi,
> >
> >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
> >> sequences.
> >
> >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
> >
> >Deactivating USE_N_END_1:
> >    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).
> >So 10-20%.
> 
> Coo - that is big.
> How are you profiling that and with what streams?

seems this question was missed
the stuff above used START/STOP_TIMER() i assume
i dont know which streams where used


> 
> >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.
> 
> I agreee (and it is what I was trying to suggest in my previous
> comment).  It also suggests that on x86 you might benefit from
> non-inlined cabac_gets to keep the code size small.
> 

> >> Default it to off on x86 but on on ARM?
> >
> >Yes, I think so.
> Is ARCH_X86/ARM an appropriate switch for this?

yes

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160128/415dbe75/attachment.sig>


More information about the ffmpeg-devel mailing list