H.264: HLS Sink + SRT Sink questions

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

H.264: HLS Sink + SRT Sink questions

MathieuP
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/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: H.264: HLS Sink + SRT Sink questions

Nicolas Dufresne-5
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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: H.264: HLS Sink + SRT Sink questions

MathieuP
alignment=7 on the MPEG TS muxer does the trick!

I can now parse my h264 stream, mux it into a MPEG TS container, and both
save it to the disk for HLS playback and broadcast it live over SRT.

Thanks Nicolas!



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: H.264: HLS Sink + SRT Sink questions

Nicolas Dufresne-5
Le jeudi 30 janvier 2020 à 17:51 -0600, MathieuP a écrit :
> alignment=7 on the MPEG TS muxer does the trick!
>
> I can now parse my h264 stream, mux it into a MPEG TS container, and both
> save it to the disk for HLS playback and broadcast it live over SRT.
>
> Thanks Nicolas!

Thanks for reporting back, glad it helped.

>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: H.264: HLS Sink + SRT Sink questions

MathieuP
Jumping back on this issue, because I have an update and it might help people
trying to do the same.

Going with alignment=7 introduced a new problem in the HLS part of my
pipeline: the DELTA_UNIT flags were never set, which means most files didn't
start with a key frame, so the first GOP was often corrupted.
I'm not actually using hlssink there but my own implementation of this logic
instead, but it's likely that hlssink would face the same problem.

So in the end, I decided to tee before the MPEG TS muxing, and use 2
instances of mpegtsmux: one for HLS (with the default alignment), and one
for SRT streaming (with alignment=7).

Hope it helps.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel