Current *proper* implementation of H264 RTP stream (RFC3984) decode is
limited to one NAL-unit per RTP packet mode.
( source file with H264 decode code: epan/dissectors/packet-h264.c,
md5sum on that file is 32a2843b03638ac85f2efe4f6d9b983c )
There is SOME code that is trying to handle FU-A (fragmented NAL-units,
no DON), that is NAL type 28, but handling of this case is not correct,
since fragmented NAL units should be re-assembled over a number (at
least 2) or RTP packets, existing code is not trying to do that, even
though it should, if it is trying to handle type 28 NALs.
This is code fragment, related to type 28 handling,
/epan/dissectors/packet-h264.c" line 1805:
==========================================================================
/* if the type is 28, it would be draw another title */
if(type == 28)
ti = proto_tree_add_text(h264_tree, tvb, offset,
1, "FU identifier");
else
==========================================================================
and then code starting at epan/dissectors/packet-h264.c" line 1833
Other RTP specific NAL types (STAP-A, STAP-B, MTAP16, MTAP24, FU-B) are
not handled in any special way at all - in particular STAP-A (NAL type
24), that is multiple NALs per RTP packet mode and is used often.
I'm entirely new to wireshark development, so I want to check these
architectural issues with seasoned Wireshark developers:
1) is it possible to decode H264 NAL unit that is fragmented over
several RTP packets (FU-A, FU-B), or wireshark decoding is limited to
just one packet?
2) is it possible to decode multiple, unknown number of NALs in STAP-A
(and STAP-B, MTAPxx) RTP packet? (it seems it should not be an issue)
I have got Perl script that does full analyis of H264/RTP encapsulation
(at least for STAP-A and FU-A packets), so if I can understand how
wireshark decode filters I can add that handling to wireshark. Most of
H264 proper decoding is coded there, but lack of proper RTP/H264
(RFC3984) makes that useless for majority of streaming scenarios.
--
Vassili Leonov
----------------------
LML LLC +1-719-359-5330
Motion video hardware solutions for GNU/Linux
vleo@xxxxxxxxxxxxxxxxxx http://linuxmedialabs.com
Attachment:
signature.asc
Description: This is a digitally signed message part