<div dir="ltr"><div>Okay, I've actually found what was wrong with my setup: </div>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 </div><div class="gmail_extra"> <div class="gmail_quote">2016-02-26 10:04 GMT+03:00 Sebastian Dröge <<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 · <a href="http://www.centricular.com" rel="noreferrer" target="_blank">http://www.centricular.com</a> _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </blockquote></div> </div>