Hi,
I am trying to create mp4 video file from pcap file having capture of RTP Stream (RTP + RTCP muxed to single port) using following pipeline: `gst-launch-1.0 -e filesrc location=file1-h264-converted.pcap ! pcapparse name=pcap ! "application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264" ! rtpbin name=rtpbin ! rtph264depay ! h264parse ! "video/x-h264" ! mp4mux ! filesink async=False location=out.mp4` However, I am getting following errors: (Full log attached) NAL unit type 26 not supported yet ERROR: from element /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0: The stream is in the wrong format. Additional debug info: Undefined packet type WARNING: from element /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0: Could not decode stream. Additional debug info: ../gst-plugins-good/gst/rtp/gstrtph264depay.c(1288): gst_rtp_h264_depay_process (): /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0 Just wanted to check if there is an issue in the pipeline? I checked the same pipeline with two different sources of H264 RTP streams and I am hitting the same issue with two different sources of H264, so I am suspecting the issue is with my pipeline rather than the stream itself. Any help is highly appreciated. Regards Abhinav _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Sorry friends, Just realized that I attached a wrong log file here. No idea how to remove this. But my issue is similar to this one - Just wanted to check if any fixes are already provided for this ? Also, is it possible to just ignore the buffers with NAL 26/27 without any harm and change the error message on bus to info or something non destructive? Any help would be highly appreciated. Regards, Abhinav On Mon, Jul 27, 2020 at 12:49 AM Abhinav Agrawal <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Hi, They're still not implemented. I actually didn't know any other deployed implementation used them. Out of curiosity, what is the sender? And no, you can't safely ignore them. They may contain important parts of the bitstream. If you need to ingest such a stream, you will have to implement support for them in rtph264depay. Patches would be very welcome upstream for this! Olivier On Sun, 2020-08-30 at 22:28 +0530, Abhinav Agrawal wrote:
--Olivier Crête [hidden email] _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Hi, Thanks for quick response. I understood. Let me try to get a patch soon if that's the case :-) >Out of curiosity, what is the sender? We have got a pcap file captured from IP Camera (Multicast RTP Stream, RTP + RTCP muxed) of one of the potential customers. They said they are are using following encoders -
I do not have much information other than this. Anything specific would be useful ? Regards, Abhinav On Sun, Aug 30, 2020 at 10:52 PM Olivier Crête <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Le dim. 30 août 2020 15 h 00, Abhinav Agrawal <[hidden email]> a écrit :
A pcap is excellent thing to share. You can develop and test this by replaying the pcap (we can help here with that if needed), and by sharing it, you let us validate your implementation even if this isn't yet implemented in our payloader. Note that implementing this in our payloader is to be made opt-in, as producing MTAP16/24 is incompatible with all client out there that do not support it (as you discovered).
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Hi Nocolas, Sorry it was an issue at our side that we were depaying an MPEG2-TTS packet with h264 depayloader. Later we realized that input stream is MPEG2-TTS type encapsulated, so it was a non issue. Thanks for your support anyways. Look forward to having more interactions in the future. Regards, Abhinav On Mon, Aug 31, 2020 at 4:23 PM Nicolas Dufresne <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |