Mousseau, Matthew schrieb:
Maybe I will also try to look into (if I have time) to do modifications
for writing au-files from Ethereal.
Then I'm thinking of making a completely new subroutine that will be
based on the rtpdump_save subroutine (instead of saving to temporar
file
when analysing a specific stream with the rtp-analysis).
Of course there will be a need to handle silence suppression, lost
packets,
out-of-order-packets, duplicates packets and so on - since there is a
fundamental difference between rtpdump-format and au-file-format
(rtpdump
is a raw stream where packets are stored in the order they are
received).
Thank you for considering modifying the feature to support this. Do you
think this would be very difficult?
I mainly use rtpdump format since I often use other codecs than G.711,
but
another advantage with rtpdump format is that when replaying the
rtpdumpfiles with rtpplay+JMPlayer or rtpplay+QuickTimePlayer the
rtp-stream will replayed in a more realistic way since those programes
will
handle dropped/duplicate packets in a more correct way, I think.
We are able to capture the audio into rtpdump files and to replay them
back to software that listens to RTP streams (QuickTime, JMStudio, etc.)
However, that doesn't get us anywhere... we're back where we started...
I still have an RTP stream that I need to capture in an audio file,
because my software only takes in audio files (like .au) to do the
quality analysis.
IMO it doesn't make sense to measure the speech quality of an audio
stream extracted from an rtp stream by ethereal, because the quality of
ethereal's rtp to audio conversion would influence the speech quality in
the audio stream.
You should measure the end to end speech quality instead.
Your endpoint should convert the rtp stream to an audio stream and then
you should take this stream as input for speech quality analysis.
However improvements to Ethereal's rtp to audio conversion algorithm are
always welcome.
Regards,
Lars Roland
