GStreamer-devel

rtph264depay: can't depay RTP over TCP video data.

classic Classic list List threaded Threaded
♦
♦
 2 messages Options
Oleksandr K
Reply | Threaded
Open this post in threaded view
♦
♦
|

rtph264depay: can't depay RTP over TCP video data.

Oleksandr K
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?

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Nicolas Dufresne-5
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: rtph264depay: can't depay RTP over TCP video data.

Nicolas Dufresne-5
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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (201 bytes) Download Attachment
Free forum by Nabble Edit this page