<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">Le 2014-08-27 17:17, Philippe De Muyter a écrit : </div> <blockquote cite="mid:20140827211724.GA2033@frolo.macqel" type="cite"> <pre wrap="">On Wed, Aug 27, 2014 at 12:19:16PM -0400, Nicolas Dufresne wrote: </pre> <blockquote type="cite"> <pre wrap="">Le mercredi 27 août 2014 à 16:58 +0200, Philippe De Muyter a écrit : </pre> <blockquote type="cite"> <pre wrap="">How can a source having known timeofday timestamps (perhaps even old timestamps as with dv1394 or matroska files) ensure that they are preserved and made available for the sink ? </pre> </blockquote> <pre wrap=""> Would it possible to clarify this question ? Initially you mention v4l2src, other sources behave differently. User can't really assume what is the meaning of a timestamp, but can transform it in one of the known form using the segment. Known forms are stream time, running time, clock time. </pre> </blockquote> <pre wrap=""> I have two use cases : - the first one is real-time acquisition with a v4l2 driver producing timeofday timestamps. In addition to my own processing where I must get access to the timeofday timestamps, I would like to use standard gstreamer plugins to produce video files containing those timestamps. - I must be able to replay those video files to feed them again to my own processing and here also I need to get the original timeofday timestamps. Thus, of course, I need a container format able to save those timestamps. </pre> </blockquote> I've given a second look at the timestamp algorithm (with the delay) and it's in fact correct. The rule has been fixed a long time ago that live source produce timestamp that are running time. To get the original timestamp back, you would have to force (probably implement) a GstClock base on timeofday (see <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> gst_pipeline_set_clock(), currently only CLOCK_MONOTONIC, what correct v4l2 driver produce, are supported). Then the original timestamp will be timestamp + base_time (see <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> gst_element_get_base_time()). This only works for v4l2src and element doing the same thing. Note that to me this is all a bit awkward. I'd would forget about getting the v4l2 timestamp, implement and set a UTC/NTP clock on my pipleine and save the base_time for each generated streams. This way, when I play back the file, I know that the NTP time I want is the streaming + ntp-base-time. What you could do also, which would seem more correct, is to propose a GstV4L2Meta that would expose original timestamp and maybe sequence number along that. That would mean adding public library to v4l2 backend. This, though, would be even more specific. About your request of having a container that store exactly these timestamp, you'll have to read containers internal specification and implementation. They rarely store time-stamp in 64bit form (sometime they only store duration). Nicolas </body> </html>