lost packets

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

lost packets

Tomasz Grobelny-2
In short: is there any gst element that would make up packets that are missing
from audio stream?

Now the long version:
I send audio data encoded with speex over rtp/udp and then on the other end I
receive it, decode and send to alsasink. The problem is that the network has
quite a considerable packet loss (let's say 5% introduced by netem kernel
module). Every few seconds the audio playback stops and I get something like:

WARNING: from element /pipeline0/alsasink0: Compensating for audio
synchronisation problems
Additional debug info:
gstbaseaudiosink.c(1190): gst_base_audio_sink_render (): /pipeline0/alsasink0:
Unexpected discontinuity in audio timestamps of more than half a second
(0:00:00.500000000), resyncing

If I use fakesink instead of alsasink the output looks like this:
/pipeline0/fakesink0: last-message = "chain   ******* < (  640 bytes,
timestamp: 0:00:02.900000000, duration: 0:00:00.020000000, offset: 43200,
offset_end: 43520, flags: 0) 0x8151458"
/pipeline0/fakesink0: last-message = "chain   ******* < (  640 bytes,
timestamp: 0:00:02.920000000, duration: 0:00:00.020000000, offset: 43520,
offset_end: 43840, flags: 0) 0x81514a8"
/pipeline0/fakesink0: last-message = "chain   ******* < (  640 bytes,
timestamp: 0:00:02.960000000, duration: 0:00:00.020000000, offset: 43840,
offset_end: 44160, flags: 0) 0x81514f8"
/pipeline0/fakesink0: last-message = "chain   ******* < (  640 bytes,
timestamp: 0:00:02.980000000, duration: 0:00:00.020000000, offset: 44160,
offset_end: 44480, flags: 0) 0x814aed0"
/pipeline0/fakesink0: last-message = "chain   ******* < (  640 bytes,
timestamp: 0:00:03.000000000, duration: 0:00:00.020000000, offset: 44480,
offset_end: 44800, flags: 0) 0x814ae80"
/pipeline0/fakesink0: last-message = "chain   ******* < (  640 bytes,
timestamp: 0:00:03.020000000, duration: 0:00:00.020000000, offset: 44800,
offset_end: 45120, flags: 0) 0x8151548"

As you can see the packet with 0:00:02.940000000 timestamp has been lost. But
it seems like alsasink cannot correctly handle such a case. Fixing alsasink
is one way to go. The other would be to use an element that would recreate
missing packets. They should contain either silence or somehow derive it from
preceeding and succeeding packets (comfort noise?). Does such an element
exist? Thanks in advance,
--
Regards,
Tomasz Grobelny

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel