Review inconsistencies / use / requirement for ClockTime about gst1-java-core HOT 3 CLOSED

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 .

from gst1-java-core.

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.

from gst1-java-core.

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! 😄

from gst1-java-core.