On Mon, 3 Jan 2011 13:44:22 -0200 Gustavo Sverzut Barbieri <[email protected]> said:
> On Mon, Jan 3, 2011 at 1:07 PM, Carsten Haitzler <[email protected]> wrote: > > On Mon, 3 Jan 2011 08:16:51 -0200 Gustavo Sverzut Barbieri > > <[email protected]> said: > > > >> On Mon, Jan 3, 2011 at 6:26 AM, Carsten Haitzler <[email protected]> > >> wrote: > >> > On Fri, 31 Dec 2010 01:31:46 +0100 Stefano Sabatini <[email protected]> > >> > said: > >> > > >> >> In data Wednesday 2010-12-29 19:57:53 +0100, Nicolas ha scritto: > >> >> > Hello, > >> >> > > >> >> > Here's a new version of EvasVideoSink, feel free to test it. > >> >> > https://sourceforge.net/projects/evasvideosink/files/ > >> >> > > >> >> > I also created a widget for Elementary. > >> >> > To test it, you need the latest svn version of Elementary, follow the > >> >> > instructions listed in the README file for compilation. > >> >> > > >> >> > Why create an Elementary widget for EvasVideoSink and not Emotion? > >> >> > > >> >> > Emotion is intended to be a complete library manager for xine, > >> >> > gstreamer and vlc but the problem with this kind of project is that > >> >> > it is never complete! > >> >> > Take the example of pidgin, it supports all the protocols, but most > >> >> > are not complete, that is why I chose GStreamer and I intend to focus > >> >> > solely on GStreamer. > >> >> > Please note, I'm not criticizing anyone, it's just my opinion! > >> >> > >> >> And if you have time to kill and you want to try something new, you > >> >> could try to write a sink for libavfilter (the FFmpeg A/V filtering > >> >> library), I recently wrote an SDL sink (check the ffmpeg-devel > >> >> archive) and I even started to work to an ecore/evas sink but got > >> >> stucked at some point. If you're interested I can let you see my > >> >> unfinished work and provide help (and eventually push it to the FFmpeg > >> >> repo). From what I can see the libavfilter variant should be much > >> >> simpler. > >> > > >> > i'm a little bit curious - how is this really much different than > >> > emotion - where emotion wraps up gst and xine in an abstracted api to > >> > access and also provides the sinks needed for both to display in the > >> > evas object emotion creates... :) well i know the difference is in that > >> > you've just done the sink bit and no wrapping/abstracting - but i'm a > >> > tad curious as to "why" when emotion already provided that? :) (if you > >> > were missing controls for the video or audio stream the emotion could > >> > always have the controls added in api...) :) > >> > >> emotion relies on some primitives that are not always reliable > >> (although they should be), like gstreamer version using decodebin. > >> Lots of systems need special pipelines to play media, some requires > >> special pipelines to play some formats. Try it on OMAP platforms and > >> check for yourself, most don't work (pandaboard does not, n800 -> n900 > >> did not as well AFAIR). > > > > in which case... emotion simply needs to be able to set up that pipeline > > then - the result is the same - output of video data as yuv (well if an > > evas sink is involved). why should the person using gst have to "specially > > set up" that pipeline per platform - why should they need to know. i'm a > > bit surprised gst was set up this way to not "just work" (well use the dsp > > and accelerate the decode anyway). i suspect a design or implementation > > flaw here on the gst+omap side - but i dont know the details. i just smell > > something wrong. but... again > > - why can't emotion just set that pipeline up properly? why push that work > > into each and every media player app? :) > > You'd need a particular/especial pipeline per hardware platform. Some > you need to simply create a new pipeline element (ie: sink), others > you need to negotiate the pad capabilities (caps) in a weird way... > I've seen all of those in real life. > > Thus the situation is: 1) we allow users to not use emotion and go > straight with gstreamer on these minor/less common hardware or 2) we > require users to patch emotion to create custom pipelines for those hw > and provide --with-gst=HW-VARIANT > > 1 is easier because most vendors provide sample apps, one would just > need to replace the sink with evas-sink, without actually having to > understand how emotion or the gstreamer works. but this makes apps "unportable" which is entirely against the whole idea of abstractions and wrappers (unportable in the sense that it is unable to take advantage of the given hardware available without custom-modifying the apps themselves - and now you get not 1 app but a dozen or more modified as opposed to fixing it & making it work in 1 place only and then suddenly all video players benefit (well ok all that use emotion,efl etc.). > 2 is desirable as more users would be able to use/reuse it. but I've > never seen these working in real life. indeed. i dont think it needs --enable necessarily - it could possibly be detected at runtime given querying info from gst, and then my bets are on ther being a pattern that will emegre - that certain "classes" of hardware need a common kind of pipe etc. > That said, I see no problem with people making this an official > gstreamer sink. Even if we go with 2. oh - i'm not saying i have a problem - i'm just thinking the whole design and reasoning behind it all seems particularly odd - and as mentioned - to me this smells of a deeper problem that right now appears to me to be just a poor gst implementation that took shortcuts and was lazy and pushed work into the apps above gst as opposed to "just handling it" properly in an abstracted way. if this turns out to be "this is hos gst is meant to work" i might say "well thats a silly design principle of gst then - but ok, that requires the next layer up take care of it.. ok - then that means emotion takes care of this" and we loop back to the above... :) > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: [email protected] > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
