[gst-devel] Cheese, netbooks and resource hungry encoders

[Philip Jägenstedt]

When I was capturing analog video with a v4l2 device at full PAL
resolution I did quite a lot of testing to find something that could
capture in real time without dropping frames. I also had the
requirement of being lossless, so I certainly didn't cover all of the
option. In any case I eventually settled for ffenc_ljpeg with queues
without size limit so that the capture would keep going even if I
temporarily was encoding at less than full rate. The resultant files
are ridiculously big, but the point of all of this was to be able to
use a cpu-intensive encoder later that could take as much time as
needed. I don't know what Cheese is, to perhaps this is inappropriate
for you.

Philip

Trivia:

pngenc was slower at any compression setting.

huffhuv couldn't handle full res UV planes (only 422). I didn't care
to throw away data at that point.

yuv4mpeg is too high bandwidth so that the disk became the bottleneck

On Mon, Jul 6, 2009 at 12:49, Axel
Philipsenburg<axel.philipsenburg at hobnox.com> wrote:
> Hi there,
>
> Filippo Argiolas wrote:
>> Do you have any suggestion about less cpu avid encoders? We used those
>> ones because they are free but if they don't work it could be worth
>> adding other options (ideally we'd add DeviceProfiles support when
>> it'll be in a good enough shape).
> Did you check the parameters on theoraenc ?
> There is the "speed-level" parameter that could
> limit the motion vector search, which is a very
> time consuming process.
>
> On the other hand, did you use a queue in the pipeline? If
> I remember correctly, Atom CPUs (used in many
> Netbooks) have Hyperthreading. Thus allowing the
> pipeline to multithread might improve the performance
> a bit.
>
> I agree with Erik that using a lower resolution will help a lot
> too. Scaling the image down with a simple filter such as
> bilinear is way faster than the encoding the larger picture.
>
> There are some other encoders that have a smaller CPU
> load but they won't generally offer good quality or file
> size either.
>
> See ya,
>
> Axel
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>



-- 
Philip Jägenstedt