Cheese, netbooks and resource hungry encoders
Locked
 
|
Hey all,
I need some suggestion from you video encoding experts. Recently we received several reports in bugzilla about Cheese not being able to do live video recording on low power cpus (like atom and in general netbooks). At the moment we record videos with a pretty standard pipeline, theoraenc, vorbisenc, oggmux. 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). I did a quick test with several encoders and it seems that ffenc_mjpeg with a medium-high bitrate consumes at least 60% less than theoraenc with default settings. Could it be a good alternative? Any other idea? Thanks! Filippo ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Cheese, netbooks and resource hungry encoders
|
|
2009/7/6 Filippo Argiolas <[hidden email]>:
> Hey all, > I need some suggestion from you video encoding experts. > Recently we received several reports in bugzilla about Cheese not > being able to do live video recording on low power cpus (like atom and > in general netbooks). At the moment we record videos with a pretty > standard pipeline, theoraenc, vorbisenc, oggmux. > 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). > I did a quick test with several encoders and it seems that ffenc_mjpeg > with a medium-high bitrate consumes at least 60% less than theoraenc > with default settings. Could it be a good alternative? Any other idea? > > Thanks! > Filippo > Recording in a lower resolution should lower the cpu requirements. Best regards, Erik > ------------------------------------------------------------------------------ > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
In reply to this post by Filippo
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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Cheese, netbooks and resource hungry encoders
|
|
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<[hidden email]> 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 > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > -- Philip Jägenstedt ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Cheese, netbooks and resource hungry encoders
|
|
In reply to this post by Erik Andrén
On Mon, Jul 6, 2009 at 3:04 AM, Erik Andrén <[hidden email]> wrote: Recording in a lower resolution should lower the cpu requirements. True, but that's only if he is able to do that. In my applications, recorded resolution and feature quality are dictated to me by regulation, so that wouldn't be an option. But at the least I suppose one could publish that tip as a possible workaround for the users (after verifying with some testing on those low-power units). I also agree with the suggestion of trying a different encoding/encoder. $0.02, E. Westbrook ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Cheese, netbooks and resource hungry encoders
|
|
In reply to this post by Filippo
On Mon, Jul 06, 2009 at 10:57:30AM +0200, Filippo Argiolas wrote:
> Hey all, > I need some suggestion from you video encoding experts. > Recently we received several reports in bugzilla about Cheese not > being able to do live video recording on low power cpus (like atom and > in general netbooks). At the moment we record videos with a pretty > standard pipeline, theoraenc, vorbisenc, oggmux. > 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). > I did a quick test with several encoders and it seems that ffenc_mjpeg > with a medium-high bitrate consumes at least 60% less than theoraenc > with default settings. Could it be a good alternative? Any other idea? We don't currently have the infrastructure for enforcing real-time encoding -- you either have enough CPU and it Just Works, or you don't, and it silently fails. Encoder libraries are starting to get features for controlling this. libtheora allows you to mark the next several frames as identical, thereby skipping frames when the encoder gets behind. Schroedinger has a similar mechanism, but it's not yet exposed in the API. I'll probably add some support in GstBaseVideoEncoder for catching QoS messages (which have not been defined yet) to connect up to the encoder features. (You know, in that magical day in the future when I get back to BaseVideo hacking.) In general, prefessional capture apps encode to an intermediate codec like AIC, ProRes422, DNxHD, or DiracPro, since the CPU usage is very predictable and quite low. But that requires large bit rates and off-line transcoding to whatever long-gop format you actually want. dave... ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
In reply to this post by AxelPhi
On Mon, Jul 6, 2009 at 12:49 PM, Axel
Philipsenburg<[hidden email]> 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. I've tried fiddling with theoraenc parameters, speed-level included, but I wasn't able to drop cpu load significantly (in the best case it dropped from 105% to 99% but recording failed anyway). Also I believe vorbisenc has a great part, it seems it doesn't perform quite well on atom. > 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. Sure the pipeline we use is roughly like: gst-launch-0.10 v4l2src ! tee name=t ! queue ! xvimagesink t. ! queue ! theoraenc ! oggmux name=m ! filesink location=test.ogg pulsesrc ! queue ! audioconvert ! vorbisenc ! m. > 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. Sure, lowering the resolution can really drop cpu load (even 40-50% less) but that unfortunately depends on the user choice. I could write a FAQ item telling them to lower down recording resolution but that wouldn't prevent the issue to come up if they don't do it. Maybe I could look for a way to guess the available cpu power and lower down recording resolution by default if it's not enough. Thanks Filippo ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
In reply to this post by David Schleef-2
On Tue, Jul 7, 2009 at 1:03 AM, David Schleef<[hidden email]> wrote:
> We don't currently have the infrastructure for enforcing real-time > encoding -- you either have enough CPU and it Just Works, or you > don't, and it silently fails. Encoder libraries are starting to > get features for controlling this. libtheora allows you to mark > the next several frames as identical, thereby skipping frames when > the encoder gets behind. Schroedinger has a similar mechanism, but > it's not yet exposed in the API. I'll probably add some support > in GstBaseVideoEncoder for catching QoS messages (which have not > been defined yet) to connect up to the encoder features. (You know, > in that magical day in the future when I get back to BaseVideo > hacking.) Thank you for clearing this. You're totally right, real time recording just works if the cpu can handle it but silently fails, sometimes outputting empty files, sometimes just freezing, etc. when the power is not enough. At least now I can blame for sure gstreamer when it happens ;-) A base class for encoding with some kind of Quality of Service would be really great. > In general, prefessional capture apps encode to an intermediate > codec like AIC, ProRes422, DNxHD, or DiracPro, since the CPU usage > is very predictable and quite low. But that requires large bit > rates and off-line transcoding to whatever long-gop format you > actually want. That would probably be an overkill for a simple application like Cheese, both from an implementation point of view (i.e. we need more manpower to add advanced features like raw/intermediate codec recording + delayed transcoding) and from a use target (it's just an application that takes photos and little videos for fun... you cannot expect it to behave professionally) point of view. Thank you, Filippo ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |