RTP player - a suggestion

[Erik de Jong <erikdejong () gmail com>]

Hello all,

After looking at bugs 13511, 13512 and others it looks like a partial
rewrite might be the way to go.

Current situation:
- Each RTP track added gets rendered to a pcm buffer for playback.
- Each RTP track gets drawn on the graph.
- When playing each track reports the played progress which draws the
vertical line on the graph.
- Starting the player means it'll start from the beginning of all tracks.
- There is no way to pause/resume playback.
- There is no way to seek.
- Selecting a graph causes playback to slow down (bug).
- Selecting tracks doesn't mean playback will start at the earliest time in
one of the selected tracks.

My proposal:
Add 'mixer' layer which will provide the following features to improve
usability:
- Keep track of selected tracks and then starting to play start at the
track that's earliest in time.
* e.g. 2 tracks, 1 starts at 0:00 and 2 at 0:30. Selecting only 2 will
start playback at 0:30
* If no tracks are selected play all tracks available as is current
behaviour.
- Keep track of playback time and render this to the graph, this prevents
each audio track playing trying to reposition the horizontal line
- Because of the 'centralized' timekeeping above, seeking as well as
pause/resume is much easier. Also a feature like selecting part of the time
line and playing only that could be a possible feature.
- Read chunks of the selected tracks and mix them together before playing
them, presumably reading chucks will improve performance compared to
reading individual samples. I'm also guessing using just one audio output
gives better performance with lots of parallel streams. The job of
RtpAudioStream is then just rendering and playback is separated into the
mixer.
- Because the mixer manages all tracks it might be relatively easy to add
video playback in future as well...
- Let RtpAudioStream render into different formats (at least pcm and au)
and let the mixer mix this into a final stream so it can be reused for
saving the audio in the RTP stream analysis dialog as well to remove
duplicate functionality.

When the mixer layer is in place it's also feasible to have more than 2
streams rendered together as could easily be the case when there are
transferred calls. This would need to be added the RTP stream analysis
dialog as we'd have to aid the user to get all sections of the conversion
together in the player.

I look forward to hearing your comments on this before I'll start
implementation!

Regards,
Erik

___________________________________________________________________________
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