GNOME Bugzilla – Bug 722332
Vp8 encoding weirdly slow
Last modified: 2014-01-17 13:42:33 UTC
gst-launch-1.0 filesrc location="/home/cschalle/Videos/A_Digital_Media_Primer_For_Geeks-360p.webm" ! matroskademux ! vp8dec ! vp8enc ! filesink location="/tmp/test.vp8" I noticed this first in transmageddon, but encoding to VP8 has suddenly become crazily slow. On my system the output here doesn't even reach 1M in 5 minutes.
It's possible that you need to do decoder/encoder decoupling (adding a queue between vp8dec / vp8enc). Also please provide some measurement, and maybe the result of perf profiling report ?
But this also happens inside transmageddon, meaning that I see it with a decodebin ! encodebin pipeline, so encodbin tend to add a lot of queue. As for measurement, I am not sure how to create that, but the reason I filed this bug report is because it is crazy slow. I mean I was looking at transmageddon for 10 minutes and the progress bar had not moved and the output file was only growing with a few K a second. So I don't think anyone trying the above gst-launch pipeline can fail to notice the slowness.
I'm just asking more info in order to figure-out if it's GStreamer fault or the libvpx. A download link: http://media.basilgohar.com/monty/episode-01/A_Digital_Media_Primer_For_Geeks-360p.webm
Works for me. First try converting from theora to VP8/matroska, then a second try with the same pipeline as you, from vp8 to vp8. 6 MB in a minute, maybe. Do you have a self built libvpx ? Could it be built without optimizations by default ? IIRC libvpx has unexpected defaults such as no shared lib.
I've run perf top for you, it shows that all the time is spend in libvpx as expected. Though there is one curiosity: /GstPipeline:pipeline0/GstVP8Dec:vp8dec0.GstPad:sink: caps = video/x-vp8, width=(int)640, height=(int)360, framerate=(fraction)90001/1 I think it's the wrong framerate exposed by the decoder that causes all this (as playback is fine, I suppose the duration is correct). 90001/1 is exposed, while in fact the duration of buffers refer to about 24/1. A "fencier" pipeline that let you see the transcoding speed and the caps: gst-launch-1.0 -v filesrc location=A_Digital_Media_Primer_For_Geeks-360p.webm \ ! matroskademux ! vp8dec ! tee name=t t. ! queue \ ! vp8enc deadline=50000000 ! filesink location=/tmp/tmp.vp8 \ t. ! queue ! fpsdisplaysink sync=false Pipeline to measure the effective playback speed: gst-launch-1.0 -v filesrc location=A_Digital_Media_Primer_For_Geeks-360p.webm \ ! matroskademux ! vp8dec ! fpsdisplaysink
Tested on 1.2.2 btw, maybe have been fixed upstream, if so it clearly need backporting.
ok, I will try to update libvpx, I got 1.2.0 here currently
ok, with updated libvpx the problem is fixed. Closing.
Do we still get a large framerate ? Is so, please file a bug.