Re: New: Type inheritance and conversion parameters





On 9/15/07, Kenneth Christiansen <kenneth christiansen openbossa org> wrote:
Hi John,

Sounds pretty nice, and this is definitely something that we need. I guess you probably want a way for the user to define what to use to do the conversion, especially when it comes to videos (many use mencoder for N800).

All of this should now be implemented in SVN. Transcoding and better nokia n800 support. In addition there should be no hard dependence on Gtk remaining in the Conduit core.

I would appreciate your thoughts on these changes and how we can continue to work together - canola, syncronization, syncropated, conduit and nokia - one big family!

See http://www.johnstowers.co.nz/blog/index.php/2007/10/31/one-thousand/ for more info

John

{"size":"640x480"} mean that the images will be resized to fit within the size of 640x480? or will they be scaled until one side fits and then cropped? or maybe that should be an option.

Cheers,
Kenneth

On 9/13/07, John Stowers < john stowers gmail com> wrote:
Hey Team
When I get internet at home in a few days I am going to do a rather large commit introducing type inheritance and conversion parameters. I will explain what these are, and how we should use them.

Motivation:
We have kind of hit a wall with the type conversion stuff, there is (currently) no sane way in the conversion framework to transcode media, resize photos, or other use cases where the general type remains the same, but something else about it changes. I want to improve the usefulness of conduit to media dataproviders. The $FUTURE_STEP after this stage is to make converters objects, and not static functions, but that can be done later.

Lets start with a contrived example

class File(DataType):
    _name_ = "file"
    def __init__(self)
        pass

class Photo(File)
    _name_ = "file/photo"
    def __init__(self)
        pass
    def get_image_size(self):
        pass

Note: _name_ specifies the named type. This used to be an argument to the base constructor.

Dataproviders may now implement a function call get_input_conversion_args and/or get_output_conversion_args which returs a dict of parameters to be passed to the conversion function

class FlickrSink
    _in_type_ = "file/photo"
    def get_input_conversion_args(self)
        return {"size":"640x480"}

Lets say the user wants to sync a folder of photos with Flickr. Folder out_type = "file" and Flickr _in_type_ = "file/photo". Converters now have configuration arguments. For example
converters = {"file,file/photo":convert_file_to_photo}
def convert_file_to_photo(file, **kwargs)
    t = file.get_mimetype()
    if t != jpeg:
        return None #may return None if a conversion is not sensible
    p = Photo(URI=f.get_URI())
    p.resize (kwargs["size"])
    return p

In the two way sync case, such as Flickr <-> Folder, the conversion from photo_to_file is not needed becase photo is a subclass of file.

Imagine syncing Rhythmbox to your n800, you want to encode the audio to a lower bitrate. In this case you define a transcode function, which is realy just a function that converts a type to itself.

converters = {"file/music,file/music":transcode_music}
def transcode_music(music, **kwargs)
    return music.transcode(kwargs["format"],kwargs["bitrate"])

Anyway I would appreciate your comments on this new functionaliy, thomas does this make sense in the image case. Obvioulsy the pseudo code above contains no error handling but is how I envision the data flow.

Jc2k, how is that gstreamer transcoder going?

John




_______________________________________________
Conduit-list mailing list
Conduit-list gnome org
http://mail.gnome.org/mailman/listinfo/conduit-list





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]