[gstreamer-bugs] [Bug 478244] rtpamrdepay make no playable stream

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=478244

  GStreamer | gst-plugins-good | Ver: 0.10.6




------- Comment #7 from Terry  2007-09-24 02:56 UTC -------
I got another problem and also seems related to the duration

The pipeline i use this time:
gst-launch -m ffmux_3gp name=mux ! filesink location=/home/video/receive.3gp \
{ udpsrc num-buffers=500 port=11002 name=audioudp caps="application/x-rtp,
media=(string)audio, payload=(int)98, clock-rate=(int)8000,
encoding-name=(string)AMR, encoding-params=(string)1, octet-align=(string)1" !
rtpamrdepay queue-delay=0 ! queue } ! mux.audio_0 \
{ udpsrc num-buffers=500 port=11000 name=videoudp caps="application/x-rtp,
media=(string)video, payload=(int)34, clock-rate=(int)90000,
encoding-name=(string)H263" ! rtph263depay queue-delay=0 ! queue } !
mux.video_0


With the above pipeline, once it receive the stream, error occurs:
Setting pipeline to PLAYING ...
Got Message from element "pipeline0" (new-clock): GstMessageNewClock,
clock=(GstClock)GstSystemClock
New clock: GstSystemClock
Got Message from element "mux" (state-changed): GstMessageState,
old-state=(GstState)GST_STATE_PAUSED, new-state=(GstState)GST_STATE_PLAYING,
pending-state=(GstState)GST_STATE_VOID_PENDING
Got Message from element "queue0" (state-changed): GstMessageState,
old-state=(GstState)GST_STATE_PAUSED, new-state=(GstState)GST_STATE_PLAYING,
pending-state=(GstState)GST_STATE_VOID_PENDING
Got Message from element "queue1" (state-changed): GstMessageState,
old-state=(GstState)GST_STATE_PAUSED, new-state=(GstState)GST_STATE_PLAYING,
pending-state=(GstState)GST_STATE_VOID_PENDING
Got Message from element "rtpamrdepay0" (state-changed): GstMessageState,
old-state=(GstState)GST_STATE_PAUSED, new-state=(GstState)GST_STATE_PLAYING,
pending-state=(GstState)GST_STATE_VOID_PENDING
Got Message from element "rtph263depay0" (state-changed): GstMessageState,
old-state=(GstState)GST_STATE_PAUSED, new-state=(GstState)GST_STATE_PLAYING,
pending-state=(GstState)GST_STATE_VOID_PENDING
Got Message from element "audioudp" (state-changed): GstMessageState,
old-state=(GstState)GST_STATE_PAUSED, new-state=(GstState)GST_STATE_PLAYING,
pending-state=(GstState)GST_STATE_VOID_PENDING
Got Message from element "videoudp" (state-changed): GstMessageState,
old-state=(GstState)GST_STATE_PAUSED, new-state=(GstState)GST_STATE_PLAYING,
pending-state=(GstState)GST_STATE_VOID_PENDING
Got Message from element "mux" (error): GstMessageError,
gerror=(GstGError)(NULL), debug=(string)"gstffmpegmux.c\(475\):\
gst_ffmpegmux_collected\ \(\):\ /pipeline0/mux:\012Failed\ to\ write\ file\
header\ -\ check\ codec\ settings"
ERROR: from element /pipeline0/mux: Could not configure supporting library.
Additional debug info:
gstffmpegmux.c(475): gst_ffmpegmux_collected (): /pipeline0/mux:
Failed to write file header - check codec settings
Execution ended after 3618236000 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
FREEING pipeline ...

I think that this is because the h263depayloader did not set the duration of a
packet which the mux need as you mentioned before
Then I tried another pipeline with a h263 deconder and encoder inserted after
the h263depayloader

gst-launch -m ffmux_3gp name=mux ! filesink location=/home/video/receive.3gp \
{ udpsrc num-buffers=500 port=11002 name=audioudp caps="application/x-rtp,
media=(string)audio, payload=(int)98, clock-rate=(int)8000,
encoding-name=(string)AMR, encoding-params=(string)1, octet-align=(string)1" !
rtpamrdepay queue-delay=0 ! queue } ! mux.audio_0 \
{ udpsrc num-buffers=500 port=11000 name=videoudp caps="application/x-rtp,
media=(string)video, payload=(int)34, clock-rate=(int)90000,
encoding-name=(string)H263" ! rtph263depay queue-delay=0 ! ffdec_h263 !
ffenc_h263 bitrate=45000 rtp-payload-size=500 gop-size=3 me-method=4 !queue } !
mux.video_0

This time, the pipeline runs sucessfully and I obtain the file.
However, the video is much faster than it should be
I do think that this is related to the duration is not set in the
h263depayloader and then the encoder calculate an incorrect duration(seems base
on arrival time).

I've read rfc2190, From my understanding, the only way to calculate the
duration is based on the timestamp, marker bit and the 90kHz clock. I am not
very sure about this but still I hope this information will save you time.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=478244.