Video H264/avc packetization is not standard

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run call client sample
2. look at each video packet
3.

What is the expected output? What do you see instead?
According to document, the video H264/avc packetization will use RFC3984, but 
for each packet sending from video.rtpdump or receiving from GMAIL client, they 
use NAL code 30. It is not defined in RFC3984. Do you use your own 
packetization method for H264/AVC for video call? Any document for it?

What version of the product are you using? On what operating system?
R57 in osx 10.6.7

Please provide any additional information below.

Original issue reported on code.google.com by orzgames...@gmail.com on 9 May 2011 at 11:40

[GoogleCodeExporter]

We use the standard packetization for H.264/SVC. The pending RFC for this 
standard is available at http://tools.ietf.org/html/draft-ietf-avt-rtp-svc.

NAL unit type 30 is for the PACSI header in a SVC stream.

Original comment by jun...@google.com on 12 May 2011 at 6:30

• Changed state: Done

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

When the "H264" payload type is used, the encoding will be as specified in RFC 
3984, single NAL packetization.

Original comment by juberti@google.com on 13 May 2011 at 12:52

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi Guys, I use "H264" as the payload type (which means H264/AVC right?) but I 
got NAL type 30 from gmail client, what's wrong? Does gmail client only support 
H264-SVC? If Gmail only supports H264-SVC, why did it still accept my call 
request which uses H264 as the payload type?

Cheers

Original comment by interfac...@gmail.com on 10 Jul 2011 at 2:09

[GoogleCodeExporter]

Hello guys, the spec says "an SVC stream, even when including PACSI NAL
units, can be processed with RFC 3984 receivers and H.264/AVC decoders." but 
all packets I received from gmail client have PACSI NAL type, is the actual 
coded video data contained in the PACSI payload? How can I extract the coded 
video data from these packets? Any help please!  

Original comment by interfac...@gmail.com on 11 Jul 2011 at 2:50

[GoogleCodeExporter]

What's your "payload type"? Please let me know what you see under "PT=???" 
within the Wireshark.
If possible, please send me your pcap file, so that I can take a look.

Original comment by jun...@google.com on 11 Jul 2011 at 6:50

• Changed state: Accepted

[GoogleCodeExporter]

Hi, thank you very much for the reply! I attached the log file. My code is 
based on the voice call example, I implemented video channel in 
LinphoneMediaEngine.cc.

As you can see from the log, when I made the video call to Gmail client, I used 
payload type 97, Gmail client can accept my call and play the video, however, 
on my libjingle client side, I got decoding error because the NAL type (30) is 
not recognized. I think the decoder on my side was trying to decode H.264/AVC 
stream but Gmail client was sending H.264-SVC stream? I'm confused because 
during the call handshaking I already specified that my payload type is 
H264/AVC according to this page: 
http://code.google.com/apis/talk/call_signaling.html#Video, and Gmail client 
accepted my request with the payload type 97, but it actually sent me H.264-SVC 
stream data whose payload type should be 96.

And during the video call I always get RTP playload with NAL type 30. Since I'm 
not familiar with the H.264/SVC RTP spec, did my misunderstand anything? Any 
further direction will be highly appreciated!

Cheers

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

Attachments:

• videocall_log.txt

[GoogleCodeExporter]

Hi there,
The log file looks good to me. Also, I'm not able to reproduce this issue by 
using the "call" example with "file mediaengine". The actual media flowing on 
both directions are all PT=97.
I would recommend to capture the stream using "Wireshark" or "Rtpdump" and 
prove that the PT=96 is sending from GMail client to your client. If you don't 
feel comfortable sending the full PCAP file to me, please send me the 
screenshot where you captured the PT=96.

Original comment by jun...@google.com on 12 Jul 2011 at 4:22

[GoogleCodeExporter]

Hi, I captured my video call and attached the pcap file (which contains a 
completed video call), I only captured the UDP packets, I made the video call 
from my client to GMail client, GMail client can play the video data but my 
client cannot, the problem was described in my last comment.

In my libjingle trace I can see my video payload type is 97 and my audio 
payload type is 110, the video decoder of mediastreamer returned error (-1) 
because the NAL type is 30.

Thanks,
Regards

Original comment by interfac...@gmail.com on 13 Jul 2011 at 2:06

Attachments:

• video_call.pcap

[GoogleCodeExporter]

Hi jun...@google.com ! 

I realized I made a mistake, I got RTP header extension after the standard 
12-byte header, mediastreamer doesn't handle the RTP header extension and it 
treats the extension header as the NAL header!! That's why I got the strange 
NAL type 30, which is not used in H264/AVC.

Thanks for help.

Cheers

Original comment by interfac...@gmail.com on 14 Jul 2011 at 2:18

[GoogleCodeExporter]

Alright, for your security/pravicy concern, I've deleted the pcap file, which 
I've reviewed. Everything looks good to me.

Original comment by jun...@google.com on 14 Jul 2011 at 4:15

• Changed state: Done

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

i have decode gtalk confrence video/voice file  form pcap through wirshark and 
i try to open using ffmpeg but it displaying me error"Invalid data found when 
processing input" when i fire the ffmpeg command like 
==D:\ffmpeg-git-14d94a1-win32-static_1\ffmpeg-git-14d94a1-win32-static\bin>ffpla
y.exe 102_230PL.dat so then i get error....SO Can you please Help me as soon as 
possible....in this email..zeeltesting402@gmail.com..

Original comment by Bs.sing...@gmail.com on 31 Jan 2012 at 10:26