Notices

Please do, major improvements too! I kinda just threw this together last night...

Yeah, I basically just added one more button to the UI, because I finally managed to get a set of audio / video / container GStreamer options that (a) worked together without complaints and (b) was simple enough to run on the base N900 media player. I suspect what really needs to be done is to create a new dialog box or window to hold the various configuration options, and just allow the main window to display the currently chosen option and the various record / pause / stop controls. Once that is done, lots more options can be added (like other video sources, etc.). It's just getting to be too much to display all on one screen...

Interesting! Hmm, maybe the camera app is bypassing X to display its data? (I guess that would make sense, if they've got a way to directly blast pixels at the screen; it could save a little CPU.)

I'm not entirely sure how to remedy this (at least within GStreamer); I guess there might be some way to access the frame buffer directly?

Yeah, I guess this is still a GStreamer app, even after I dropped the audio encoder and set the video speed to 5 frames per second. It looked like I was getting CPU usage of 30% or less overall during my (limited) testing, but that's still a lot of CPU, and I didn't try to record much significant animation. (And I dunno what happens when two apps try to use the DSP at the same time...)

Well, shoot. That is not a message I would expect; the "avContainer" is a GStreamer matroskamux element, and the "outputFile" is a GStreamer filesink element. These elements should be regenerated anew each time the GStreamer pipleline is created; an error like that would mean, I think, that some portion of a previous pipeline was hanging around and interfering with the new one. I've got an internal check to make sure that I don't try to start a new pipeline if one is already running, but maybe I need to check more closely to see whether the previous pipeline was cleanly removed...

BTW, the error messages that pop up in the Hildon banners are also sent to the "STDERR" stream. So if you'd like, you should be able to catch them if you run Orechiette from the command line...

Copernicus... I love your app... really! But... an you change the icon with something in maemo style?

Eh? What's un-Maemo-style about Orecchiette's icon?

Being an Italian, I am sure you know where the app's name comes from. I personally find it rather fitting.

Given my rather minimal artistic skills, I'm always open to suggestions as to improvements in the icons.

I'll probably be updating the icons a bit in the future, as it turns out that my current icons don't scale up well (which is something that is now required for high-pixel-density screens). I do intend to keep the pasta theme going as long as I can, though...

Also, by the way, the formula I'm currently using for video starts with the ximagesrc element, passes that data through ffmpegcolorspace and into the dspmp4venc encoder, then throws it into the matroskamux container element and then to a file. If you'd like to do that on the command line, the command should be something like this:

That'll record video, but no audio. (And yeah, "pathAndNameOfFile" should be replaced with whatever you want to call the file.)

That new feature is absolutely awesome idea, and - to me - a complete surprise. I wasn't aware that something like this might be thrown together so quickly. Anyway, I can imagine some very good uses for it, even from top of my head

Now, as I may presume, I'm not a kind of 'nay'sayer, but are you sure that it fits Orecchiette, and shouldn't become separate program? Now, I understand that having zillion tools for similar things may be irritating (both for developer and users), so personally, I'm split a little about this, but we've gone from audio-recording to video-screen-recording. And I can quite imagine that feature/options list for that componenjt will only get longer with time..

/Estel

Well, to be honest, the reason why I was able to throw it together so quickly is that Orecchiette is at the moment something of a gui front-end for calls to GStreamer. I did intend for Orecchiette to be just a "little ear", and so tailored to audio recording tasks, but it might work as a general front-end to GStreamer tasks of all sorts. Certainly, using Orecchiette here allows you to take advantage of Pichlo's work on file naming, and (once I get things working properly) should let you control both video and audio encoding formats. (And yeah, I don't see why we couldn't just throw in options for the front and back video camera sources too... GStreamer can be a fantastically powerful tool. )

But yeah, it might make more sense to have separate apps focussed on separate media recording tasks.

What is video screen recording ?

I will assume this is not a troll. Making a film of what is happening on the screen of the device. Also known as screen-casting.

It's pretty much as the name says -- you take the content being displayed on the screen, and store it to a file in a manner that can be played back like any other type of video recording.

This can be convenient for showing examples of apps running on the phone, for teaching users how to use the phone in general or an app in particular, or really any number of situations where you'd like to have a record of what is happening on the screen...

(Here's a link to the example video I posted earlier.)