Clock / queue issue

[David Jaggard]

On 23 December 2015 at 15:44, Sebastian Dröge <sebastian at centricular.com>
wrote:

>
> Which demuxer is this? Are you transferring MPEG-TS over RTP?


Yes it's going in to rtpmp2tdepay and tsdemux.


> Also
> which transcoding elements are used?


On the video side it is going into decodebin (h264parse, avdec_h264) ->
deinterlace -> x264enc -> rtph264pay

On the audio side it is decodebin (aacparse, avdec_aac_latm) ->
audioconvert (converting from F32LE 2 channel to S16LE, 1 channel ) ->
audioresample (48K in and 48K out) -> VoAacEnc -> rtpmp4gpay


> Does the same happen if you only
> output the audio/video directly to a sink without transcoding and also
> without sending over the network again?
>

I'll have to set those scenarios up separately and they will take a long
time to run.

>
> The clock-slaving algorithm implemented in rtpbin (rtpjitterbuffer to
> be exact) should prevent such problems if caused by clock drift between
> the sender and receiver clock.
>

Forgive my ignorance on this but why would this pipeline need to care about
clock drift? Should it not just take each frame as it arrives and process
it as fast as possible such that the output frame rate would be identical?

>
> --
> Sebastian Dröge, Centricular Ltd · http://www.centricular.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/20151223/6b4375c2/attachment.html>