Transmit absolute time

[Sebastian Dröge]

On Sa, 2015-10-24 at 16:07 +0200, Pietro Bonfa' wrote:
> On 10/24/2015 01:08 PM, Sebastian Dröge wrote:
> > On Sa, 2015-10-24 at 12:52 +0200, Pietro Bonfa' wrote:
> > > On 10/23/2015 09:38 AM, Sebastian Dröge wrote:
> > > > That the base time is not known when the first buffer happens
> > > > in
> > > > the
> > > > source is indeed a problem. How are you generating buffers and
> > > > when?
> > > 
> > > Yes, the buffers are generated by appsrc. They are generated when
> > > the
> > > callback function connected to the "need-data" signal is called
> > > so I
> > > assumed that checking the state of the pipeline was not needed.
> > > I will check that in the real implementation running_time +
> > > base_time
> > > gives exactly the time when the buffer is captured and report
> > > back.
> > 
> > Are you timestamping the buffers outside appsrc yourself, or using
> > the
> > do-timestamp=true property?
> 
> I'm using this DIY approach (reporting relevant code from the
> attachment
> of the previous email also available here
> https://github.com/bonfus/GstMadness/blob/master/AppSrcAndSync/test7.
> c)
> 
> 
> static uint frame_count = 0;
> ctx->timestamp = gst_util_uint64_scale_int (1, GST_SECOND, 2) *
> frame_count;
> 
> // simulate wait for camera to produce frame
> struct timespec a;
> a.tv_sec=0;
> a.tv_nsec=100;
> while (ctx->timestamp > (gst_clock_get_time (global_clock)-ctx-
> >begin))
> {
>   nanosleep(&a, NULL);
> }
> 
> GST_BUFFER_PTS (buffer) = ctx->timestamp;
> 
> However let me mention that this is just some (bad) code I wrapped
> from various examples in order to learn something about timestamping.
> I don't really care if the code is wrong. I care to know that my
> conclusion from the previous post were wrong as you told me!

By timestamping from outside appsrc, you don't really know when the
element reached the PLAYING state. You can only get the base time (and
are guaranteed to get a clock) when the element is in PLAYING. And
should not produce any buffers before that.

> > > Finally, just to keep you posted, I implemented metadata in the
> > > GstElement that parses the RTP extension and then I discovered
> > > that
> > > metadata are generally not copied through the pipeline (damn!).
> > 
> > If you're using 1.6, generic metadata will be copied over. If an
> > element doesn't you found a bug :)
> 
> Is there a special definition for generic metadata?
> 
> I found that identity, queue and tee copy my metadata while
> rtph264depay doesn't.

rtph264depay only copies over metadata that has no tags, or tags that
it can transform or understand (currently none).

> > Which tags did you use to register your metadata?
> > 
> 
> Initially I just used some dummy values like
> 
> static const gchar *tags[] = { "id", "val", NULL };

Remove the tags and then it should work :)
The tags mean to which "aspect" of a buffer the metadata applies. For
example there are tags for memory, audio, video, video-dimensions, etc.

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151024/6d4d456f/attachment.sig>