| |
| |
| |
|
Page: 1 2 3
Comments:
<0> Hmm. Not familiar with nVidia graphics hardware...
<0> You could try -V xshm or -V opengl
<0> (the latter ***uming that you're using the closed-source taintware)
<1> okay, brightness works with -V xshm, but I get the message "the amount of dropped frame is too high"
<0> Hmm... with xine using Xv, does "xvattr -a XV_BRIGHTNESS -v 1000" do anything?
<1> I should put these options on the command line?
<0> Separate command.
<1> there is no xvattr command; it says "command not found"
<0> Then install it :-)
<1> ok
<0> BTW, you could use a video post-processing plugin: "eq" or "eq2", but it's still worth knowing whether Xv attributes work before you try them.
<0> Oh well :-)
<2> hi
<2> FlAFKeyes: around?
<3> siretart, yeah
<2> FlAFKeyes: could you perhaps rebounce me your patch?
<4> siretart, which one of many? :)
<2> Flameeyes: I'm reading xine-devel via gmane, and it cripples attachments :/
<2> Flameeyes: the patch about xine-lib on sparc
<4> just a second
<2> Flameeyes: do you know what --disable-vis actually does? or suppose to do?
<2> I don't see its effects in Makefile.am, currently.
<4> http://dev.gentoo.org/~flameeyes/patches/xine-sparc.patch
<2> ok. thanks
<4> it should disable VIS support (extension of sparc64), right now it probably do it in libmpeg2 only
<2> Flameeyes: btw, does your patch only fix libavcodec or libmpeg2 as well?
<4> libmpeg2 should take care of itself with --disable-vis in theory
<2> I'm currently testbuilding that
<2> no, libmpeg2 fails even with --disable-vis
<4> can you pastebin the error?
<2> argl. my bad, it does with --disable-vis. sorry
<4> vis should be available only on sparc64 iirc so for sparc32 build it has to be disabled, or at least i think so
<2> now I try with your patch. I ***ume it unconditionally sets --disable-vis on sparc, yes?
<4> no, by default it's still enabled
<2> on sparc32, that is
<4> you need to p*** --disable-vis to the configure to build on sparc32, it will disable the vis support from ffmpeg when --disable-vis is p***ed, that is the part where the error is at the start
<4> i have no idea how to detect sparc32/sparc64 :/
<2> I'm building on sparc64, but the code just doesn't compile
<2> not at least without p***ing -mcpu=v9
<4> hmm that would be bad
<4> is there anything higher than v9 right now?
<2> I don't know, I'm no sparc expert
<4> because maybe i can make it p*** -mcpu=v9 when enabling vis, if there isn't an higher one
<2> I just try to fix xine for debian
<4> eh we're on the same boat then :)
<2> the problems seems rather to be that the 2 mentioned object generate sort of inline ***embly code, which ***ume more than 32 registers
<4> yes but forcing -mcpu=v9 only on thos is likely to be a problem
<4> i would rather force it in CFLAGS when vis is enabled
<2> optimum would be runtime detection if vis is there or not
<2> I'm not sure if the code doesn't already have
<4> i'm barely able to understand x86/amd64 asm, so i won't look into the actual code myself :P
<4> refresh the patch, and try with that, it enables -mcpu=v9 when enabling vis
<2> err, it seems it has
<2> look at dsputil_vis.c, function static int vis_level (), at top
<2> it catches a SIGILL, so the code tries a VIS instruction, but handles a SIGILL
<4> hm okay, but if -mcpu is forced the invalid instructions might not be related to vis at all but other parts of the code, even the SIGILL handler
<2> hm. true.
<2> would be worth a try, but I don't have a sparc32 around
<2> and libmpeg2 doesn't seem to have the same autodetection, just libavcodec
<4> libmpeg2's simd support is flaky, quite a bit
<2> Flameeyes: I still need to pas --disable-vis with your patch? - because without, it doesn't do it..
<4> to build for sparc32, yes you need to p*** --disable-vis
<4> does debian differentiate between sparc32 and sparc64, or simply has a sparc arch?
<2> it does kind of. sparc64 uses a 64bit kernel with 32bit userland
<2> rationale: benchmarks didn't show enough performance gain
<4> so the same package is used in both?
<2> yepp
<4> in that case, you'd need to p*** --disable-vis
<4> so that it will run in both, or it will fail on true sparc32 hardwares
<2> which would be sad because ultrasparcs won't support from vis code
<2> well, there is a post on debian-release about this question
<4> yep sad, but probably necessary :/
<2> because there are already some packages, like the ffmpeg debian package, which already p***es -mcpu=ultrasparc
<4> on gentoo they still use 32-bit userland, but the package si built differently if it's sparc or ultrasparc
<2> or -mcpu=v9, not sure
<2> rationale: there is no xorg driver in debian/etch for true sparc32, so why bother with ffmpeg there
<2> not sure about unstable, I heard it would come with xorg 7.1
<4> eh maybe you can do the same for xine-lib, but i would not put the -mcpu thing on xine itself for now
<2> ok
<2> still testing your patch, this time with --disable-vis
<4> siretart, i'm asking in #gentoo-sparc right now, -mcpu=v9 is a generic so forcing it would downgrade some users
<4> i'll try working it around so that it will put it if nothing else is selected
<2> my approach was to apply it only to the object files which ***ume > 32bit registers
<4> will downgrade those for some, and break for who p***es --disable-vis
<2> so xine is still usable for sparc32 users, perhaps not when using videos requiring libmpeg2, but others ;)
<2> --disable-vis is broken anyway
<4> right now or after my patch?
<2> right now
<4> so it's worth fixing it entirely :)
<2> well, it seems its broken for libffmpeg/libavcodec/sparc only, src/libmpeg2 does 'respect' it
<4> siretart, refresh the url i gave you above, that patch adds -mcpu=v9 when vis is enabled and no other -mcpu is provided, should do what you need then
<2> just a sek, sparc is slooooow :/
<2> and still compiling :/
<4> good news, at least it didn't die already :P
<2> hi darren!
<2> Flameeyes: finally, your patch together with --disable-vis do it on debian/sparc
<4> siretart, good, i :l commit it then
<4> *i'll
<0> siretart, have you heard anything from siggi recently?
<0> ACTION is still seeing this on trying to update the website:
<0> /var/www/test
<0> ssh: cvs.sf.net: Temporary failure in name resolution
<0> cvs [update aborted]: end of file from server (consult above messages if any)
<2> _ds: he wrote anwered 2 mails on debbugs, and answer me one mail. I gave him a status update and asked him how to proceed. i'm waiting for an answer on this for over a week
<0> :-\
<2> _ds: do you have an ETA for the 1.1.2 release?
<0> Er... *should* be fairly soon, I think...
<2> as you've seen, I have already uploaded a more or less recent version to experimental
<4> siretart, i committed the vis patch now
<2> Flameeyes: cool. thanks
<2> I still wonder how to proceed with debian/sparc.
<4> siretart, thank you for spending time rebuilding it :P
<2> Flameeyes: AFAIUI, --disable-vis shouldn't harm on other archs, no?
<2> please ignore the .bzrignore ;)
<4> siretart, --enable/--disable vis is noop for non-sparc targets
<0> siretart: might be worth making sure that your packaing changes are in CVS
<2> _ds: well, I didn't want to spam xine-cvs with all my testbuilds and stuff
<2> _ds: I'd rather prefer if the debian/ dir was be removed from xine-cvs altogether
<2> or if it could be held in a separate branch
<2> which is painfull with cvs, I know
<0> Remove it from the tarball, yes. Leave it in CVS, yes. I'll agree to that.
<2> ok. then I copy 'my' debian/ dir to cvs now
<0> Eternal ffmpeg?
<0> Er, external?
<4> eternally unreleased ffmpeg :)
<0> I suppose so :-)
<4> btw i shortened the diff against original ffmpeg today, i should be able to shorten it a bit more too, but i'd like to do that with a new copy after 1.1.2 release
<2> _ds: right. in that branch, i'm running autogen on the buildds, and in experimental, I'm experimenting with using debian's ffmpeg instead of the xine-lib internal one
<4> and i'm going to force the gentoo ebuild to use external too
<2> because experimental is, well, experimental :)
<4> siretart, hope experimental has a recent enough ffmpeg :)
<2> Flameeyes: I'm using the ffmpeg package currently in debian unstable/testing, which works at least on amd64 like a charm
<0> siretart: fine, just so long as that autogen.sh invocation is removed when uploading 1.1.2...
<4> siretart, well what is that? because if it's based on the last release.. it's old
<2> _ds: why don't you want running autogen on the buildd?
<2> Flameeyes: see http://packages.qa.debian.org/f/ffmpeg.html
<0> Should only be run as needed.
<4> siretart, yeah that is newer enough i suppose :)
<2> _ds: in principle yes, but it might be that I need to modify some Makefile.am files, then I need to rerun autohell
<2> Flameeyes: Sam is very responsive of some other maintainer needs a newer ffmpeg snapshot. so no problem ehere
<0> siretart: then make sure that the new Makefile.in is represented in the .diff.
<4> _ds, bad style to patch both
<0> Hmm?
Return to
#xine
or
Go to some related
logs:
#kde
#perl
perlbop
XMLIO_ArrayElement.h
#postfix
What is GSI? ACPI
seems to be moved loop gentoo libtool
debian dvdcss2
192.168.254.255+virus
|
|