On Sat, 27 May 2006 13:15:29 -0500 [EMAIL PROTECTED] wrote: > It's the first time I've ever run transcode, so I was just using some > of the performance metrics I've seen in the mailing archive. ~40 felt > pretty good
Yes, _it is_ pretty good, but I expect a bit more from a dual G5 :) > when I saw lots of complaints getting more than 10 fps! Yes, me too :\ In the common case, I think the reason is lack of ASM optimization into codec (that's usually the performance killer in transcoding), and in turn I think that's usually caused by old/incomplate toolchain or by old/outdated codedc (es: *vanilla* XviD <= 1.0.x on amd64. I say vanilla since exists some patch to speedup XviD 1.0.2/1.0.3 on amd64; XviD 1.1.0 works very good natively on amd64). > Maybe we could add a benchmark page to the wiki. I'd be happy to run > benchmarks on my machine against some reference movie file if anyone > thinks that would be helpful. At minimum we could help catch > performance regressions between code changes. That's a good idea, the only problem is to find some adequate no-copyrighted source material. I'll add this to my TODO list and put something online ASAP. [...] > If I help anywhere it will be in cleaning up the command-line > switches (or documenting when/why someone would use them). My head is > still spinning from reading the man page. That's a good idea too, but we must consider that there is a fair number of frontends out there that relies on the existing transcode switches and on their stability across releases, so we must proceed slowly on this field. For example, I've just changed the -V/--use_rgb/--yuv422 switches a few days ago, with some regrets since I'm pretty sure that some frontend will be broken by this move. Anyway, previous situation was really too bad (at least for me :P), so I've taken this risk. Anyway, if you want to contribute, you're more than welcome! :) Documentation especially is always welcome. You just need to grab a fresh CVS snapshot, subscribe to transcode-devel, and if you're in doubt don't hesitate to ask! > > Changelog is already pretty huge, I'll extract only a few highlights: > > - completely rewritten aclib (low-level asm-acclerated routine > > library), > > with new optimizations for i386/amd64. Unfortunately, there is > > nothing > > for Altivec because we (current active developers) lack of hardware, > > and because I lack expertise :P > Altivec is deprecated for the Mac line anyway. U-hu, that's a really interesting news. Well, -1 things to learn =) > That changelog looks pretty serious. Does HEAD even compile and work > with all those architectural changes going on? Is there a stable branch? HEAD isn't stable. Personally I consider it somewhere between alpha and beta quality. We (active developers) take special care to let HEAD always in at least compilable state, we consider a problem if after a commit HEAD doesn't compile. Anyone can always get HEAD and give it a spin, if it like to do so ;) Anyway, I use HEAD for my everyday usage (v4l recording (and records transcoding and a few other uncommon uses), and AFAIK Andrew (the other active developer) does the same. All that I use for my everyday routine works less or more flawlessly (even here AFAIK it's the same for Andrew ;) ), but we lacks testing for obvious reasons, so HEAD can't be considered stable. Finally, it's definitevely possible that we have unvoluntary broken something on platforms/architectures on which we don't have access, like macs. So your contribute (as well as the everyone that runs transcode on macs ;) ) will be particulary appreciated :) [...] > > For interested people, there is a tarball with wavlib alone > > avalaible here: > > http://fromani.exit1.org/ > > (duh, this version is pretty outdated, I'll updated ASAP. If > > someone is > > interested just let me know so I'll speedup update process :P) > > My Powermac is big endian (PPC) so I could lend a hand with this > test. Just drop me a note here or send me a direct email. Fine. Stay tuned, I'll update wavlib snapshot ASAP and add a few testing instructions. Best regards. -- Francesco Romani - Ikitt ['people always complain, no matther what you do'] IM contact: (email-me, I have antispam default deny!) icq://27-83-87-867 some known bugs: http://www.transcoding.org/cgi-bin/transcode?Bug_Showcase
