[peak3d]

@popy could you pls ONLY enable video video component debugging in the component log select box?
This is what I asked for in point 3.) in https://forum.kodi.tv/showthread.php?tid...pid2749504

 @popy I now grepped out the timing values and they look fine.

2. questions

1.) Do you have a A/V unsync from ~ 150 ms?
2.) Can you provide a logcat?
 - navigate to the video (don't play)
 - adb logcat -c
 - play video 30 secs
- adb logcat -d | pastebinit

[Koying]

"reference" does not refer to a large user base.

I agree on the principle, just that, in this specific instance, using an antiquated, deprecated OpenGL as a reference is probably not the proper choice, *especially* if most of your userbase is not even using it.
IIRC, GLES is supported on desktop platforms (fritsch?), so what's the point of OpenGL anymore?

Not that it matters much, as most embedded platforms does not use GL at all as primary renderer, but at least it would make sense

[Koying]

Thought it was generally accepted among people understanding a GL pipeline that forcing a CPU to GPU sync is bad for performance as GL is async most of the time.

I don't get that point. usleep does not halt the GPU, and there is a GPU to CPU sync point when doing the GL buffer swap
In neither approach is the GPU waiting, but the CPU is with both, just that the usleep approach is platform-independent.

EDIT: Well, the GPU *is* waiting, but usleep is making it explicit, while SwapBuffer+vsync makes it implicit.
Result is the same, just that the multiple renderers *not* having implicit each have to reimplement it

[Koying]

Even better it would be if the guys that you paid a whole lot of money would fix their shit ...

Sorry to derail this thread, btw. Just that this kind of remarks I find outrageous.
*If* Netflix, Amazon, Plex, VLC had the same issues, we could argue, but this is just a plain Kodi issue...  

Someone smart surely said at one point that to find the correct answer, you first have to ask yourself the proper question

[FernetMenta]

"reference" does not refer to a large user base.

I agree on the principle, just that, in this specific instance, using an antiquated, deprecated OpenGL as a reference is probably not the proper choice, *especially* if most of your userbase is not even using it.
IIRC, GLES is supported on desktop platforms (fritsch?), so what's the point of OpenGL anymore?

Not that it matters much, as most embedded platforms does not use GL at all as primary renderer, but at least it would make sense   

Also Apple will abandon GL on OSX but that does not matter here. As mentioned, a reference implementation shows how things are supposed to work. Windows does not use OpenGL but is closer to the reference as GLES platforms.

[popy]

@popy could you pls ONLY enable video video component debugging in the component log select box?
This is what I asked for in point 3.) in https://forum.kodi.tv/showthread.php?tid...pid2749504

 @popy I now grepped out the timing values and they look fine.

2. questions

1.) Do you have a A/V unsync from ~ 150 ms?
2.) Can you provide a logcat?
 - navigate to the video (don't play)
 - adb logcat -c
 - play video 30 secs
- adb logcat -d | pastebinit

Tried to get locat running without success. Adb connects to IP:5555 but adb devices says: unauthorized. Also sideloaded apks like catlog failed because root is missing.

Don't want to root my brand new TV.

Is there another way of get logcat running?

PS: There is no popup on adb connect!?

[popy]

Update: it seems in newer firmwares philips is blocking adb.

@CiNcH: can you please try to get a logcat from your Sony like described above from peak3d?
Here is a short description: https://stackoverflow.com/questions/3983...ogcat-logs

[Koying]

Also Apple will abandon GL on OSX but that does not matter here. As mentioned, a reference implementation shows how things are supposed to work. Windows does not use OpenGL but is closer to the reference as GLES platforms. 

  
As usual, you don't listen.
The point is that you're wasting time on OpenGL all the while blaming GLES to not follow.
Making GLES the reference platform solves both issues.

[FernetMenta]

This is the renderer path, btw, not the decoder
Not sure why you think cross-platform sync via usleep is worse than platform-specific hacks (eg waiting for vsync; about droid, is not?

  
btw: the problem you are facing here is caused by optimisations of other GLES platforms. Raspberry Pi and IMX were the first that skipped GUI rendering during video playback. This created the need to throttle the main thread for video layer rendering in case of no GUI rendering.

right, this was just another hack for video layer rendering. see above for proper solution.

[FernetMenta]

Making GLES the reference platform solves both issues. 

  
Wrong. The problem is not the GLES path, the problem is the bypass renderers aka video layer rendering, as done by Android, Raspberry Pi, Rockchip and friends.

[Koying]

btw: the problem you are facing here is caused by optimisations of other GLES platforms. Raspberry Pi and IMX were the first that skipped GUI rendering during video playback. This created the need to throttle the main thread for video layer rendering in case of no GUI rendering.

No. The problems started exactly here: https://github.com/xbmc/xbmc/pull/9542
It's when you decided that the GL Swap + vsync became the sequencing master, obviously putting all non-gl renderers at odd.

Wrong. The problem is not the GLES path, the problem is the bypass renderers aka video layer rendering, as done by Android, Raspberry Pi, Rockchip and friends.

There comes into picture that those are 99.9% of the Kodi devices, which use non-gl primary video renderers. Same for Windows.
Creating a reference (actually OpenGL or GLES matters little; using GLES is "only" the smartest thing to do) that doesn't fit you app actual usage is, sorry to say, braindead.

Video playing devices are embedded platforms, nowadays. Those use a video layer for rendering. Live with it.

[CiNcH]

@CiNcH: can you please try to get a logcat from your Sony like described above from peak3d?

OK, but as I said, I was already in contact with @peak3d concerning this issue and we did not come to a conclusion. Timings are correct according to the log. It is 25p played at 60Hz which the TV's motion interpolator takes care of in the end. And what we are seeing is certainly no fps != Hz judder.
 

yep, h264 in 720p.

Think that it is the 25p that is of interest here...
 

1.) Do you have a A/V unsync from ~ 150 ms?

Typically yes. Interestingly video is earlier. So I would have to set audio offset to "ahead by 225ms". But then I run into juddery playback, see here.
 

 2.) Can you provide a logcat?
 - navigate to the video (don't play)
 - adb logcat -c
 - play video 30 secs
- adb logcat -d | pastebinit

Here we go...

[amcs_stutter_sample(noaudio)_nodebug.txt] (video component logging only)
[amcs_stutter_sample(noaudio).txt] (debug + video component logging enabled)

What's probably worth pointing out is that stutters are always at exactly the same positions. Here again is the YouTube video demonstrating the stutters.


A lot of players on Android TV suffer from the same issue. Just to give a small summary of the thread, here are those that do not:
- stock Video app (libstagefright)
- Kodi 15 (libstagefright)
- SPMC17 (MediaCodec Surface)
- MX Player (HW+ mode/libstagefright)

And those that do suffer from the issue:
- Kodi 16, 17, 18 (MediaCodec Surface)
- SPMC16 (MediaCodec Surface)
- VLC (MediaCodec Surface)
- MX Player (HW mode/MediaCodec Surface)

[peak3d]

thx @CiNcH , I can reproduce the 25/50 on android shield, too.
From what I remember the issue was introduced with OREO update.

Will try to find something, but the timings kodi sends to MediaCodec API look fine (40ms diff between the frames.
So something seems to be not Ok with androids internal renderer for 25/50.

50/50 plays perfect here, even on shield

[CiNcH]

What did you actually play back to reproduce it? On Sony ATV, all Android TV versions from Lollipop to Marshmallow suffered from this issue. Interestingly, the 1080p25 sample from here plays fine though.

[peak3d]

What did you actually play back to reproduce it? On Sony ATV, all Android TV versions from Lollipop to Marshmallow suffered from this issue. Interestingly, the 1080p25 sample from here plays fine though.

 https://drive.google.com/file/d/0BwxFVkl...sp=sharing

I have ~ every 2-3 secs a hickup playing this video.