tsdemux(of version 0.10.23) : new segment event problem

[Edward Hervey]

Hi,

  That's the old logic. In 1.x the logic is more robust to such cases.

  We don't provide support for 0.10 anymore.

   Regards,

     Edward


On Mon, 2014-03-03 at 21:19 -0800, ShivaKumar wrote:
> 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.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-- 
Edward Hervey
bilboed at bilboed.com