mpeg-ts multifdsink

[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 <sebastian at centricular.com>:

> 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
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160226/f9397e57/attachment.html>