rtph264depay: can't depay RTP over TCP video data.
Nicolas Dufresne
nicolas at ndufresne.ca
Fri Jun 21 14:56:10 UTC 2019
Le jeudi 20 juin 2019 à 17:17 +0300, Oleksandr K a écrit :
> Hi, I'm trying to create video+audio file of RTP/TCP session from pcap dump. I found some bugs in pcapparse and irtspparse, fix them, and now I have valid RTP frames after
> > /opt/gstreamer/gst-uninstalled.py gst-launch-1.0 -v filesrc location=cam_full.pcap ! pcapparse src-ip=ip_here src-port=554 dst-ip=192.168.220.151 dst-port=50056 ! irtspparse channel_id=0 ! filesink location=rtp_ch0.dump
> >
>
> output file size is 900+KB.
> Next, I try:
> > /opt/gstreamer/gst-uninstalled.py gst-launch-1.0 -v filesrc location=cam_full.pcap ! pcapparse src-ip=ip_here src-port=554 dst-ip=192.168.220.15 dst-port=50056 ! irtspparse channel_id=0 ! application/x-rtp, media=video, clock-rate=90000, encoding-name=H264, payload=99 ! rtph264depay ! filesink location=rtp_ch0_h264.dump
> >
>
> And now output file size is only 30KB.
> I know that dump and data are valid because I have hand-written node.js script that sucessfuly depacketize same dump, and whichI want to replace with gst-based solution.
> I enable debug log and found that only NAL type == 1 is actually dumped, but the dump also contains type 24 and 28. Here's the part of the log:
> > 0:00:01.056172015 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:1059:gst_rtp_h264_depay_process:<rtph264depay0> [00m receiving 31 bytes
> > 0:00:01.056176391 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:1079:gst_rtp_h264_depay_process:<rtph264depay0> [00m NRI 3, Type 24
> > 0:00:01.056179870 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:1104:gst_rtp_h264_depay_process:<rtph264depay0> [00m payload_len: 30
> > 0:00:01.056228868 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:892:gst_rtp_h264_depay_handle_nal:<rtph264depay0> [00m handle NAL type 7
> > 0:00:01.056232383 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:899:gst_rtp_h264_depay_handle_nal:<rtph264depay0> [00m !rtph264depay->byte_stream: 1
> > 0:00:01.056269150 [335m17080 [00m 0x1f030a0 [33;01mLOG [00m [00m rtph264depay gstrtph264depay.c:577:gst_rtp_h264_add_sps_pps:<rtph264depay0> [00m Adding new SPS 0
> > 0:00:01.056436232 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:892:gst_rtp_h264_depay_handle_nal:<rtph264depay0> [00m handle NAL type 8
> > 0:00:01.056442685 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:899:gst_rtp_h264_depay_handle_nal:<rtph264depay0> [00m !rtph264depay->byte_stream: 1
> > 0:00:01.056502592 [335m17080 [00m 0x1f030a0 [33;01mLOG [00m [00m rtph264depay gstrtph264depay.c:617:gst_rtp_h264_add_sps_pps:<rtph264depay0> [00m Adding new PPS 0:0
> > 0:00:01.057621853 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:1059:gst_rtp_h264_depay_process:<rtph264depay0> [00m receiving 1408 bytes
> > 0:00:01.057629134 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:1079:gst_rtp_h264_depay_process:<rtph264depay0> [00m NRI 3, Type 28
> > 0:00:01.057635203 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:1184:gst_rtp_h264_depay_process:<rtph264depay0> [00m S 1, E 0, wait_start: 1
> > 0:00:01.057639819 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:1202:gst_rtp_h264_depay_process:<rtph264depay0> [00m wait_start = FALSE
> > 0:00:01.057690575 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:1224:gst_rtp_h264_depay_process:<rtph264depay0> [00m queueing 1411 bytes
> > 0:00:01.057704657 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:1248:gst_rtp_h264_depay_process:<rtph264depay0> [00m finish: 0
> > 0:00:01.059906676 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:1059:gst_rtp_h264_depay_process:<rtph264depay0> [00m receiving 1408 bytes
> > 0:00:01.059915590 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:1079:gst_rtp_h264_depay_process:<rtph264depay0> [00m NRI 3, Type 28
> > 0:00:01.059921731 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:1184:gst_rtp_h264_depay_process:<rtph264depay0> [00m S 0, E 0, wait_start: 1
> > 0:00:01.059926528 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:1299:gst_rtp_h264_depay_process:<rtph264depay0> [00m waiting for start
> > 0:00:01.060617957 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:1059:gst_rtp_h264_depay_process:<rtph264depay0> [00m receiving 1408 bytes
> > 0:00:01.060623572 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:1079:gst_rtp_h264_depay_process:<rtph264depay0> [00m NRI 3, Type 28
> > 0:00:01.060628972 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:1184:gst_rtp_h264_depay_process:<rtph264depay0> [00m S 0, E 0, wait_start: 1
> > 0:00:01.060633569 [335m17080 [00m 0x1f030a0 [37mDEBUG [00m [00m rtph264depay gstrtph264depay.c:1299:gst_rtp_h264_depay_process:<rtph264depay0> [00m waiting for start
> >
>
> For now, I don't know how depacketization works, but it seems that for type 28 there's always wait_start=TRUE, and type 24 just skipped by return in gst_rtp_h264_depay_handle_nal().
> Any ideas?
If you need a parsable RTP stream, you need to use
rtpstreampay/rtpstreamdepay.
regards,
Nicolas
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190621/22cc5323/attachment.sig>
More information about the gstreamer-devel
mailing list