gstclock and absolute time

Wed Jun 27 03:14:26 PDT 2012

Hi all,

Another update.

Using this pipeline

GST_DEBUG=rtpbin:5 gst-launch --gst-debug-no-color rtspsrc
location=rtsp://192.168.3.27/axis-media/media.amp?audio=0 latency=200
! rtph264depay ! ffdec_h264 ! ffmpegcolorspace ! fakesink

(the log is http://pastebin.com/iYUpyCZR)

I have no more asserts. Anyone can figure out why? Why my UNIX local
time from 0? Is there a way to propagate across the pipeline the
_remote time_, with events or using buffer timestamp?

TIA,

pz-

2012/6/26 Pazzo Da Legare <pazzodalegare at gmail.com>:
> Hi all again,
>
> Probably I found something interesting activating log for "rtpbin":
>
> GST_DEBUG=rtpbin:5 gst-launch --gst-debug-no-color rtspsrc
> location=rtsp://192.168.3.27/axis-media/media.amp?audio=0 latency=200
> ! rtph264depay ! ffdec_h264 ! ffmpegcolorspace ! shmframeserver
> latency=200 ! ffmpegcolorspace ! fakesink
>
>
> http://pastebin.com/ZqaN09MQ
>
> it seems that rtpbin cannot read localtime....any clue? Is it a bug?
>
> BR,
>
> pz
>
> 2012/6/26 Pazzo Da Legare <pazzodalegare at gmail.com>:
>> Dear Josh,
>>
>> I want just to add a bit of info. I'm trying to understand how to
>> correlate data from signal "handle-sync"
>> (http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-gstrtpjitterbuffer.html#GstRtpJitterBuffer-handle-sync)
>>  of GstRtpJitterBuffer and "stats" of rtpsession but I really don't
>> understand what base-time is....
>>
>> This is what I get from GstRtpJitterBuffer "handle-sync" signal:
>>
>> application/x-rtp-sync, base-rtptime=(guint64)2490599386,
>> base-time=(guint64)137714729, clock-rate=(uint)90000,
>> sr-ext-rtptime=(guint64)2491725922,
>> sr-buffer=(buffer)80c800069af6cadbd39457a5e959817b9484b862000003ed0010b1da81ca000c9af6cadb0116726f6f7440616f63632d617869732d646f6d656f6c640204726f6f7406094753747265616d6572000000;
>>
>> and at the same time from rtpsource "stats":
>>
>> application/x-rtp-source-stats, ssrc=(uint)2599865051,
>> internal=(boolean)false, validated=(boolean)true,
>> received-bye=(boolean)false, is-csrc=(boolean)false,
>> is-sender=(boolean)true, seqnum-base=(int)-1, clock-rate=(int)90000,
>> rtp-from=(string)192.168.3.27:50088,
>> rtcp-from=(string)192.168.3.27:50089, octets-sent=(guint64)0,
>> packets-sent=(guint64)0, octets-received=(guint64)1155650,
>> packets-received=(guint64)1060, bitrate=(guint64)703428,
>> packets-lost=(int)0, jitter=(uint)83, have-sr=(boolean)true,
>> sr-ntptime=(guint64)15245907008652149115, sr-rtptime=(uint)2491725922,
>> sr-octet-count=(uint)1094106, sr-packet-count=(uint)1005,
>> sent-rb=(boolean)true, sent-rb-fractionlost=(uint)0,
>> sent-rb-packetslost=(int)0, sent-rb-exthighestseq=(uint)18120,
>> sent-rb-jitter=(uint)97, sent-rb-lsr=(uint)1470108312,
>> sent-rb-dlsr=(uint)337017, have-rb=(boolean)false,
>> rb-fractionlost=(uint)0, rb-packetslost=(int)0,
>> rb-exthighestseq=(uint)0, rb-jitter=(uint)0, rb-lsr=(uint)0,
>> rb-dlsr=(uint)0, rb-round-trip=(uint)0;
>>
>> Does anybody know how to obtain the damn time reference  from
>> sr-rtptime/sr-ntptime to pipeline "absolute time" (aka the  one
>> defined here http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/part-synchronisation.txt)?
>>
>> TIA,
>>
>> pz
>>
>>
>>
>>
>> 2012/6/26 Pazzo Da Legare <pazzodalegare at gmail.com>:
>>> Dear Josh,
>>>
>>> Thank you very much for your links.
>>>
>>> I thought I couldn't find the right parameter to instruct rtspsrc to
>>> propagate the time downstream (or better to say to use the rtsp source
>>> time as clock reference) I was more than sure that it would have been
>>> possible, but now you confirm that a "crazy" idea to manage sr-message
>>> is the only (known) way to extract source reference: I'm trying to
>>> follow exactly the same approach trying to extract absolute time from
>>> rtspsrc and send a metadata event (GST_EVENT_TAG) through my pipeline.
>>> The point is how to correlate internal absolute time (what you can get
>>> with gst_clock_get_time()) and ntptime of RTCP protocol without
>>> _error_ (i.e. taking into account source->rtspsrc transmission time)?
>>>
>>> I can intercept RtpSession information but I have no way to relate
>>> (sr-ntptime, sr-rtptime) with the time (internal absolute time) of the
>>> frame they are referring to. Any clue?
>>>
>>> BR,
>>> pz
>>>
>>>
>>>
>>>
>>> 2012/6/26 Josh Doe <josh at joshdoe.com>:
>>>> On Tue, Jun 26, 2012 at 6:06 AM, Pazzo Da Legare
>>>> <pazzodalegare at gmail.com> wrote:
>>>>> Dear all,
>>>>>
>>>>> How can I convert gst_clock_get_time() value in an absolute time (with
>>>>> year, month, day, ....). I'm playing with an rtsp camera, using
>>>>> rtspsrc, and I would like to retrieve absolute time (ntp stream time)
>>>>> across my pipeline. Is there an easy way to do that?
>>>>>
>>>>> from element's clock time now  (=Tue Jun 26 12:03:34 CEST 2012) I get
>>>>> something like:
>>>>>
>>>>> 6112256969101111
>>>>>
>>>>> and it contains a bunch of thousands of seconds....
>>>>>
>>>>> I'm a little bit puzzled.
>>>>
>>>> gst_clock_get_time() will just give you a monotonically increasing
>>>> integer. Subtracting the base time from that will give you the stream
>>>> time:
>>>> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/chapter-clocks.html
>>>>
>>>> If you're talking about the ISO 8601 timestamps that indicate the
>>>> absolute UTC time, this doesn't appear to be implemented currently:
>>>> http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/gst-libs/gst/rtsp/gstrtsprange.c#n249
>>>> http://tools.ietf.org/html/rfc2326#page-18
>>>>
>>>> A few issues. Not all servers support absolute time ranges. You can
>>>> only get an absolute time if you requested the range in the same
>>>> format, so rtspsrc would need to be given this information. Or you
>>>> could extract a time range from SDP. Either way, you'd need a way to
>>>> get the time to the application.
>>>>
>>>> This last part is what I'm interested. For now I'm sending a
>>>> GST_TAG_DATE_TIME event to indicate the start time of the stream, so a
>>>> buffer absolute time can be calculated from this absolute time and the
>>>> stream time. If there's a better way (GstMeta?) then I'd like to hear
>>>> it.
>>>>
>>>> -Josh
>>>> _______________________________________________
>>>> gstreamer-devel mailing list
>>>> gstreamer-devel at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel