GNOME Bugzilla – Bug 576524
rtpbin, jitterbuffer: add mode to support for recording RTP streams
Last modified: 2011-10-29 15:47:27 UTC
Trying to record audio from a RTP stream. Sender: gst-launch-0.10 -v audiotestsrc ! lame ! rtpmpapay ! udpsink Receiver: gst-launch-0.10 --gst-debug-level=3 udpsrc ! application/x-rtp, payload=14, clock-rate=90000, media=audio ! gstrtpjitterbuffer ! rtpmpadepay ! flump3dec ! audioconvert ! vorbisenc ! oggmux ! filesink location=audio.ogg is getting this errors: 0:00:07.465505183 10321 0x2573100 WARN vorbisenc vorbisenc.c:1194:gst_vorbis_enc_chain:<vorbisenc0> Buffer is discontinuous, flushing encoder and restarting (Discont from 0:00:07.177071624 to 0:00:07.233669678) which relays on the recorded audio quality :-( NOTE: using "audiorate" removes these errors, but does not fix the audio quality. Workaround: Prior to filing this report, I compared the audio quality with: gst-launch-0.10 --gst-debug-level=3 udpsrc ! application/x-rtp, payload=14, clock-rate=90000, media=audio ! gstrtpjitterbuffer ! rtpmpadepay ! mp3parse ! filesink location=audio.mp3 Recording in MP3 gives a better audio quality.
Have you tried inserting mp3parse before the decoder ? As such : rtpmpadepay ! mp3parse ! flump3dec ! audioconvert ... Also, do you get the same issue with other decoders ? Like mad from gst-plugins-ugly
Hi, I tried receiving with this pipeline (as you suggested) and the problems persist: gst-launch-0.10 --gst-debug-level=3 udpsrc ! application/x-rtp, payload=14, clock-rate=90000, media=audio ! gstrtpjitterbuffer ! rtpmpadepay ! mp3parse ! mad ! audioconvert ! vorbisenc ! oggmux ! filesink location=audio.ogg These are the errors I am getting: 0:00:03.773714327 9691 0x102a500 WARN vorbisenc vorbisenc.c:1172:gst_vorbis_enc_chain:<vorbisenc0> Buffer is older than previous timestamp + duration (0:00:03.493159287< 0:00:03.510566893), cannot handle. Clipping buffer. 0:00:03.864839735 9691 0x102a500 WARN vorbisenc vorbisenc.c:1194:gst_vorbis_enc_chain:<vorbisenc0> Buffer is discontinuous, flushing encoder and restarting (Discont from 0:00:03.513482072 to 0:00:03.586037345) 0:00:04.029115432 9691 0x102a500 WARN vorbisenc vorbisenc.c:1194:gst_vorbis_enc_chain:<vorbisenc0> Buffer is discontinuous, flushing encoder and restarting (Discont from 0:00:03.691985474 to 0:00:03.748582344) 0:00:04.168466941 9691 0x102a500 WARN vorbisenc vorbisenc.c:1172:gst_vorbis_enc_chain:<vorbisenc0> Buffer is older than previous timestamp + duration (0:00:03.887893999< 0:00:03.905306122), cannot handle. Clipping buffer.
This is not supported yet, RTP is meant for playback, not for capture. We need a 'record' mode for RTP streams so that it does not try to interpollate the timestamps. This would then again cause more trouble when streams need to be synchronized together.
I can record good quality audio files from RTP streams, but using different encoders than vorbisenc. For instance MP3. See above. I am positive that having this RTP recording mode would help a lot, but for the time being, and since recording MP3 audio from RTP is working quite okay, I had thought it was more a vorbisenc problem rather than a general RTP problem.
The thing is that mp3 does not preserve the timestamps, so it works by accident. If you were to put the mp3 inside a container that preserved timestamps like matroska, it would fail in the same way.
Created attachment 131792 [details] [review] Patch to add new functionality to the vorbisenc I have updated gst-plugins-base from SVN three hours ago. Tried to add a new property to the plugin: The new property is "preserve-timestamps". This way, if this option is set to False, the encoder will just ignore it when timestamps are out of order, increasing the RTP recording quality. Note: I think this patch is not 100% perfect yet :-/ --> default value should be TRUE --> seems to be set to False all the time
yes, vorbisenc is totally the wrong place to do this. You should concentrate on disabling the timestamp interpollation in gstrtpbin instead.
gstrtpbin and gstrtpjitterbuffer now have a buffer-mode and mode property respectively.
Which means that this bug can be closed now?
*** Bug 598147 has been marked as a duplicate of this bug. ***
Please feel free to reopen the bug in case it's not fixed in later version of Gstreamer.