Bursts in UDP streaming

[Alexis Berlemont]

Hi,

I would like to understand why the following pipeline bursts groups of
packets every 100 ms:

filesrc ! mpegtsdemux ! mpegtsmux ! udpsink.

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.

------------------------------------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Alexis Berlemont]

Hi,

On Wed, May 19, 2010 at 5:11 PM, Alexis Berlemont
<[hidden email]> 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.

------------------------------------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel