Re: Conduit & iPod Module - Week 7

["John Stowers" <john stowers gmail com>]

On Tue, Jul 15, 2008 at 8:22 PM, Alexandre <airmind gmail com> wrote:
> Hi,
>
> I've finally fixed my Bazaar branch and included my latest code:
> https://code.launchpad.net/~airmind/conduit/gsoc08

Thats great to see. Have you merged in trunk lately? It will make it
easier for me to merge your work later on if you remain close to
upstream.

> If anyone has an iPod you could try it out (just remember it will accept any
> file, even non-supported media). You can even copy files back from the iPod
> to your computer. You need the libgpod python bindings (0.6 or better).
>
> I started to implement the video conversion using gst.parse_launch, so I
> could get a pipeline easily, but I reached a problem when I tried to
> implement video scaling. The problem is that I need to scale down the video
> size if it is too big (for instance, the iPod only supports 320x240 videos),
> but for this I need to know the video dimensions. So I could run the
> pipeline over it once to get the video dimensions, and then run it again for
> the real conversion, but that would mean too much overhead. So, I got into
> Gstreamer internals to find a way to dynamically set the output video size,
> but it is being harder then I thought. I need to set the pipeline to run, so
> I get the video dimensions, but that sets the output size. Somehow I need to
> put the needed dimensions in between that.
> Also, because I needed all this stuff, I re-implemented some code using a
> pipeline directly, which gives me more control (and more complexity). I
> think I'll still use parse_launch for modules to pass their encoders, so
> they can pass a full pipeline if they need to, and it wil be added to the
> pipeline just as another element. But for this to work I have to figure out
> the GhostPad completely (I think I got it now, but it still very confusing).

Yeah. If you look at how I was doing conversions, using ffmpeg, I had
to parse the video twice, the first time to determine the dimensions,
etc.

If its easier for you to run a simple small pipeline to first
determine video size then I support that idea. Im a big supporter of
getting it working in the first iteration, and making it better later
on. One benefit of the first pass to determine the size is that it
would also act as a test to check if the video file is readable, and
gstreamer has the correct codecs, etc.

>
> And I've been thinking about the last part of my project, a easy-to-use
> interface to all these features, similar to the iTunes experience. The
> problem is that I don't know how it fits with Conduit. This interface don't
> fit with the Conduit drag-and-drop model, and I don't know if a program just
> to configure Conduit is needed (after all, you could just open Conduit and
> drag-and-drop the required modules). It would be great if Conduit could fit
> this kind of interaction inside itself, but I really don't know how. So, my
> goal is to create something that could be used by media-players, like
> Rhythmbox. It would replace the current iPod plugin with an interface very
> similar to the iTunes, allowing the user to choose to manually manage the
> iPod, or to automatically sync playlists, notes, etc.
> I still need to research the Conduit DBus interface, to see if everything I
> need is supported.

Let me know if there is anything else you need from the DBUS interface
and I will add it.

It should definately be possible to do a much simpler GUI using
Conduit over DBUS alone. This topic was discussed quite a lot at
GUADEC, and I completely support this approach.

There are quite a few examples on how to use the DBus interface in the
tools/scripts directory IIRC

Good work,

John

>
> --
> Alexandre Rosenfeld
>
> EngComp 06 - USP São Carlos
> _______________________________________________
> gnome-soc-list mailing list
> gnome-soc-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-soc-list
>
>