lightspark-users team mailing list archive

["Jasper St. Pierre" <jstpierre@xxxxxxxxxxx>]

On Tue, Mar 13, 2012 at 2:10 PM, Alessandro Pignotti
<a.pignotti@xxxxxxxx> wrote:
> 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.

That's not true. gstreamer supports a bunch of formats, including
their own H.264 and AAC decoders, and MP4 and FLV demuxers. These
don't stem from ffmpeg at all.

> 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.

cairo is fully threadsafe. Pango is not. Clutter isn't thread-safe,
because OpenGL isn't.

Several major applications are using Clutter - it was initially
developed for at OpenedHand for several big projects there. It got
used when building Moblin, which got carried forward into
Meego-Netbook, and is still being using in Dawati, which is the base
of Tizen. It's used in GNOME Shell, and it's used in countless other
open-source projects. I know that Cisco and Bosch use it internally.

As I said before, if we move to Clutter, it makes sense until the
Clutter Apocalypses are done and Clutter 2.0 is released, simply
because starting development by moving to a shaky API is not a good
thing to do.

> 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.

Everything is just a matter of "working a bit on the code". But if we
don't have to write that code, why should we? We get everything we
want for free.

> Still it will be useless without the ffmpeg-gstreamer plugin installed

flvdemux, aacparse are in gst-plugins-good. h264parse is in
gst-plugins-bad, and they have several elements for flash video.
'playbin2' should work fine for most files

> 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
>>
>
>
>
> --
> Mailing list: https://launchpad.net/~lightspark-users
> Post to     : lightspark-users@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~lightspark-users
> More help   : https://help.launchpad.net/ListHelp



-- 
  Jasper