lightspark-users team mailing list archive

[Alessandro Pignotti <a.pignotti@xxxxxxxx>]

Comments below inline

Il giorno mar, 13/03/2012 alle 14.58 -0400, Jasper St. Pierre ha
scritto:
> 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.
on my Ubuntu Oneiric system: gst-inspect-0.10 | grep 264
rtp:  rtph264depay: RTP H264 depayloader
rtp:  rtph264pay: RTP H264 payloader
videoparsersbad:  h264parse: H.264 parser
typefindfunctions: video/x-h264: h264, x264, 264
x264:  x264enc: x264enc
ffmpeg:  ffdec_h264: FFmpeg H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
decoder
ffmpeg:  ffmux_ipod: FFmpeg iPod H.264 MP4 format muxer
h264parse:  legacyh264parse: H264Parse

h264parse should be a parser for the h264 bitstream, not a decoder, I
might be wrong but a quick inspection of the code suggest this. Please
correct me if I am wrong.
The only decoder I see is provided by ffmpeg.
> 
> > 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.
I am referring to commit 159450414695d99a0c7633d13d8444c76405538c. Pango
rendering is protected by a different mutex.
> 
> 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.
I don't know how much "for free" it would be. I trust your opinion on
this.
> 
> > 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
> 
> 
>