Uoti Urpala wrote:
"0 otherwise" is questionable IMO as it's a valid position (though nothing seems to check that now).
With return type "int" this is suitable for OSD use only (and you might want a more precise value for that too in some situations).
yes, I'll unify to double all timing-related functions
I think it's very questionable to make a demuxer-level function to query the current time. The demuxer packets could be buffered and the demuxer shouldn't know which part is being _displayed_ at the moment. If there's a better guess about the current time than the value that is now set as pts in the packets
whether the current timing is more precise than demux timestamps depends on the implementation of _GET_CURRENT_TIME control; in the case of dvd it's absolutely not better (something better than 1 second of accuracy)
then either 1) the pts should be set to that value instead,
not the case
or if the value is not suitable for pts use then 2) it should be placed in another field associated with the demuxed packets.
why there should be a link between demux packets (demux-stream specific) and playtime (mux/stream specific) ? Don't forget that this function is intended to show on the OSD the value of the current playtime, not to be used as a central synchronization clock