I am debugging a C++ video renderer that uses eglPresentationTimeANDROID() to improve the lipsynk. This egl extension is not available on all devices I tested, but for some (e.g. adreno), it must be manually disabled - otherwise the stream gets stuck. I understand that some devices actually ignore the PTS (cf. Android Native Window timestamp).
I have recently faced more devices (quite exotic) that fail when this feature is enabled, and I consider disabling it altogether. But to make this decision I want to measure the effect of this PTS before I decide to get rid of it.
Usually, the only way to see the extension having any effect is to use systrace to monitor the output of something like Grafika's "scheduled swap" Activity (which was created for this purpose). There's no reason for a stream to get stuck, at least in the AOSP sources; I don't know what code might have been added by OEMs.
The logic at render time should be:
Badly-formed PTS values should pause display for at most a second. Timestamps use the monotonic clock, so aren't subject to clock updates.
It's not necessary to use the feature so long as you can pace submission of video frames perfectly. The point of the extension was to make it easier for apps to manage sync. The goal was to use it in the system video players to improve sync, but I don't know if that actually happened. (I don't see it used in AOSP sources.)