| Bug ID |
12126
|
| Summary |
RTP stream analysis: false positive bad packets for video mark frames ("incorrect timestamp")
|
| Product |
Wireshark
|
| Version |
2.0.1
|
| Hardware |
x86
|
| OS |
Windows 7
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
GTK+ UI
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 14330 [details]
brief snippet demonstrating the RTP analysis issue
Build Information:
Version 2.0.1 (v2.0.1-0-g59ea380 from master-2.0)
Copyright 1998-2015 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with Qt 5.3.2, with WinPcap (4_1_3), with libz 1.2.8, with
GLib 2.42.0, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.2, with GnuTLS
3.2.15, with Gcrypt 1.6.2, with MIT Kerberos, with GeoIP, with QtMultimedia,
with AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with locale C, with
WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version
1.0 branch 1_0_rel0b (20091008), with GnuTLS 3.2.15, with Gcrypt 1.6.2, without
AirPcap.
Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz (with SSE4.2), with 3996MB of
physical memory.
Built using Microsoft Visual C++ 12.0 build 31101
--
As already earlier reported in earlier bugs 165 and 4194, all the latest builds
of wireshark do incorrectly identify all video rtp "mark" frames as "bad RTP
frames". Reason: Incorrect timeframe.
See this with many different H.264 streams, which usually send a bundle of
consequent RTP packets that all belong to a single frame. This single video
frame completes with the last packet which has the RTP marker set as "true".
All these RTP packets from the same video frame come with monotonous increased
RTP sequence numbers, but all with identical RTP time stamp:
H264 PT=DynamicRTP-Type-96, SSRC=0xA166212A, Seq=13492, Time=3950436739 FU-A
H264 PT=DynamicRTP-Type-96, SSRC=0xA166212A, Seq=13493, Time=3950436739 FU-A
H264 PT=DynamicRTP-Type-96, SSRC=0xA166212A, Seq=13494, Time=3950436739 FU-A
H264 PT=DynamicRTP-Type-96, SSRC=0xA166212A, Seq=13495, Time=3950436739,
Mark FU-A End <-- marked as "BAD"
So the RTP analysis falsly reports one RTP packet of each video frame as "bad".
Which is quite distracting - you cannot find "true positives" by "next problem
packet" because of the mass of false positives.
Any chance to improve this? E.g. by an analysis flag from the GUI?
You are receiving this mail because:
- You are watching all bug changes.