tsdemux(of version 0.10.23) : new segment event problem

[ShivaKumar]

Hi all,


I am using "tsdemux" of gst-plugins-bad of version 0.10.23 in push mode.
Where tsdemux uses first pts of whichever stream(audio/video) comes first as
a start time of new segment event for all other streams also.

i.e., if audio packet comes first, then tsdemux uses pts of that first audio
packet as the start time of  new segment for both audio and video.

My question is why is this designed so, why not use first pts of video for
video pad new segment and why not first pts of audio for audio pad new
segment. 


In my case audio packets is coming first and its pts is used as start time
for new segment for both audio and video and the difference between first
audio and video packet pts is around ~35ms. Since basesink for video is
using this new segment time for converting buffer time to running time of
video frame, the difference ~35 ms is getting added up for my video pipeline
latency.


Below is the equation that base sink uses for converting buffer time to
running time


( pts of a video frame ) - ( start time of newsegment event(which is pts of
first audio packet here) + base_time

So just repeating my question, why is tsdemux is designed so. 

Please help...





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