lightspark-users team mailing list archive

[Alessandro Pignotti <a.pignotti@xxxxxxxx>]

Hi everyone,

the reason why ffmpeg has been used in lightspark is that, ultimately,
gstreamer will resort to ffmpeg to provide the actual decoding support.
Since I wanted for lightspark to strive for efficiency adding layers of
indirection has been avoided as much as possible.

I, of course, see that, as several part of the codebase have been moved
to using glib and gtk provided functionality it makes sense to also use
other parts of the platform. I'd like to add a couple of points to the
discussion though.

1) Let's be pragmatical and avoid getting everything from the platform
just for the sake of it. 
2) Although I'm 100% positive that pulling in cairo was the only sane
solution to provide good vectorial graphics we are still plagued by
cairo non thread safety and still severely limit lightspark ability to
scale over multiple processors. cairo is used by everyone and I am sure
that cairo maturity will improve over time, but still lightspark had
pushed the limit of the implementation. For this reason I would like to
avoid pulling in clutter now. When it will be used by major, complex
applications we may decide to use it. Moreover, there is no work AFAIK
currently on graphics stuff, so I don't see any urgent reason to rework
that code. If reworking will be needed to add more features it would
make lots of sense to migrate to clutter though.
3) About gstreamer, I think it could make sense to use it, but please do
not think that it is the only solution to have features like hardware
decoding. It would be easy to have them using ffmpeg as well, it's just
a matter of working a bit on the code. I have never done it before since
I had no supported hardware. The biggest advantage I see in moving to
gstreamer is to make it more easy to ship lightspark by default. Still
it will be useless without the ffmpeg-gstreamer plugin installed

Cheers guys, is nice to see some good talking on the list
Alessandro

Il giorno mar, 13/03/2012 alle 12.28 +0200, Jani Monoses ha scritto:
> Hi all,
> 
> IMHO the Lightspark project should concentrate on making a complete
> and high-quality AVM2/Flash API implementation
> and not spend resources on tangential problems.
> Even if some of its requirements for media playback are different from
> what a simple video player has,  I think
> using gstreamer/clutter+other tried and tested libraries instead of
> ffmpeg+homegrown GL rendering
> would buy in the long run a few advantages:
> - less code to maintain, and less of it platform specific
> - gains from whenever those libs evolve and implement hw accelerated
> video playback
> - support various fringe architectures, where it is more likely to
> have a gstreamer plugin than something that can be piggybacked on the
> existing ffmpeg code
> - runtime selection between GL/GLES
> - easier contributions in the rendering/playback parts of code from
> those with experience in the GNOME stack
> 
> It is likely not an easy task but I feel it may be worth doing.
> Any drawbacks - besides the effort needed - that I am missing?
> 
> Jani
>