[gst-devel] Queue with leaky=2 keeps one old buffer

Ron McOuat rmcouat at smartt.com
Wed Apr 22 06:46:38 CEST 2009


I have a question on the queue element.

I have a video source which is linked to a tee element. On the src pad 
side of the tee element I add a queue and a processing bin for each branch.

One of the branches of the tee I would like to sometimes record for a 
period of time and then turn off while the rest of the pipeline runs and 
when I restart I would like to record N sec back from the current time. 
I set the queue to leak old buffers using leaky=2 with the 
max-size-time=N*10^9 for N sec.

When I want the bin to stop recording, I block the src pad of the queue 
and send EOS to the sink pad of the bin queue is connected to and then 
unlink the processing bin.

When I resume I make a new processing bin, link it in, send a new 
segment to the sink pad of the processing bin and unblock the queue src pad.

This all works fine except for one problem. To figure it out I added a 
src pad buffer probe to queue and printed out the buf.timestamp with the 
following output which is running at 8 fps:

Element   Timestamp
queue 12098600000
queue 12222186000
queue 12345175000
queue 12474597000
queue 12604791000
queue 12721661000
stop


resume
queue 12844894000
queue 25230688000
queue 25346042000
.
Output cut to shorten listing
.
queue 35591986000
queue 35723800000
queue 35842484000
stop

resume
queue 35973339000
queue 60480289000
queue 60603448000


The queue holds one more buffer from the previous sequence based on the 
timestamp and then passes in buffers starting N sec older than the 
current time. The video source puts the time in the image so I believe 
the buffer timestamp is correct based on observation of the video. This 
messes up the mux timing further downstream with the first buffer 
relative to the remaining buffers could be hours old. I reset the base 
time in the downstream bin to get a zero relative time but this is set 
from the first buffer.

I got around it by having the queue src pad buffer probe drop the first 
buffer after a resume by returning False.

Is there something else I should be doing or is it possible this is a bug?

Thanks

Ron




More information about the gstreamer-devel mailing list