[Erik de Jong <erikdejong@xxxxxxxxx>]

On Mon, Mar 27, 2017 at 4:54 PM, Anders Broman <anders.broman@xxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx>
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