Guy Harris wrote:
On Aug 25, 2006, at 1:45 PM, Shaun Jackman wrote:
I've created an MPEG stream decoder for Wireshark. It's useful for
decoding streaming audio. It currently supports MPEG-1, MPEG-2,
MPEG-2.5 audio, layers 1, 2, 3. To test out the protocol decoder, the
first half of the patch adds a wiretap file format to allow opening
your favourite MPEG audio file (mp3 for example). The second half of
the patch adds the protocol decoder. This patch is generated against
wireshark 0.99.2.
The current SVN version of Wireshark has a dissector,
epan/dissectors/packet-mp2t.c, for "RFC 2250 MPEG2 (ISO/IEC 13818-1)
Transport Stream dissection".
Does it duplicate what your dissector does, or do they handle different
layers of the encoding - for example, should the current dissector call
your dissector for MPEG-1 or MPEG-2 payload, rather than just dissecting
the payload as an opaque blob, as it does now?
(Erwin - the RFC's title is "RTP Payload Format for MPEG1/MPEG2 Video";
does your dissector handle only MPEG-2, not MPEG-1? Also, the title
says "Video", but the abstract says "This memo describes a packetization
scheme for MPEG video and audio streams.")
RFC2250 applies to at least two types of RTP traffic, PT_MPV and
MP_MP2T. The PT_MPV dissecting is done by packet-mpeg1.c and the PT_MP2T
dissecting is done by my newer packet-mp2t.c.
The MP2T has a MPEG2 Transport Stream inside, I believe there are
possibilities to pack those transport streams also in raw UDP packets,
and it is also used in files.
So there could be some overlap, and we have to look into removing that
overlap if it is there :-)
The mpeg2 transport stream decoding could be moved to a own dissector,
since it always uses 188bytes packets. For the other (MPEG1, MP3, MPEG4,
etc.) formats I don't really know.
What of course would be real interesting is to display the actual
pictures (or sounds), but i don't know how far we can legally go, cause
about every mpeg decoding system is patented :-/
- Erwin
