
<html><head></head><body>Actually no. We should just ditch GET_TIME entirely, and report the offset from timestamps to normal play time when that offset changes (as opposed to when the PCR changes). The offset is essentially the PTS value corresponding to NPT zero.<br><br>Reporting values that change all the time does not make sense. Or rather it's impossible.<br><br>The issue is what to do with GET_POSITION. If there is a known length, then we can compute position as:<br>NPT = PTS - PTS_offset<br>Position = NPT / Length<br><br>But is there a demuxer that can compute a position but not a total length?<br><br><div class="gmail_quote">Le 10 mars 2021 13:51:53 GMT+02:00, "Rémi Denis-Courmont" <remi@remlab.net> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Hi,<br><br>I can see the argument for converting GET_TIME and GET_POSITION to events, and then GET_TITLE, and GET_CHAPTER. But duration (GET_LENGTH) and NPT offset are mostly constant. NPT does not look like the most pressing issue in terms of conversion from polling to event.</blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>