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. |
10th June 2003, 12:49 | #21 | Link | |
Registered User
Join Date: Apr 2003
Location: france
Posts: 26
|
good news
i did some tests and got beautiful results also i have some questions : - in producer log , i get: Quote:
in general , is there a way to ensure ehq is 'really' enabled ? - is <useThreads> enabled ? (should i delete this line ?) - do you think that max startup latency at 60 is a good default for encodes ? i make my tests on short files (about one minute), does it have any influence on bits distribution ?
__________________
pardon my frenglish... |
|
10th June 2003, 12:58 | #22 | Link |
retired developer
Join Date: Oct 2002
Location: Canada
Posts: 8,978
|
@Zedude
Make me a special build and I'll test
__________________
Detritus Software |
10th June 2003, 13:24 | #24 | Link |
Registered User
Join Date: Feb 2002
Posts: 1,195
|
@zedude
>the video packet size should be 16380 like i asked in the audience ? in the audience i think custom=MAXpacketsize at 16380 not the average packet size but i am not sure. >- do you think that max startup latency at 60 is a good default for encodes ? much latency is hight and must the codec can analyse the motion to made a better bit redistribution. Bye.
__________________
AutoDub v1.8 : Divx3/4/5 & Xvid Video codec and .OGG/.MP3/.AC3/.WMA audio codec. AutoRV10 v1.0 : Use RealVideo 10 Codec and support 2 Audio Streams and Subtitles. Last edited by Dark-Cracker; 10th June 2003 at 13:40. |
10th June 2003, 15:11 | #25 | Link |
Moderator
Join Date: Oct 2002
Location: Seattle
Posts: 1,584
|
Re customPacketSize : the reason this is currently needed for the codec, is to over-ride Producer's request to set it to 1352. Later this will change, and Producer will set it correctly for high bitrate VBR streams meant for download, and it will also be a Producer option. But for now, please use 16000 in the codecProperties, not 16380 (long story, this is due to a bug in old renderers, and we would like old players/renderers to work..)
Re useThreads : this is no longer needed. If you have a dual CPU, you could set useThreads to 0, but there is no advantage, it will just run slower, so this is good only for debug purposes. With regards to hyper-threaded P4s : I detect this, and actually disable threading, due to cache contention causing slightly lower performance with two codec threads on hyper-threaded systems. True dual CPU systems rock though, almost twice the speed of single CPU systems. Re Max startup latency : Maybe I will add a codec registry hack later, but the problem is the codec is too good at staying at the average bitrate, and it would rarely, if ever fill a large buffer. Perhaps only in 1-pass where it is not as good at keeping the average bitrate (yes, 1-pass sometimes actually looks better for short clips, because it spends more bits, filling the latency buffer to a higher level, but then also creating a higher bitrate larger file). We are planning to improve 2-pass VBR, so maybe there will be improvements happening in this area.
__________________
This information is provided "AS IS" with no warranties, grants no rights, and reflects my personal opinion. |
10th June 2003, 15:23 | #26 | Link | |
Registered User
Join Date: Nov 2001
Posts: 9,770
|
Quote:
is there any official codec numbering, like realvideo9.0.2, to know which version i am using... there are so many files i dont know which one is the most important to check the version number (erv43260.dll/erv4.dll ?) thanks
__________________
Between the weak and the strong one it is the freedom which oppresses and the law that liberates (Jean Jacques Rousseau) I know, that I know nothing (Socrates) MPEG-4 ASP FAQ | AVC/H.264 FAQ | AAC FAQ | MP4 FAQ | MP4Menu stores DVD Menus in MP4 (guide) Ogg Theora | Ogg Vorbis use WM9 today and get Micro$oft controlling the A/V market tomorrow for free |
|
10th June 2003, 15:24 | #27 | Link | |
RV10 Nerd
Join Date: Apr 2002
Posts: 247
|
Re: RV9-EHQ
Quote:
450kbps (386kpbs video @634x344:24fps, 64 kpbs audio) was previously just outside of what I consider 10 out of 10 video (on Japanese cartoons). But it is now firmly inside. The "stuff going on" that is in the pre-EHQ encode is not in the EHQ (complexity = 80) encode. Impressive work, karl! --- Heh, time to bug Doomie for another codec shootout |
|
10th June 2003, 15:42 | #28 | Link |
Registered User
Join Date: Apr 2003
Location: france
Posts: 26
|
ok , thank you for these answers
i 'll soon update rmfactory with this custompacketsize and keep maxstartuplatency at 25 sec as default... my tests showed me i could now encode with a lower bits/(pix*frame) value (about 0.03 less) without losing any quality and at the same time i get a better quality in high action scenes you did great work karl !!
__________________
pardon my frenglish... |
10th June 2003, 17:07 | #29 | Link |
Moderator
Join Date: Oct 2002
Location: Seattle
Posts: 1,584
|
@everyone : thanks for your comments, I am really glad you notice a difference! I am sure it is much too soon for another codec test, but Doom9's most recent test along with one from c't, were part of the reason I started this work.
@bond : I am not exactly sure what nanDub-tuning means, but this work is all in the core codec, improving its decision logic. Good idea re version information. I will change it in the DLL to read "RealVideo 9 EHQ". that way it is easier to see which version is which. Until then, you could always keep backup copies in appropriately named folders @31 Flavas : good example on where visual improvement can be found. I have a clip provided by Sirber, with foreground objects moving across a pure white background. At 350 kbps, the improvement is much higher than I had hoped for. @zedude : interestingly enough, that reduction in number of bits/pix is just about what I have noticed as well during my experiments. As an example, if I were previously using 0.18 bits/pix for a certain clip, I can now use 0.15 or even 0.145.
__________________
This information is provided "AS IS" with no warranties, grants no rights, and reflects my personal opinion. |
10th June 2003, 17:43 | #30 | Link | |
Registered User
Join Date: Dec 2001
Posts: 987
|
Re: Re: Re: RV9-EHQ
Quote:
|
|
10th June 2003, 19:17 | #31 | Link |
retired developer
Join Date: Oct 2002
Location: Canada
Posts: 8,978
|
What's the point in decompressing RMVB?
__________________
Detritus Software |
10th June 2003, 22:25 | #33 | Link |
retired developer
Join Date: Oct 2002
Location: Canada
Posts: 8,978
|
I made some tests with EHQ. Quality is deffinitly better. Image is sharper and low-bitrate encodes really needs it.
[edit] But... 4 hours is SO long!!! Would be great to optimize the encoder for 3DNOW!/3DNOW!+. 3DNow!+ : Enhanced 3DNow! Technology from AMD. The enhanced 3DNow! technology implemented in the AMD Athlon takes 3D multimedia performance to new heights and builds on the 21 instructions of AMD's original 3DNow! technology - the first x86 instruction set to use superscalar SIMD floating-point techniques. Enhanced 3DNow! adds 24 new instructions - 19 to improve MMX™ integer math calculations and enhance data movement for Internet streaming applications and 5 DSP extensions for soft modem, soft ADSL, Dolby Digital, and MP3 applications. This new DSP functionality of the AMD Athlon is not supported by the Pentium III. 3DNow!+ capable CPU AMD : Athlon Duron
__________________
Detritus Software Last edited by Sirber; 10th June 2003 at 22:41. |
10th June 2003, 23:58 | #34 | Link |
Registered User
Join Date: Oct 2002
Location: Israel
Posts: 371
|
LOL! Sirber, you're really thinking that 4 hours it's a long time? How about 20 hours just to complete the first pass.
Duration: 2:28:34 /EHQ-80/1024x436/850kbps/2-passVBR wanna guess the name of the DVD title? (A hint: "Stay with me!") Btw: Great work Karl!, thank you very much. Speed is really none important factor for me (well, almost )as long as I am getting great results. |
11th June 2003, 02:17 | #35 | Link | |
retired developer
Join Date: Oct 2002
Location: Canada
Posts: 8,978
|
Quote:
P.S. My FTP is open To all modo: I'm just joking. In fact, I have no idea what's the DVD title. "Stay with me!" can suite a lot of movies, like E.T., Home Alone and Terminator 2...
__________________
Detritus Software Last edited by Sirber; 11th June 2003 at 17:17. |
|
11th June 2003, 12:58 | #36 | Link |
RV9 Convaincu !
Join Date: Apr 2002
Location: Toulouse
Posts: 31
|
Some tests with dual AMD :
Tests done with x2real (720x304 avi source from a divX 2CD 1200 Kbits) compression at 675 Kbits complexity 65 : 75-83 % of CPU load -> 35-42 fps (a bit degraded compare from divx) complexity 80 : 92-99 % of CPU load -> 14-18 fps (no visual degradation from the divx) Very good ! <UseThread> create in .rpad from RMFactory 0.3 lock the dual mode : 50% cpu load. I delete it in my tests. EHQ at 80 use all the power of dual cpu !! cool. Before it was about 80-85 % I use X2Real to convert AVI-AVS, and easy insertion of filters and job control (but no jobsave ). RMFactory 0.3 avi option is not very intuitive. ------------------------------------------------------------------------ A7M-266 2x2XP1.77Ghz@2.4GHz 1Go RAM XP
__________________
UteamVision |
11th June 2003, 13:35 | #37 | Link |
RV9 Fan
Join Date: Jan 2002
Location: Canada, Quebec, Rimouski
Posts: 37
|
44 minutes X-File episode SVCD (org. source: DVD) -> 350 Kbits (318 video) 1-pass VBR, encoder complexity 80 @ 480 x 360: 6 hours and 10 minutes (was: 1 and a half hour at encoder complexity 65) on a Celereon 1.7 GHz with 384 MB RAM.
The result is really most impressive and pleasing to my eyes. At 65 this rate used to produce acceptably good results. The "stuff going on" in the background or out of the focus would sometimes hint at that this was a low bitrate encode but overall the quality was good enough (TV/VHS) to watch without being bothered or having a cheap messy feel to it. Now, with encoder complexity at 80, the results are really impressive: a clear, thight picture with hardly any "stuff going on". Karl really must be too much with his nose in it for him to say "I am really glad you notice a difference!" as only extremely visually impaired persons would not notice an difference :-) It's just like that: it's not a matter of bending over closely to your screen to try to figure out what, if anything, has changed - it is self evident. Well worth the extra encoding time. Ruud
__________________
"In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." |
11th June 2003, 14:34 | #38 | Link | |
retired developer
Join Date: Oct 2002
Location: Canada
Posts: 8,978
|
Quote:
__________________
Detritus Software |
|
11th June 2003, 15:40 | #39 | Link | |
RV9 Fan
Join Date: Jan 2002
Location: Canada, Quebec, Rimouski
Posts: 37
|
Quote:
Ruud
__________________
"In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." |
|
11th June 2003, 15:51 | #40 | Link |
retired developer
Join Date: Oct 2002
Location: Canada
Posts: 8,978
|
So you encodes animes... 2-pass VBR is the best for that. Still scenes are at 16kbps, and high-action scenes at >800kbps.
__________________
Detritus Software |
|
|