Login  Register

playing live mpegts stream over udp

classic Classic list List threaded Threaded
11 messages Options Options
Embed post
Permalink
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

playing live mpegts stream over udp

Julien Isorce
Hi,

I am trying to play nicely a usual mpegts stream from network.  (720p h264/ac3 mpegts over udp multicast)
The pipeline is:
gst-launch uridecodebin uri=239.102.101.3:1013 ! then audio and video renderers.
My network interface is connected in 1GO.

With default properties, the video has a lot of macro block. If I record the network packets in a pcap file then
I can perfeclty play the stream using pcapparse.
So I think the problem comes from some buffering pbs.

When configuring with some heuristics use-buffering=1, buffer-duration and buffer-size properties of uridecodebin,
the video contains less macro blocks but it still contains enough block to make me fill it's not normal.

With VLC the stream is played almost perfectly.

Am I doing something wrong ? Should I need a something like a jitterbuffer (no rtp here) ?

Any help would be appreciated.
Sincerely
Julien Isorce


------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: playing live mpegts stream over udp

Edward Hervey
Administrator
On Fri, 2011-01-14 at 20:08 +0100, Julien Isorce wrote:

> Hi,
>
> I am trying to play nicely a usual mpegts stream from network.  (720p
> h264/ac3 mpegts over udp multicast)
> The pipeline is:
> gst-launch uridecodebin uri=239.102.101.3:1013 ! then audio and video
> renderers.
> My network interface is connected in 1GO.
>
> With default properties, the video has a lot of macro block. If I
> record the network packets in a pcap file then
> I can perfeclty play the stream using pcapparse.
> So I think the problem comes from some buffering pbs.
>
> When configuring with some heuristics use-buffering=1, buffer-duration
> and buffer-size properties of uridecodebin,
> the video contains less macro blocks but it still contains enough
> block to make me fill it's not normal.
>
> With VLC the stream is played almost perfectly.
>
> Am I doing something wrong ? Should I need a something like a
> jitterbuffer (no rtp here) ?

  I had a look at the problem over the weekend (reproduced it by using
vlc server streaming mpeg-ts over udp) and basically the timing
algorithms in mpegtsdemux are completely bogus (which is something we
knew, but never confirmed). By introducing an evil hack in mpegtsdemux
for that specific setup I could get it to play much more smoothly.

  You also want to set the udpsrc buffer-size property to a much higher
value (500kB should do it) if you're using high-ish bandwith streams.

  The solution ?
  * Stream using proper rtsp (when vlc server is configured that way it
works flawlessly with GStreamer).
  * Fix mpegtsdemux (I'd recommend buying hospital-sized packs of
aspirin if you do that)
  * Help work on the from-scratch tsdemux project (some people looked
into a similar issue some time back)

     Edward

>
> Any help would be appreciated.
> Sincerely
> Julien Isorce
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel



------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: playing live mpegts stream over udp

Kapil Agrawal
In reply to this post by Julien Isorce
Hello Julien,

Based on my personal experience I think you might even try ffdemux_mpegts.

Yeah fixing mpegtsdemux would surely need aspirin.

Best
Kapil 

On Sat, Jan 15, 2011 at 12:38 AM, Julien Isorce <[hidden email]> wrote:
Hi,

I am trying to play nicely a usual mpegts stream from network.  (720p h264/ac3 mpegts over udp multicast)
The pipeline is:
gst-launch uridecodebin uri=239.102.101.3:1013 ! then audio and video renderers.
My network interface is connected in 1GO.

With default properties, the video has a lot of macro block. If I record the network packets in a pcap file then
I can perfeclty play the stream using pcapparse.
So I think the problem comes from some buffering pbs.

When configuring with some heuristics use-buffering=1, buffer-duration and buffer-size properties of uridecodebin,
the video contains less macro blocks but it still contains enough block to make me fill it's not normal.

With VLC the stream is played almost perfectly.

Am I doing something wrong ? Should I need a something like a jitterbuffer (no rtp here) ?

Any help would be appreciated.
Sincerely
Julien Isorce


------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
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

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: playing live mpegts stream over udp

Julien Isorce
Hi,

Thx for your informations.

I set the udpsrc buffer-size property to 20 000 000 bytes and it seems to be fine for now. (If I put 10 000 000 I am getting some macro blocks, same with 500 000)
(the stream is around 13 MB/s)

I cannot control the stream server (and I cannot select an other encapsulation) since it's a professional source of one of our customer.

Sincerely
Julien

2011/1/17 Kapil Agrawal <[hidden email]>
Hello Julien,

Based on my personal experience I think you might even try ffdemux_mpegts.

Yeah fixing mpegtsdemux would surely need aspirin.

Best
Kapil 

On Sat, Jan 15, 2011 at 12:38 AM, Julien Isorce <[hidden email]> wrote:
Hi,

I am trying to play nicely a usual mpegts stream from network.  (720p h264/ac3 mpegts over udp multicast)
The pipeline is:
gst-launch uridecodebin uri=239.102.101.3:1013 ! then audio and video renderers.
My network interface is connected in 1GO.

With default properties, the video has a lot of macro block. If I record the network packets in a pcap file then
I can perfeclty play the stream using pcapparse.
So I think the problem comes from some buffering pbs.

When configuring with some heuristics use-buffering=1, buffer-duration and buffer-size properties of uridecodebin,
the video contains less macro blocks but it still contains enough block to make me fill it's not normal.

With VLC the stream is played almost perfectly.

Am I doing something wrong ? Should I need a something like a jitterbuffer (no rtp here) ?

Any help would be appreciated.
Sincerely
Julien Isorce


------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
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

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel



------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: playing live mpegts stream over udp

TalleyHo
In reply to this post by Edward Hervey
Could you elaborate on the timing algorithm issues?  My manager has provided me w/ the hospital sized boxes of aspirin and I've been asked to make this work.

I'm in a similar situation in that I cannot control the source stream format.  I'm also up against a proprietary h/w decoder that has its own issues.  Definitely between a rock and a hard place here.

I'm stuck using gstreamer 10.28, and the bad-10.18 plugin as well, so I've got quite a mountain to climb.  

I've looked at back-porting the new mpegtsdemux from the .22 release and it seems feasible if it has improved functionality.  

Thoughts, suggestions and prayers appreciated.
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: playing live mpegts stream over udp

Sudhirkumar
Hi,

We are able to display an mpeg-stream over udp on DM3730.
The video resolution is 1280x720 with 60fps.

gst-launch -v udpsrc uri="udp://192.168.10.40:5544" ! mpegtsdemux ! h264parse ! TIViddec2 ! queue ! tidisplaysink2

But, when streaming an video of resolution 640x480 60fps, the video display is playing with delay.
i.e its taking time to buffer and then play, whereas when streaming an video of 1280*720 it is playing smoothly.

Can anyone suggest what could be the issue

Regards
SudhirKumar

Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: playing live mpegts stream over udp

Sudhirkumar
In reply to this post by TalleyHo
Hi,

We are able to display an mpeg-stream over udp on DM3730.
The video resolution is 1280x720 with 60fps.

gst-launch -v udpsrc uri="udp://192.168.10.40:5544" ! mpegtsdemux ! h264parse ! TIViddec2 ! queue ! tidisplaysink2

But, when streaming an video of resolution 640x480 60fps, the video display is playing with delay.
i.e its taking time to buffer and then play, whereas when streaming an video of 1280*720 it is playing smoothly.

Can anyone suggest what could be the issue

Regards
SudhirKumar

Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: playing live mpegts stream over udp

Tim-Philipp Müller-2
On Tue, 2012-11-27 at 20:52 -0800, Sudhirkumar wrote:

Hi,

> We are able to display an mpeg-stream over udp on DM3730.
> The video resolution is 1280x720 with 60fps.
>
> gst-launch -v udpsrc uri="udp://192.168.10.40:5544" ! mpegtsdemux !
> h264parse ! TIViddec2 ! queue ! tidisplaysink2
>
> But, when streaming an video of resolution 640x480 60fps, the video display
> is playing with delay.
> i.e its taking time to buffer and then play, whereas when streaming an video
> of 1280*720 it is playing smoothly.
>
> Can anyone suggest what could be the issue

It might be in TIViddec2, IIRC there is an internal buffer of some sort,
and it waits for that to be full before decoding (to be sure it's got at
least one frame or something). That was on a different board though, but
might still apply. You can put an identity element before TIViddec2 and
the video sink to see when the first buffer goes through the pipeline
where.

Cheers
 -Tim

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: playing live mpegts stream over udp

amartin
Hi,

To control the jitter you can use gstrtpjitterbuffer. Anyway your pipeline seems weird for me (where is the depayloader?):

gst-launch udpsrc uri=udp://localhost:5004 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP2T-ES, payload=(int)33" ! gstrtpjitterbuffer latency=200 ! application/x-rtp ! rtpmp2tdepay ! video/mpegts ! mpegtsdemux ! video/x-h264 ! queue ! decodebin ! autovideosink

Best,

Angel

2012/11/28 Tim-Philipp Müller <[hidden email]>
On Tue, 2012-11-27 at 20:52 -0800, Sudhirkumar wrote:

Hi,

> We are able to display an mpeg-stream over udp on DM3730.
> The video resolution is 1280x720 with 60fps.
>
> gst-launch -v udpsrc uri="udp://192.168.10.40:5544" ! mpegtsdemux !
> h264parse ! TIViddec2 ! queue ! tidisplaysink2
>
> But, when streaming an video of resolution 640x480 60fps, the video display
> is playing with delay.
> i.e its taking time to buffer and then play, whereas when streaming an video
> of 1280*720 it is playing smoothly.
>
> Can anyone suggest what could be the issue

It might be in TIViddec2, IIRC there is an internal buffer of some sort,
and it waits for that to be full before decoding (to be sure it's got at
least one frame or something). That was on a different board though, but
might still apply. You can put an identity element before TIViddec2 and
the video sink to see when the first buffer goes through the pipeline
where.

Cheers
 -Tim

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: playing live mpegts stream over udp

Tim-Philipp Müller-2
On Mon, 2012-12-03 at 11:19 +0100, Angel Martin wrote:

Hi Angel,

> To control the jitter you can use gstrtpjitterbuffer. Anyway your
> pipeline seems weird for me (where is the depayloader?):

I was assuming he is sending MPEG-TS over UDP without any additional RTP
payloading. In which case rtpjitterbuffer won't do much (the ts demuxer
should theoretically take care of what the jitterbuffer does), and no
depayloader is required.

 Cheers
  -Tim

> gst-launch udpsrc uri=udp://localhost:5004 caps="application/x-rtp,
> media=(string)video, clock-rate=(int)90000,
> encoding-name=(string)MP2T-ES, payload=(int)33" ! gstrtpjitterbuffer
> latency=200 ! application/x-rtp ! rtpmp2tdepay ! video/mpegts !
> mpegtsdemux ! video/x-h264 ! queue ! decodebin ! autovideosink
>
>
> Best,
>
>
> Angel
>
> 2012/11/28 Tim-Philipp Müller <[hidden email]>
>         On Tue, 2012-11-27 at 20:52 -0800, Sudhirkumar wrote:
>        
>         Hi,
>        
>         > We are able to display an mpeg-stream over udp on DM3730.
>         > The video resolution is 1280x720 with 60fps.
>         >
>         > gst-launch -v udpsrc uri="udp://192.168.10.40:5544" !
>         mpegtsdemux !
>         > h264parse ! TIViddec2 ! queue ! tidisplaysink2
>         >
>         > But, when streaming an video of resolution 640x480 60fps,
>         the video display
>         > is playing with delay.
>         > i.e its taking time to buffer and then play, whereas when
>         streaming an video
>         > of 1280*720 it is playing smoothly.
>         >
>         > Can anyone suggest what could be the issue
>        
>        
>         It might be in TIViddec2, IIRC there is an internal buffer of
>         some sort,
>         and it waits for that to be full before decoding (to be sure
>         it's got at
>         least one frame or something). That was on a different board
>         though, but
>         might still apply. You can put an identity element before
>         TIViddec2 and
>         the video sink to see when the first buffer goes through the
>         pipeline
>         where.
>        
>         Cheers
>          -Tim
>        
>         _______________________________________________
>         gstreamer-devel mailing list
>         [hidden email]
>         http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>        
>
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: playing live mpegts stream over udp

amartin
Dear Tim,

I usually perform this kind of pipelines with rtp layer, this is why I suggested a solution in that way.

But, You are right, he is not using rtp at all.

Best,

Angel


2012/12/3 Tim-Philipp Müller <[hidden email]>
On Mon, 2012-12-03 at 11:19 +0100, Angel Martin wrote:

Hi Angel,

> To control the jitter you can use gstrtpjitterbuffer. Anyway your
> pipeline seems weird for me (where is the depayloader?):

I was assuming he is sending MPEG-TS over UDP without any additional RTP
payloading. In which case rtpjitterbuffer won't do much (the ts demuxer
should theoretically take care of what the jitterbuffer does), and no
depayloader is required.

 Cheers
  -Tim

> gst-launch udpsrc uri=udp://localhost:5004 caps="application/x-rtp,
> media=(string)video, clock-rate=(int)90000,
> encoding-name=(string)MP2T-ES, payload=(int)33" ! gstrtpjitterbuffer
> latency=200 ! application/x-rtp ! rtpmp2tdepay ! video/mpegts !
> mpegtsdemux ! video/x-h264 ! queue ! decodebin ! autovideosink
>
>
> Best,
>
>
> Angel
>
> 2012/11/28 Tim-Philipp Müller <[hidden email]>
>         On Tue, 2012-11-27 at 20:52 -0800, Sudhirkumar wrote:
>
>         Hi,
>
>         > We are able to display an mpeg-stream over udp on DM3730.
>         > The video resolution is 1280x720 with 60fps.
>         >
>         > gst-launch -v udpsrc uri="udp://192.168.10.40:5544" !
>         mpegtsdemux !
>         > h264parse ! TIViddec2 ! queue ! tidisplaysink2
>         >
>         > But, when streaming an video of resolution 640x480 60fps,
>         the video display
>         > is playing with delay.
>         > i.e its taking time to buffer and then play, whereas when
>         streaming an video
>         > of 1280*720 it is playing smoothly.
>         >
>         > Can anyone suggest what could be the issue
>
>
>         It might be in TIViddec2, IIRC there is an internal buffer of
>         some sort,
>         and it waits for that to be full before decoding (to be sure
>         it's got at
>         least one frame or something). That was on a different board
>         though, but
>         might still apply. You can put an identity element before
>         TIViddec2 and
>         the video sink to see when the first buffer goes through the
>         pipeline
>         where.
>
>         Cheers
>          -Tim
>
>         _______________________________________________
>         gstreamer-devel mailing list
>         [hidden email]
>         http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel