Current Position of Stream at receiver side in RTP

[Chuck Crisler]

The RTP timestamp should reflect when the packet was put into the RTP
payload (or perhaps when initially encoded) and should also be based on
90,000 Hz sample rate, baring dropped packets. You could compute the time
from the first received timestamp until the current, but you would have to
account for rollover, which happens pretty quickly. However, this doesn't
give any indication of how long the video sequence is, you only know how
much you have received, not what percentage of the total. If you want that
you would need to communicate the total length out of band, which would be
easy enough to do.


On Wed, Nov 13, 2013 at 3:59 AM, danil4u <danil4u at gmail.com> wrote:

> Hi,
>    I'm using using RTP to stream my video data from Server to Client. It
> works fine.
>
> Now I want to show the progress bar on server and client, on server side I
> could able to do it using the gst_element_query_positon() but on client
> side(received side) If I use the same API even though I get current time
> but
> it seems it is gst pipeline time, that means even though I don't get data
> from server, this time is still increasing. Is there anyway of knowing the
> time information from received RTP packet? how to print that timestamps
> value into some local variable?
>
> thanks
>
>
>
> --
> View this message in context:
> http://gstreamer-devel.966125.n4.nabble.com/Current-Position-of-Stream-at-receiver-side-in-RTP-tp4663287.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20131113/1e172b11/attachment.html>