udpsrc: Video becomes jerky after one hour of playback

[Aleksey Yulin]

We're trying to play a TS stream unicasted to the udp port. After adding a queue element after the udpsrc the playback is fine. Our pipeline looks as follows:

udpsrc port=1234 ! queue ! decodebin2 ! ffmpegcolorspace ! xvimagesink

But after an hour of playback the video picture becomes jerky, covered by multiple green boxes and other artifacts. It looks like some frames are being dropped on the source or decoder starts to skip them.

What could be the reason for this issue? Is it possibly that the queue becomes emty and doesn't fill again? We tried to use 'queue2' instead of 'queue' but got the same result.

Additional info:

As we investigated the problem doesn't occur when no audio is decoded. With only video stream decoded and rendered everything is OK.
With audio enabled we could see the following messages in the log when the issue occurs:

0:00:49.150325603  5059  0xa058430 WARN              mp3parse gstmpegaudioparse.c:1418:head_check:<mpegaudioparse0> invalid sync
0:01:08.432148631  5059  0xa058430 WARN         baseaudiosink gstbaseaudiosink.c:961:gst_base_audio_sink_skew_slaving:<autoaudiosink0-actual-sink-alsa> correct clock skew 10668150 > 10666500
0:01:08.456541406  5059  0xa058430 WARN         baseaudiosink gstbaseaudiosink.c:985:gst_base_audio_sink_skew_slaving:<autoaudiosink0-actual-sink-alsa> correct clock skew -10747958 < -10666500
0:01:08.602715248  5059  0xa058430 WARN         baseaudiosink gstbaseaudiosink.c:961:gst_base_audio_sink_skew_slaving:<autoaudiosink0-actual-sink-alsa> correct clock skew 10675206 > 10666500
0:01:08.780355617  5059  0xa058430 WARN         baseaudiosink gstbaseaudiosink.c:985:gst_base_audio_sink_skew_slaving:<autoaudiosink0-actual-sink-alsa> correct clock skew -10781251 < -10666500
0:01:08.965338713  5059  0xa058430 WARN         baseaudiosink gstbaseaudiosink.c:961:gst_base_audio_sink_skew_slaving:<autoaudiosink0-actual-sink-alsa> correct clock skew 10682803 > 10666500
0:01:09.097057383  5059  0xa058430 WARN         baseaudiosink gstbaseaudiosink.c:985:gst_base_audio_sink_skew_slaving:<autoaudiosink0-actual-sink-alsa> correct clock skew -10673820 < -10666500
0:01:09.114648042  5059  0xa058430 WARN         baseaudiosink gstbaseaudiosink.c:961:gst_base_audio_sink_skew_slaving:<autoaudiosink0-actual-sink-alsa> correct clock skew 10676674 > 10666500
0:01:13.145390323  5059  0xa058430 WARN              mp3parse gstmpegaudioparse.c:1418:head_check:<mpegaudioparse0> invalid sync
0:01:13.145595198  5059  0xa058430 WARN              mp3parse gstmpegaudioparse.c:1418:head_check:<mpegaudioparse0> invalid sync
0:01:13.145654719  5059  0xa058430 WARN              mp3parse gstmpegaudioparse.c:1418:head_check:<mpegaudioparse0> invalid sync
0:01:13.145808770  5059  0xa058430 WARN              mp3parse gstmpegaudioparse.c:1418:head_check:<mpegaudioparse0> invalid sync
0:02:00.071110148  5059  0x9fe3908 WARN     mpegsectionfilter gstsectionfilter.c:133:gst_section_filter_push: section lost, last continuity counter: 4we now have a pusi at continuity counter: 6
0:02:20.883816947  5059  0xa063fd8 WARN              mpeg2dec gstmpeg2dec.c:1182:gst_mpeg2dec_chain:<mpeg2dec0> Decoding error #1
0:02:26.068963892  5059  0xa058430 WARN              mp3parse gstmpegaudioparse.c:1418:head_check:<mpegaudioparse0> invalid sync

[Wim Taymans]

On Mon, 2009-03-23 at 06:21 -0700, Aleksey Yulin wrote:
>
> We're trying to play a TS stream unicasted to the udp port. After adding a
> queue element after the udpsrc the playback is fine. Our pipeline looks as
> follows:
>
> udpsrc port=1234 ! queue ! decodebin2 ! ffmpegcolorspace ! xvimagesink

The transport stream demuxer does not yet support live streams.

Wim
>
> But after an hour of playback the video picture becomes jerky, covered by
> multiple green boxes and other artifacts. It looks like some frames are
> being dropped on the source or decoder starts to skip them.
>
> What could be the reason for this issue? Is it possibly that the queue
> becomes emty and doesn't fill again? We tried to use 'queue2' instead of
> 'queue' but got the same result.


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Aleksey Yulin]

One more thing I've investigated - playing around with the queue placed right after udpsrc seems to affect this issue, so it looks like buffer underrun or overrun causes some source data to be lost thus and element downstream starts process further data incorrectly.

Wim Taymans-2 wrote

The transport stream demuxer does not yet support live streams.

Where I could read about what should be additionally implemented for the demuxer to support live streams so I could implement this?