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.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 10th June 2003, 12:49   #21  |  Link
zedude
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:
PID828,Informational,SDK Encoding,2003/06/10 01:22:32,15004,Starting analysis pass
PID828,Diagnostic,Video Codec,2003/06/10 01:22:32,20049,Setting video packet size to 1352
the video packet size should be 16380 like i asked in the audience ? i think i'm wrong somewhere but don't know where
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...
zedude is offline   Reply With Quote
Old 10th June 2003, 12:58   #22  |  Link
Sirber
retired developer
 
Sirber's Avatar
 
Join Date: Oct 2002
Location: Canada
Posts: 8,978
@Zedude

Make me a special build and I'll test
__________________
Detritus Software
Sirber is offline   Reply With Quote
Old 10th June 2003, 13:11   #23  |  Link
zedude
Registered User
 
Join Date: Apr 2003
Location: france
Posts: 26
@sirber : you just have to edit video audience and change maxstartuplatency value...you know i'm lazier than you
__________________
pardon my frenglish...
zedude is offline   Reply With Quote
Old 10th June 2003, 13:24   #24  |  Link
Dark-Cracker
Registered User
 
Dark-Cracker's Avatar
 
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.
Dark-Cracker is offline   Reply With Quote
Old 10th June 2003, 15:11   #25  |  Link
karl_lillevold
Moderator
 
karl_lillevold's Avatar
 
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.
karl_lillevold is offline   Reply With Quote
Old 10th June 2003, 15:23   #26  |  Link
bond
Registered User
 
Join Date: Nov 2001
Posts: 9,779
Quote:
Originally posted by karl_lillevold
2) all my work on RV9-EHQ is actually in the codec itself. It's all about the codec making more optimal encoding decisions, without changing the format of the bitstream. The resulting bitstream can then be played back in existing decoders. There are also improvements in Producer, but these are feature and system related. So to summarize: the RV9-EHQ changes live in the encoder codec which is part of Helix Producer, but produces RV9 bitstreams that are backwards compatible with existing RV9 decoder codecs.
so all the work on the improvement of the codec quality is done in the codec itself (so nothing like nandub-tuning?)...

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
bond is offline   Reply With Quote
Old 10th June 2003, 15:24   #27  |  Link
31 Flavas
RV10 Nerd
 
Join Date: Apr 2002
Posts: 247
Re: RV9-EHQ

Quote:
Originally posted by karl_lillevold

Will the improvement be worth the slower encoding speed?
Yes! At least in my humble opinion.

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
31 Flavas is offline   Reply With Quote
Old 10th June 2003, 15:42   #28  |  Link
zedude
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...
zedude is offline   Reply With Quote
Old 10th June 2003, 17:07   #29  |  Link
karl_lillevold
Moderator
 
karl_lillevold's Avatar
 
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.
karl_lillevold is offline   Reply With Quote
Old 10th June 2003, 17:43   #30  |  Link
RadicalEd
Registered User
 
Join Date: Dec 2001
Posts: 987
Re: Re: Re: RV9-EHQ

Quote:
Originally posted by slavickas
with new producer it is possible output to raw yuv file, and probably Karl have spme self-made tools
hey yeah, speaking of this, is there a better way than EO Video to decompress RealVideo stuff :|
RadicalEd is offline   Reply With Quote
Old 10th June 2003, 19:17   #31  |  Link
Sirber
retired developer
 
Sirber's Avatar
 
Join Date: Oct 2002
Location: Canada
Posts: 8,978
What's the point in decompressing RMVB?
__________________
Detritus Software
Sirber is offline   Reply With Quote
Old 10th June 2003, 19:22   #32  |  Link
slavickas
I'm Shpongled
 
slavickas's Avatar
 
Join Date: Nov 2001
Location: Lithuania
Posts: 303
Quote:
Originally posted by Sirber
What's the point in decompressing RMVB?
maybe burning as (s)vcd? and that's all i can think
slavickas is offline   Reply With Quote
Old 10th June 2003, 22:25   #33  |  Link
Sirber
retired developer
 
Sirber's Avatar
 
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.
Sirber is offline   Reply With Quote
Old 10th June 2003, 23:58   #34  |  Link
Ramirez
Registered User
 
Ramirez's Avatar
 
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.
Ramirez is offline   Reply With Quote
Old 11th June 2003, 02:17   #35  |  Link
Sirber
retired developer
 
Sirber's Avatar
 
Join Date: Oct 2002
Location: Canada
Posts: 8,978
Quote:
Originally posted by Ramirez
wanna guess the name of the DVD title? (A hint: "Stay with me!")
[censored]

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.
Sirber is offline   Reply With Quote
Old 11th June 2003, 12:58   #36  |  Link
nah
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
nah is offline   Reply With Quote
Old 11th June 2003, 13:35   #37  |  Link
DaWolf
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."
DaWolf is offline   Reply With Quote
Old 11th June 2003, 14:34   #38  |  Link
Sirber
retired developer
 
Sirber's Avatar
 
Join Date: Oct 2002
Location: Canada
Posts: 8,978
Quote:
Originally posted by DaWolf
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.
Always do a 2-pass VBR. Quality will be better and you won't spend too much bits on useless places.
__________________
Detritus Software
Sirber is offline   Reply With Quote
Old 11th June 2003, 15:40   #39  |  Link
DaWolf
RV9 Fan
 
Join Date: Jan 2002
Location: Canada, Quebec, Rimouski
Posts: 37
Quote:
Originally posted by Sirber
Always do a 2-pass VBR. Quality will be better and you won't spend too much bits on useless places.
Yeah indeed, if time is an issue it's usually better to do a CBR. My reasoning for doing 1-pass was the idea that if I set the peak high action scenes get a bit smoother. The X-Files are quite static; lot of walking, standing, talking. But once in a while they chase someone or wrestle someone to the floor and I figured (1-pass) VBR would give it some extra leeway. I wouldn't mind having a CBR setting where I can adjust how much it will go over the CBR when it encounters (too much) movement. As it is the normal leeway in CBR doesn't hold up to sudden movements.

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."
DaWolf is offline   Reply With Quote
Old 11th June 2003, 15:51   #40  |  Link
Sirber
retired developer
 
Sirber's Avatar
 
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
Sirber is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 16:10.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.