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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |