3

Reference - Why sliced thread affect so much on realtime encoding using ffmpeg x264?

With Zerolatency / sliced-threads enabled, I am observing that the decoding time shoots up! I am encoding on my Windows 10 laptop and streaming to Samsung S4 phone where it is decoded and rendered. If usually, decoding takes 2-3 ms, it shoots up to around 25 ms if I use sliced-threads. It is a real time streaming application so I need low latency and that's why I enabled zerolatency. Can someone help please?

I am using the hardware decoder on the phone.

Community
  • 1
  • 1
Ajay Ponna Venkatesh
  • 71
  • 1
  • 6
  • Did you try the intra-refresh? http://www.chaneru.com/Roku/HLS/X264_Settings.htm#intra-refresh – RawBean Apr 14 '16 at 15:23
  • Hi @RawBean, I tried enabling the 'intra-refresh' option. It does not help at the encoder side i.e. the NAL output is got only after around 7 packets are fed to the encoder (This is because of the frame-threading). When we give zero-latency or sliced-threads=true, each frame is sliced into as many slices as number of threads so that NAL output is available right after first frame. My issue is that with this, decoding time increases! I am not sure why zero latency should increase decoding time. – Ajay Ponna Venkatesh Apr 17 '16 at 08:24
  • Can someone help please? – Ajay Ponna Venkatesh May 05 '16 at 14:07
  • Good question. Not obvious answer. I will have a look at the source code and will try to help you. – RawBean May 05 '16 at 15:05
  • Thanks @RawBean. My requirement is for a live streaming kind of application where my goal is to reduce latency to minimum. For this, I want the encoder output (NAL) to be available immediately without any other side effect. Zero-latency solves my first problem but it increases decoding time which doesn't help me. – Ajay Ponna Venkatesh May 09 '16 at 09:56
  • With my minimal understanding of the x264 code, I tried doing this hack - I made "threads=1" so that even through frame based threading (parallel encoding) happens, I am limiting the number of threads to 1. So the output would be available immediately. This works for 720p content but for a 1080p content, just 1 thread for encoding chokes up the CPU and encoding time shoots up! I will be looking forward for some workaround to my issue from you :) – Ajay Ponna Venkatesh May 09 '16 at 09:56
  • did you try the option "fastdecode" in addition to "zerolatency"? You could use the two at the same time, and it must decrease decoding time. – RawBean May 09 '16 at 11:30
  • Yes, that was the first thing I tried. In fact, I'm using 'ultrafast' cpu preset option. That already takes care of all parameters that are set for fastdecode. However, for my confirmation again, I tried enabling fastdecode on top of zerolatency and my observations are with these settings itself. No reduction in decoding time. Please note I'm using native android hardware decoder. – Ajay Ponna Venkatesh May 14 '16 at 05:29
  • I guess it's related to the hw decoder too. Only a guy knowing the limitations of that hw could answer you. – RawBean May 14 '16 at 05:32

0 Answers0