H.264: HLS Sink + SRT Sink questions

MathieuP mathieu.pierfitte at nirovision.com
Wed Jan 29 23:07:47 UTC 2020


Hello GStreamer,


I have been using a pipeline that reads frames from an RTSP stream and
stores TS files to the disk to be able to distribute them via HTTP Live
Streaming (HLS), using a pipeline that I could break down to this:

gst-launch-1.0 rtspsrc location=rtsp://my/rtsp/stream ! rtph264depay !
h264parse config-interval=-1 ! mpegtsmux ! hlssink location=export

(I am not showing any tees, queues or custom elements because I think they
are irrelevant to the problem I'll talk about soon, but the real pipeline is
quite big)


This pipeline has been working fine for me for some time. However, a new
spec I have is for my pipeline to also start live streaming. SRT looks
perfect for my use case, because I already have muxed MPEG TS files, which
actually include 3 KLV tracks in my real pipeline. So I'm now trying to turn
my pipeline into this:

gst-launch-1.0 rtspsrc location=rtsp://my/rtsp/stream ! rtph264depay !
h264parse config-interval=-1 ! mpegtsmux ! tee name=t ! queue ! hlssink
location=export t. ! queue ! srtsink uri=srt://:8888


Problem is, while this pipeline starts and seems to be running fine, I can't
play my stream with this simple pipeline:

gst-launch-1.0 srtsrc uri=srt://127.0.0.1:8888 ! decodebin ! autovideosink


If I show more logs, I can see a lot of:

0:00:02.475511000 36924 0x7f8e818d1ed0 WARN               h264parse
gsth264parse.c:1351:gst_h264_parse_handle_frame:<h264parse0> broken/invalid
nal Type: 1 Slice, Size: 7508 will be dropped
0:00:02.543474000 36924 0x7f8e818d1ed0 WARN               h264parse
gsth264parse.c:1351:gst_h264_parse_handle_frame:<h264parse0> broken/invalid
nal Type: 1 Slice, Size: 7523 will be dropped
0:00:02.609336000 36924 0x7f8e818d1ed0 WARN               h264parse
gsth264parse.c:1351:gst_h264_parse_handle_frame:<h264parse0> broken/invalid
nal Type: 1 Slice, Size: 6307 will be dropped
0:00:02.677009000 36924 0x7f8e818d1ed0 WARN               h264parse
gsth264parse.c:1351:gst_h264_parse_handle_frame:<h264parse0> broken/invalid
nal Type: 1 Slice, Size: 7464 will be dropped
0:00:02.883966000 36924 0x7f8e818d1ed0 WARN               h264parse
gsth264parse.c:1351:gst_h264_parse_handle_frame:<h264parse0> broken/invalid
nal Type: 5 Slice IDR, Size: 130693 will be dropped


I took the HLS branch out of the equation, and noticed this simple pipeline
reproduces the issue:

gst-launch-1.0 rtspsrc location=rtsp://my/rtsp/stream ! rtph264depay !
h264parse ! mpegtsmux ! srtsink uri=srt://:8888


Simply removing h264parse from the pipeline seems to solve my SRT issue.
However, by doing that, I will break my HLS endpoint, because most of my TS
files end up not being playable (because of missing SPS/PPS I assume).

Can someone please help me understand what is happening here? Is the
solution to mux 2 different MPEG TS streams, so that I can put a h264parse
before my hlssink but no h264parse before my srtsink? Why would that be
necessary?


For the record, I am using GStreamer 1.16.0.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/


More information about the gstreamer-devel mailing list