In my latest test build LE 9.0 aren't any frames skips for subtitles:
LibreELEC-S905.arm-8.90.5-12-gf54f8c3-K.tar
I tested it with video form #1.
BTW in log from from #1 aren't any frame skips. Frame skip is reported in log as:
10:47:11.431 T:4096036880 DEBUG: CRenderManager::PrepareNextRender idx:0 Skip:1 iter.pts:0.250 m_lf:9 lf:1071286228 latency:0.100 dvdClock:0.298Pls report any issue with kodi debug log.
In my latest test build LE 9.0 aren't any frames skips for subtitles:
LibreELEC-S905.arm-8.90.5-12-gf54f8c3-K.tar
I tested it with video form #1.
I wish I could confirm that but I had other results. With 8.90.5 I still have stuttering on my Minix S912. No idea why the log doesn't show it but I see a few dropped frames and as it seems I'm not the only one. Some are sensitive and others not at all. I belive my eyes only.
I wish I could confirm that but I had other results. With 8.90.5 I still have stuttering on my Minix S912.
This is different build with new fixies.
And next time report only with log.
In my latest test build LE 9.0 aren't any frames skips for subtitles:
LibreELEC-S905.arm-8.90.5-12-gf54f8c3-K.tar
I tested it with video form #1.
Is there a corresponding build for S912 devices as the Minix U9-H? thanks
Is there a corresponding build for S912 devices as the Minix U9-H? thanks
I am preparing LE 8.90.6 for S912.
I am preparing LE 8.90.6 for S912.
Thanks that's very nice! Will test it for sure!!
Subtitle rendering issue is presented only in LE 9.0 for S912. It looks like issue with libhybris. In log I see lost of control for >100ms. I'll try to collect more precise debug information. Zero skips for testing video played by LE 9.0 S905.
Subtitle rendering issue is presented only in LE 9.0 for S912. It looks like issue with libhybris. In log I see lost of control for >100ms. I'll try to collect more precise debug information. Zero skips for testing video played by LE 9.0 S905.
Thank you mate. It's nice to see some light at the end of the tunnel 
afl1 Perhaps you could try removing this line to remove the wait for vsync: LibreELEC.tv/libhybris-0001-fbdev_window-wait-for-fence-to-be-signalled-and-clos.patch at libreelec-8.2 · kszaq/LibreELEC.tv · GitHub
Of course this would cause GUI tearing but it's worth a try.
afl1 Perhaps you could try removing this line to remove the wait for vsync: LibreELEC.tv/libhybris-0001-fbdev_window-wait-for-fence-to-be-signalled-and-clos.patch at libreelec-8.2 · kszaq/LibreELEC.tv · GitHub
Of course this would cause GUI tearing but it's worth a try.
I tried to remove the wait for sync, it didn't help.
Finally I have got the subtitle rendering issue evidence. Responsible for this issue is libhybris. Swapping buffers in rendering takes ages >36ms.
At 24fps to show one frame takes 41.7ms, but with rendering subtitles took 43ms.
13:24:47.707 T:4098699280 DEBUG: CAMLCodec::PollFrame - ok
13:24:47.707 T:4098699280 DEBUG: Render: CRenderManager::Render - method:0
13:24:47.707 T:4098699280 DEBUG: Render: CRenderManager::Render - next method:0
13:24:47.707 T:4098699280 DEBUG: CVideoPlayer::Render clear:0 alpha:255 gui:0
13:24:47.707 T:4098699280 DEBUG: CApplication::Render - Flip()13:24:47.707 T:4098699280 DEBUG: CGLContextEGL::SwapBuffers - begin
13:24:47.709 T:3633525584 DEBUG: CVideoPlayer::ProcesVideoData size:134808 dts:15.391 pts:15.558 dur:41.000ms, clock:6.943 level:105
13:24:47.711 T:3603944272 DEBUG: CAMLCodec::GetTimeSize: len:15 dl:1380753 fs:1286842 front:117516
13:24:47.711 T:3633525584 DEBUG: CVideoPlayer::ProcesVideoData size:78039 dts:15.432 pts:15.474 dur:41.000ms, clock:6.945 level:106
13:24:47.711 T:3603944272 DEBUG: CAMLCodec::DequeueBuffer: Try again after: 3ms
13:24:47.712 T:3633525584 DEBUG: CVideoPlayer::ProcesVideoData size:65331 dts:15.474 pts:15.516 dur:41.000ms, clock:6.946 level:106
13:24:47.715 T:3633525584 DEBUG: CVideoPlayer::ProcesVideoData size:142004 dts:15.516 pts:15.683 dur:41.000ms, clock:6.949 level:107
13:24:47.717 T:3603944272 DEBUG: CAMLCodec::GetTimeSize: len:15 dl:1308817 fs:1286842 front:117516
13:24:47.717 T:3603944272 DEBUG: CAMLCodec::DequeueBuffer: Try again after: 3ms
13:24:47.719 T:3633525584 DEBUG: CVideoPlayer::ProcesVideoData size:81159 dts:15.558 pts:15.599 dur:41.000ms, clock:6.953 level:107
13:24:47.720 T:3633525584 DEBUG: CVideoPlayer::ProcesVideoData size:66056 dts:15.599 pts:15.641 dur:41.000ms, clock:6.954 level:108
13:24:47.721 T:3603944272 DEBUG: CAMLCodec::GetTimeSize: len:15 dl:1286545 fs:1286842 front:117516
13:24:47.721 T:3603944272 DEBUG: CAMLCodec::GetTimeSize: len:14 dl:1286545 fs:1169326 front:104375
13:24:47.722 T:3603944272 DEBUG: CAMLCodec::GetPicture: VC_BUFFER LEV:0.58 ttd:-32ms x:-0.05
13:24:47.722 T:3603944272 DEBUG: CAMLCodec::ADDData: dl:1286545 sum:1226919 sz:57593
13:24:47.722 T:3603944272 DEBUG: CAMLCodec::AddData: dl:1286545 sum:1226919 sz:57593 dts_in:7.925 pts_in:7.967 ptsOut:6.924 ttd:-32ms overflow:0
13:24:47.722 T:3603944272 DEBUG: CAMLCodec::GetTimeSize: len:15 dl:1312272 fs:1226919 front:104375
13:24:47.722 T:3603944272 DEBUG: CAMLCodec::DequeueBuffer: Try again after: 3ms
13:24:47.727 T:3603944272 DEBUG: CAMLCodec::GetTimeSize: len:15 dl:1344138 fs:1226919 front:104375
13:24:47.727 T:3603944272 DEBUG: CAMLCodec::DequeueBuffer: Try again after: 3ms
13:24:47.731 T:3603944272 DEBUG: CAMLCodec::GetTimeSize: len:15 dl:1344138 fs:1226919 front:104375
13:24:47.731 T:3603944272 DEBUG: CAMLCodec::DequeueBuffer: Try again after: 3ms
13:24:47.735 T:3603944272 DEBUG: CAMLCodec::GetTimeSize: len:15 dl:1344138 fs:1226919 front:104375
13:24:47.735 T:3603944272 DEBUG: CAMLCodec::DequeueBuffer: Try again after: 3ms
13:24:47.740 T:3603944272 DEBUG: CAMLCodec::GetTimeSize: len:15 dl:1344138 fs:1226919 front:104375
13:24:47.740 T:3603944272 DEBUG: CAMLCodec::DequeueBuffer: Try again after: 3ms
13:24:47.743 T:4098699280 DEBUG: CGLContextEGL::SwapBuffers - end
13:24:47.743 T:4098699280 DEBUG: CApplication::Render - return
13:24:47.743 T:4098699280 DEBUG: CXBApplicationEx::Run - Repeat13:24:47.744 T:4098699280 DEBUG: CXBApplicationEx::Run - FrameMove()
13:24:47.744 T:3603944272 DEBUG: CAMLCodec::GetTimeSize: len:15 dl:1344138 fs:1226919 front:104375
13:24:47.744 T:3603944272 DEBUG: CAMLCodec::DequeueBuffer: idx:167 pts:6.966
13:24:47.744 T:3603944272 DEBUG: CAMLCodec::GetPicture: index:167, pts:6.966 dur:42.000ms overflow:0
13:24:47.745 T:3603944272 DEBUG: CVideoPlayerVideo::OutputPicture - ttd:-12ms pts:6.966 Clock:6.979 Level:2
13:24:47.746 T:3603944272 DEBUG: CAMLCodec::GetTimeSize: len:15 dl:1344138 fs:1226919 front:104375
13:24:47.746 T:3603944272 DEBUG: CAMLCodec::DequeueBuffer: Try again after: 3ms
13:24:47.746 T:4098699280 DEBUG: CRenderManager::FrameMove - start
13:24:47.746 T:4098699280 DEBUG: PrepareNextRender: frameOnScreen: 6.980 renderPts: 7.111 nextFramePts: 6.882 -> diff: 0.229 render: 1 forceNext: 0
13:24:47.747 T:4098699280 DEBUG: CRenderAML::ReleaseBuffer - idx:164
13:24:47.747 T:4098699280 DEBUG: CRenderManager::FrameMove - released buffer:5
13:24:47.747 T:4098699280 DEBUG: CXBApplicationEx::Run - Render()
13:24:47.748 T:4098699280 DEBUG: Render: CRenderManager::Render - next method:0
13:24:47.748 T:4098699280 DEBUG: CVideoPlayer::Render clear:1 alpha:255 gui:1
13:24:47.750 T:4098699280 DEBUG: CApplication::Render - RenderEx()
13:24:47.750 T:4098699280 DEBUG: CAMLCodec::ReleaseFrame idx:165, drop:0
13:24:47.750 T:4098699280 DEBUG: CRenderAML::RenderUpdate - released idx:165 pts:6.882
13:24:47.750 T:4098699280 DEBUG: CAMLCodec::PollFrame - ok
Swapping buffers in S905 takes only 1ms.
14:07:00.947 T:4100100112 DEBUG: CApplication::Render - Flip()
14:07:00.947 T:4100100112 DEBUG: CGLContextEGL::SwapBuffers - begin
14:07:00.948 T:4100100112 DEBUG: CGLContextEGL::SwapBuffers - end
14:07:00.948 T:4100100112 DEBUG: CApplication::Render - return
afl1 Great find. Does it also take that long if you disable vsync?
It doesn't help.
Finally I have got the subtitle rendering issue evidence. Responsible for this issue is libhybris. Swapping buffers in rendering takes ages >36ms.
I'm so glad you have found evidence for the issue. Does this mean you don't need a debug log anymore ? I didn't had much time yesturday ( and now I'm at work ) but I was able to test your latest ( 8.90.6 ) buld for the s912 and I can say with confidence that the stuttering is still present with subtitles enabled. It doesn't matter if its embedded or external srt. I've used the same scene as it's the sample in #1. But this time double checked with both ( mkv) remuxes from the BD and UHD-BD. Same result.
For now there is only solution replace S912 box with S905 box.
For now
I understand that you guys do this for free and I'm really appreciate it so it's just a question and I don't want to sound unpatient or something.
Does "For now" means that you will continue to work to solve this specific issue for the S912 or that would rather mean the issue may be solved in the not so near future ?
Read warning in #1. Using libhybris and Android gralloc Mali driver this issue is unable to fix. If you want to use LE for S912 you have to tolerate subtitle stuttering.
avirex I don't think it'd be an easy task to solve. Libhybris for GPU means lots of trials and errors and I've already tried many things to overcome the swapbuffer delay. But maybe someone with a fresh look will find a solution for this...
