This last week, I finally got the prototype for Air Mozilla 2 up and running. Air Mozilla is the live streaming video presence of Mozilla.
With the release of Firefox 3.1, we'll have native video support in the browser, actually Theora video + Vorbis audio in an Ogg container, and so I'm working on building our Air Mozilla capabilities out to support this and the new HTML5 <video> tag.
For the first prototype, the tool-chain is still very basic. I'm just focused on getting the video from my camera to your browser and none of the nice web-based UI and other cool bits I've got planned for later.
I've got Ubuntu 8.10 installed on my MacBook Pro (2.2 GHz Intel Core 2 Duo). I'm using dvgrab to pull the DV content off of a Panasonic AG-DVX100B via FireWire. The camera supports 480i/60 (NTSC), 480p/24fps, and 480p/30fps but I'm also likely to be supporting HD cameras sometime later this year. I pipe the data to ffmpeg2theora v0.23 for encoding and then use oggfwd to push the resulting video up to an icecast2 server.
This all works rather well as long as I'm using low or medium quality encoding settings in ffmpeg2theora but as soon as I move up the dial in quality, I start pushing the CPU on my MBP pretty hard. This will only get worse with HD.
I know for MPEG1, H.264 and other codecs, there are dedicated encoding cards but I don't think any such thing exists that would work with ffmpeg2theora. The standard libtheora isn't multi-threaded so I don't think more cores would help, though I could be wrong. So is this just an issue of speed then? I'd like to have some more freedom here so I'm hoping you all can help me answer this question.
What is the best value CPU for video encoding using the tool-chain I described above.
Posted by: Peter | January 10, 2009 6:57 PM
Asa, do you have an applescript to automate that process or do you have to deal with each app separately yourself?
Posted by: Mr Lizard | January 11, 2009 5:49 AM
You may want to ask to the Theora mailing list:
Posted by: Lino Mastrodomenico | January 11, 2009 4:04 PM
I know that the ffmpeg under debian does not(!) use MMX. If you rebuild the package you can improve the speed by 150%.
Posted by: Daniel | January 12, 2009 1:25 AM
Transcoding is a highly intensive CPU task no matter what. Your only hope are for better programmers / better software to take advantage or multi-core. CPU instructions or better yet write in some GPGPU language.
Most modern processors, while not getting slower per core, are really focusing on increasing multi-threaded capabilities.
Posted by: Damian | January 12, 2009 11:21 AM
You would benefit from SSE4 and such only if compiled yourself the packages with the optimization flags.
If you compile optimizing (without any debug symbol, stripping, with optimization flags, using mmx, sse, 3, 4, etc.) you may get better results.
Posted by: Asrail | January 12, 2009 1:59 PM
I think you should consider offloading the processing to the video card trough VDPAU or something similar, because that kind of processing is much more optimized in modern GPU design than any CPU available.
Posted by: Anonymous | January 14, 2009 3:03 PM
Ouch, this might prove a big issue for the Theora format to be widespread. Currently H.264, or open-source container/codec mkv/x.264, are the best choice for HD encoding.
We didn't test Theora yet but were planning to release an HD video advertising the video element in Firefox 3.1 by the end of the month. I think I'll try to be more specific on the Theora mailing list to cover any big issue before we're too close to release time.
Posted by: Laurent | January 20, 2009 10:22 AM
Ouch, this might prove a big issue for the Theora format to be widespread. Currently H.264, or open-source container/codec mkv/x.264, are the best choice for HD encoding.
We didn't test Theora yet but were planning to release an HD video advertising the video element in Firefox 3.1 by the end of the month. I think I'll try to be more specific on the Theora mailing list to cover any big issue before we're too close to release time.
Posted by: Laurent | January 20, 2009 10:24 AM
Ouch, this might prove a big issue for the Theora format to be widespread. Currently H.264, or open-source container/codec mkv/x.264, are the best choice for HD encoding.
We didn't test Theora yet but were planning to release an HD video advertising the video element in Firefox 3.1 by the end of the month. I think I'll try to be more specific on the Theora mailing list to cover any big issue before we're too close to release time.
Posted by: Laurent | January 20, 2009 10:24 AM
Asa, I don't know if you know or not, or if the library updates itsself, but there's a vulnerablity in FFmpeg. I found out about it from DHS/FEMA's daily open infrastructure report (I'm an Emergency Management minor), and generally they're fairly slow about reporting anything to do with technology except critical infrastructure but since you said you're using this, I thought I'd let you know.
Anyway, this is the report itsself:
January 29, Heise Online – (International) Vulnerability found in FFmpeg library. A vulnerability has been found in FFmpeg that may be exploited by a (remote) attacker to execute arbitrary code in the context of FFmpeg or an application using the FFmpeg library. FFmpeg is a free tool and library collection which is used to record, convert and stream audio and video. It is used by several popular open source software projects including VLC media player, MPlayer, Perian, and others. The cause of the problem, according to an expert, is an error during the processing of files in proprietary 4X movie format (4XM). For a successful attack, the victim must open a manipulated file. FFmpeg versions before version 16846 are affected. Version 16846 has now been released and closes the hole in the libavformat/4xm.c file. Users can upgrade from the FFMpeg repository or wait for the distributions to update.
Source: http://www.heise-online.co.uk/news/Vulnerability-found-in-FFmpeg-library--/112517 29.
Posted by: Franklin Adams | January 30, 2009 9:08 PM
I think the whole transcoding process is rather CPU intensive. The newer Intel penryn CPUs with SSE4 might give you some improvement as they have quite a few video related instructions I believe but I'm not sure it will be significant. You might want to look at a gstreamer pipeline which would be able to pull straight from the camera at one end and output the required ogg theora at the other. The theora plugin for gstreamer might also be more multithreaded. You could use it from direct from the command line or get something like PiTiVi to setup the right combo. You could use something like "gst-launch v4l2src ! video/x-raw-yuv,width=320,height=240 ! ffmpegcolorspace ! theoraenc ! oggmux ! filesink location=video-out.ogg" for testing. Not sure whether you need a width/height option and see if that gives you any improvement with cpu utilisation. Also that wouldn't deal with the audio stream. There's quite a good summary for commandline output on the OLPC wiki too http://wiki.laptop.org/go/GStreamer
Peter