RV9 or XVID for a DVD-rip? [Archive]

Sgt_Strider

13th December 2002, 04:35

Hi, recently reading the latest threads in this forum and the xvid forum, I am a bit confuse in which codec to use for compressing my dvd rips. I am planning to use the default NTSC DVD resolution which is 720x480. Quality is a top priority over size but its debateable and my bitrate is somewhere between 1500-1800kb. For XVID I would be using q-pel and b-frames. Not sure what I can use in RV9 though but I would expect it to be without b-frames and q-pel. Anyway I read that XVID is good for high bitrate and RV9 for low bitrate but then some ppl claim that its really good. Anyway sorry for my bad grammar, I'm just quickly trying to jot down what's in my head right now. Thx

-h

13th December 2002, 04:58

It depends on what you want to do with it in the future.

I would first suggest encoding a sequence from your source with several codecs - RV9, XviD, DivX, whatever, just so you see how they perform at the bitrate you want.

Then:

- If you will always store and play the video from your computer, use the format which performed best in your test.
- If you would like to some day play the video on a standalone unit, use XviD (the most likely to be hardware supported due to DivX-related bugs)
- If you want to keep the video for a long time, use XviD (again a standards issue)
- If you don't care about any of these points, again use whichever format looked best in your test

-h

Sgt_Strider

13th December 2002, 05:42

Originally posted by -h
It depends on what you want to do with it in the future.

I would first suggest encoding a sequence from your source with several codecs - RV9, XviD, DivX, whatever, just so you see how they perform at the bitrate you want.

Then:

- If you will always store and play the video from your computer, use the format which performed best in your test.
- If you would like to some day play the video on a standalone unit, use XviD (the most likely to be hardware supported due to DivX-related bugs)
- If you want to keep the video for a long time, use XviD (again a standards issue)
- If you don't care about any of these points, again use whichever format looked best in your test

-h

Well I'm thinking about putting the files in a file server that is in within my LAN. I want to be able to stream the file from the server to my computer. Anyway I really don't want to use XVID until xvid 1.0 comes out. The funny thing is that koepi said that there may never be xvid 1.0. What do he mean by that? Is there a possibility that we're only going to see q-pel and b-frames in the developmental versions?

-h

13th December 2002, 06:19

Well I'm thinking about putting the files in a file server that is in within my LAN. I want to be able to stream the file from the server to my computer.

Pretty much anything you choose can be streamed.

Anyway I really don't want to use XVID until xvid 1.0 comes out. The funny thing is that koepi said that there may never be xvid 1.0. What do he mean by that? Is there a possibility that we're only going to see q-pel and b-frames in the developmental versions?

Why 1.0? What happens then?

XviD may never reach 1.0 because version numbers are actually meaningless, all they tell you is that something is newer (not necessarily better, faster, more stable, etc.).

I would approach XviD with a set of goals to perform the job at hand - is it stable, does it conform to the MPEG-4 spec, is it fast, does the output look good, etc.. The version number has nothing to do with any of those points, which is why I ignore version numbers on pretty much everything I use. Sure a version number may lend some weight to the notion that it's better than what came before, but that's often not the case.

-h

Hiro2k

13th December 2002, 07:02

I think he meant that a version 1.0 would mean that all the stuff in the DEV builds now will have been bug tested and added to the official release. Correct me if im wrong Sgt_Strider.

But i agree with you -h. Version numbers have nothing to do with how good a program really is.

Sgt_Strider

13th December 2002, 07:40

Originally posted by -h
Well I'm thinking about putting the files in a file server that is in within my LAN. I want to be able to stream the file from the server to my computer.

Pretty much anything you choose can be streamed.

Anyway I really don't want to use XVID until xvid 1.0 comes out. The funny thing is that koepi said that there may never be xvid 1.0. What do he mean by that? Is there a possibility that we're only going to see q-pel and b-frames in the developmental versions?

Why 1.0? What happens then?

XviD may never reach 1.0 because version numbers are actually meaningless, all they tell you is that something is newer (not necessarily better, faster, more stable, etc.).

I would approach XviD with a set of goals to perform the job at hand - is it stable, does it conform to the MPEG-4 spec, is it fast, does the output look good, etc.. The version number has nothing to do with any of those points, which is why I ignore version numbers on pretty much everything I use. Sure a version number may lend some weight to the notion that it's better than what came before, but that's often not the case.

-h

There is some thread in the xvid forum saying something about the latest developmental version isn't mpeg 4 iso compatible? I want to be able to use AAC with the xvid video but if its not compatible then there's no point to use xvid right now unless I use the stable version, but I don't think there is q-pel and b-frames enable.

-h

13th December 2002, 07:55

There is some thread in the xvid forum saying something about the latest developmental version isn't mpeg 4 iso compatible? I want to be able to use AAC with the xvid video but if its not compatible then there's no point to use xvid right now unless I use the stable version, but I don't think there is q-pel and b-frames enable.

I haven't tested it personally. Perhaps a feature is being used that is known to have problems (i.e. QPel). The only way to be sure is to encode something and try playing it with msfdam or Envivio - if you have to resort to the stable version to get something working, who's to say that it won't still perform well in your test? And who's to say that QPel will even give you a better encode? It has performed poorly for me in several tests, so I see no reason to use it until further optimisations are added some time in the future.

-h

Sgt_Strider

14th December 2002, 00:43

Originally posted by Hiro2k
I think he meant that a version 1.0 would mean that all the stuff in the DEV builds now will have been bug tested and added to the official release. Correct me if im wrong Sgt_Strider.

But i agree with you -h. Version numbers have nothing to do with how good a program really is.

Hiro2k that's exactly what I mean, all of the features in the developer's build have been tested and added to the official release.

OUTPinged_

17th December 2002, 07:17

Anyway I really don't want to use XVID until xvid 1.0 comes out.

-h, that thread just proves how much all those new people care about version numbers.

It could be wiser to release that 0.9 as 1.0 imo, just to make them use it for their initial tests.

31 Flavas

17th December 2002, 08:25

Originally posted by Sgt_Strider

I am planning to use the default NTSC DVD resolution which is 720x480. Quality is a top priority over size but its debateable and my bitrate is somewhere between 1500-1800kb. Quality wise speaking, karl just posted a thread about being able to do anamorphic playback of your encodes if you choose RV9. That is something, correct me if wrong, that none of the other players/encoders can do.

It's free extra quality (if the dvd is anamorphic encoded) and should show off well at the bitrate you're targeting.

ChristianHJW

17th December 2002, 10:49

Originally posted by 31 Flavas karl just posted a thread about being able to do anamorphic playback of your encodes if you choose RV9. That is something, correct me if wrong, that none of the other players/encoders can do.

XviD Team is already looking into this, the new XviD API 3 already suports custom AR flags, its just that no encoding tool or editor would allow setting the flag accordingly, and there are no Dshow filters making us of the flag.

milan was talking about the issue in a thread in XviD forums, search for threads with the word 'anamorphic' in the title .. its not at all trivial because due to the way DirectShow is building a playback graph milan's filter would need the info about the correct AR before negotiating with the AVI parser and video renderer, so he said the flag must be copied somewhere in the AVI header so he can read it and resize accordingly.

Not necessary to mention anymore ( i really said it often enough ) that this problem will be solved finally once my beloved baby will be born ;) ...

OUTPinged_

17th December 2002, 10:57

for 1500 bitrate he even can ran into movies where sub-640x resolution will be needed.

I think if you will make right preprocessing setup (ivtc, denoise, right resolution, crop, good audio settings), you will get good results with both codecs.

RV9 will look less ugly if you will fail at that task and XVID will shine in case you will succeed.

choices choices.

karl_lillevold

18th December 2002, 00:28

amirm

25th December 2002, 02:58

Originally posted by 31 Flavas
Quality wise speaking, karl just posted a thread about being able to do anamorphic playback of your encodes if you choose RV9. That is something, correct me if wrong, that none of the other players/encoders can do.

It's free extra quality (if the dvd is anamorphic encoded) and should show off well at the bitrate you're targeting.

Windows Media Player and Encoder/SDK Verison 9 support encoding of any aspect ratio. The ratio can be entered at encoding time and the player will use that information to do the proper resizing at playback time to match the display aspect ratio. So anamorphic encoding at any aspect ratio is already supported in WMV9/WMP98.

As to it translating into "free quality", this is not exactly correct. If you encode in "widescreen" by sacrificing vertical resolution (i.e. what you see on a typical 4:3 TV), then indeed, you will get better quality. But this comes at the expense of vertical resolution. "anamorphic" encoding on the other hand, would involve encoding at the original (higher) vertical resolution on the DVD. Such a video would look wrong on a computer screen but the above aspect ratio correction in the player will compensate, resulting in proper images. However, since you are encoding more vertical lines, you will need higher bitrates to match the same qaulity of the non-anamorphic encoding.

Note that the above explanation applies to any codec, not just Windows Media Video (WMV).

Amir
Microsoft

bond

25th December 2002, 16:29

Originally posted by amirm
Amir
Microsoft

Hm does M$ (same as Real) now also send their people to doom9's forum?

RadicalEd

25th December 2002, 19:18

yep, this is quite the popular media forum. Thats thanks to doom9 and all the awesome members that make this community so outstanding. God we're cool :cool:
heheh, merry xmas :p

amirm

26th December 2002, 22:09

Originally posted by bond
Hm does M$ (same as Real) now also send their people to doom9's forum?

I can't speak for Real but we don't "send" anyone to a forum. Our people contribute to various forums they are interested in with their spare time.

I am personally pretty active on avsforum (among others) and saw a post from Nic regarding his well-done Windows Media encoder and followed him here. I found out that a lot of smart people hang around in this forum so I decided to poke my nose in once in a while -- mostly to learn but to contribute when called for. And of course, I couldn't let Karl run "open loop" without someone keeping him in check :).

Thanks,
Amir
Microsoft

bond

26th December 2002, 22:27

So let's talk about some m$ internals!

When will m$ go opensource with wm9? ;)

Nic

27th December 2002, 01:27

OT: I just downloaded the latest wm9_sdk I see it has been updated & ill update my wm9enc accordingly ;) Glad to have you Amir :)

-Nic

karl_lillevold

1st January 2003, 17:30

Originally posted by amirm
I can't speak for Real but we don't "send" anyone to a forum. Our people contribute to various forums they are interested in with their spare time
Just to make sure : no one "sent" me here either. I was reading the forum for its interesting discussions and encoding tips. Then I noticed there were a a lot of RV9 discussions, including a few false rumors and misconceptions, and wanted to try to contribute some of my experience. This is for my own interest and in my spare time, although I do forward relevant information and feedback to the rest of the (small) codec group at RealNetworks.

I am so lucky I get to work with what is my main interest, which is video compression. If RealNetworks had not paid my salary, I would probably have worked within the same field for another company, or spent a huge amount of my spare time on the same topic.

Sgt_Strider

1st January 2003, 22:31

Hey Karl, do you happen to have a formula in calculating the bitrate for encoding with RV9 or a program to? There is a guide that mentions using gknot for calculating the bitrate but I don't think it was design for use with RV9 but rather XVID and DivX 5.

karl_lillevold

1st January 2003, 23:52

Originally posted by Sgt_Strider
Hey Karl, do you happen to have a formula in calculating the bitrate for encoding with RV9 or a program to? There is a guide that mentions using gknot for calculating the bitrate but I don't think it was design for use with RV9 but rather XVID and DivX 5.
I haven't used GKnot extensively so I am not 100% sure what its bitrate calculator does. For RV9 encoding, when Total Filesize is the target, AutoRV9 has an accurate bitrate calculator built-in that even includes the RM file format overhead. It shows which bits/pixel number the resulting bitrate corresponds to as well. Very generally, and without comparing with anything, I have seen 0.18 bits/pixel or higher result in very good quality. If the bits/pixel number goes too high, anamorphic (or 720 wide) encoding might be a good idea.

Does this help, or were you looking for the actual formula used in the bitrate calculator? A little stand-alone program would be a great project.

Sgt_Strider

2nd January 2003, 00:35

The bitrate calculator doesn't quite do what I really wanted to do. You see I need to enter the total file size in order for it to give me some sort of avg bitrate. What if I'm not sure how big I want it to be? I just want to leave the file in my computer at this point and I have no desire to put it in a CD although I might do a 2 cd encode sometime in the future.

Btw by just entering 2100 MB for my desire file size gave me a avg. bitrate similar to the one gknot gave...

karl_lillevold

2nd January 2003, 22:24

Originally posted by Sgt_Strider
The bitrate calculator doesn't quite do what I really wanted to do. You see I need to enter the total file size in order for it to give me some sort of avg bitrate. What if I'm not sure how big I want it to be? I just want to leave the file in my computer at this point and I have no desire to put it in a CD although I might do a 2 cd encode sometime in the future.

Btw by just entering 2100 MB for my desire file size gave me a avg. bitrate similar to the one gknot gave...
That must be a very high bitrate. What's the bits/pixel number? Your quality may be limited by resolution, so anamorphic encoding would probably be a good choice, but is not yet supported in AutoRV9, and you have to run the AutoRV9 producer command line manually after adjusting the .avs script, and producer command line parameters. I guess I should write up a guide for this..

Hmm, I am afraid I am still not clear exactly what the question is...

You can get from filesize -> bitrate, or bitrate -> filesize. This formula is reversible, and does not depend on the codec.

Are you looking for a tool to estimate which bitrate is needed to achieve excellent quality? For this, just enter different filesizes until you get to my recommended bits/pixel number. That should be a good starting point, which you may adjust based on your own preference.

Sgt_Strider

2nd January 2003, 22:33

Originally posted by karl_lillevold
That must be a very high bitrate. What's the bits/pixel number? Your quality may be limited by resolution, so anamorphic encoding would probably be a good choice, but is not yet supported in AutoRV9, and you have to run the AutoRV9 producer command line manually after adjusting the .avs script, and producer command line parameters. I guess I should write up a guide for this..

Hmm, I am afraid I am still not clear exactly what the question is...

You can get from filesize -> bitrate, or bitrate -> filesize. This formula is reversible, and does not depend on the codec.

Are you looking for a tool to estimate which bitrate is needed to achieve excellent quality? For this, just enter different filesizes until you get to my recommended bits/pixel number. That should be a good starting point, which you may adjust based on your own preference.

If you can write a guide in how to do a anamorphic encoding with RV9. It would make things much simpler. Maybe you can base it on the Helix Producer basic/Plus???

karl_lillevold

5th January 2003, 15:36

Originally posted by Sgt_Strider
If you can write a guide in how to do a anamorphic encoding with RV9. It would make things much simpler. Maybe you can base it on the Helix Producer basic/Plus???
Done. See my edits in this thread (http://forum.doom9.org/showthread.php?s=&threadid=40572). It requires Helix Producer Plus, available from the Helix Community.

Sgt_Strider

5th January 2003, 22:59

Originally posted by karl_lillevold
Done. See my edits in this thread (http://forum.doom9.org/showthread.php?s=&threadid=40572). It requires Helix Producer Plus, available from the Helix Community.

Thx :)

oddball

6th January 2003, 00:43

I think amirm has some wires crossed on how anamorphic is handled. Forgettting the technicalities for a moment. Anamorphic is handled by the viewing device. Not the software per se. When viewing an anamorphic signal widescreen TV's/monitors benefit from it the most (That is not to say that 4:3 TV's cannot benefit from the extra vertical resolution also. In fact many modern 4:3 TV's have a mode just for this).

When viewed on a monitor an anamorphic video/DVD will look too tall unless either a) the software compensates and corrects the aspect (Thus losing the benefits of the vertical res in the first place). Or. b) The monitor recognises the anamorphic flag (if sent) and squeezes the video vertically to correct ratio accordingly (Otherwise you have to do this yourself manually by adjusting the monitors vertical stretch).
With TV output using overlay methods (Mainly) the TV does the vertical squeeze for you. Widescreen TV's look great using this method. If you zoom a non-anamorphic letterbox image on a widescreen TV you usually see the scan lines due to lack of vertical res.

Someone said that anamorphic requires more bits for the additional res. To some extent this is true in the fact that there is extra info vertically for any aspect ratio above 4:3. But lets not forget it's being encoded at 4:3 ratio (with anamorphic flag set in the stream). So it will get as much bits as a 4:3 encode would get anyhow. Tty to think of it in the same manner as when cropping the black bars from DVD video when transcoding to DiVX/Xvid etc. The amount of bits spent on the black bars is minimal but still there.

Anyhow I am going a little off topic here.

*NONE*. I repeat. *NONE* of the current crop of codecs give perfect functionality yet. Lack of SPDIF AC3/DTS output from either WMV9 or RV9 puts a damp squib on things for me seeing as I use an external AC3/DTS reciever and *NOT* PC 5.1 speakers. The inclusion of an anamorphic encoding/decoding flag in the video signal would be nice but it's not the be all and end all for me.

My trusty old Matrox G400 Max 32 DH does a fine job of outputting via overlay a nice 16:9 stretch on non-anamorphic widescreen material (Better than my TV does in fact).

*BOTH* M$ and Real(cash) forgot to do one thing when they came up with these 'oh so wonderful' codecs.

They forgot to ask people what features they actually want!

karl_lillevold

6th January 2003, 01:57

Originally posted by oddball
I think amirm has some wires crossed on how anamorphic is handled. Forgettting the technicalities for a moment. Anamorphic is handled by the viewing device. Not the software per se. When viewing an anamorphic signal widescreen TV's/monitors benefit from it the most (That is not to say that 4:3 TV's cannot benefit from the extra vertical resolution also. In fact many modern 4:3 TV's have a mode just for this).

When viewed on a monitor an anamorphic video/DVD will look too tall unless either a) the software compensates and corrects the aspect (Thus losing the benefits of the vertical res in the first place). Or. b) The monitor recognises the anamorphic flag (if sent) and squeezes the video vertically to correct ratio accordingly (Otherwise you have to do this yourself manually by adjusting the monitors vertical stretch).
Like I explained in the RV9 Anamorphic thread, if the viewing device is limited to 640 pixel width, which is probably true for many TVs, you are right, there is no advantage to anamorphic encodes for RV9 (or WMV9), or anamorphic DVDs for that matter.

However, when the resolution is higher, which is true for
1) widescreen TVs, high res TVs, and for PC playback, the PCs video card TV out resolution is set to higher than 640, and for
2) PC monitors when display resolution is set to 800x600 or higher,
there is a clear advantage to anamorphic encodes or DVDs. When the player does aspect ratio correction, it will preserve the increased vertical resolution, i.e not squeeze it, and stretch the video horizontally to the correct aspect ratio. This is the key to the increased quality.

Originally posted by oddball
They forgot to ask people what features they actually want!
Thanks for the feedback regarding SPDIF AC3/DTS output. In fact, I have the same problem myself. Like the rest of you, I am currently limited to old-fashioned Dolby Surround when I play back RV9 encoded content on my home theater system. There is nothing I would have liked more than 5.1 channels with direct AC3 output to my old Marantz DP870 external AC3 decoder. I will absolutely make sure this feature request is forwarded.

Sirber

6th January 2003, 02:02

@karl

Is it normal for a first pass, 4h45 for a 1h45 long movie on a Athlon XP 2 GHz?

karl_lillevold

6th January 2003, 02:16

Originally posted by Sirber
Is it normal for a first pass, 4h45 for a 1h45 long movie on a Athlon XP 2 GHz?
No, that does not sound normal. On my 2.4GHz P4, the encoding speed is about real-time, i.e. about 1h45 for 1st pass in your example. Are you using any pre-filters, inverse telecine, de-interlace? How about your resize filter? Lanczos is good quality, but very slow. I will ask my co-worker who has an Athlon 1800, to measure typical encoding speed on his system.

Sirber

6th January 2003, 02:21

Hum... I forgot about the filters :D

I have:

# PLUGINS
LoadPlugin("C:\PROGRA~1\Autorv9\SOFTS\AVSFILE\MPEG2DEC.DLL")
LoadPlugin("C:\PROGRA~1\Autorv9\SOFTS\AVSFILE\LANCZOS3.DLL")
LoadPlugin("C:\PROGRA~1\Autorv9\SOFTS\AVSFILE\DECOMB.DLL")
LoadPlugin("C:\PROGRA~1\Autorv9\SOFTS\AVSFILE\CONVOLUTION3D.DLL")
#
# VIDEO SOURCE
Video=Mpeg2Source("D:\Films\DVD\Lord of the ring\DVD 1\CD1_29FPS.d2v")
#
# IVTC
Video=Telecide(Video,guide=1)
Video=Decimate(Video,cycle=5)
#
# CROPPING
Video=Crop(Video,4,60,712,356)
#
# RESIZING
Video=Lanczos3Resize(Video,720,304)
#
# CONVOLUTION 3D FILTER (Medium)
Video=Convolution3D(Video,0,3,4,3,4,2.8,0)
#
# FINISH
Return(Video)

##

I think Telecine and Convolution3D slow the process... they add ~ 1h30 hours...

Sirber

6th January 2003, 13:25

Now the results:
Lord Of The Ring: The Fellowship of the Ring DVD1
*** I bought it :D ***

XviD: (2x80kbps Vorbis)(1CD)(no postproc)

Quant: MPEG
alt-cc: 500/90/30
bf: 2@100

Sharp image in slow and high motion scenes
Few blocks that hurt my eyes in high motion.
Output files: 1 OGM
Overall: 8/10

RV9: (2x64kbps)(1CD)

Sharp image in slow motion scenes
Blurry in background, less details
No blocks :)
Output files: 2 SMIL, 2 RM and 1 RMVB
Overall: 9/10

sam_b

6th January 2003, 15:12

Sirber, if you use alt-cc at that strength you will get blocks on high motion. Thats the point of it. (Simplification I know)

2-100 (what no third number?) is a very weird setting for a rip of this kind. You don't state the resolution or resize method.

I also think you're mad for using MPEG quants on a 1cd FOTR and then complaining about blocks.

I'm not saying this is not a valid test, but if you want apples to apples, this aint it.

Didée

6th January 2003, 15:20

@ Sirber:

Ah, my current "testing victim", too. Am I right that you're dealing with the "special extended" version (~3h20min) ?

Try XviD again with normal CC @ 0/0, maybe 5/12 (hi/lo).
And what's BF:2@100? Is 100 multiplier or offset? If you're using an "older" XviD build that has only multiplier for Bframes, then you'll gain very, very little with "100". For current builds, I typically use 3/100/200 or 3/125/150 (#/mult/offset).
Oh, and your res is 720*304! I'd give it a shot *without* Conv3D. There is only little noise - leaving that noise in could also avoid some blocks. After all, you're aiming for ~0.165 b/p*f. In this region, mpeg-4 may indeed throw some blocks - especially when using inefficient Bframe-settings.
(Personally, I will go for 640*256 @ 2CD for archiving. Currently, I'm fiddling to get it on one CD just for fun. And it looks not bad on TV ;) )

These settings of course are discussable, of course. Just my point of view.

Sorry for getting slightly OT

Didée

Didée

6th January 2003, 15:25

Originally posted by sam_b
I also think you're mad for using MPEG quants on a 1cd FOTR and then complaining about blocks.
No. For what I see, Sirber has encoded DVD1 of the 2-DVD extended version set.

And yes, alt-CC is supposed to produce some blocks in hi-motion.

And no, he did mention resolution and resize method. Look a some posts earlier: Violà, the complete script!

And - ooops! ;) For my 1CD-encode, I *am* using mpeg quants. A little blockbustering with special masking/layering ... :D

sam_b

6th January 2003, 16:41

@didee & sirber

Memo to self: pay more attention to authors of previous posts. Sorry about that sirber. I did not mean to criticise as much as it seemed. I suppose I got a bit defensive about XviD :D

Sirber's settings (except poss B-frames) *are* valid settings, but not exactly codec-friendly. 720 x 304 lanczos is tough as resizings go, whichever way you look at it. And I know MPEG-q is often a valid choice, I do use it myself often (and hvs-best) but against RV9 at similar bitrates it's gonna look mighty different w/o pp. I have seens a lanczos resize add 30% onto a bicubic .33/.33 first pass size.

These settings of course are discussable, of course. Just my point of view.

You are very subtle Didee :) But you're right, I should have added this to the end of my post... might have made my point a bit clearer.

Oh, how is the box-set organised re. DVD1/2? I only know the original.

Edit: what layering and masking you using?

karl_lillevold

6th January 2003, 16:51

Yup, with that set of filters, the encoding speed sounds about right.

For your next encode, I would swap Lanczos3 for bicubic neutral, skip Convolution3D (probably not needed for low grain source), and Force Film in DVD2AVI (if possible) to avoid inverse telecine in AVISynth.

Didée

6th January 2003, 16:59

@ sam_b

It was a work-in-progress snapshot of this idea (http://forum.doom9.org/showthread.php?s=&goto&threadid=37135&postid=236386). Still has to be further developped - and, in the end, maybe cancelled. Me has too little time for exhaustive experimenting ... alas.

/edit #97 :devil:
the second post on page 8. Damn, how is the exact syntax to point to a specific post within a thread?

Sirber

7th January 2003, 02:49

Originally posted by karl_lillevold
Yup, with that set of filters, the encoding speed sounds about right.

For your next encode, I would swap Lanczos3 for bicubic neutral, skip Convolution3D (probably not needed for low grain source), and Force Film in DVD2AVI (if possible) to avoid inverse telecine in AVISynth.

I red (maybe here :D) that Convolution3D was improving Rv9 compression, but it seems to be very slow. Is bicubic faster than Lanczos3? Force Film on DVD2AVI, I red that it was not always the best algo for inverse telecine. I did the second DVD in RV9. The quality is superb, but some blur in background, but no squares. I saw what doom9 was talking in the codec comparison #3, that RV9 was using less bits on background. I think the background gets bluried by the post-processing filter because it has less details than the foregrounds objects. I started AutoDub at 7h AM, and all finished at 5h PM on a 2 GHz.

For XviD...

I used 2 b-frames @ 100 quant because I wanted a clean movie. I also used MPQG quant because I think the best if I don't want to use post-processing. H263 square the scene, MPEG don't.

For RV9...

It would be great to be able to pan-scan movies in fullscreen... Sound quality @ 64kbps is great and sound like a 80kbps Vorbis. Vorbis @64 has some problems with water and wind.

Conclusion:

XviD is a great and fast codec. RV9 is a great codec too, with slow filters ;) I think I'll switch to RV9 for my next encodes, 1. because of the quality, and 2. it can be played on Linux!!!

sam_b

7th January 2003, 04:14

@Didee
Cheers for the link. Sound complex....

@Sirber
Bicubic is significantly faster than lanczos. It's built-in to recent avisynths by the way so you can just use lanczosresize(x,y) w/o the plugin if you wish. Both are faster than C3D though. Force film on DVD2AVI is faster but will not always work. Karl suggested to use it if it works in your situation. May not though.

Not trying to bully you Sirber, seriously, but.. IMHO....

At your bitrates, you will get *more* mosquito noise with that b-frame setting. It will not be cleaner. This will be true at high rates though.

MPEG has a sharper image, but with more mosquito noise and more tendency to block. I assume this is what you mean by 'squaring'. H263 blocks much less and looks cleaner. It will require less PP to achieve the same level of cleanliness, at the price of a softer image. If you have found otherwise in certain situations would be interested to hear though.

And are you suggesting that XviD cannot be played back in linux??

I have no problem with RV9 at all, but at least give XviD a chance before you jump ship :D

karl_lillevold

7th January 2003, 05:07

Originally posted by Sirber
I red (maybe here :D) that Convolution3D was improving Rv9 compression, but it seems to be very slow. Is bicubic faster than Lanczos3? Force Film on DVD2AVI, I red that it was not always the best algo for inverse telecine. I did the second DVD in RV9. The quality is superb, but some blur in background, but no squares. I saw what doom9 was talking in the codec comparison #3, that RV9 was using less bits on background. I think the background gets bluried by the post-processing filter because it has less details than the foregrounds objects. I started AutoDub at 7h AM, and all finished at 5h PM on a 2 GHz.

RV9 is a great codec too, with slow filters ;) I think I'll switch to RV9 for my next encodes, 1. because of the quality, and 2. it can be played on Linux!!!
Forced FILM: I read the following somewhere for when to choose Forced FILM, which has always worked for me. Set a start-point somewhere in the middle of the source, then set Video->Field Operation to None. Start Preview for a while, and if it stabilizes on FILM Progressive, you can change to Forced FILM, before setting the start-point back to the beginning of the source. Otherwise, choose None, and use the proper filters in AVISynth.

In the cases where you see blurry background, are you sure that's not in the original as well? Most of the time the camera focus is on the foreground objects you know :)

With regards to slow filters : Bicubic is faster than Lanczos. I compared carefully the quality for still images, and noticed some, but very marginal difference (in favor of Lanczos), but still have on my list of things to do, to compare the two carefully for RV9 encodes. It may be that it affects compressibility in an un-expected manner. I have rarely used C3D myself, and only noticed the need for it for very grainy (oldish) material.

Sirber

7th January 2003, 13:20

Originally posted by sam_b
And are you suggesting that XviD cannot be played back in linux??

I have no problem with RV9 at all, but at least give XviD a chance before you jump ship :D [/B]

No but, personaly I don't know how to install Audio and Video codecs in linux :D. I'm newbie with X, and quite good in console.

I didn't "jump ship", XviD is still good for me, and RV9 is another good choice.

sam_b

7th January 2003, 15:17

If you install mplayer (the rpms work fine for me, don't know your distro) it will play pretty much everything out of the box. Inc. DivX3 and XviD. Impressive piece of work. My P3 500 laptop can play stuff under it that windows never could get to play properly.

Sirber

7th January 2003, 22:48

does mplayer include vorbis and mp3 support?

sam_b

7th January 2003, 23:39

Yep. Check out http://www.mplayerhq.hu

Quick list says:

Supported input formats

# (S)VCD (Video CD) directly from CD-ROM or from CDRwin's .bin image file
# DVD, directly from your DVD disk, using libmpdvdkit (included) or libdvdread/libdvdcss (optional) for chapter support and decryption
# MPEG 1/2 System Stream (PS/PES/VOB) and Elementary Stream (ES) file formats
# RIFF AVI file format
# ASF/WMV/WMA format
# QT/MOV/MP4 format
# RealAudio/RealVideo format
# OGG/OGM format
# VIVO v1,v2 format
# FLI format
# NuppelVideo format
# yuv4mpeg format
# FILM (.cpk) format
# RoQ format
# supports reading from file, fifo/stdin, (S)VCD/DVD or network via HTTP/MMS/MMST/RTP

Supported video and audio codecs

# The most important video codecs: MPEG1 (VCD) and MPEG2 (SVCD/DVD/DVB) video
# MPEG4, DivX ;-), OpenDivX (DivX4), DivX 5.02, XviD and other MPEG4 variants
# Windows Media Video v7 (WMV1), v8 (WMV2) and v9 (WMV3) used in .wmv files
# RealVideo 1.0, 2.0 (G2), 3.0 (RP8), 4.0 (RP9)
# Sorenson v1/v3 (SVQ1/SVQ3), Cinepak, RPZA and other common QuickTime codecs
# Intel Indeo codecs (3.x,4.1,5.0)
# VIVO v1, v2
# MJPEG variants, HuffYUV, ZLIB/MSZH, ASV2 and other capture/hardware formats
# FLI, RoQ and other old/rare animation formats

# The most important audio codecs: MPEG layer 1, 2 and 3 (MP3) audio
# AC3/A52 (dolby digital) audio (software or SP/DIF)
# WMA (DivX Audio) v1, v2 (native codec)
# WMA 9 (WMAv3), Voxware audio, ACELP.net etc (using x86 DLLs)
# RealAudio: COOK, SIPRO, ATRAC3, DNET (using RP's plugins)
# QuickTime: Qclp, Q-Design QDMC/QDM2, MACE 3/6 (using QT's DLLs)
# Ogg Vorbis audio codec
# VIVO audio (g723, Vivo Siren) using x86 DLL
# alaw/ulaw, (ms)gsm, pcm, *adpcm and other simple old audio formats