Wireshark mailing list archives
H264 decoding limitations in wireshark v 1.3.3
From: Vassili Leonov <vleo () linuxmedialabs com>
Date: Fri, 12 Mar 2010 17:43:32 +0300
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 () linuxmedialabs com http://linuxmedialabs.com
Attachment:
signature.asc
Description: This is a digitally signed message part
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- H264 decoding limitations in wireshark v 1.3.3 Vassili Leonov (Mar 12)
- Re: H264 decoding limitations in wireshark v 1.3.3 Anders Broman (Mar 12)