NAL type 18 from GMail client when making a video call

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Integrate linphone mediastream2 with libjingle
2. Based on the libjingle voice example, implement video call
3. Make a video call (choose payload type 97: H.264/AVC) from libjingle client 
to GMail client

What is the expected output? What do you see instead?
libjingle client cannot decode the packets sent from GMail client, the H.264 
decoder in mediastreamer always gets decoding error

What version of the product are you using? On what operating system?

Please provide any additional information below.
1. RTP packets from GMail always have NAL type 18, which causes decoding error 
because the H.264 codec in mediastreamer doesn't recognize this NAL type, NAL 
type 18 is a "reserved" NAL type according to "ITU-T Recommendation H.264", 
doesn't anyone know how to handle such NAL type?

Original issue reported on code.google.com by interfac...@gmail.com on 18 Jul 2011 at 11:40

[GoogleCodeExporter]

Hi Guys,

This is an issue about video call between libjingle client and GMail client, I 
always receive packets with NAL type 18 from GMail client

Here is an example packet which I captured using wireshark:

[RTP Standard header: 12 bytes]
90 e1 4e de // Payload type is 97, so this is correct
71 46 f3 05 
e2 28 97 85 

[Extension header: 12 bytes, no problem] check this FYI: 
http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10

be de 00 03
66 00 00 00 
02 c8 ea c5 

[Actual payload: 0x72 indicates the NAL type is 18]
72 00 00 1b 
21 e3 18 0b
...

"ITU-T Recommendation H.264" says:

----
NAL units having nal_unit_type equal to 13 and 19 may be discarded by decoders 
without affecting the decoding process for NAL units having nal_unit_type not 
equal to 13 or 19 and without affecting conformance to this Recommendation | 
International Standard. (Page 57)
----

But I received a lot of NAL 18 packets, I think I cannot simply ignore them, 
I'm not a H.264 expert, does anyone know to handle NAL 18 packets? Is it 
specific to GMail client?

Kind Regards

Original comment by interfac...@gmail.com on 18 Jul 2011 at 12:27

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

now I understand the extension header is:

be de 00 03
66 00 00 00 
02 c8 ea c5 
72 00 00 1b 

So the payload starts with "0x21", but my decoder always returns error because 
the first byte of my payload is always "0x21", why do I always get coded slice? 
An idea?  

Original comment by interfac...@gmail.com on 20 Jul 2011 at 12:52

[GoogleCodeExporter]

If the first byte after the extension header is 21, the NAL unit type is 
1(non-IDR slice), but I think the first two NAL units you should receive are 
7(SPS) and 8(PPS). Are you using wireshark to make the capture? Does it show 
only non-IDR NAL units? Here I don't have this issue.

Original comment by diego.cd...@gmail.com on 12 Aug 2011 at 4:09

[GoogleCodeExporter]

I found I actually missed SPS and PPS frame because GMail started the stream 
before I accepted, that's why I "always" got slice frames. 

Thanks Diego. 

Original comment by interfac...@gmail.com on 18 Aug 2011 at 10:46

[GoogleCodeExporter]

Original comment by juberti@google.com on 9 Sep 2011 at 7:36

• Changed state: Done