H.264 streaming: choppy video + timestamp warnings

[Parisot, Adam]

Hi all,

I'm trying to develop a GStreamer-based application to receive and
display H.264 video from a network source.  The protocol is not
particularly important.  I've tried raw UDP with MPEG-TS encapsulation
as well as RTP with no encapsulation and I'm seeing the same performance
issue in both cases.

Video starts skipping badly shortly after initiating playback and I see
these warnings from GStreamer:

> 0:00:03.165877350 21089       0xb09010 WARN                basesink
gstbasesink.c:2686:gst_base_sink_is_too_late:<sink> warning: A lot of
buffers are being dropped.
> 0:00:03.165917755 21089       0xb09010 WARN                basesink
gstbasesink.c:2686:gst_base_sink_is_too_late:<sink> warning: There may
be a timestamping problem, or this computer is too slow.

I can stream point-to-point between two instances of VLC just fine, so I
don't think there's an inherent problem with the hardware or network.

My pipeline looks like this (for UDP + MPEG-TS):

> udpsrc port=8200 caps="video/mpegts" \
>   ! mpegtsdemux \
>   ! ffdec_h264 \
>   ! glimagesink

I have tried inserting a queue at various points in the pipeline and an
"h264parse" element before the decoder, but neither brings any
noticeable improvement.

Also, the GStreamer core and good/bad/ugly plugin sets are all at the
latest released revisions.

Can anyone offer any insight as to what might be causing this behavior?

--
Regards,
Adam


DISCLAIMER:
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.

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Marc Leeman]

> Video starts skipping badly shortly after initiating playback and I see
> these warnings from GStreamer:

Can you provice the exact setup of the streaming side too so that we can
try to reproduce it on our end on Thursday (a day off tomorrow).

We have a small pipeline that streams an mkv with 720p over the network
and decode it on the other side; I can't say that I have noticed much
problems.

--
  greetz, marc
Murphy's Law, that brash proletarian restatement of Godel's Theorem.
                -- Thomas Pynchon, "Gravity's Rainbow"
crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 GNU/Linux

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Kapil Agrawal]

Adam,

Try using sync=false at the end of your decode pipeline.
The warning you pointed says that sink is dropping, as it getting late buffers.

Best
Kapil

On Wed, Jul 21, 2010 at 12:16 AM, Parisot, Adam <[hidden email]> wrote:

Hi all,

I'm trying to develop a GStreamer-based application to receive and
display H.264 video from a network source.  The protocol is not
particularly important.  I've tried raw UDP with MPEG-TS encapsulation
as well as RTP with no encapsulation and I'm seeing the same performance
issue in both cases.

Video starts skipping badly shortly after initiating playback and I see
these warnings from GStreamer:

> 0:00:03.165877350 21089       0xb09010 WARN                basesink
gstbasesink.c:2686:gst_base_sink_is_too_late:<sink> warning: A lot of
buffers are being dropped.
> 0:00:03.165917755 21089       0xb09010 WARN                basesink
gstbasesink.c:2686:gst_base_sink_is_too_late:<sink> warning: There may
be a timestamping problem, or this computer is too slow.

I can stream point-to-point between two instances of VLC just fine, so I
don't think there's an inherent problem with the hardware or network.

My pipeline looks like this (for UDP + MPEG-TS):

> udpsrc port=8200 caps="video/mpegts" \
>   ! mpegtsdemux \
>   ! ffdec_h264 \
>   ! glimagesink

I have tried inserting a queue at various points in the pipeline and an
"h264parse" element before the decoder, but neither brings any
noticeable improvement.

Also, the GStreamer core and good/bad/ugly plugin sets are all at the
latest released revisions.

Can anyone offer any insight as to what might be causing this behavior?

--
Regards,
Adam


DISCLAIMER:
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.

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

--
www.mediamagictechnologies.com (Gstreamer, ffmpeg, Red5, Streaming)
twitter handle: @gst_kaps
http://www.linkedin.com/in/kapilagrawal

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Edward Hervey]

On Tue, 2010-07-20 at 14:46 -0400, Parisot, Adam wrote:
> Hi all,
>
> I'm trying to develop a GStreamer-based application to receive and
> display H.264 video from a network source.  The protocol is not
> particularly important.  I've tried raw UDP with MPEG-TS encapsulation
> as well as RTP with no encapsulation and I'm seeing the same performance
> issue in both cases.

  I wouldn't try to use mpeg-ts because of mpegtsdemux's poor/wrong
support for timestamping when working with live stream (which is why
you're getting all those sync issues).

  H264 over rtp (and not h264-in-mpegts-over-rtp) should work correctly
though. You'll have to figure out how to configure vlc to broadcast in
regular rtp though.

   Edward

>
> Video starts skipping badly shortly after initiating playback and I see
> these warnings from GStreamer:
>
> > 0:00:03.165877350 21089       0xb09010 WARN                basesink
> gstbasesink.c:2686:gst_base_sink_is_too_late:<sink> warning: A lot of
> buffers are being dropped.
> > 0:00:03.165917755 21089       0xb09010 WARN                basesink
> gstbasesink.c:2686:gst_base_sink_is_too_late:<sink> warning: There may
> be a timestamping problem, or this computer is too slow.
>
> I can stream point-to-point between two instances of VLC just fine, so I
> don't think there's an inherent problem with the hardware or network.
>
> My pipeline looks like this (for UDP + MPEG-TS):
>
> > udpsrc port=8200 caps="video/mpegts" \
> >   ! mpegtsdemux \
> >   ! ffdec_h264 \
> >   ! glimagesink
>
> I have tried inserting a queue at various points in the pipeline and an
> "h264parse" element before the decoder, but neither brings any
> noticeable improvement.
>
> Also, the GStreamer core and good/bad/ugly plugin sets are all at the
> latest released revisions.
>
> Can anyone offer any insight as to what might be causing this behavior?
>

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Parisot, Adam]

> -----Original Message-----

> From: Marc Leeman [mailto:[hidden email]]
> Sent: 20Jul10 16:42
> To: Discussion of the development of GStreamer
> Subject: Re: [gst-devel] H.264 streaming: choppy video + timestamp
> warnings
>> Video starts skipping badly shortly after initiating playback and I
>> see these warnings from GStreamer:
>
> Can you provice the exact setup of the streaming side too so that we
> can try to reproduce it on our end on Thursday (a day off tomorrow).

Sure, when testing UDP w/MPEG-TS, I use VLC 1.1.0 as the sender with the
following command line:

  cvlc -v -L <file_to_stream>
--sout=#std{access=udp,mux=ts,dst=<destination_ip>:8200} --no-sout-audio

With RTP, I'm using a version of the Gstreamer RTP example from
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/tests/exampl
es/rtp/server-v4l2-H264-alsasrc-PCMA.sh, which I modified to use a
filesrc instead of a v4lsrc (see attached).  The script can be invoked
with the following syntax:

  ./server-file-H264.sh <file_to_stream> <destination_ip>

> We have a small pipeline that streams an mkv with 720p over the
> network and decode it on the other side; I can't say that I have
> noticed much problems.

Can you share this pipeline?  I'd like to try it on my end.

--
Regards,
Adam


DISCLAIMER:
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.

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Parisot, Adam]

Hi Kapil,

 

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.

 

Regards,

Adam

---

From: Kapil Agrawal [mailto:[hidden email]]
Sent: 21Jul10 01:19
To: Discussion of the development of GStreamer
Subject: Re: [gst-devel] H.264 streaming: choppy video + timestamp warnings

Adam,

Try using sync=false at the end of your decode pipeline.
The warning you pointed says that sink is dropping, as it getting late buffers.
  
Best
Kapil

On Wed, Jul 21, 2010 at 12:16 AM, Parisot, Adam <[hidden email]> wrote:

Hi all,

I'm trying to develop a GStreamer-based application to receive and
display H.264 video from a network source.  The protocol is not
particularly important.  I've tried raw UDP with MPEG-TS encapsulation
as well as RTP with no encapsulation and I'm seeing the same performance
issue in both cases.

Video starts skipping badly shortly after initiating playback and I see
these warnings from GStreamer:

> 0:00:03.165877350 21089       0xb09010 WARN                basesink
gstbasesink.c:2686:gst_base_sink_is_too_late:<sink> warning: A lot of
buffers are being dropped.
> 0:00:03.165917755 21089       0xb09010 WARN                basesink
gstbasesink.c:2686:gst_base_sink_is_too_late:<sink> warning: There may
be a timestamping problem, or this computer is too slow.

I can stream point-to-point between two instances of VLC just fine, so I
don't think there's an inherent problem with the hardware or network.

My pipeline looks like this (for UDP + MPEG-TS):

> udpsrc port=8200 caps="video/mpegts" \
>   ! mpegtsdemux \
>   ! ffdec_h264 \
>   ! glimagesink

I have tried inserting a queue at various points in the pipeline and an
"h264parse" element before the decoder, but neither brings any
noticeable improvement.

Also, the GStreamer core and good/bad/ugly plugin sets are all at the
latest released revisions.

Can anyone offer any insight as to what might be causing this behavior?

--
Regards,
Adam


DISCLAIMER:
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.

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

--
www.mediamagictechnologies.com (Gstreamer, ffmpeg, Red5, Streaming)
twitter handle: @gst_kaps
http://www.linkedin.com/in/kapilagrawal

DISCLAIMER:
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.
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Kapil Agrawal]

Adam,

Sure its not at all a preferred solution. Just suggested you so you could understand the actual issue. As edward mentioned mpegts isnt  a good idea to use.

Also if its choppy maybe the packets might be getting dropped, or the decoder is throwng sum error/warnings

Best
Kapil

On Wed, Jul 21, 2010 at 6:26 PM, Parisot, Adam <[hidden email]> wrote:

Hi Kapil,

 

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.

 

Regards,

Adam

---

From: Kapil Agrawal [mailto:[hidden email]]
Sent: 21Jul10 01:19

To: Discussion of the development of GStreamer
Subject: Re: [gst-devel] H.264 streaming: choppy video + timestamp warnings

Adam,

Try using sync=false at the end of your decode pipeline.
The warning you pointed says that sink is dropping, as it getting late buffers.
  
Best
Kapil

On Wed, Jul 21, 2010 at 12:16 AM, Parisot, Adam <[hidden email]> wrote:

Hi all,

I'm trying to develop a GStreamer-based application to receive and
display H.264 video from a network source.  The protocol is not
particularly important.  I've tried raw UDP with MPEG-TS encapsulation
as well as RTP with no encapsulation and I'm seeing the same performance
issue in both cases.

Video starts skipping badly shortly after initiating playback and I see
these warnings from GStreamer:

> 0:00:03.165877350 21089       0xb09010 WARN                basesink
gstbasesink.c:2686:gst_base_sink_is_too_late:<sink> warning: A lot of
buffers are being dropped.
> 0:00:03.165917755 21089       0xb09010 WARN                basesink
gstbasesink.c:2686:gst_base_sink_is_too_late:<sink> warning: There may
be a timestamping problem, or this computer is too slow.

I can stream point-to-point between two instances of VLC just fine, so I
don't think there's an inherent problem with the hardware or network.

My pipeline looks like this (for UDP + MPEG-TS):

> udpsrc port=8200 caps="video/mpegts" \
>   ! mpegtsdemux \
>   ! ffdec_h264 \
>   ! glimagesink

I have tried inserting a queue at various points in the pipeline and an
"h264parse" element before the decoder, but neither brings any
noticeable improvement.

Also, the GStreamer core and good/bad/ugly plugin sets are all at the
latest released revisions.

Can anyone offer any insight as to what might be causing this behavior?

--
Regards,
Adam


DISCLAIMER:
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.

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

--
www.mediamagictechnologies.com (Gstreamer, ffmpeg, Red5, Streaming)
twitter handle: @gst_kaps
http://www.linkedin.com/in/kapilagrawal

DISCLAIMER:
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.

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

--
www.mediamagictechnologies.com (Gstreamer, ffmpeg, Red5, Streaming)
twitter handle: @gst_kaps
http://www.linkedin.com/in/kapilagrawal

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel