From: Miguel F. <mfr...@gm...> - 2004-09-28 19:20:39
|
hi, i've just commited the xxmc patch to our cvs. the xxmc driver adds support to via XvMC vld extensions (via cle266 hw mpeg2 decoder) that should be made part of x.org tree anytime soon (i guess). the new driver supersedes the old xvmc in terms of features, since it also provides fallback to idct and mocomp accelerations and plain xv for non-accelerated output (like non-mpeg content). it also supports blending overlays, a feature that nobody cared to implement at the old xvmc driver. i'd like to thank Thomas for his great work ;-) my current plan is to obsolete the older xvmc plugin in the long run. there's no hurry though. there is also a new concept of a "xvmc wrapper", or libXvMCW. this lib allows linking xine to a library that is not vendor specific and which dynamically loads either nvidia, via, i810, whatever. this will make packager's maintainers much happier, since their xine binary will run with any xvmc implementation. the idea is that libxvmcw will be provided by x.org, but we must make it available somewhere else for compatibility with the existing x.org/xfree86 installed base. i have at least one thing i'd like to suggest Thomas: can we simplify the xxmc_data.format thing by changing directly frame->format to reflect the actual format being used? i don't think anything prevent us from returning a different format than decoder asked, provided the decoder can understand this. Miguel ps: Thomas, as we talked before, i'm giving you cvs access. welcome to the xine project ;-) i must have some general cvs access comments written somewhere, but in short: try not to break things. when in doubt, ask on xine-devel before commiting something. ps2: i hope i did not break the configure.ac with my changes. in case of trouble please report... |
From: Dan S. <da...@el...> - 2004-09-28 20:19:52
|
* Miguel Freitas <mfr...@gm...> shaped the electrons to say... >i've just commited the xxmc patch to our cvs. the xxmc driver adds >support to via XvMC vld extensions (via cle266 hw mpeg2 decoder) that >should be made part of x.org tree anytime soon (i guess). the new >driver supersedes the old xvmc in terms of features, since it also >provides fallback to idct and mocomp accelerations and plain xv for >non-accelerated output (like non-mpeg content). it also supports >blending overlays, a feature that nobody cared to implement at the old >xvmc driver. i'd like to thank Thomas for his great work ;-) Yes, great work Thomas. Are all/some of the above features supported for XvMCNVIDIA, and the i810 library? Or just Via specific for now? Thanks. -D -- Good judgment comes from experience. Experience comes from bad judgment. |
From: Miguel F. <mfr...@gm...> - 2004-09-28 20:41:38
|
On Tue, 28 Sep 2004 13:19:45 -0700, Dan Sully <da...@el...> wrote: > * Miguel Freitas <mfr...@gm...> shaped the electrons to say... > > >i've just commited the xxmc patch to our cvs. the xxmc driver adds > >support to via XvMC vld extensions (via cle266 hw mpeg2 decoder) that > >should be made part of x.org tree anytime soon (i guess). the new > >driver supersedes the old xvmc in terms of features, since it also > >provides fallback to idct and mocomp accelerations and plain xv for > >non-accelerated output (like non-mpeg content). it also supports > >blending overlays, a feature that nobody cared to implement at the old > >xvmc driver. i'd like to thank Thomas for his great work ;-) > > Yes, great work Thomas. Are all/some of the above features supported for > XvMCNVIDIA, and the i810 library? Or just Via specific for now? do you mean fallback to xv and overlay blending? yes, it is supported for other xvmc hardware as well (provided you use -V xxmc, not -V xvmc). miguel |
From: Dan S. <da...@el...> - 2004-09-28 21:20:04
|
* Miguel Freitas <mfr...@gm...> shaped the electrons to say... >> >i've just commited the xxmc patch to our cvs. the xxmc driver adds >> >support to via XvMC vld extensions (via cle266 hw mpeg2 decoder) that >> >should be made part of x.org tree anytime soon (i guess). the new >> >driver supersedes the old xvmc in terms of features, since it also >> >provides fallback to idct and mocomp accelerations and plain xv for >> >non-accelerated output (like non-mpeg content). it also supports >> >blending overlays, a feature that nobody cared to implement at the old >> >xvmc driver. i'd like to thank Thomas for his great work ;-) >> >> Yes, great work Thomas. Are all/some of the above features supported for >> XvMCNVIDIA, and the i810 library? Or just Via specific for now? > >do you mean fallback to xv and overlay blending? yes, it is supported >for other xvmc hardware as well (provided you use -V xxmc, not -V xvmc). Yes, and also the VLD extensions? Is that Via specific? -D -- <dr.pie> 31336.5: the neighbor of the l33t |
From: Miguel F. <mfr...@gm...> - 2004-09-28 21:54:02
|
On Tue, 28 Sep 2004 14:20:01 -0700, Dan Sully <da...@el...> wrote: > Yes, and also the VLD extensions? Is that Via specific? yes, VIA/unichrome is the only xvmc driver supporting VLD extension. this is why it is still regarded as an unnofficial extension. miguel |
From: <uni...@sh...> - 2004-09-29 19:50:04
|
Hi! Miguel Freitas wrote: >hi, > >i have at least one thing i'd like to suggest Thomas: can we simplify >the xxmc_data.format thing by changing directly frame->format to >reflect the actual format being used? i don't think anything prevent >us from returning a different format than decoder asked, provided the >decoder can understand this. > > > > Yes, I'll have a look at this. I understand it plays much better that way with deinterlacing and possibly also other things. The XvMC wrapper is in Xorg CVS now, but I'll also provide a standalone package at the unichrome site in a couple of days. /Thomas >Miguel > >ps: Thomas, as we talked before, i'm giving you cvs access. welcome to >the xine project ;-) > > Thanks! >i must have some general cvs access comments written somewhere, but in >short: try not to break things. when in doubt, ask on xine-devel >before commiting something. > > > I'll try ;). /Thomas >ps2: i hope i did not break the configure.ac with my changes. in case >of trouble please report... > > >------------------------------------------------------- >This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >Use IT products in your business? Tell us what you think of them. Give us >Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more >http://productguide.itmanagersjournal.com/guidepromo.tmpl >_______________________________________________ >xine-devel mailing list >xin...@li... >https://lists.sourceforge.net/lists/listinfo/xine-devel > > |
From: Michael R. <mr...@us...> - 2004-10-01 20:36:19
|
Hi Thomas, Hi Miguel, > i'd like to thank Thomas for his great work ;-) Many thanks from me too. This is really fantastic work. VIA's own modification of xine was certainly better than nothing and it demonstrated VIA's good will, but this new implementation is really shiny clean. Not only that, it helps improves plain XvMC as well. Really cool! > my current plan is to obsolete the older xvmc plugin in the long run. > there's no hurry though. Now that we are at throwing away plugins, would it be messy/difficult/stupid to merge drop the Xv plugin as well and somehow integrate it into XxMC too? At least with the old XvMC video out I had the feeling that it shared a lot of common code with Xv and some fixes had to go into both files. > ps: Thomas, as we talked before, i'm giving you cvs access. welcome to > the xine project ;-) > i must have some general cvs access comments written somewhere, but in > short: try not to break things. when in doubt, ask on xine-devel > before commiting something. I have kept my notes from last time. I hope this does not frighten anyone, but I think I should convert this to HTML and put it on the website somewhere: * The developer documentation for xine-lib is the xine hacker's guide. This is a good starting point for any fundamental questions. * When you commit new code, please follow the xine coding style you can see in (almost ;) ) any file. * The usual things apply for CVS: Break as little as possible, at least have it compile. Be extra careful before a release (which is announced some days before on xine-devel), since we release from CVS HEAD and usually do not use CVS branches. * It is a good idea to subscribe to the various xine mailing lists, especially xine-devel (I guess you are already) and xine-cvslog. The latter receives a copy of all CVS commits, so you can easily see, if someone changed (or even broke) your code. * xine-lib includes copies of code from a lot of other projects to support as much media as possible without forcing the user to install dozens of libraries. When you make modifications to any of that code, try to feed the changes back into the original project or provide a patch to ease merging future versions of the external project. * When you are in doubt about something you want to commit or you are making bigger changes or changes to critical parts of the xine engine, post a patch to xine-devel for discussion before committing. * Tell us, if you do not need your account any more, since abandoned accounts are a security risk. So much on regulation, now: Welcome to the team and happy coding! Michael -- "Order is for the simple-minded - it's the genius who rules the chaos." -Sir Arthur Conan Doyle |
From: Miguel F. <mfr...@gm...> - 2004-10-01 22:11:42
|
Hi Michael, On Fri, 1 Oct 2004 22:21:43 +0200, Michael Roitzsch <mr...@us...> wrote: > Now that we are at throwing away plugins, would it be messy/difficult/stupid > to merge drop the Xv plugin as well and somehow integrate it into XxMC too? > At least with the old XvMC video out I had the feeling that it shared a lot of > common code with Xv and some fixes had to go into both files. I'm quite sure there is a lot of shared code between xxmc and xv, in fact, more than xvmc had. still, i'd prefer keeping them as separated plugins (in order to compile xxmc without xvmc headers we would need to add quite some #ifdefs). the xv plugin is a critical component, and it's now stable and well tested. i don't think we should drop it. what i'd like to do though is to cleanup the xv implementation inside xxmc. there's no need for that hacky software deinterlacer there, tvtime usage can be mandatory. > I have kept my notes from last time. I hope this does not frighten anyone, but > I think I should convert this to HTML and put it on the website somewhere: sure, developer's corner's material! :) currently there is a problem with xinehq updating. the cvs is complaining like that: cvs update: move away documentation/static/bindings.html; it is in the way C documentation/static/bindings.html cvs update: move away documentation/static/bugs.html; it is in the way C documentation/static/bugs.html cvs update: move away documentation/static/developer.html; it is in the way C documentation/static/developer.html P documentation/static/donations.html cvs update: move away documentation/static/muxine.c; it is in the way C documentation/static/muxine.c cvs update: move away documentation/static/samplecode.html; it is in the way C documentation/static/samplecode.html and only Siggi can fix it (he has shell access). as soon as this is fixed i'd like to copy the test server (reorganized entries) to the main site. Miguel |
From: <uni...@sh...> - 2004-10-01 22:31:30
|
Hi! Michael Roitzsch wrote: >Hi Thomas, Hi Miguel, > > > >>i'd like to thank Thomas for his great work ;-) >> >> > >Many thanks from me too. This is really fantastic work. VIA's own modification >of xine was certainly better than nothing and it demonstrated VIA's good >will, but this new implementation is really shiny clean. Not only that, it >helps improves plain XvMC as well. Really cool! > > > Thanks for the positive feedback, and also to Miguel for all design suggestions and comments. >Now that we are at throwing away plugins, would it be messy/difficult/stupid >to merge drop the Xv plugin as well and somehow integrate it into XxMC too? >At least with the old XvMC video out I had the feeling that it shared a lot of >common code with Xv and some fixes had to go into both files. > > > Before this is done, One has to consider the way the xxmc plugin drops back to Xv: First, if no XvMC at all is present, or the decoder plugin is not xxmc aware, it behaves more or less exactly like the Xv plugin. Minor modifications in colorkey autopainting and how unscaled osd is handled when it is disabled in the config file. Second, If there is no XvMC surface type compatible to what the decoder plugin requests, or if XvMC surface allocation fails, it falls back to using YV12 surfaces. In this case YUY2 is not available. I'm not sure whether this is a severe restriction. There is some work left to do here: If surfaces are YV12 due to this type of fallback, they should be advertised as such so that post plugins can work on them. At the moment they are still IMGFMT_XXMC, and the actual type is hidden in the accel_data struct. Regards Thomas |