Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
7th June 2010, 07:27 | #1541 | Link | ||
RedDwarf Fan
Join Date: Jun 2005
Location: United Kingdom
Posts: 198
|
I'm interested in purchasing a nVidia card so I can use DG NV Tools after having great difficulty decoding BBC HD video using software methods. I have a HD3850 512MB video card currently where the cards idle power consumption was an important thing when I decided to purchase it. ATI latest cards do use less power than nVidia, probably due to AMD's CPU design experience, it's not a myth like I have seen mentioned. It's a pity that ATI doesn't get it's act together and provide a means to program for it's GPU's like nVidia does.
Seeing as there is no ATI GPU assisted decoder for AVISynth and there seems like very little chance of one being produced, I have decided to add a nVidia card as a 2nd Video card in my PC and the card needs to have very low idle power consumption but provide good decoding capabilities. I have read through most of this thread and a large part of the NV Tools development notes and nVidia correspondence and seen people asking about the decoding performance of various cards and seen no definitive guide to allow people to decide which card to purchase. Really doing such tests requires the same PC setup and multiple nVidia cards which people do not usually have access to. nVidia are really the people who could provide such information but it's whether their figures could be trusted. Does anyone know of any figures to indicate the performance of various nVidia cards, especially when de-interlacing 1080i content? What type of performance could I expect from a GT 240 DDR5 512MB/1GB card? I would be particularly interested in decoding figures from such a card. Quote:
GPU Resizing would also be of interest providing the quality was good. How does it compare to Spline36resize or Spline64resize? Quote:
Would I experience any difference between 512MB and 1GB of onboard memory? How would 1GB benefit me over a 512MB card? Are there any restrictions on the number of H264 streams that can be opened at the same time? Can it open 2 or 3 different streams and process all at the same time in one AVISynth script? http://en.wikipedia.org/wiki/Purevid...n_PureVideo_HD nVidia Card Feature table Video card Power Usage |
||
7th June 2010, 13:21 | #1542 | Link | ||||
Guest
Join Date: Jan 2002
Posts: 21,901
|
Quote:
Quote:
Quote:
Quote:
|
||||
7th June 2010, 17:10 | #1544 | Link | |
Registered User
Join Date: Sep 2006
Posts: 82
|
Quote:
But I do know about their 3/2 lockdowns (we'll probably get them again for the duration of the world cup) but in the case in question it was really 2/0. |
|
7th June 2010, 23:11 | #1545 | Link |
Registered User
Join Date: Apr 2009
Posts: 57
|
@RedDwarf1 regarding GPU processing quality, and for who ever asking himself the same questions.
I can only give my subjective impressions, but I've done quiet a bit of video encoding since 2002.. * Resizing: DG NV tools are aimed mainly at HD content. In that case, resizing, if any, means downscaling. Bilinear will do a great job here. Actually, when it comes to downscaling, almost every algo is a champ. I am very satisfied with what CUDA does here. And bilinear is quiet good at upscaling too, although I did it only once with CUDA. * De-interlacing: when the source is clean, I get great de-interlacing with DG NV. However. I'm encoding a TV show DVD right now (NTSC), and was not satisfied with what CUDA does here. But it's comparable to what I get from a "professional" software player (TotalMedia Theatre 3, "hardware acceleration" disable), so, can I really blame CUDA?! What I know, is that I get a better looking image with VLC de-interlacing (blend), and an amazing result in AviSynth with eedi2/tdeint (I can post examples if you want, but basically, all lines are straight and smooth with no "stairs" effect with eeid2/tdeint). Of course, I pay dearly for this quality on the CPU level.. (2.65 fps is brutal, but my x264 options are pretty wild, too ) * Cropping: don't buy CUDA for this! Cropping is so cheap, it almost makes no difference if you do in CPU or GPU.. But if you can make your GPU do it, why the heck not?! * Memory: this is the topic that brought me to this forum. I have a 256MB 8600 GT (I'm anti-gamer, is you wish), and that's worth 1 1080p stream. I can do up to 3 720x540 standard def concurrent instances, barely. This doesn't mean these numbers scale up linearly with memory quantity, though.. it just gives a hint: if you go for it, go heavy on the DDR! Other testimonials would definitely shed some more light on this specific topic Cheers. WasF/ |
8th June 2010, 03:52 | #1547 | Link |
Registered User
Join Date: Apr 2009
Posts: 57
|
Of course, neuron2 .. some features go hand in hand, indeed.
Still, you can do cropping alone on the GPU. And I don't see where the obligation to GPU-crop comes from if I do resizing: I've been doing DGMultiSource(resize_w=720, resize_h=540) for 6 episodes now, with no cropping, and it works just fine (DGI: CLIP 0 0 0 0) and I don't see what would be illegal if I added an Crop() to my AviSynth script on top of that, too.. You got me worried now! If you'd care to elaborate, I'd be curious to know what I'm missing.. |
8th June 2010, 10:50 | #1550 | Link |
Registered User
Join Date: Apr 2009
Posts: 57
|
Oh! I got it, I got it!
Yes, if you do GPU resizing and need cropping, it would be much easier and safer to do it all in GPU. I was more thinking technical limitation or somethin' .. Believe it or not, the first time I used DG NV tools, it was for re-encoding Avatar, and I did resizing with CUDA and a bit of cropping in the AVS script ('Never understand the 8 Mbs/s thing! What was H.264 for, again?!!) |
9th June 2010, 01:33 | #1551 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Status report on 64-bit support
I have just run DGIndexNV built for x64 for the first time! It's working great. And it's very fast on my i7-980X overclocked to 4.2 GHz.
The major challenge was the color conversion and display routines. In DGIndexNV x32 I use a simple C loop to unpack CUVID's NV12 to planar YV12 and then compiler intrinsics for an asm implementation of YV12 to packed RGB for display via Windows GDI (as implemented in the CUVID Client). But those intrinsics are not available on x64. (The code in DGIndex [the open source one] of course uses 32-bit asm files. Those would have to be recoded but can't be used in any case due to GPL.) So I wrote a high-performance pure C implementation of YV12 to RGB using lookup tables. This conversion is actually a little faster than the one in the current x32 version. I spent all day making the needed revisions to the cropping and save BMP utilities to make them work with the new conversion code. The source filters should be easy as there is no asm code in them. So who will tell me where to get the latest and most stable x64 version of Avisynth? Can it coexist with the x32 version? Last edited by Guest; 9th June 2010 at 01:39. |
9th June 2010, 05:18 | #1552 | Link |
Registered User
Join Date: Nov 2003
Posts: 1,281
|
http://forum.doom9.org/showthread.php?t=152800 Set's version. Runs fine with 32bit version installed, and actually needs the 32bit installed for the registry pointers.
Oh, and I'll happily beta test with you.
__________________
http://www.7-zip.org/ |
9th June 2010, 07:32 | #1553 | Link |
ZZZzzzz...
Join Date: Jan 2007
Location: USA
Posts: 303
|
Unfortunately, I don't believe there is an official x64 build of Avisynth. In addition to JoshyD's build (listed above), Squid_80 has a x64 build of Avisynth as well as precompiled plugins here. As to which one is more stable, I would say neither are as stable as the official x86 build; however, if you forced me to pick one, I would probably recommend JoshyD's build. Hopefully IanB will get inspired and come up with an official x64 build sometime this year.
|
9th June 2010, 08:14 | #1554 | Link |
Registered User
Join Date: Nov 2003
Posts: 1,281
|
Squids build is about 3 years old iirc.
__________________
http://www.7-zip.org/ |
9th June 2010, 11:52 | #1555 | Link |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,542
|
Neuron, would you implement an auto/manual crop interface in DGIndex? Staxrip and other gui's sometimes lose a lot of time in cropping procedures. It could be glad to have the possibility to get it before.
(nice english today, I must have temperature)
__________________
@turment on Telegram |
9th June 2010, 14:48 | #1556 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Please provide specs for the functionality you want. I ask because it's not obvious to me. For example, say I have a letterboxed movie and cropping away just the black leaves a certain non-mod (4, 8, 16) vertical size. Should I overcrop to enforce mod? What frame(s) should be used for the calculations? Etc. I have never used autocrop so if you want this you have to be really clear about what you want.
|
9th June 2010, 15:38 | #1557 | Link |
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,259
|
I normally do something a long the lines of:
1. allow user to specify: - threshold 0/16/32 (= color value that will still count as black) - mod the output should have after cropping (2/4/8/16) 2. analyse 500 frames from the source: - e.g. take every framecount/500 frames a frame - if source is < 500 frames analyse all - if seeking is an issue skip the first framecount/10 frames then analyse 5 frames skip 100 frames until you got 500 (if source is too short for this, lower frames to skip) - drop results where width or height more than halves - from the results take the crop values from the frame with the larges non black area 3. adjust crop values to mod - overcrop to archive the output mod the user wanted Cu Selur |
9th June 2010, 22:15 | #1558 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Thanks, Selur.
My first test runs into problems. I have a 16 level black bar but as it approaches the video it gets lighter (due to encoding). It's hard to pick a threshold because some of the pixels are 46 and higher but still in the bar. Do you just get close and then hope the mod operation finishes the job? If so, it seems very unrobust. |
10th June 2010, 00:00 | #1560 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
That's too complicated, but thanks for the suggestion. With a decent fixed threshold (32) and enforcing the mod (and fixing the bug I had) I get acceptable results.
I've added the feature for the next release with a threshold of 32 and mod 4/8/16. It operates on the frame that is displayed when the cropping dialog is entered. I'll tweak it further as needed. |
Thread Tools | Search this Thread |
Display Modes | |
|
|