H264 over RTP - missing h264 sequences

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

H264 over RTP - missing h264 sequences

26,150 Views
MicMoba
Contributor V

I can show a h264 stream over RTP on my display by using GStreamer. Bandwith usage is approximately at 25Mb.

When I connect a second streaming source to my display the video is juddering. But only one stream. The Bandwith usage is approximately at 50Mb.

To exclude the VPU I extracted from every streaming source a h264-file and copied to my display. Then I playback both files simultaniosly by using GStreamer. It works well.

So the receiving of RTP frames and the rtph264depay was left. To check this I recorded rtpdumps with rtpdump-tool form rtptools.

I recorded a stream fom source 1 and source 2 while both streams are running. Then I recorded a from each stream a single dump.

I copied the dumps to my PC. Then I playback the dumps with rtpplay also from rtptools to localhost and trace these dumps with Wireshark.

I decoded the UDP frames as RTP->H264 and looked at the H264 Seq-Number. (Is shown in the info field of each frame). I noticed that the seq-numbers of all good working streams were always increased by 1. At the stream where I noticed juddering the seq-numbers sometimes increased by 10 or 20 or something between  (See attached Image No.19 to No.20, Seq jumps from 55256 to 55269)

So my question. Is it allowed that the seq-numbers increased by more than 1?

Is there a lost of frames in my network stack?

Thanks Michael

EDIT: 03.08.2020 - 15:26

I did further investigations. I think it has something to do with udp frame drops. When I look at /proc/net/udp I can see a lot of drops when both streams are running. It can be an explaination for the missing seq-numbers but I don't understand why only seq-numbers of one stream are missing and not of both.

EDIT: 04.08.2020 - 9:16

I did tcpdump for both UDP ports on my display and analyse them with Wireshark. I saw that packets of the one stream that also has missing h264 seq-numbers were droped.

In my opinion this is the proof that it is an issue with the network stack. But I can't understand why only frames of one stream were droped.

Labels (3)
Tags (4)
0 Kudos
Reply
3 Replies

26,081 Views
MicMoba
Contributor V

Hi Joan,

we use a Trizeps7 SOM module from Keith & Koep. The Ethernet PHY is already on this module. We only fit a RJ45 plug with coils to our base board.

Therefore we use a modified Keith & Koep BSP.

0 Kudos
Reply

26,044 Views
joanxie
NXP TechSupport
NXP TechSupport

I'm not familiar with this board, what nxp board did you board design based on? could you reproduce this issue on nxp board?

0 Kudos
Reply

26,081 Views
joanxie
NXP TechSupport
NXP TechSupport

what board and bsp version are you talking about?

0 Kudos
Reply