I've noticed that some of my rtspsrc pipelines give errors/warnings like the following. Are these fatal? What are the implications? 2020-01-09T00:29:29.616Z - WARNING - src:rtph264depay13 msg:Could not decode stream. dbg:gstrtph264depay.c(1288): gst_rtp_h264_depay_process (): /GstPipeline:pipeline24/GstRtpH264Depay:rtph264depay13:\nUndefined packet type 2020-01-09T00:29:29.627Z - ERROR - src:rtph264depay13 msg:The stream is in the wrong format. dbg:gstrtph264depay.c(1299): gst_rtp_h264_depay_process (): /GstPipeline:pipeline24/GstRtpH264Depay:rtph264depay13:\nNAL unit type 27 not supported yet Thanks! - Bill _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Le mercredi 08 janvier 2020 à 20:26 -0500, Bill Klein a écrit :
> I've noticed that some of my rtspsrc pipelines give errors/warnings like the following. Are these fatal? What are the implications? This is about packet aggretation, or if you prefer, placing multiple NALs into a single RTP packet. At the moment, we support STAP-A and STAP-B depayloading. This means aggregating multiple NALs into a packet, though all NALs will be sharing the same timestamp. MTAP16 and MTAP24 (this is the one you have hit) are not implemented. This is about multiple NALs into one packet, but with potentially multiple timestamps. https://tools.ietf.org/html/rfc6184#section-5.7 https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/gst/rtp/gstrtph264depay.c#L1160 It should not be too hard to implement, I personally never had a server producing this. It's rare because to produce this, an payloader need to introduce a significant amount of latency. In GStreamer you will have to split back NALs per timestamp, as NALs in one buffer are expected to share the same timestamp. Now, is it fatal or not, that depends on what the server uses it for. MTAP is unlikely to contain crucial information like headers, since those are most of the time followed by an IDR NAL which is usually quite big. So the efficient aggretation will be STAP-A or B, as all the content endup having the same timestamp. So it is quite likely that only some delta slices endup there, which will create a minor glitch in rendering if it was just dropped. Though, GStreamer currently post an ERROR message on the bus, and that's meant to be fatal. I think, best use of your time is to implement the remaining in the depayloader. > > 2020-01-09T00:29:29.616Z - WARNING - src:rtph264depay13 msg:Could not decode stream. dbg:gstrtph264depay.c(1288): gst_rtp_h264_depay_process (): /GstPipeline:pipeline24/GstRtpH264Depay:rtph264depay13:\nUndefined packet type > > 2020-01-09T00:29:29.627Z - ERROR - src:rtph264depay13 msg:The stream is in the wrong format. dbg:gstrtph264depay.c(1299): gst_rtp_h264_depay_process (): /GstPipeline:pipeline24/GstRtpH264Depay:rtph264depay13:\nNAL unit type 27 not supported yet > > Thanks! > > - Bill > _______________________________________________ > 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 |
Free forum by Nabble | Edit this page |