Re: [Freevo-devel] The future of Freevo 2.0

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.

------------------------------------------------------------------------------
5 Ways to Improve & Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can 
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/

_______________________________________________
Freevo-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freevo-users