On Sun, 2005-04-17 at 13:19 +0200, Dirk Meyer wrote:
> Hi,
Hi Dischi. How've you been? Seems a bit has changed since I last
looked at freevo. :)
> applications may also use it. This involves storing all thumbnails in
> the large dir (128x128 is too small for us) as png with meta
> informations.
Unfortunately the spec doesn't allow for formats other than png. I
agree that using epeg is a performance gain that can't be ignored. But
the common use-case is probably a lot of jpegs and a system with epeg
installed, in which case pyimlib2's current thumbnail code will not
adhere to the specs. So other applications won't be able to benefit
from the thumbnails, which pretty well obviates the whole point of using
~/.thumbnails.
On the other hand, it also seems like quite a reasonable extension under
the circumstances. And the fallback (non epeg) code does generate a
spec-compliant thumbnail. There should, of course, be some logic
elsewhere that cleans up deprecated thumbnails.
There doesn't seem to be any provision for local repositories though. I
think this is a useful addition to the thumbnail spec that Freevo could
benefit from.
My first instinct is this really isn't pyimlib2 territory, since it's
not specifically Imlib2. But it _is_ image library territory, and with
the shmem stuff in pyimlib2, I really set the stage for pyimlib2 to be a
more general purpose, kitchen sink thing anyway. :)
My only objection to pyimlib2 now is the indentation style. Replaced by
spaces? My tabs! My beautiful tabs! Oh, woe! :) It is, however,
maintainer's prerogative. :)
> Right now my version here supports both, the old vfs and the
> .thumbnails style. But do we need both? To keep the code cleaner, I
> want to remove the vfs way of thumbnailing. Comments on that?
Ignoring issues of code stability in current cvs (since I have no idea
where Freevo is now in that respect), I think it makes perfect sense to
remove thumbnailing from the vfs.
> And two questions remain: First, what to do with rom drives? A disc
> can change the drive, so the thumbnailer won't find it. I was
> thiunking of VFS/disc/DISC_NAME/.thumbnails as a solution for the
> problem.
This seems reasonable. Another approach might be to put the thumbnails
in the regular ~/.thumbnails directory but include the CD name in the
hash, but I think your suggestion is better. Either way, the current
thumbnail code in pyimlib2 doesn't allow for repositories in different
locations.
Actually, if you added local repository support to the thumbnailing
code, you could reuse that with removable media, and create a local
repository under <VFS>/disc/DISC_NAME/. Perhaps add an optional
'local_repository_base' argument to both thumbnail_create() and
thumbnail_check() which defaults to _thumbnail_dir / _failed_dir if not
specified. (Although, if specified, it would have to not include the
dirname in the md5 digest.)
> Second: do we need creating thumbnails with the cache helper?
Why not? Can't it just reuse current code? I think having this in the
cache helper is nice. Some users probably run freevo cache in a cron at
night or something, just to index files they might have added but
haven't browsed in Freevo yet.
So I've been hacking quite a bit over the last couple of weeks. For the
curious, let me digress terribly and blabber about what I'm working on.
I haven't hacked on Mebox for some time, as you know, but I've had
plenty of ideas, only with no time to hack. Nothing to show for all my
work yet. Mostly just proof-of-concept testing and support code. I've
been completely revamping the vfs code in mebox. It supports live
queries and auto-indexing of any new file in the repository (so long as
the system supports inotify), a feature inspired from the Beagle
project. By live queries I mean you can do
vfs.query("artist='Vangelis'") and it will return a vfs directory of
files matching that query. You can attach callbacks to a monitor on
that directory that gets signaled when a new file is added to user's
library that matches that query. Since it uses inotify, the feedback is
pretty immediate. Very cool stuff. :)
I also wrote an ipc library that Just Works and is completely trivial
because Python rules. So, say a server has some instance object 'foo'
that it wants a client to be able to use, it does:
ipc = IPCServer("program.socket")
ipc.register_object("foo", foo)
And the client does:
ipc = IPCClient("program.socket")
foo = ipc.get_object("foo")
The client can start using 'foo' now as if it were local. Any mutable
objects (instances, lists, dicts, whatever) passed back and forth
between client and server either via return values or arguments are
automatically referenced (rather than copied). Things just work. This
really isn't anything magical if you're familiar with Python, but I do
think it's really cool. Python continues to amaze me.
But the most significant stuff I've been working on remains how I'm
going to do the display for MeBox. Mevas was the answer, but now I'm
not so sure. I've been doing some fiddling with evas (from the
Enlightenment project) and it seems viable.
My proof-of-concept work with evas is split up into several parts.
MeBox has many requirements in terms of UI features. The main ones in
terms of difficulty are good OSD (solved with bmovl2 in the mevas
approach) and the ability to take video and scale it dynamically, so you
can have thumbnail views of video, or a small corner window of the video
for an EPG. My approach before was "dynamic filters" in mplayer: make
VF_SCALE something you can manipulate via a slave command. But mplayer
isn't built for this and it's unstable.
So with evas I've come up with a completely new approach. It's elegant,
given the constraints, and it's very cool. For OSD, I made a new
filter, vf_osd, that steals a lot of code from bmovl2 but simplifies
things. vf_osd basically works like the OSD support in ivtv. You setup
a buffer via shared memory and write to it BGRA pixels. Then, via the
fifo, you tell mplayer which areas have been updated. It does BGRA to
YV12(A) conversion on the fly. This requires the colorspace conversion
code to be very quick, of course. In my tests it looks quite feasible.
Global alpha is still supported so you can do fullscreen fades quite
smoothly.
So the OSD requirement is solved: when Mplayer is running, we can have
fast, smooth OSD support. This is nothing new; bmovl2 offered this
before. But vf_osd is a simpler approach, moving the logic out mplayer
and into the controlling application. This is sort of ironic, since
this is exactly the _opposite_ of what I did with bmovl2. But the
requirements are different, since I don't need to render a full
application UI using mplayer.
The next question is how to solve the problem of getting thumbnail-sized
video on top of the display, which would be using evas. So I wrote
another mplayer filter, vf_outbuf, which writes the video frame to a
shared memory location. The controlling (evas) app will setup a shmem
object that is the image buffer to an Evas Image object. Using a very
simple synchronization method (just use the first byte in the shmem
buffer), the controlling process monitors the sync byte, and updates the
canvas image when the sync byte indicates a new frame is available.
So we have an mplayer video that is a canvas object. (You might be
asking why not use Emotion, but the short answer is that I want to use
mplayer, and mplayer cannot be used as an application library.) But the
cool thing is that since this is an evas canvas object, we can
manipulate it like any other. We can move it around, scale it, change
its alpha value, apply a color map to it, whatever. The COOLER part is
that with evas's opengl acceleration, this is not only slick, but really
fast. This means I can do MCE-style fade/slide/scale effects of video
that's very smooth. And since I've got enough of the evas API wrapped
in pyevas (which I'll release independently at some point), all this is
written in Python and looking very good.
At some point I will have some sort of technology demo of this. MeBox
is still vaporware, however. And I still use Freevo. :) But maybe
Freevo can continue to benefit from my work in some way.
Ok, back to reality. Dischi, I'd like to make some changes to pyimlib2.
Specifically, I'd like to add Py_BEGIN_ALLOW_THREADS /
Py_END_ALLOW_THREADS to various places, to make threading performance
better. Do I still have write-access to the repository?
Cheers,
Jason.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
