Wireshark · Wireshark-dev: Re: [Wireshark-dev] H264 decoding limitations in wireshark v 1.3.3

["Anders Broman" <a.broman@xxxxxxxxx>]

Hi,
>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?
It should be possible to do using the reassembly functions in
epan/reassemble.c depending on how the fragmentation is done.

>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)

That should also be possible by repeatedly calling the NAL unit decoding
code, the caveat is that the NAL unit decoding code would have to return the
offset e.g dissect the complete NAL unit(finding the start of the next one).
This is currently not done at least not for all NAL unit types. It may also
require keeping information
About the decoder Information in memory to be able to fully dissect the NAL
unit. It may also not be possible for incomplete streams.

It may also be desirable to have a preference as to the detail of dissection
as full dissection may make WS slow for large captures and use a lot of
memory.
Regards
Anders
 

-----Ursprungligt meddelande-----
Från: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] För Vassili Leonov
Skickat: den 12 mars 2010 15:44
Till: wireshark-dev@xxxxxxxxxxxxx
Ämne: [Wireshark-dev] H264 decoding limitations in wireshark v 1.3.3

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