tsdemux(of version 0.10.23) : new segment event problem

ShivaKumar shivakumar.mudugal at gmail.com
Wed Mar 5 21:02:22 PST 2014


Even in the document link which you have asked to refer says below words
under "Timestamps" section


-----------------------------------------------------------------------------------------
The following transformation to running_time exist:

    if (NS.rate > 0.0)
      B.running_time = (B.timestamp - NS.start) / NS.abs_rate + NS.accum
    else
      B.running_time = (NS.stop - B.timestamp) / NS.abs_rate + NS.accum

We write B.running_time as the running_time obtained from the NEWSEGMENT
event
and the buffers of that segment.

*The first displayable buffer will yield a value of 0 (since B.timestamp ==
NS.start and NS.accum == 0).*
--------------------------------------------------------------------------------------------


i.e., running time of first video displayable buffer should also be 0 (since
B.timestamp ==
NS.start), in this tsdemux case since it is giving first audio pts as
NS.start running time for first video buffer is not zero instead is +35
milli seconds, and hence the total time comparable against clock (i.e.,
absolute_time) also increased by 35 milli seconds which is adding to the
delay... 

So if you go by what synchronization document says for all stream
(audio/video) its corresponding first pts should be  NS.start... which is
not the case in tsdemux.





--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/tsdemux-of-version-0-10-23-new-segment-event-problem-tp4665712p4665778.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.


More information about the gstreamer-devel mailing list