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. |
25th May 2003, 12:53 | #101 | Link | |
Guest
Posts: n/a
|
Quote:
|
|
25th May 2003, 13:01 | #102 | Link |
Newbie Forum Mod
Join Date: Aug 2002
Location: way too deep in (cyber)space
Posts: 2,436
|
thanks for the clarification.
i'm probably going to do some speed test soon, right now i don't have any time for it though. thanks for your great work steVe
__________________
Search the forum, read the forum rules once more and use the search function on doom9.org before posting! oh btw my amazon.de wishlist |
25th May 2003, 16:30 | #103 | Link |
Retired, but still around
Join Date: Oct 2001
Location: Lone Star
Posts: 3,058
|
NIc, could you verify from reading the code that:
1> Manual entry of idct in mpeg2source line always overrides a Def file idct entry. 2> If multiple DEF files exist, such as in working dir, plugin dir and/or a dir in which a loadplugin is directed to, which DEF file will be used? [I assume the loadplugin dir] I am learning to never assume the obvious, hence the question. As always, a big thanks for this work to you and Tom. |
25th May 2003, 17:58 | #104 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 4,926
|
@ Nic Trbarry and Shodan
absolute great work you do here are my Speed and Size results PSNR results based against idct2 coming soon nullspeed in XviD was used XviD itself used SimpleIDCT Test Sequence is a 1501 frame 640x480 capture @ 25 fps DVB for size test encoded @ q2 no other features Simple Profile System: Still my good old P4 1.8 Williamete Code:
idct1=compression time 00:01:55.756 (12.97fps) 38,2 MB (40.080.896 bytes) idct2=compression time 00:01:55.748 (12.97fps) 38,2 MB (40.080.896 bytes) idct3=compression time 00:01:58.076 (12.71fps) 38,3 MB (40.178.176 bytes) idct4=compression time 00:02:14.946 (11.12fps) 38,3 MB (40.197.120 bytes) idct5=compression time 00:01:52.496 (13.34fps) 38,2 MB (40.080.896 bytes) idct6=compression time 00:01:55.920 (12.95fps) 38,2 MB (40.129.536 bytes) idct7=compression time 00:01:55.783 (12.96fps) 38,1 MB (39.989.760 bytes) Code:
idct1=106.0153 idct2=106.0153 same as (infinite) no difference idct3=58.5690 idct4=58.4507 idct5=106.0153 idct6=59.1600 idct7=58.4504 idct3,4,6 and 7 show major differences where idct6 is the nearest to idct1 and idct7 is the farthest if you do some fuzzy logic you could say that the one with the biggest size is the best quality wise and the one with the smallest the badest but this must not be the true have to do more research to compare them in a more mathematical way could maybe somebody help here ? Last edited by CruNcher; 25th May 2003 at 20:25. |
25th May 2003, 20:22 | #107 | Link | |
Registered User
Join Date: Oct 2001
Location: Gainesville FL USA
Posts: 2,092
|
Quote:
- Tom edit: What I should have done if not so lazy is on errors return a copy of the previously decoded good frame. Last edited by trbarry; 25th May 2003 at 20:24. |
|
25th May 2003, 21:17 | #108 | Link |
Moderator
Join Date: Oct 2001
Location: England
Posts: 3,285
|
@CruNcher:
Thanks loads for those tests Dont understand why skal's was slightly slower...Oh well, good to have for completeness. Looks like SimpleiDCT might be useful-ish though Very interesting second results, idct=7 should be more accurate than idct=2 (idct=2 is almost exactly what XviD used to use (intel one with peter gubanovs changes)). Therefore it appears the difference between there output is quite large ? Or am I misreading the results? @Tom: SimpleiDCT uses permutated data as its input, (its all in the new file idctnew.cpp (or newidct.cpp, I forget which). Meaning it goes through a little "for" loop to begin with? Is that easy to speed up with assembly or should the compiler already be doing a pretty good job? @Blight: If you have a stream thats corrupt when using mpeg2dec3.dll and can upload a little bit, I can try and work on it. Otherwise it might be quite difficult for me to fix anything. @DDogg: In my best homer simpson voice: "I don't know". Ill have to look that up myself. I didn't really like all the override code in there so I tried to ignore it. But ill check and post back. Cheers, -Nic |
25th May 2003, 23:24 | #109 | Link | |
Registered User
Join Date: Oct 2001
Location: Gainesville FL USA
Posts: 2,092
|
Quote:
I'm not sure yet if there are mmx games that would go faster yet. But there probably are. - Tom edit: (after further head scratching) ... It would probably be faster yet if the wrapper was not called at all. Instead modify Simple_idct to rearrange the parms onto the stack. Also the idct could probably be changed to just output the values into the correct place so you didn't have to copy them again on the way back. It looks like there is a simple output pointer in edx that could be changed about half way through and the values do not have to be rearranged on output. But I won't be able to do this soon myself. Last edited by trbarry; 26th May 2003 at 00:01. |
|
28th May 2003, 05:48 | #110 | Link |
Anime Team!
Join Date: Jan 2002
Location: JulyCity
Posts: 280
|
a Noob question....
If I have an Athlon XP (so, no sse2) and choose the iDCT = 5 (for P4) what iDCT is used?... this will crash? (I write this because this not crash my cpu) When I run DebugView it only say "Overiding iDCT With: 5" and the encoding process is ok, strange I think BTW Nic,Tbarry,sh0dan Thanks for the new Toys
__________________
Old time lurker |
28th May 2003, 07:24 | #111 | Link |
Registered User
Join Date: Sep 2002
Location: Seattle
Posts: 551
|
I used idct=5 by mistake on my Athlon XP. Worked fine. I suspect it does a CPUID and when it fails to see SSE2, doesn't use SSE2 featurettes. It may revert to whatever your CPU is capable of, e.g. idct=2.
UNLESS the override code is incorrect and not working. In which case, we're probably all using idct=2 without knowing it. By the way, where can I find the override definition file? That's my preferred method of overriding; I don't like to tweak the commandline because then it's one more thing my frontend can't do for me with absolutely zero invervention. Last edited by JohnMK; 28th May 2003 at 07:38. |
28th May 2003, 07:47 | #114 | Link |
Moderator
Join Date: Oct 2001
Location: England
Posts: 3,285
|
Where did I say that? And it depends what you mean by override. If you mean the idct you set in the mpeg2source line then that definitely works...but as for the .def file, I honestly cant be sure because I havent tested that bit, nor did I change any of that code, so I just "assume" it works
-Nic |
29th May 2003, 09:15 | #117 | Link |
n00b ever
Join Date: May 2002
Posts: 627
|
default parms?
dear devels!
would anyone take care of the description of the plugin? there's one included but (imho) it's outta date. e.g. it says def.idct=0(=read from d2v). would any of u list the available parms & their default values? i'm esp interested in moderate_h/v as it seems to be always on & i'm getting more&more convinced that it's responsible for some strange artifacting on decoding. i've been unable to figure out (from the readme) how to switch it off safely. thx y Last edited by yaz; 29th May 2003 at 09:38. |
29th May 2003, 10:44 | #119 | Link | ||
n00b ever
Join Date: May 2002
Posts: 627
|
nic :-)
Quote:
Quote:
anyway, right now i'd be sufficed with the trick of swiching off moderate_h/v safely. what's the way of doing it? btw, is it operable at all? thx y ps. i use this filter with pleasure&success (thx for your efforts!) but at a moment it's occured to me whether i know what am i doing xactly :-) |
||
29th May 2003, 11:10 | #120 | Link |
Moderator
Join Date: Oct 2001
Location: England
Posts: 3,285
|
The .html is upto date and correct. I didn't like the .def file mainly because people would include it with the .dll and not realise that any changes in there would always override the d2v file etc.
(And it just confused matters...you can just use an old .def file if you wish. But I do not support its use) The moderate_v & moderate_h aren't turned on unless you turn on post-processing. They are the variables that control the strength of post-processing (exactly the same as they are in my XviD DShow filter). -Nic |
Thread Tools | Search this Thread |
Display Modes | |
|
|