Re: WebM format for Record
>> >> This is with no changes to the pipelines. I just wanted a quick >> reference. >> > > This is XO-1.5? > Tiago I only tested on the XO-1.5, but I don't see any reason we shouldn't see similar improvements on the XO-1 -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WebM format for Record
On Sun, Apr 10, 2011 at 2:48 AM, Jon Nettleton wrote: > > > > Oh and there was a question about backwards compatibility. I know > > there would be work testing it, but I see no problems with backward > > compatibility. We would just have to check file types and adjust the > > pipeline accordingly. We would also have to adjust the mimetype > > properties to any Activities that may hard code them. > > > > A quick follow up. I decided to do a general shoot out for Record and the > different codecs. Here is an html5 page that shows all three codecs. > > Upper Left is default Record. CPU utilization was around 95% on average. > Upper Right is webm Record CPU utilization was around 75% on average > Lower Left is theora 1.2.0alpha1. CPU Utilization was around 95% on > average. > > This is with no changes to the pipelines. I just wanted a quick reference. > > This is XO-1.5? Tiago > Jon > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WebM format for Record
On Sun, Apr 10, 2011 at 9:58 PM, John Watlington wrote: > > You forgot to include the URL of the page ? > > On Apr 9, 2011, at 9:48 PM, Jon Nettleton wrote: > Sorry I hit reply all, but looks like the mailing list was stripped off. http://dev.laptop.org/~jnettlet/record_tests/ -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WebM format for Record
> > Oh and there was a question about backwards compatibility. I know > there would be work testing it, but I see no problems with backward > compatibility. We would just have to check file types and adjust the > pipeline accordingly. We would also have to adjust the mimetype > properties to any Activities that may hard code them. > A quick follow up. I decided to do a general shoot out for Record and the different codecs. Here is an html5 page that shows all three codecs. Upper Left is default Record. CPU utilization was around 95% on average. Upper Right is webm Record CPU utilization was around 75% on average Lower Left is theora 1.2.0alpha1. CPU Utilization was around 95% on average. This is with no changes to the pipelines. I just wanted a quick reference. Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WebM format for Record
On Sat, Apr 9, 2011 at 11:16 AM, Benjamin M. Schwartz wrote: > On 04/09/2011 02:00 PM, Daniel Drake wrote: >> Ben, what are your thoughts on Theora vs WebM for Record? You >> mentioned at one point that Theora developers were considering >> focusing on the low-power arena (being displaced by WebM on the >> high-power high-res front), is that direction being taken? > > Essentially, yes. The WebM encoder (libvpx) has always been much slower > than libtheora because VP8 is much more computationally intensive than > Theora. The libtheora devs have been working to expand this difference by > adding encoder speed optimizations. Google has also worked on speed optimizations for the vp8 encoder. The version of libvp8 included in Fedora 14, might be in updates-testing, includes these optimizations. You will see in my patch I am using speed setting 2 which is a single pass encoding meant for live streaming. I am so far very impressed with the system demands as well as the quality. With speed set to 2, and quality at 5 ( middle of the road ) I was able to record full 2 minute clips at Low Res, High Res, and also did some testing at 640x480. 400x300 recordings were using about 70-80% cpu utilization encoding in the WebM format. Google is also working on ARM optimizations that will be important for the XO 1.75 > > The latest versions of libtheora (1.2 alphas, and maybe even more in SVN > head) contain a lot of work to speed up encoding. I have recommended > several times that OLPC ship 1.2-prerelease libtheora in the default > build, due to the significant speed improvements. I did test this version out but found the improvements on our hardware to be marginal. I know there was talk about constant bit rate vs vbr possible needing to be tweaked. I didn't have the time to look into it then. > >> So encoding speed is quite a big deal > > Indeed. I don't see WebM as being a realistic option for Record until > OLPC gets WebM encoders in silicon, which will presumably be after XO-3. You can see in this video http://www.youtube.com/watch?v=ilmMrtlzSRg that the WebM on the XO 1.5 is really working better than our current release. You will hear a few pops in the audio, those points were when we would previously lose all sink between audio and video. In this video the sink isn't perfect but relatively close. Oh and there was a question about backwards compatibility. I know there would be work testing it, but I see no problems with backward compatibility. We would just have to check file types and adjust the pipeline accordingly. We would also have to adjust the mimetype properties to any Activities that may hard code them. -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WebM format for Record
On 04/09/2011 02:00 PM, Daniel Drake wrote: > Ben, what are your thoughts on Theora vs WebM for Record? You > mentioned at one point that Theora developers were considering > focusing on the low-power arena (being displaced by WebM on the > high-power high-res front), is that direction being taken? Essentially, yes. The WebM encoder (libvpx) has always been much slower than libtheora because VP8 is much more computationally intensive than Theora. The libtheora devs have been working to expand this difference by adding encoder speed optimizations. The latest versions of libtheora (1.2 alphas, and maybe even more in SVN head) contain a lot of work to speed up encoding. I have recommended several times that OLPC ship 1.2-prerelease libtheora in the default build, due to the significant speed improvements. > So encoding speed is quite a big deal Indeed. I don't see WebM as being a realistic option for Record until OLPC gets WebM encoders in silicon, which will presumably be after XO-3. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WebM format for Record
On 8 April 2011 14:04, Jon Nettleton wrote: > Hey Guys, > > I was hoping to get more work done on this but haven't had the chance > to work on it any further. This patch switches Record to use the WebM > video format as specified by google. Thanks for looking at this, this will be useful for experimenting with it. As you're probably aware, some extra work would be needed before applying this as it would break backwards compat as-is. Ben, what are your thoughts on Theora vs WebM for Record? You mentioned at one point that Theora developers were considering focusing on the low-power arena (being displaced by WebM on the high-power high-res front), is that direction being taken? The standard quality videos are 160x120, XO-1.5 also offers 400x300 as an option. We do encoding to Theora and WebM on-the-fly (with gstreamer buffers so it doesn't matter if it's not real time, but it needs to keep up to avoid exhausting the buffer). So encoding speed is quite a big deal - Jon, do you have any comparitive numbers? Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WebM format for Record
> > > I do know that one thing that needs to be fixed is the preview image > shown while the recording is being encoded is displayed in greyscale > instead of color. A note on this point from Eben: https://dev.laptop.org/ticket/2585#comment:10 Busy Indication: When Record is switching modes, processing audio, compressing video, etc, we would like to place a grayscale still of the most recent video frame on screen, reducing the contrast a good deal so that it is clearly inactive. This will take the place of any large clock/wait/busy icons. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
WebM format for Record
Hey Guys,
I was hoping to get more work done on this but haven't had the chance
to work on it any further. This patch switches Record to use the WebM
video format as specified by google. It should work on our F14
builds. The videos will playback in Record, but you will have to
patch your mimetypes files to add support to other programs. In
particular you should add video/webm to the
/usr/share/sugar/data/mime.defaults file.
I do know that one thing that needs to be fixed is the preview image
shown while the recording is being encoded is displayed in greyscale
instead of color. Other than that I am quite happy with the recording
quality. You will still notice an audio hiccup at between 14 and 20
seconds of the start of the recording. This is where we would
previously lose audio sync. With this patch the sync re-adjusts
itself but leaves a small hiccup in the audio track.
Hope this is useful to someone.
-Jon
From 42c66aaf17686be5b5320698c7d258e11164812d Mon Sep 17 00:00:00 2001
From: Jon Nettleton
Date: Fri, 8 Apr 2011 05:50:25 -0700
Subject: [PATCH] Convert to using WebM video format
This switches Record to use vp8 video and ogg audio
in a matroska container. This is the standard that
makes up the WebM video format. The encoder quality
and performance seems to be better than the existing
ogg/theora combination.
---
constants.py |4 +-
glive.py | 59 +
2 files changed, 32 insertions(+), 31 deletions(-)
diff --git a/constants.py b/constants.py
index 9b0ed4a..2381029 100644
--- a/constants.py
+++ b/constants.py
@@ -26,8 +26,8 @@ MEDIA_INFO[TYPE_PHOTO] = {
MEDIA_INFO[TYPE_VIDEO] = {
'name' : 'video',
-'mime' : 'video/ogg',
-'ext' : 'ogg',
+'mime' : 'video/webm',
+'ext' : 'webm',
'istr' : _('Video')
}
diff --git a/glive.py b/glive.py
index 07d187b..14288cf 100644
--- a/glive.py
+++ b/glive.py
@@ -38,9 +38,9 @@ import utils
logger = logging.getLogger('glive')
-OGG_TRAITS = {
-0: { 'width': 160, 'height': 120, 'quality': 16 },
-1: { 'width': 400, 'height': 300, 'quality': 16 } }
+WEBM_TRAITS = {
+0: { 'width': 160, 'height': 120, 'quality': 5 },
+1: { 'width': 400, 'height': 300, 'quality': 5 } }
THUMB_STUB = gtk.gdk.pixbuf_new_from_file(
os.path.join(get_bundle_path(), 'gfx', 'stub.png'))
@@ -180,13 +180,14 @@ class Glive:
colorspace = gst.element_factory_make("ffmpegcolorspace", "vbcolorspace")
-enc = gst.element_factory_make("theoraenc", "vbenc")
-enc.set_property("quality", 16)
+enc = gst.element_factory_make("vp8enc", "vbenc")
+enc.set_property("quality", 5)
+enc.set_property("speed", 2)
-mux = gst.element_factory_make("oggmux", "vbmux")
+mux = gst.element_factory_make("matroskamux", "vbmux")
sink = gst.element_factory_make("filesink", "vbfile")
-sink.set_property("location", os.path.join(Instance.instancePath, "output.ogg"))
+sink.set_property("location", os.path.join(Instance.instancePath, "output.webm"))
self._videobin = gst.Bin("videobin")
self._videobin.add(queue, scale, scalecapsfilter, colorspace, enc, mux, sink)
@@ -217,7 +218,7 @@ class Glive:
def _config_videobin(self, quality, width, height):
vbenc = self._videobin.get_by_name("vbenc")
-vbenc.set_property("quality", 16)
+vbenc.set_property("quality", 5)
scaps = self._videobin.get_by_name("scalecaps")
scaps.set_property("caps", gst.Caps("video/x-raw-yuv,width=%d,height=%d" % (width, height)))
@@ -366,7 +367,7 @@ class Glive:
self.model.still_ready(self._audio_pixbuf)
-line = 'filesrc location=' + audio_path + ' name=audioFilesrc ! wavparse name=audioWavparse ! audioconvert name=audioAudioconvert ! vorbisenc name=audioVorbisenc ! oggmux name=audioOggmux ! filesink name=audioFilesink'
+line = 'filesrc location=' + audio_path + ' name=audioFilesrc ! wavparse name=audioWavparse ! audioconvert name=audioAudioconvert ! vorbisenc name=audioVorbisenc ! matroskamux name=audioOggmux ! filesink name=audioFilesink'
audioline = gst.parse_launch(line)
taglist = self._get_tags(constants.TYPE_AUDIO)
@@ -376,7 +377,7 @@ class Glive:
vorbis_enc.merge_tags(taglist, gst.TAG_MERGE_REPLACE_ALL)
audioFilesink = audioline.get_by_name('audioFilesink')
-audioOggFilepath = os.path.join(Instance.instancePath, "output.ogg")
+audioOggFilepath = os.path.join(Instance.instancePath, "output.webm")
audioFilesink.set_property("location", audioOggFilepath)
audioBus = audioline.get_bus()
@@ -448,10 +449,10 @@ class Glive:
if not self._has_camera:
return
-self._ogg_quality = quality
-self._config_videobin(OGG_TRAITS[quality]['quality'],
-OGG_TRAITS[quality]['width'],
-OGG_TRAITS[quality]['height
