mpeg-ts multifdsink

[Sebastian Dröge]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160226/bce394bd/attachment.sig>