NAL unit type 26, 27 not yet supported

Nicolas Dufresne nicolas at ndufresne.ca
Mon Aug 31 10:53:45 UTC 2020


Le dim. 30 août 2020 15 h 00, Abhinav Agrawal <aagrawal at futopstech.com> a
écrit :

> 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 -
>
> Hitachi Kokusai Electric HC-IP3100HD
>
> I do not have much information other than this. Anything specific would be
> useful ?
>

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).


> Regards,
> Abhinav
>
> On Sun, Aug 30, 2020 at 10:52 PM Olivier Crête <
> olivier.crete at collabora.com> wrote:
>
>> 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:
>>
>> 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 -
>>
>>
>> http://gstreamer-devel.966125.n4.nabble.com/rtph264depay-Undefined-packet-type-amp-NAL-unit-type-26-27-not-supported-yet-td4693045.html
>>
>>
>> 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 <aagrawal at futopstech.com>
>> wrote:
>>
>> 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
>>  logs.tar.gz
>> <https://drive.google.com/file/d/1mP2_6rxS4kdUbh7iCTSGJN0blq_SPC0l/view?usp=drive_web>
>>
>> _______________________________________________
>>
>> gstreamer-devel mailing list
>>
>> gstreamer-devel at lists.freedesktop.org
>>
>>
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>> --
>>
>> Olivier Crête olivier.crete at collabora.com
>>
>> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200831/ccbce8f0/attachment-0001.htm>


More information about the gstreamer-devel mailing list