*rtp_stream* -> rtpstream to follow common name
Change-Id: I381bc1cdb8206c5cfe67e94dd7fb1a5cb25f9c16
Reviewed-on: https://code.wireshark.org/review/28394
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Changes:
- rtpstream_packet renamed to rtpstream_packet_cb to follow *_cb pattern
- variables/types used in iax2_analysis_dialog were created as copy of *rtp* ones, but names were left as *rtp* -> *iax2*
- struct _rtp_stream_info replaced with rtp_stream_info_t
- there was tap-rtp-analysis.h, but no tap-rtp-analysis.c - related content was moved from tap-rtp-common.c
- *rtp_stream* functions renamed to *rtpstream*
- renamed rtp_stream_info_t to rtpstream_info_t to follow *rtpstream* pattern.
- renamed ui/rtp_stream.c rtpstream_draw -> rtpstream_draw_cb
Change-Id: Ib11ff5367cc464ea1b0c73432bc50b0eb9cd203e
Reviewed-on: https://code.wireshark.org/review/28299
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Move */ to a separate line below the SPDX identifier.
Change-Id: Id1032215449cfccae0933147b45e04b65e0b727f
Reviewed-on: https://code.wireshark.org/review/27211
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The first is deprecated, as per https://spdx.org/licenses/.
Change-Id: I8e21e1d32d09b8b94b93a2dc9fbdde5ffeba6bed
Reviewed-on: https://code.wireshark.org/review/25661
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
In the RTP player dialog, list the default audio device first, ensure
it's selected by default and ensure that the list items are unique.
According to
http://code.qt.io/cgit/qt/qtmultimedia.git/tree/src/plugins/windowsaudio/qwindowsaudiodeviceinfo.cpp?h=5.9
the default device on Windows uses the special WAVE_MAPPER id, which
appears to support various sample rates even when the underlying
hardware doesn't.
Ensuring the names are unique fixes an issue I'm seeing on a test
machine here.
When decoding, check to see if our sample rate is supported by our
output device and adjust accordingly.
Bug: 13906
Change-Id: Iddc0beb2459bfac42276ff29d227c2619b0a8d90
Reviewed-on: https://code.wireshark.org/review/22756
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
When the sample rate is zero, a floating point exception (FPE) occurs in
QAudioDeviceInfo::nearestFormat. Detect the error condition instead and
show an error.
Change-Id: Ie2eaa57847938fe15607fa26d0f4e08e7ddd23d1
Fixes: v2.3.0rc0-1664-gd59653f8d5 ("Qt: Make the RTP player output device selectable.")
Reviewed-on: https://code.wireshark.org/review/19569
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Fix build error:
ui/qt/moc_rtp_player_dialog.cxx:87:76: error: ‘currentOutputDeviceName’ was not declared in this scope
case 0: *reinterpret_cast< QString*>(_v) = currentOutputDeviceName(); break;
Change-Id: I065862540e775c3e965cb5d3ae4c53bd8d505bdd
Reviewed-on: https://code.wireshark.org/review/19142
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
The CONSTANT attribute indicates that the same value will be returned
every time. That isn't the case here so remove it.
Change-Id: Ie7451e6aabcb4fa1a6960762d96ad190f32b3d7a
Reviewed-on: https://code.wireshark.org/review/19130
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Add a combobox for selecting the output device and populate it with our
available devices. Let the user know if our output format isn't
supported.
Ping-Bug: 13105
Change-Id: I299c7d0f191bb66d93896338036000e2c377781f
Reviewed-on: https://code.wireshark.org/review/19046
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
When dragging the UI, this somehow causes a great lag. Then by
spam-clicking on the Stop button, a double free seems to occur.
Fix this by moving the audio cleanup to the outputStateChanged callback
as documented at https://doc.qt.io/qt-5/qaudiooutput.html. Note that
calling stop() in the IdleState also triggers a change event, resulting
in the desired cleanup.
Stop streams before the dialog is closed (via accept/reject). This
*cannot* be done in the destrutor of RtpPlayerDialog because destructing
QAudioOutput processes events from the event queue, resulting in
preature destruction of other objects... crash.
Change-Id: I6bfb33c9396e9bc1ffd346519d22390a97b6bdaf
Reviewed-on: https://code.wireshark.org/review/11894
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Copy the jitter logic from rtp_player.c to rtp_audio_stream.cpp. This
still isn't correct but the RTP player should now be complete enough to
start looking at the bug list at the top of rtp_player_dialog.cpp.
Disable timing and jitter controls while we're playing while we're here.
Fixes bug 11635.
Bug: 11635
Change-Id: Ie583ade522702cbe1bbcea4475a535caa1d74fa2
Reviewed-on: https://code.wireshark.org/review/11295
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
In RtpAudioStream split tapping+decoding into separate member functions.
Store RTP payloads in memory. In RtpPlayerDialog split tapping+plotting.
This more closely resembles what we're doing in the GTK+ UI and paves
the way for jitter support and other changes.
Change-Id: I244c225cec8930545622e6582b7be35ebe45b237
Reviewed-on: https://code.wireshark.org/review/11195
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Rename the "Play Call" button to "Play Streams". Move the button
creation code to a common routine. Use it to add a "Play Streams" button
to the RTP Stream Analysis, similar to the GTK+ UI.
Don't restrict RTP to IPv[46] as suggested by Michal. I don't have any
RTP-over-Bluetooth captures so I can't test this directly.
Change-Id: I4703cac1d5bf5b3ff0255d36da2c5164feb0547d
Reviewed-on: https://code.wireshark.org/review/10888
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Change-Id: I28ae077be535f32ef81ac370d6782033f219017d
Reviewed-on: https://code.wireshark.org/review/10777
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Note the "initial". This is woefully incomplete. See the "to do" lists
below and in the code.
This differs a bit from the GTK+ version in that you specify one or more
streams to be decoded.
Instead of showing waveforms in individual widgets, add them all to a
single QCustomPlot. This conserves screen real estate and lets us more
easily take advantage of the QCP API. It also looks better IMHO.
Change a bunch of checks for QtMultimediaWidgets to QtMultimedia. We
probably won't use the widgets until we make 5.0 our minimum Qt
version and plain old QtMultimedia lets us support Qt 4 more easily
(in theory at least).
Add resampling code from libspeex. I initially used this to resample
each packet to match the preferred rate of our output device, but this
resulted in poorer audio quality than expected. Leave it in and use to
create visual samples for QCP and to match rates any time the rate
changes. The latter is currently untested.
Add some debugging macros.
Note that both the RTP player and RTP analysis dialogs decode audio data
using different code.
Note that voip_calls_packet and voip_calls_init_tap appear to be dead
code.
To do:
- Add silence frames where needed.
- Implement the jitter buffer.
- Implement the playback timing controls.
- Tapping / scanning streams might be too slow.
Change-Id: I20dd3b66d3df53c9b1f3501262dc01458849f6b4
Bug: 9007
Reviewed-on: https://code.wireshark.org/review/10458
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Jiri Novak