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