H.264: HLS Sink + SRT Sink questions

[Nicolas Dufresne]

Le mercredi 29 janvier 2020 à 17:07 -0600, MathieuP a écrit :
> 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

Maybe the SPS/PPS are never repeated for some reason ? Have you considered
changing dropping config-interval, or using fixed internal ? This looks like a
bug. Note that ideally for SRT, you want to use tsmux alignment=7 on mpegtsmux,
that should not have any side effect on HLS.

> 
> 
> 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/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel