Mauro Carvalho Chehab wrote:
[clip]
Hi Sakari,
What is that status of the event API? It is my impression that it is pretty
much finished. Sakari, can you make a final 2.3 RFC? Then Guru can take over
and start the implementation.
Ah.
One thing that I was still wondering was that are there use cases where
other kind of time stamps might be useful? I guess that when the V4L2
was designed no-one though of the need for time stamps of different
type. So are there use cases where gettimeofday() style stamps would
still be better?
If you ever need to relate an event to a specific captured frame, then that
might well be useful. But I can't think of an actual use case, though.
In that case we might choose to leave it driver's decision to decide
what kind of timestamps to use and in that case application would just
have to know. The alternative would be to use union and a flag telling
what's in there.
Let's go with timespec. If we need to add an event that has to relate to
a specific captured frame then it is always possible to add a struct timeval
as part of the event data for that particular event.
I don't agree. It is better to use the same timestamp type used by the streaming
interface. Having two different ways to represent it for the same devices is
confusing, and changing it later doesn't make sense. I foresee some cases where
correlating the two timestamps would be a need.
timespec style timestamps are superior in video encoding, for example.
timeval is wall clock time which is unsuitable for video encoding due to
clock slewing and daylight saving time.
ALSA and Gstreamer use monotonic clock (someone correct me if I'm
wrong!, cc Stefan Kost) which is more usable for multimedia
applications. The rate for gettimeofday() clock is different than
clock_getres(CLOCK_MONOTONIC) which in practice means that the process
acquiring the video buffers must call clock_getres() after VIDIOC_DQBUF
to properly timestamp the buffers. This kind of timestamping, however,
depends on the process' ability to run immediately.
I wouldn't want to carry this kind of problems on to the event interface.
One possibility would be also to create events when new video buffers
become available. Then both the event and the corresponding video buffer
would be available, having the same field_count. Perhaps not pretty but
would well make it possible to compare the timestamps.
--
Sakari Ailus
sakari.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
