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. |
30th June 2003, 15:07 | #242 | Link | |
easily bamboozled user
Join Date: Sep 2002
Location: Atlanta
Posts: 373
|
Quote:
I was just thinking about this because I'm having a lot of trouble trying to remove noise (from flat areas as well as mosquito noise from around detailed edges) without destroying detail, and it's proving exceedingly difficult because my source is extremely soft and dull but at the same time highly detailed. I was thinking it would be nice to be able to experiment with seperate thresholds for luma and chroma, but really it's by no means crucial. Also, if you made it have 4 threshold variables, it would be extremely cumbersome and tedious for the majority of cases where you want to use the same values for luma and chroma. You would probably want to include some kind of way to be able to use the old moderate_h/moderate_v, so that you can just give the 2 values and use them for both luma and chroma, instead of having to give 4 values even when you don't want to use seperate luma/chroma thresholds. |
|
3rd July 2003, 09:26 | #245 | Link |
Registered User
Join Date: Jun 2003
Posts: 121
|
using sparse version of idct=6
Hi all,
just a quick note: if you're building MPEG2dec3 from source code, you may try to use the "sparse" version of idct=6, by adding in global.h an: extern "C" void Skl_IDct16_Sparse_SSE(short *block); and changing line 194 of vfapidec.cpp to: idctFunc = Skl_IDct16_Sparse_SSE (note that there are MMX-only versions, too) Should work ok. I'd be curious about the speed, then... bye |
3rd July 2003, 10:14 | #246 | Link |
Moderator
Join Date: Oct 2001
Location: England
Posts: 3,285
|
Sorry skal, I forget to email you back about that. I read the email while I was away and didn't get time to reply and then it got lost in all the spam I get sent.
Ill definitely add the sparse version in the next release, which ill try to do over the weekend. Im everso short on time recently Thanks -Nic ps @all: What are the disadvantages of using DirectShowSource for MPEG-1? Speed? Why would a MPEG1Source filter be better? (Ive never used DirectShowSource for MPEG-1) |
3rd July 2003, 12:30 | #247 | Link |
Retired AviSynth Dev ;)
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
|
@Nic: DirectShow cannot do random access which makes it very painful to use in any setup. Beside that, forward seeking can be very slow.
I have tried my best to get Directshow to perform better, but API stuff is very cryptic to me. I guess a random access, audio capable DirectshowSource would solve tons of problems.
__________________
Regards, sh0dan // VoxPod |
3rd July 2003, 23:53 | #248 | Link |
Moderator
Join Date: Nov 2002
Location: Inside
Posts: 718
|
@nic:
DirectShowSource does not always provide the correct framecount for MPG1 files. Also, I'm hoping that the de-blocking and de-ringing routines in MPEG2DEC3 will work better if the file is opened natively than if you use BlindPP and DirectShow. |
5th July 2003, 20:06 | #249 | Link |
Moderator
Join Date: Nov 2002
Location: Inside
Posts: 718
|
Oh yes, one more thing: DS *often* fails to determine the framerate of mpg1 material Then you have to set it manually with the FPS= parameter, which means opening the file in vdub and find the real FPS and adding it to the script. Not a huge issue, but it is a pain in the butt.
|
6th July 2003, 22:54 | #251 | Link |
Registered User
Join Date: May 2003
Location: Germany
Posts: 502
|
pavgusb
mpeg2dec3 as well as other plugins contains sometimes the 3dnow instruction "pavgusb". Because 3dnow is from AMD, the Intel compiler, which usually generates faster code than VC++ cannot compile such plugins. It would therefore be a good idea to make the 3dnow code subject to conditional compilation such that it can be excluded when one wants to use the Intel compiler.
|
16th July 2003, 19:16 | #252 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
Please don't be mad at me about that, but I have to come back to the iDCT comparison a few pages ago. I wanted to compare their speeds on my good old AMD Duron 800. And the interesting result was: No remarkable difference between all the 7 iDCTs.
Do you see my problem here? Not yet? Well... The Duron is not capable of SSE2 instructions, so iDCT=5 should have been crashing on my Duron - but it didn't crash. Therefore now I doubt that there are really different iDCT routines used at all! Or is there a "silent fallback" to a compatible iDCT in this case? To show a different result: With CPU=6 it decoded (with a few filters) at 13.8 fps, with CPU=0 and fastMC=true at 19.4 fps. The d2v project file was made by DVD2AVI 1.76 (from an original TheWEF GKnot package) with MMX32 setting (iDCT=2), the test was running after a fresh install on Win2K with AviSynth 2.5.2 from the current GKnot 0.28.5 package. Last edited by LigH; 16th July 2003 at 19:18. |
16th July 2003, 22:04 | #254 | Link |
Moderator
Join Date: Nov 2002
Location: Inside
Posts: 718
|
@LigH - If you are testing iDCT speed, don't use any filters or CPU settings. Only set your iDCT. You are not trying to test a Real World scenario. You are testing the raw iDCT speed ONLY.
The difference between some iDCT's will be small and trying to use filters or postprocessing could *easily* overwhelm the difference, thus making different iDCT's look equally fast. @all - Does anyone use FastMC? Is there an advantage to using it? The doc itself says not to use it.... |
16th July 2003, 23:15 | #255 | Link |
Moderator
Join Date: Oct 2001
Location: England
Posts: 3,285
|
The fallback probably isn't that silent Try loading dbgview and see whats spat out knowing me...probably something
Yup they do work, but there isn't much difference, its only slight. especially on a duron 800...you're not going to notice much....No full SSE and no SSE2. -Nic |
17th July 2003, 03:09 | #256 | Link |
Registered User
Join Date: Oct 2001
Location: Gainesville FL USA
Posts: 2,092
|
I thought a Duron could handle at least SSEMMX. Are there normal integer SSE instructions it can't handle?
- Tom
__________________
My video filters (still) at www.trbarry.com. |
17th July 2003, 05:46 | #257 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
@ Cyberia:
Of course, when comparing iDCTs, I try to use as few additional "brakes" as possible. Those two examples came from a different short comparison, that's just why I told that... _ @ trbarry: SSEMMX shall be supported. And of course, I could have tried DebugView, I just have no experience with it yet. I hope I will gain some that I can report more details - I'll answer soon... _ @ all: I know that the iDCT alone won't make much difference compared to other parts of the decoding process; but almost no measurable at all?! Wow - then I wonder why some people made such an effort in ancient MPEG2AVI and Flask/Xmpeg times: In those times it must have been important to chose one (I can remember a range between 4 and 23 fps in Xmpeg), but in MPEG2DEC3 they all must have been optimised to the hilt - and that's really remarkable on your programming efforts! Therefore, thanks to all you developers for your great work! _____ P.S.: Not as much output as expected. AVS code: Code:
LoadPlugin("H:\Programme\GordianKnot.new\mpeg2dec3.dll") mpeg2source("N:\Movies\Trailer\Mortal_Kombat_2\trMK2.d2v", CPU=0, fastMC=true) Code:
00000000 07:29:59.520 [1016] mmmmmm 00000001 07:30:15.884 [1016] Overiding iDCT With: 1 00000002 07:30:23.505 [1016] Overiding iDCT With: 3 00000003 07:30:26.759 [1016] Overiding iDCT With: 4 00000004 07:30:29.604 [1016] Overiding iDCT With: 5 00000005 07:30:32.177 [1016] Overiding iDCT With: 6 00000006 07:30:35.141 [1016] Overiding iDCT With: 7 Last edited by LigH; 17th July 2003 at 06:36. |
26th July 2003, 14:19 | #259 | Link |
Moderator
Join Date: Oct 2001
Location: England
Posts: 3,285
|
Urgh! Just realised that Marc took out Luminance_Filter from MPEG2Dec3, so it pays no attention to the luminance controls in the d2v file. Id never noticed that. Im gonna fix it and put up a new version.
Just trying to remember whats on my todo list: I think ill just fix the luminance filter, add skal's idct properly and then test the speed with an ICL 7.1 and a MSVC .net and release the fastest. Be back later, -Nic |
26th July 2003, 14:36 | #260 | Link |
IUUULEEEENZ
Join Date: Mar 2002
Location: Italy
Posts: 452
|
Just a little request (if you want to do it). Could you add some optimizzations for 3dnow processors (Athlon, AthXP)? Maybe a SSEMMX3DNOW IDCT or something like that. I'm sure that many users will appreciate them.
PS: I know that Intel Compiler doesn't support them. I don't know anything in programming ... maybe another compiler should do it
__________________
PC1:AMD Athlon II x4, 4GB DDR2, Ati Radeon 4830, 4 hard disks |
|
|