Ethereal-dev: Re: [Ethereal-dev] Building mpeg-4 dissector, help.
Simol Hailstone wrote:
>
> >> I don't know so much about the details in MPEG-4 and if
> >> it is possible to make a heuristic dissector for it,
> >> i.e. if there is something in the RTP payload that is
> >> very specific for MPEG-4.
>
> > There is actually a bit sequence that is unique in an mpeg4
> > elementary video stream that is called start code. This
> > code is a 32bit sequence composed of 23 0 and a 1 (0000 0000
> > 0000 0000 0000 0001).The next 8 bits are to determine the
> > type of content of the video stream (VOPs, GVOPs, SPRITEs ecc.)
> > So totally there are 32bits that determines the RTP payload
> > in an unique way.
> >
> > Would this be enough to accomplish a heuristic dissection?
>
>
> That would match MPEG-2 video Elementary Streams too, since
> they also use 0x00000001 for start codes...
>
I guess that there is a risk that the pattern may be valid also for some
other codecs, but maybe it can be used together with some other heuristics
and configuration settings in the dissectors.
Is it normal that the static payload type (payload type 32 or 33) is used
when MPEG-2 is used ?
Then it might be possible to handle MPEG-2 differently than MPEG-4.
One idea could be to add a table in rtp dissector that could be used only
for heuristic dissection of dynamic payload types (payload types in
range 96 - 127).
As an addition to checking that the packets match a certain pattern (certain
bits set, length of payload, ...) you could maybe configure the dissector
with a payload type range, e.g. having a range specified as
"96;97;99;103;104;107" in preference setting. The dissector could then
accept only packets that matches the pattern and where the dynamic payload
type is in the range specied in the preference setting. So if you don't want
packets to be
decoded with MPEG-4 dissector you could set the range to "".
I guess that the "start code" mentioned above may not appear in every RTP
packet for a MPEG-4 stream, so maybe there is also a need to use the
"conversation" mechanism to decode all packets related to a specific RTP
stream with a specific payload dissector.
If there is no "conversation" started it could be started and some data can
be stored that will make RTP dissector to use a specific payload dissector.
If there is already a "conversation" some data can be set so that RTP
disector will use a specific payload dissector for all packets for that
"conversation".
