[gst-devel] Bursts in UDP streaming

[Alexis Berlemont]

Hi,

On Wed, May 19, 2010 at 5:11 PM, Alexis Berlemont
<alexis.berlemont at gmail.com> wrote:
> Hi,
>
> I would like to understand why the following pipeline bursts groups of
> packets every 100 ms:
>
> filesrc ! mpegtsdemux ! mpegtsmux ! udpsink.
>
I took some little time to look back at this issue. The first time, I
did not notice that the buffers' timestamps were not increasing
correctly. The step is indeed 40 ms but instead of having:
-> 40 80 120 160 200 240
I have:
120 40 80 240 160 200

I isolated this problem in mpegtsdemux. The TS demux seems to use the
PTS values so as to timestamp its output buffers. This seems the
correct behaviour for a decoding context but not for a remuxing one,
especially when the TS muxer does not seem to re-timestamp its output
buffers.

Concerning the TS muxer, there are some points I do not understand.
Because of the collect method, I did manage to make the following
pipeline work without queue:
filesrc ! mpegtsdemux  demux.video ! mpegstsmux ! udpsink
                                  demux.audio_____|

The thread was stuck in the TS muxer because some sink pads were
empty. So I add to inject queues between the demuxer and the muxer.Is
it the correct solution?

With queues between the demuxer and the muxer, I faced another problem
which occurs randomly: one the component (either audio or video) is
not present in the output stream and some critical messages are
printed at a high rate:
CRITICAL **: tsmux_stream_bytes_in_buffer: assertion 'stream != NULL' failed
CRITICAL **: tsmux_stream_add_data: assertion 'stream != NULL' failed
...

Any idea ?

Is mpegtsmux adapted for streaming ?

> In order to understand this phenomena, I looked at the code of
> gstmultiudpsink. I tried to find out which function was in charge of
> checking the buffer timestamp and performing the real sleep.
> If my understanding of the situation is correct, the call stack is like this:
>
> gst_base_sink_render_object ->
> gst_base_sink_do_sync ->
> gst_base_sink_wait_clock -> ... gst_clock_id_wait
>
> Am I correct ? Did I miss something ? anything ?
>
> With a debugger, I tried to monitor the value of the argument "time"
> in the function gst_base_sink_wait_clock. As I was unable to use
> tracepoints (because of threads), I add a dirty g_print in the source
> code. So, I saw that the timestamp was increasing regularly by step of
> 40 ms.
>
> If the step is 40 ms, does anyone have an idea why wireshark record
> bursts every 100ms?
>
> Does anyone know how to reduce the 40 ms step (it seems like the PCR
> interval, doesn't it ? ) ?
>
> Many thanks in advance.
>
> Alexis.
>

Alexis.