After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 548979 - jerky playback fluendo demux plugin with udpsrc
jerky playback fluendo demux plugin with udpsrc
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.10.19
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-08-22 10:08 UTC by Ambily
Modified: 2011-08-18 14:04 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ambily 2008-08-22 10:08:46 UTC
Please describe the problem:
I am experiencing some issues while using rtp/udp live streaming of TS
encapsulated H.264 stream.

The sender side pipe line is as

gst-launch filesrc location=
gst-launch filesrc location=grandma.qcif.yuv blocksize=1 ! videoparse
format=0 width=176 height=144 ! x264enc byte-stream=1 ! flutsmux !
rtpmp2tpay ! udpsink host=localhost port=1234.

the receiver side the pipeline is as :

gst-launch udpsrc port=1234 ! rtpmp2tdepay ! flutsdemux ! ffdec_h264 ! queue
! sdlvideosink

The display is jerky and only I frames gets displayed at the sink.

The observations we have on the issue so far are the following.

1. The display is fine when we use tcpserversrc at the receiver and
tcpclientsink at the sender.(since its not a live src)

2.The display is fine if we modify the code of udpsrc and make it a non-live
src.

4.The timestamps of the packets arriving at the sink are the same in both
live and non-live cases but in the live case the packets seems to be late
when compared with current clock time.

5. The qos messages from the sink make the decoder skip to the next I frame
and this continues all the way.

6.The display is fine if we disable the sync property at the sdlvideosink.

7. The fluedo demux plugin seems to assume the the timestamp of the buffers are always 0. It doesnt seem to take care of the live property of the src.




Regards
Ambily



Steps to reproduce:
1. Start the receiver side pipeline and the sender side pipeline as in the description.
2. 
3. 


Actual results:
Jerky playback observed.

Expected results:
Normal smooth playback . Dropping of frames at the receiver when network delay is there.

Does this happen every time?
yes

Other information:
It seems the demux need to handle the live src case also while timestamping.
Comment 1 Wim Taymans 2008-08-22 15:08:33 UTC
Can't reproduce, as it turns out flutsdemux provides a clock that makes these things work for me.

I tried:

sender: gst-launch videotestsrc ! x264enc byte-stream=1 ! flutsmux ! rtpmp2tpay ! udpsink

receiver: gst-launch udpsrc caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP2T-ES" ! rtpmp2tdepay ! flutsdemux ! queue max-size-buffers=0 max-size-bytes=0 ! ffdec_h264 ! xvimagesink

Maybe something is wrong with your versions of the elements or the pipelines. I would start by making the blocksize something bigger than 1 byte. I would also suggest putting the queue on the receiver before the decoder and setting the max-size-buffers and max-size-bytes to 0.
Comment 2 Ambily 2008-08-22 15:42:10 UTC
Hi Wim,

In the scenario I reported, the issue won't arise if we start the sender first and then the receiver.The issue is observed when the receiver is started first.

I also see a clock being active in the pipeline.

Also the following are the versions I am using.
Could you please specify the version in your setup?

Gstreamer core - 0.10.19
good plugin - 0.10.7 (udp/rtp)
bad - 0.10.7 (x264)
Fluendo demux - 0.10.15.



Regards
Ambily.


Comment 3 Wim Taymans 2008-08-22 15:58:37 UTC
yes sorry, you are right about starting the receiver first. Will search some more.
Comment 4 Wim Taymans 2008-08-22 16:44:25 UTC
It seems the PCR is aligned to the absolute clock time instead of the running_time.
Comment 5 Ambily 2008-08-27 09:21:14 UTC
Hi,

You mean,this happens while sending the new segment?

The gst_fluts_demux_send_new_segment and gst_fluts_parse_adaptation_field are the two functions which seems to be making use of the PCR values.

I commented out the fluendo TS clock and in the gst_fluts_demux_send_new_segment function, the stream->base-time was initialized with the running time.

This works, without the fluendo clock.
Is it a correct fix?
Comment 6 Sebastian Dröge (slomo) 2011-05-19 08:07:13 UTC
Is this still a problem? If it is, is the correct fix to ignore the demuxer clock?
Comment 7 Tobias Mueller 2011-08-18 14:04:20 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!