Could you provide some sample captures about the RTP issues cheers
On Tue, May 2, 2017 at 6:58 PM, Erik de Jong <erikdej...@gmail.com> wrote: > > > On Tue, Mar 28, 2017 at 9:44 AM, Alexis La Goutte < > alexis.lagou...@gmail.com> wrote: > >> >> >> On Mon, Mar 27, 2017 at 9:33 PM, Jirka Novak <j.no...@netsystem.cz> >> wrote: >> >>> Hi, >>> >>> >> 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. >>> >>> I understand Peter, but I'm afraid it is not possible to change Qt code >>> without touching GTK. The reason is that both depends on common files in >>> ui/ (ui/rtp_stream, ui/tap-rtp* etc). >>> When I started to work on Qt, it induced changes in common ui/ code and >>> as consequence I broke GTK code. >>> >>> I might be wrong because my additional aim was to write common code for >>> RTP analysis too (when you check the code for RTP analysis, you will >>> again find multiple places with same functionality - GTK, Qt and >>> TShark). Therefore I had to touch code in common ui/ directory more >>> often than just RTP player related changes might require. >>> >>> On the other hand, I'm really afraid that changes for Qt will induce >>> changes for GTK. The option could be copy all related ui/ files and >>> split them for GTK and Qt. >>> But I'm not sure whether it is good approach. >>> >> For me, it can be a valid approach because we can to remove GTK... (in >> next release GTK is disable by default and i think for 2018, we remove GTK >> support...) >> > > I'm afraid this thread kind of silently died, looks like it's a difficult > thing to tackle ;-) > > In my opinion my suggestion earlier (https://www.wireshark.org/lis > ts/wireshark-dev/201703/msg00073.html) is the least invasive way to go > about this. It won't harm legacy users and will promote code reuse. > > >> >>> Sincerely yours, >>> >>> Jirka Novak >>> >>> ____________________________________________________________ >>> _______________ >>> 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-requ...@wireshark.org?subject=unsubscr >>> ibe >>> >> >> >> ____________________________________________________________ >> _______________ >> 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-requ...@wireshark.org?subject=unsubscr >> ibe >> > > > ____________________________________________________________ > _______________ > 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-requ...@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-requ...@wireshark.org?subject=unsubscribe
