RTP playback "quirks" have caused me plenty of grief in the past. This sounds like a massive step forward in usability.
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@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
