Receiver pipeline fails to goto playing state in streaming audio scenario

[danny.smith]

Hi,

We have built an  application in where a sender streams audio to multiple
receivers over a network 
where we use this approach: 

*Sender

Setup netclock provider (server)
Use system clock for that and the pipeline
ntp-time-source”: clock-time

*Receiver

Setup netclient clock with sender's server
Use that for the pipeline and set 500ms fixed latency
ntp-time-source”: clock-time, “ntp-sync”: TRUE, “buffer-mode”: synced

based on this presentation:
https://gstreamer.freedesktop.org/data/events/gstreamer-conference/2015/Sebastian%20Dr%C3%B6ge%20-%20Synchronised%20multi-room%20media%20playback%20and%20distributed%20live%20media%20processing%20and%20mixing%20with%20GStreamer.pdf

We are experiencing an issue during setup where the receiver pipeline fails
to go to Playing state due to the rtpjitterbuffer either throwing away all
data or buffering it. This prevents the rtpbin from creating a src-pad and
we cannot link our pipeline. This happens maybe around 20% of the time.

Using buffer-mode: synced the rtpjitterbuffer should use the first recieved
buffers timestamp as base time, could it be that this mechanism fails for
some reason causing the jitterbuffer to believe that all packets are either
late or should be played some time in the future? 
Could there be another explanation for this issue?

Can mention that our receiving pipeline uses a short jitterbuffer and and a
short total pipe latency in order to achieve low latency streaming.

If we wanted to manage base time ourselves by getting the timeproviders
current time stamp and distributing/applying this time stamp to the
receivers using these calls:
gst_pipeline_use_clock (clock);
gst_element_set_start_time(pipeline, GST_CLOCK_TIME_NONE);
gst_element_set_base_time(pipeline, base_time);
, should we also apply this time stamp on the sender pipeline?

Which buffer-mode should we use if we want to manage base time ourselves?

Do we need to alter any of the other above mentioned parameters if we want
to manage base time ourselves? 

Regards,
Danny





--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Receiver-pipeline-fails-to-goto-playing-state-in-streaming-audio-scenario-tp4683285.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.