Wireshark mailing list archives

Re: RTP player - a suggestion


From: Erik de Jong <erikdejong () gmail com>
Date: Mon, 27 Mar 2017 17:37:47 +0200

On Mon, Mar 27, 2017 at 4:54 PM, Anders Broman <anders.broman () ericsson com>
wrote:



-----Original Message-----
From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-bounces@
wireshark.org] On Behalf Of Peter Budny
Sent: den 27 mars 2017 16:48
To: 'Developer support list for Wireshark' <wireshark-dev () wireshark org>
Subject: Re: [Wireshark-dev] RTP player - a suggestion

Hi Anders,

-----Original Message-----
From: wireshark-dev-bounces () wireshark org
[mailto:wireshark-dev-bounces () wireshark org] On Behalf Of Anders Broman
Sent: Monday, March 27, 2017 4:12 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] RTP player - a suggestion

My proposal:
Add 'mixer' layer which will provide the following features to
improve
usability:

 I started work on "proof of concept" for very similar idea. I
didn't finished it yet. But I have a few points which I would like
to mention and discuss it there:

1) There are at least four points where is RTP processed to audio -
once for "audio player" and once for "audio save". GTK and Qt UI
branch has own code for it => four places.

I analysed it and found that even Qt code is derived from GTK, it is
slightly different. On the other hand, the main difference is between
code in audio player and audio save in each branch.

Therefore my idea is to extract RTP audio processing code to some kind
of library.

I made part of work on it and found that there is one big issue - GTK
code "idea" is very different to Qt code. Up to now I found no way how
to prepare API for such library which can be used from GTK and Qt code
in parallel.

The question is whether it makes sense to update GTK code when there
is long term idea to leave it? If so, there is much more work than
just for Qt.

I would vote for not updating the GTK for the reasons you mention.
Worst case I'd say remove the GTK RTP player.

I disagree.  Right now, the GTK RTP player is the only one that I
consider usable.  By comparison, the Qt RTP player only barely works, and
is unusable if you're dealing with more than one stream.  If these changes
can improve the Qt >version to be about as good as the GTK version was/is,
then perhaps breaking the GTK version is okay.  But don't break/remove the
GTK version *and* leave the Qt version less than fully functional.
--
Peter Budny

My thinking is that if fixing the Qt version without too much work means
ditching the GTK version that is OK in the development track as the GTK
version is still available in older
Versions. Hopefully a usable Qt version would be available before the next
release.

The alternative may be that no one wants to work on any of the versions...


I think that because the RTP code is all contained in the respective UI it
won't break anything for GTK when enhancing the Qt code. When considering
Jirka's comment, how about the following:

- leave GTK as it is
- write a glib based RTP library which can be called from the Qt interface
(but should be possible to backport this to GTK as well if needed, might be
nice to add this to the cli interface as well). This library would do
pretty much what I described as the 'mixer' layer in my initial email. I
think there are no real advantages to using Qt for processing and mixing
the audio so using glib for portability between interfaces has priority.
- rewrite Qt interface to use the above mixer in the player
- remove audio save options in the RTP stream analysis

Best regards,
Erik

Regards
Anders

____________________________________________________________
_______________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=
unsubscribe
____________________________________________________________
_______________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=
unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

Current thread: