On 11-07-17 05:47 AM, Dirk Meyer wrote:
> I tried XBMC some days ago and while it looks very nice, it forces me to
> organize my media collection in a way I don't want to and has some
> usability issues (IMHO). Therefore, I still need Freevo. :)
You know it's funny you say that, because after finally upgrading the OS
on my HTPC -- I had an uptime of 380+ days and I was reluctant to reboot
:) -- I also decided to try XBMC.
Someone else complained that configuring it was difficult, but I didn't
find that at all. It ran immediately after installation and
configuration was fairly straightforward via the GUI (modulo lirc).
It's certainly overall better than the mishmash of half-baked prototypes
I was using before. But yes, I did have some usability issues (e.g.
library required way too much handholding, requiring manual library
scanning after adding or deleting content) and some stability issues
(e.g. intermittent crashes while switching display refresh rates to
match video framerate).
> The main problem with Freevo 2.0 is my and Jason's lack of time the last
> year. Development was not only slow, it wasn't existant.
Yes, this is the fate of many small open source projects: developers
eventually get carriers and/or lives and progress atrophies. I wish I
had the motivation and energy I had when I was 20. :)
> Jason: I assign your name to some smaller stuff here, I hope it is OK. ;)
Mostly. :)
> 1. kaa.base is done and has all the cool stuff I want. If there is a
> bug, Jason and I will take care of it. But it shouldn't be much.
The coverage of the docs isn't complete, but what's there is pretty well
documented. And yes, I'm certainly happy to answer questions and
respond to bug reports.
http://doc.freevo.org/api/kaa/base/
> 2. kaa.metadata is also done. Maybe add or change a parser, but that is
> not important right now. Patches are always welcome.
Especially an M2TS parser. This is one of the bigger gaps in
kaa.metadata right now. This would be a great, focused little project
for someone looking to contribute. Adding parsers to kaa.metadata is
quite simple and you're not required to figure out how kaa.base or other
big chunks of code works.
All you need to do is read the ISO 13818-1 spec. *cough* :)
> 5. kaa.candy has the basics, but may need some nice effects like
> mirror-effect, better animations, etc. It has everything we need to make
> Freevo 2.0 work but it could be nicer. If you know C (Python not needed)
> and want to play with clutter or if you now Python and want to dive into
> kaa.candy, drop me a note. You only need to know kaa.base and clutter as
> dependency.
I think we should seriously revisit kaa.candy now. clutter has come a
long way since we looked at it last, and it now includes containers and
layout managers, and lots of new effects and animations, which is a lot
of what kaa.candy aimed to add. We should gut what's no longer
necessary in kaa.candy and stay as tight to clutter as possible.
> 6. XBMC looks soooo cool. The big background images, the animations.
> Nice! We do have the code in Freevo 2.0 to do the same (even support to
> grab TV show or movie specific wallpapers and images).
Yeah, but a lot of the credit there really goes to the awesome
contributors of thetvdb.com and themoviedb.org. I'm still amazed at the
quality of the fan art.
> 7. kaa.beacon is mostly done. I have some minor things on my list I will
> do the next weeks. The big problem is a better network support. Jason:
> we talked about distributed beacon servers. Do you still plan to do
> this? Do you still have time for it?
It's still on my to-do list, but knowing how much hacking time I've done
in the past year, I shouldn't make any promises.
My biggest use-case is that I do most of my file management on my NAS,
and the HTPC just has an NFS mount to consume the media. My HTPC is
where beacon would run, but because INotify doesn't work through NFS,
beacon doesn't see the changes.
We had some neat ideas about distributed beacon instances, but there are
a couple simpler-to-implement options that I'm more likely to get to first:
1. An INotify reflector: a small process that just passes INotify
events over RPC back to the beacon server
2. Have an option to periodically scan NFS mounts in addition to
INotify. Currently (IIRC), polling is disabled if INotify is supported.
#2 is easiest to implement by a long shot. It's not as elegant as it
won't catch file moves, though.
> 8. kaa.popcorn (or video player) needs clutter support to write on a
> texture. This would enable us to draw on top of the video and put it on
> the background. Again: help needed here. we could either put the mplayer
> output on a texture or use gstreamer. Jason played with the first option
> but the code is not finished yet. Jason: do you think you can finish it?
This is a big piece. It's the piece that has given me a huge amount of
grief because of the fact that we're *really* trying to have a
multi-process architecture.
I should start by saying I'm not especially interested in GPUs other
than those from NVIDIA. I've used NVIDIA for a decade and I really like
the hardware and the capabilities. Shame about the closed-source
driver. I vow to switch to a Free alternative as soon as they can
compete. Developers with other hardware can obviously volunteer to
support their preferred hardware. :)
In working on this a couple years back, I hit a wall. The most elegant
design was to use GLX_EXT_texture_from_pixmap to redirect an
out-of-process pixmap rendered by MPlayer (or whatever player) to a
local GL texture that we could manipulate. Even if all you wanted to do
was slap it onto the screen unmodified, this provided the foundation to
doing nice custom OSD as well.
This worked great for Xv, so it could be used for Xine with DVDs. With
VDPAU, we could get away with it at 24p. But higher framerates started
to tax the GPU too much, resulting in dropped frames. And forget about
deinterlacing.
I was hoping NVIDIA would have optimized this path in the past two
years, but it's still sluggish. There's no reason in principle it needs
to be. Recently, NVIDIA added GL_NV_vdpau_interop, which provides an
API to have VDPAU render straight to a GL texture. The problem is that
this doesn't work out-of-process. The video player would need to be
part of the display process.
This is bad news for our goals of using stock MPlayer as a separate
process. Near as I can tell, we have something like four options:
1. Only redirect video to a GL texture when we need to do something
with it, like do on-screen display or play it in a thumbnail while
the user navigates the menus.
* Pro: we can keep the player out-of-process and no custom patches
needed
* Con: noticeable glitching (a flicker caused by starting the
redirection and raising the Freevo window over the MPlayer VDPAU
window) even when doing something like displaying a simple OSD
to show current time or whatever.
2. Patch MPlayer to allow Freevo to control the contents of the
VdpBitmapSurface used for the OSD, but redirect video to GL texture
when we want to display the video in a thumbnail (or background)
during menu navigation
* Pro: we can keep the player out-of-process
* Pro: smooth, glitch-free OSD
* Con: requires custom patches and custom installation of MPlayer
* Con: glitch when dropping to thumbnail mode
3. Fuse the video player and the display engine (clutter) into a single
process, and use GL_NV_vdpau_interop to get the video into a texture
to be rendered by clutter
* Pro: most flexible, glitch-free solution
* Con: we're basically forking MPlayer at this point
* Con: if player crashes, so does Freevo [but I have an idea about
this, see later]
* Con: requires implementing frame timing logic (not using MPlayer
for that anymore)
4. Like 3, except use VdpBitmapSurface for OSD, and GL_NV_vdpau_interop
(or maybe just straight texture_from_pixmap) when dropping to
menu/thumbnail mode
* I think this is what XBMC does
* Pro: still leverages nice timestamp-based display of VDPAU's
presentation queue
* Con: forking MPlayer
* Con: minor glitch when dropping to menu mode; this is less than
the glitch in #2 because there's no need to remap/raise/lower
and X11 windows
5. ???
6. Profit
None of these are obviously better than the others (except for perhaps
#6), but #2 is probably a fair compromise.
If we do merge the video player into the display process (like XBMC) --
and in fact I think we should do what I'm about to describe /anyway/ --
we should decouple the display from the main process. The main process
can talk to the display process (which runs clutter plus the player) via
RPC, and always maintain the scene graph and all state needed so that it
can replay it at any time if the display process crashes. If the
display crashes, the main process can restart it and immediately get the
GUI back to the exact state it was in before (although if a video was
playing, it may end up seeking to a slightly different position).
This is a new architecture for Freevo, but I like it, because one of the
things I found annoying about XBMC was when it crashed, it was quite
disruptive. Also, it means the nasty, temperamental C bits get stuffed
into the display process that's allowed to crash, all the stable, robust
Python bits are in the main process, which is expected to be
long-lived. The display process could as well be written purely in C.
> 11. There is not webserver for Freevo 2.0. Anyone willing to take over
> this part? You have complete control what you want to do. I guess you
> have to know your HTML/CSS/JS-fu.
I'm also lately of the opinion that we need a web services API. RESTful
is trendy, and it's usually very easy to work with, lowering the barrier
to entry. But this is something we should not worry about until we have
a stable and complete core.
> 12. Android / iPhone support? Not needed but nice to have
As a Canadian, I also feel obligated to include BlackBerry in there. :)
I actually really like controlling my HTPC from my PlayBook. A nice web
UI that's touch friendly is all we need.
Jason.
|