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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190620/f807e6fe/attachment.html>