mpeg-ts multifdsink

[Krutskikh Ivan]

Hi all,

I want to serve mpeg-ts streams by http mainly for vlc clients in python. I use gstreamer multifdsink for this. The main script for serving streams is 

        if self.sink_type == 'multifdsink':  
            pipe = os.pipe()
            client_id= pipe[1]
            self.sink.emit("add", client_id)
            new = os.fdopen(pipe[0],'r',0)
            try:
                while True:
                        data = new.read(1024)
                        wfile.write(data)
                        wfile.flush()
           
            except:
                print 'Except'
                self.sink.emit('remove',client_id)
                new.close()
                os.close(pipe[0])
                os.close(pipe[1])

So wfile should receive mpeg-ts stream. But when I use gstreamer pipeline

rtspsrc name=source latency=100  ! queue ! rtph264depay ! h264parse ! mpegtsmux name=mux ! multifdsink  name=sink

But on the clients I get a lot of errors and no video.

[00007f1f34c04468] ts demux error: libdvbpsi (PSI decoder): TS discontinuity (received 15, expected 14) for PID 0
[00007f1f34c04468] ts demux error: libdvbpsi (PSI decoder): TS discontinuity (received 15, expected 14) for PID 32
[00007f1f34c04468] ts demux error: libdvbpsi (PSI decoder): TS discontinuity (received 13, expected 12) for PID 0
[00007f1f34c04468] ts demux error: libdvbpsi (PSI decoder): TS discontinuity (received 13, expected 12) for PID 32
[00007f1f34c04468] ts demux error: libdvbpsi (PSI decoder): TS discontinuity (received 11, expected 10) for PID 0
[00007f1f34c04468] ts demux error: libdvbpsi (PSI decoder): TS discontinuity (received 11, expected 10) for PID 32

I've inspected the mpegtsmux element and found out that alignment property can be the source of my issue. So for pipeline

rtspsrc name=source latency=100  ! queue ! rtph264depay ! h264parse ! mpegtsmux name=mux alignment=1024 ! multifdsink  name=sink

I can get video for the first client. I considered it a victory... Until I've added a second player. Additional players just fail to show any video without errors. They are receiving the data aright, but fail to output video. With gstreamer client I get an eternal PREROLL.

It seams to be a time stamp issue and broken data stream due to read/write dynamics on pipe. I was very frustrated until I tries mpegpsmux. Everything is working for pipeline

rtspsrc name=source latency=100  ! queue ! rtph264depay ! h264parse ! mpegpsmux name=mux ! multifdsink  name=sink

But the timescale is all wrong and I get long time from initial connection to the first frame (waiting for the key frame. multifdsink sync-method=1 does not fix the issue). I was wondering if I could either fix mpegtsmux or the multifdsink dynamics for my app to work correctly.

Thanks in advance!

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

[Sebastian Dröge-3]

On Fr, 2016-02-26 at 09:37 +0300, Krutskikh Ivan wrote:
> Hi all,
>
> I want to serve mpeg-ts streams by http mainly for vlc clients in
> python. I use gstreamer multifdsink for this. The main script for
> serving streams is  

multifdsink is not doing HTTP btw, but that should be unrelated to your
problem here.

>
> So wfile should receive mpeg-ts stream. But when I use gstreamer
> pipeline
>
> rtspsrc name=source latency=100  ! queue ! rtph264depay ! h264parse !
> mpegtsmux name=mux ! multifdsink  name=sink
>
> But on the clients I get a lot of errors and no video.
>
> [00007f1f34c04468] ts demux error: libdvbpsi (PSI decoder): TS
> discontinuity (received 15, expected 14) for PID 0

This means that the MPEG-TS that is received by the clients is
corrupted. Can you check that it's all ok if you let multifdsink write
to a file? Can you play back the resulting file?

> I've inspected the mpegtsmux element and found out that alignment
> property can be the source of my issue. So for pipeline 
>
> rtspsrc name=source latency=100  ! queue ! rtph264depay ! h264parse !
> mpegtsmux name=mux alignment=1024 ! multifdsink  name=sink

The alignment property should be unrelated. It just defines how many
MPEG-TS packets there are going to be per buffer. Apart from better
performance there should be no difference here.

> I can get video for the first client. I considered it a victory...
> Until I've added a second player. Additional players just fail to
> show any video without errors. They are receiving the data aright,
> but fail to output video. With gstreamer client I get an eternal
> PREROLL.
>
> It seams to be a time stamp issue and broken data stream due to
> read/write dynamics on pipe. I was very frustrated until I tries
> mpegpsmux. Everything is working for pipeline

Can you run a GStreamer pipeline and get a debug log with
GST_DEBUG=3,*ts*:6,h264parse:6 ? That should tell us a bit more.

> rtspsrc name=source latency=100  ! queue ! rtph264depay ! h264parse !
> mpegpsmux name=mux ! multifdsink  name=sink
>
> But the timescale is all wrong and I get long time from initial
> connection to the first frame (waiting for the key frame. multifdsink
> sync-method=1 does not fix the issue). I was wondering if I could
> either fix mpegtsmux or the multifdsink dynamics for my app to work
> correctly.

mpegpsmux probably does not mark buffers that contain a keyframe as
keyframes, or it does not repeat its headers whenever a video keyframe
is received so that you have to wait until it does that automatically.

You'll have to check the output that is received and what exactly is
missing there for the receivers.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


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

[Krutskikh Ivan]

Okay, I've actually found what was wrong with my setup:

h264parse somehow screwed internal video clocking from ip cam. without it mpeg-ts worked like a charm:

rtspsrc name=source latency=100  ! queue ! rtph264depay  ! mpegtsmux name=mux ! multifdsink  name=sink

2016-02-26 10:04 GMT+03:00 Sebastian Dröge <[hidden email]>:

On Fr, 2016-02-26 at 09:37 +0300, Krutskikh Ivan wrote:
> Hi all,
>
> I want to serve mpeg-ts streams by http mainly for vlc clients in
> python. I use gstreamer multifdsink for this. The main script for
> serving streams is  

multifdsink is not doing HTTP btw, but that should be unrelated to your
problem here.

>
> So wfile should receive mpeg-ts stream. But when I use gstreamer
> pipeline
>
> rtspsrc name=source latency=100  ! queue ! rtph264depay ! h264parse !
> mpegtsmux name=mux ! multifdsink  name=sink
>
> But on the clients I get a lot of errors and no video.
>
> [00007f1f34c04468] ts demux error: libdvbpsi (PSI decoder): TS
> discontinuity (received 15, expected 14) for PID 0

This means that the MPEG-TS that is received by the clients is
corrupted. Can you check that it's all ok if you let multifdsink write
to a file? Can you play back the resulting file?

> I've inspected the mpegtsmux element and found out that alignment
> property can be the source of my issue. So for pipeline 
>
> rtspsrc name=source latency=100  ! queue ! rtph264depay ! h264parse !
> mpegtsmux name=mux alignment=1024 ! multifdsink  name=sink

The alignment property should be unrelated. It just defines how many
MPEG-TS packets there are going to be per buffer. Apart from better
performance there should be no difference here.

> I can get video for the first client. I considered it a victory...
> Until I've added a second player. Additional players just fail to
> show any video without errors. They are receiving the data aright,
> but fail to output video. With gstreamer client I get an eternal
> PREROLL.
>
> It seams to be a time stamp issue and broken data stream due to
> read/write dynamics on pipe. I was very frustrated until I tries
> mpegpsmux. Everything is working for pipeline

Can you run a GStreamer pipeline and get a debug log with
GST_DEBUG=3,*ts*:6,h264parse:6 ? That should tell us a bit more.

> rtspsrc name=source latency=100  ! queue ! rtph264depay ! h264parse !
> mpegpsmux name=mux ! multifdsink  name=sink
>
> But the timescale is all wrong and I get long time from initial
> connection to the first frame (waiting for the key frame. multifdsink
> sync-method=1 does not fix the issue). I was wondering if I could
> either fix mpegtsmux or the multifdsink dynamics for my app to work
> correctly.

mpegpsmux probably does not mark buffers that contain a keyframe as
keyframes, or it does not repeat its headers whenever a video keyframe
is received so that you have to wait until it does that automatically.

You'll have to check the output that is received and what exactly is
missing there for the receivers.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


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

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

[Sebastian Dröge-3]

On Fr, 2016-02-26 at 15:49 +0300, Krutskikh Ivan wrote:
> Okay, I've actually found what was wrong with my setup:
>
> h264parse somehow screwed internal video clocking from ip cam.
> without it mpeg-ts worked like a charm:

Can you file a bug about that, ideally with a debug log and output of

gst-launch-1.0 -v \
  rtspsrc latency=100 ! rtph264depay ! \
    identity silent=false name=before ! \
    h264parse ! \
    identity silent=false name=after ! \
    mpegtsmux ! fakesink silent=false

Thanks!

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


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

[Arjen Veenhuizen]

@Krutskikh Ivan: please file a bug if possible. I happen to have come across the same problem recently but are no longer able to replicate it (I do not longer have access to the setup). I do remember it involved rtph264depay + h264parse + mpegtsmux + rtpmp2tpay + udpsink (git master). VLC (in contrast to gst-launch-1.0) was unable to play the resulting stream.