Review inconsistencies / use / requirement for ClockTime

[neilcsmith-net]

Clock/timing methods accept and return ClockTime, mapped to/from long. However, Structure::getValue return a Long for clock times. Should make these consistent, and for efficiency why are we not just returning long?

[mutantbob]

One thing I would point out is that ClockTime has methods like fromMillis and fromMicros. If you decide to get rid of ClockTime, all the javadocs (and parameter names) should make it clear that the long is expressed in nanoseconds (or whatever unit is appropriate). I would even go so far as to rename ClockTime.value to ClockTime.nanos .

[neilcsmith-net]

Agreed, and ClockTime might persist in some capacity as a utility class (or we just refer people to TimeUnit). The key thing is to make Structure::getValue consistent with other uses, and remove ClockTIme from the lowlevel mappings so we're not creating unnecessary objects - not cheap there!

ClockTime is just an unsigned 64-bit long in GStreamer - this change would be (mostly) consistent with upstream.

[neilcsmith-net]

OK, ClockTime will be replaced by long for all parameters and return types. The type information is just not available from the native layer to make this consistent. But do we switch to TimeUnit for conversion, or make ClockTime a similar enum and utility holder wrapping TimeUnit? And potentially handling the fact that the value is an unsigned long - although wrapping shouldn't be an issue any time soon! 😄