Hi all!
Here is a list of type, layerid and tid I get from rtp packets(first two bytes parsed):
t=1,l=32,ti=0
t=0,l=34,ti=3
t=0,l=32,ti=2
t=0,l=54,ti=7
t=0,l=36,ti=2
t=0,l=54,ti=1
t=0,l=33,ti=3
t=1,l=0,ti=0
t=1,l=0,ti=0
t=1,l=0,ti=0
t=0,l=15,ti=5
t=1,l=0,ti=0
t=0,l=27,ti=3
t=1,l=0,ti=0
t=1,l=0,ti=0
t=0,l=20,ti=1
t=1,l=0,ti=0
t=1,l=0,ti=0
t=1,l=0,ti=0
t=0,l=23,ti=4
t=1,l=0,ti=0
t=0,l=14,ti=4
t=1,l=0,ti=0
According to the standard type 0 or 1 signals that payload is single nal unit. But I see annex_b 0 0 0 1 sequences inside rtp payload so rtp payload is not single nal unit. it is not aggregated/fu as well.
Attached are headers and slice of payloads of the first and second rtp h265 packets from beginning or webrtc session.
If I cut strange first byte and combine all rtp payloads with the same timestamps I get valid h265 frame I can play in players. if I just combine all rtp payloads with the same timestamp I get garbage in playback.
Resulting h265 frame has multiple nal-units separated by annex_b_delimiter 0 0 0 1
As for me, RTP payload for h265 produced by IOS/MacOS is malformed. packetization-mode is not presented in Apple devices' offers and hence should be considered as packetization-mode=0 where the only single nal unit per rtp packet allowed. but what I see is not single not unit but something else.
Could anybody share some thoughts about this ? may be somebody had experience with h265 support in webrtc on Apple or another devices