NAL type 18 from GMail client when making a video call
GoogleCodeExporter opened this issue · comments
Google Code Exporter commented
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
Google Code Exporter commented
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
Google Code Exporter commented
[deleted comment]
Google Code Exporter commented
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
Google Code Exporter commented
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
Google Code Exporter commented
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
Google Code Exporter commented
Original comment by juberti@google.com
on 9 Sep 2011 at 7:36
- Changed state: Done