<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3627" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Verdana size=2><SPAN class=644215112-21072010>Hi
Kapil,</SPAN></FONT></DIV>
<DIV><FONT face=Verdana size=2><SPAN
class=644215112-21072010></SPAN></FONT> </DIV>
<DIV><FONT face=Verdana size=2><SPAN class=644215112-21072010>Adding sync=false
does improve playback significantly, going from a slide show to mostly smooth
video, but the video still looks slightly choppy when compared to
playing the same source locally. Reading the documentation for the sync
parameter, it sounds like the sink will display frames in whatever order they
arrive in, so I'm thinking this is not the preferred
solution.</SPAN></FONT></DIV>
<DIV><FONT face=Verdana size=2><SPAN
class=644215112-21072010></SPAN></FONT> </DIV>
<DIV><FONT face=Verdana size=2><SPAN
class=644215112-21072010>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=Verdana size=2><SPAN
class=644215112-21072010>Adam</SPAN></FONT></DIV><FONT face=Verdana
color=#008080 size=2></FONT><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Kapil Agrawal
[mailto:kapil.agl@gmail.com] <BR><B>Sent:</B> 21Jul10 01:19<BR><B>To:</B>
Discussion of the development of GStreamer<BR><B>Subject:</B> Re: [gst-devel]
H.264 streaming: choppy video + timestamp warnings<BR></FONT><BR></DIV>
<DIV></DIV>Adam,<BR><BR>Try using sync=false at the end of your decode
pipeline. <BR>The warning you pointed says that sink is dropping, as it
getting late buffers.<BR><SPAN class=644215112-21072010><FONT face=Verdana
color=#008080 size=2> </FONT></SPAN><BR>Best<BR>Kapil<BR><BR>
<DIV class=gmail_quote>On Wed, Jul 21, 2010 at 12:16 AM, Parisot, Adam <SPAN
dir=ltr><<A
href="mailto:Adam.Parisot@barco.com">Adam.Parisot@barco.com</A>></SPAN>
wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Hi
all,<BR><BR>I'm trying to develop a GStreamer-based application to receive
and<BR>display H.264 video from a network source. The protocol is
not<BR>particularly important. I've tried raw UDP with MPEG-TS
encapsulation<BR>as well as RTP with no encapsulation and I'm seeing the
same performance<BR>issue in both cases.<BR><BR>Video starts skipping badly
shortly after initiating playback and I see<BR>these warnings from
GStreamer:<BR><BR>> 0:00:03.165877350 21089 0xb09010
WARN
basesink<BR>gstbasesink.c:2686:gst_base_sink_is_too_late:<sink>
warning: A lot of<BR>buffers are being dropped.<BR>> 0:00:03.165917755
21089 0xb09010 WARN
basesink<BR>gstbasesink.c:2686:gst_base_sink_is_too_late:<sink>
warning: There may<BR>be a timestamping problem, or this computer is too
slow.<BR><BR>I can stream point-to-point between two instances of VLC just
fine, so I<BR>don't think there's an inherent problem with the hardware or
network.<BR><BR>My pipeline looks like this (for UDP + MPEG-TS):<BR><BR>>
udpsrc port=8200 caps="video/mpegts" \<BR>> ! mpegtsdemux
\<BR>> ! ffdec_h264 \<BR>> ! glimagesink<BR><BR>I have
tried inserting a queue at various points in the pipeline and
an<BR>"h264parse" element before the decoder, but neither brings
any<BR>noticeable improvement.<BR><BR>Also, the GStreamer core and
good/bad/ugly plugin sets are all at the<BR>latest released
revisions.<BR><BR>Can anyone offer any insight as to what might be causing
this behavior?<BR><FONT
color=#888888><BR>--<BR>Regards,<BR>Adam<BR><BR><BR>DISCLAIMER:<BR>Unless
indicated otherwise, the information contained in this message is privileged
and confidential, and is intended only for the use of the addressee(s) named
above and others who have been specifically authorized to receive it. If you
are not the intended recipient, you are hereby notified that any
dissemination, distribution or copying of this message and/or attachments is
strictly prohibited. The company accepts no liability for any damage caused
by any virus transmitted by this email. Furthermore, the company does not
warrant a proper and complete transmission of this information, nor does it
accept liability for any delays. If you have received this message in error,
please contact the sender and delete the message. Thank you.<BR></FONT>
<DIV>
<DIV></DIV>
<DIV
class=h5><BR>------------------------------------------------------------------------------<BR>This
SF.net email is sponsored by Sprint<BR>What will you do first with EVO, the
first 4G phone?<BR>Visit <A href="http://sprint.com/first"
target=_blank>sprint.com/first</A> -- <A
href="http://p.sf.net/sfu/sprint-com-first"
target=_blank>http://p.sf.net/sfu/sprint-com-first</A><BR>_______________________________________________<BR>gstreamer-devel
mailing list<BR><A
href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</A><BR><A
href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel"
target=_blank>https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</A><BR></DIV></DIV></BLOCKQUOTE></DIV><BR><BR
clear=all><BR>-- <BR><A
href="http://www.mediamagictechnologies.com">www.mediamagictechnologies.com</A>
(Gstreamer, ffmpeg, Red5, Streaming)<BR>twitter handle: @gst_kaps<BR><A
href="http://www.linkedin.com/in/kapilagrawal">http://www.linkedin.com/in/kapilagrawal</A><BR></BLOCKQUOTE><p></p><p>DISCLAIMER:<br>Unless indicated otherwise, the information contained in this message is privileged and confidential, and is intended only for the use of the addressee(s) named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message and/or attachments is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email. Furthermore, the company does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. If you have received this message in error, please contact the sender and delete the message. Thank you.</BODY></HTML>