vp8enc waiting for EOS

[David Klasinc]

Greetings,

this is my command line:

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=1000000 threads=3 ! \
queue name=before_mux ! webmmux name=mux ! queue ! \
filesink location="test.webm"

I record for about 10 seconds of the video, then I press CTRL-C and it
takes more than 20 seconds for data to be flushed on disk and file written.

Is there a way to minimize this time? When encoding with x264 the flush
is almost instant.

Regards,
David
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Carlos Rafael Giani]

On 2012-10-28 09:42, David Klasinc wrote:

> Greetings,
>
> this is my command line:
>
> 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=1000000 threads=3 ! \
> queue name=before_mux ! webmmux name=mux ! queue ! \
> filesink location="test.webm"
>
> I record for about 10 seconds of the video, then I press CTRL-C and it
> takes more than 20 seconds for data to be flushed on disk and file written.
>
> Is there a way to minimize this time? When encoding with x264 the flush
> is almost instant.
>
> Regards,
> David
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

I don't have a solution for you, but at least I could reproduce and
isolate the issue more:

The pipeline:

   gst-launch-1.0  -e ximagesrc ! videorate ! video/x-raw,framerate=15/1
! videoconvert ! vp8enc ! fakesink

shows the same problem. In fact, the framerate caps are not even necessary:

   gst-launch-1.0  -e ximagesrc ! videorate ! videoconvert ! vp8enc !
fakesink

behaves the same.

Things I have noticed:
a) removing videorate gets rid of the delay at the end
b) replacing ximagesrc with for example videotestsrc (and using a
capsfilter to simulate ximagesrc sink caps) gets rid of the delay too
c) using ximagesrc with properties endx=10 and endy=10 also gets rid of
the delay
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

On Sun, 2012-10-28 at 09:42 +0100, David Klasinc wrote:

> Greetings,
>
> this is my command line:
>
> 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=1000000 threads=3 ! \
> queue name=before_mux ! webmmux name=mux ! queue ! \
> filesink location="test.webm"
>
> I record for about 10 seconds of the video, then I press CTRL-C and it
> takes more than 20 seconds for data to be flushed on disk and file written.
>
> Is there a way to minimize this time? When encoding with x264 the flush
> is almost instant.

It's probably just the vp8 encoder being incredibly slow... maybe try
some other options there to see if those make a difference.

Also, how many frames per sec do you get from ximagesrc?

Cheers
 -Tim

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[David Klasinc]

On 10/28/2012 11:22 AM, dv wrote:

> I don't have a solution for you, but at least I could reproduce and
> isolate the issue more:
>
> The pipeline:
>
>    gst-launch-1.0  -e ximagesrc ! videorate ! video/x-raw,framerate=15/1
> ! videoconvert ! vp8enc ! fakesink
>
> shows the same problem. In fact, the framerate caps are not even necessary:
>
>    gst-launch-1.0  -e ximagesrc ! videorate ! videoconvert ! vp8enc !
> fakesink
>
> behaves the same.
>
> Things I have noticed:
> a) removing videorate gets rid of the delay at the end

How can I control framerate of the output video? Is there another way?
And additional question would be, why on earth is it working with x264enc?

> b) replacing ximagesrc with for example videotestsrc (and using a
> capsfilter to simulate ximagesrc sink caps) gets rid of the delay too
> c) using ximagesrc with properties endx=10 and endy=10 also gets rid of
> the delay

This is probably because there is very little data to encode and write
to disk.

Just now I tried to record a 5 minute screen capture and it took almost
three minutes to flush it to disk. This is really poor performance. :(

Regards,
David
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Carlos Rafael Giani]

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.)

regards

> On 10/28/2012 11:22 AM, dv wrote:
>
>> I don't have a solution for you, but at least I could reproduce and
>> isolate the issue more:
>>
>> The pipeline:
>>
>>    gst-launch-1.0  -e ximagesrc ! videorate ! video/x-raw,framerate=15/1
>> ! videoconvert ! vp8enc ! fakesink
>>
>> shows the same problem. In fact, the framerate caps are not even
>> necessary:
>>
>>    gst-launch-1.0  -e ximagesrc ! videorate ! videoconvert ! vp8enc !
>> fakesink
>>
>> behaves the same.
>>
>> Things I have noticed:
>> a) removing videorate gets rid of the delay at the end
>
> How can I control framerate of the output video? Is there another way?
> And additional question would be, why on earth is it working with x264enc?
>
>> b) replacing ximagesrc with for example videotestsrc (and using a
>> capsfilter to simulate ximagesrc sink caps) gets rid of the delay too
>> c) using ximagesrc with properties endx=10 and endy=10 also gets rid of
>> the delay
>
> This is probably because there is very little data to encode and write
> to disk.
>
> Just now I tried to record a 5 minute screen capture and it took almost
> three minutes to flush it to disk. This is really poor performance. :(
>
> Regards,
> David
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[David Klasinc]

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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel