NAL unit type 26, 27 not yet supported

[Abhinav Agrawal]

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 <nicolas at ndufresne.ca>
wrote:

>
>
> 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/20200907/4164736e/attachment.htm>