vp8enc waiting for EOS

David Klasinc bigwhale at lubica.net
Fri Nov 2 02:25:56 PDT 2012


On 11/01/2012 10:17 PM, dv wrote:
> Adding deadline=66666 to the vp8enc properties allows the encoder to
> drop frames. Then, the launcher quits almost immediately after the EOS
> event is received. This explains why it takes longer to quit after
> encoding for a longer while - a lot of frames are queued up, and the
> encoder can't keep up.
>
> (The 66666 come from the frame rate, 15 fps. 1000000/15 ~ 66666 usecs.)

I did some testing now and the command line that works is this:

gst-launch-1.0 -e ximagesrc endx=1919 endy=1079 use-damage=false \
show-pointer=true ! queue ! videorate ! \
video/x-raw,framerate=15/1 ! videoconvert ! \
vp8enc end-usage=vbr target-bitrate=800000000 threads=3 \
static-threshold=1000 token-partitions=2 max-quantizer=30 ! \
queue name=before_mux ! webmmux name=mux ! \
queue ! filesink location="test-videorate.webm"

Flush is now immediate.

But I did encounter a problem doing all this in python. After seven 
minutes into the recording my computer ran out of ram and I have 8GB of 
it. The pipeline is exactly the same with the same parameters. It 
appears something is wrong with python implementation of this.

There seems to be a memory leak somewhere, not sure if in the 
introspection of gstreamer.

Rgrds,
David



More information about the gstreamer-devel mailing list