[ffmpeg] make muxers reusable
Submitted by Terry
Link to original bug (#491271)
Description
Hi,
I've got a problem int he following pipeline(for recording stream into a 3gp file):
gst-launch ffmux_3gp name=mux0 ! filesink name=file0 { udpsrc name=audioudp0 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" ! gstrtpjitterbuffer name=audiojitter0 latency=0 ts-offset=1000000 ! rtpamrdepay queue-delay=0 name=audiodepay0 ! amrnbdec ! amrnbenc ! queue name=audioqueue0 } ! mux0.audio_0 { udpsrc name=videoudp0 caps="application/x-rtp, media=(string)video, payload=(int)34, clock-rate=(int)90000, encoding-name=(string)H263" ! gstrtpjitterbuffer name=videojitter0 latency=0 ts-offset=1000000 ! rtph263depay queue-delay=0 name=videodepay0 ! video/x-h263, framerate=8/1 ! ffdec_h263 name=videodec0 ! videorate name=videorate0 ! video/x-raw-yuv,framerate=8/1 ! ffenc_h263 name=videoenc0 rtp-payload-size=500 gop-size=20 me-method=4 !queue name=videoqueue0 } ! mux0.video_0
when i start the pipeline to record a stream, then i set the pipeline to NULL
after that i restart the pipeline to record again(another stream)
it shows error like that
0:00:49.519585000 12784 0xb0e05a90 ERROR ffmpeg :0:: error, non monotone timestamps 210962 >= 2033
0:00:49.519638000 12784 0xb0e05920 ERROR ffmpeg :0:: error, non monotone timestamps 210962 >= 2193
0:00:49.519672000 12784 0xb0e05920 ERROR ffmpeg :0:: error, non monotone timestamps 210962 >= 2353
0:00:49.519705000 12784 0xb0e05920 ERROR ffmpeg :0:: error, non monotone timestamps 210962 >= 2513
0:00:49.519737000 12784 0xb0e05920 ERROR ffmpeg :0:: error, non monotone timestamps 210962 >= 2673
0:00:49.519768000 12784 0xb0e05920 ERROR ffmpeg :0:: error, non monotone timestamps 210962 >= 2833
0:00:49.519803000 12784 0xb0e05920 ERROR ffmpeg :0:: error, non monotone timestamps 210962 >= 2993
The problem is that it remember the last packet's timestamp value and hence not going to proccess the new stream packet until its timestamp higher the the last timestamp of the old stream.
As far as I know, the NULL state should not contain any state and should not remember anything. Therefore, I think this may be a bug