Re: [Bitpim-devel] What is expected of getringtones/getwallpapers?

[Roger B. <ro...@ro...>]

Stephen Wood wrote:
> What does BitPim expect the getwallpapers and getringtones routines to
> return?  I gather that it expects arrays of the actual contents of the
> files on the phone.  But what is the index of this array, the filename
> of the file on the phone?  That appears to be the case here:

I would appreciate it if you could update web/phonespec.html with
various useful bits of information (such as this) as you find them
out.

Two things are added to the result dictionary.  One is an index
describing each piece of media.  This is currently a name field 
and an origin field (for example the VX6000 has images in 
brew/shared, brew/shared/mms, brew/shared/mms/d, the camera and
some builtin.  The origin fields are set to images, mms, drm
camera and builtin respectively).

Everything returned there ends up being selectable in the 
phonebookentryeditor.  There is a same index attached to
this email.  Currently it is a dictionary with arbitrary
numbers as the keys.  (The numbers don't mean anything!
They are just a legacy of the earlier codebase where they
were the actual index numbers used on the VX4400.  Feel
free to update all the code to make it a list rather
than a dictionary. :-)

When writing out, images are sent to the origin they
came from assuming the phone has it available.  If not
they just get assigned to the first location with free
space.  This means that you can trivially read everything
from a VX6000 and dump them to a VX4400 without having
to worry about the differening locations available.

Note also that the current code doesn't write back to
the camera on the VX6000.  There are many ways to get
this wrong (eg knowing that you are trying to send back
an image you got from the camera but which has been
renamed in the camera UI).  I also saw little
utlity in it.

Anyway, that is what ends up in 'wallpaper-index'.  'wallpaper'
is a dictionary where each key is one of the names from
the index, and the value is binary data.

Back in the main BitPim code, it uses the names as the name
on the filesystem.  You could have mutliple entries in
the index with the same name but ...

> Some Sanyo phones can take short movies.  Can I return the movies in the
> same structure as the wallpapers?

Sure.  The only current constraint is that it must be possible to
display them as an image.  What format are they in?  The current
method I can see to display an image is to use ffmpeg to convert
to motion jpeg, and then rip the first frame out of the resulting
file.  For example, assuming the video is foo.movie,

  ffmpeg -i foo.movie foo.mjpg

The the first frame is gotten using the details on this page:

http://www.lokigames.com/development/download/smjpeg/SMJPEG.txt

If we want to get really fancy, the image can be replaced once
a second with a second into the the movie itself, so it somewhat
looks animated.

I am currently planning on using a custom version of Wine
and including it in the BitPim distribution.  (The last time
I checked, we only need the main binary, two shared library
and one dll totalling just under a meg compressed).  That
will allow just using the Windows version of ffmpeg,
and pvconv (which is only available on Windows).  Steven
may be able to pull something similar off with qemu, Wine
and some glue for the Mac.

> What would be suggested for handing duplicate filenames? 

There is logic behind the current scheme, mainly trying to
deal with having multiple models of phones, and doing the
right thing when moving stuff between them.  Having the same
name but different content would be somewhat confusing.
(This isn't necessarily the right solution, just what I
arbitrarily picked, and I am very open to changing it).

It also means that things like drag and drop or saving
out of the wallpaper/ringtone displays are simple.
If we allowed multiple files of the same name, then they
would have to stored in a hierarchy which would complicate
the saving or dragging.

> If one takes a
> picture with a Sanyo camera phone, then assigns it as a wallpaper to a
> phonebook entry, there will be two files on the phone with the same
> name.  The large file is the picture and the small file is the picture
> sized properly to be a wallpaper.

The VX6000 quite happily points at the original camera image.  It
never duplicates images in the same way.

What I would be inclined to do in your case is to give the camera
images a different name, or a unique prefix.  For example, if
the file is actually 'face.jpg' then call it that from wallpaper,
but from the camera call it '#camera_face.jpg' or something
similarly arbitrary.

Roger