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. |
14th December 2002, 02:47 | #1 | Link |
Registered User
Join Date: May 2002
Location: Canada
Posts: 59
|
switching to Xvid ;)
hey all, i've used everything from flask to sbc in the past 2 years and i've just made my first xvid encode using koepi's 04102002 codec.. i must say, i am very impressed with the quality of my first try. knowing that people will work on it is always a plus.
anyways, i'm encoding a 2h45min movie and i'm getting some noise around moving objects (people mainly). which settings would be able to help this or is it probably a bit too low of a bitrate? thanks, KroniK |
14th December 2002, 03:16 | #2 | Link |
Registered User
Join Date: Oct 2001
Posts: 213
|
Yeah, XviD seems to give a lot of mosquito noise... Are you using MPEG quantizers? Try using H263 and see if you like the results. Or try using the latest "unstable" builds, with Chroma Motion on. Try using a higher resolution, those noise appear more on lower resolution clips.
|
14th December 2002, 15:36 | #6 | Link |
Registered User
Join Date: Jan 2002
Location: northern canada
Posts: 215
|
there are settings in the unstable buildings of xvid and there are many filters for asynth that can help you with this.
The ones you finial choose is as always ur preferences and likes welcome to the open codec |
14th December 2002, 15:38 | #7 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
kronik,
yep, welcome to the board and to XviD! You gave no information on HOW you are things doing ATM. Anyways, 2h45m is pretty long. Everything depends on many things, but I would *strongly* suggest to use a lower resolution! Perhaps around 576*240, but that's just a guess. Don't make the failure to insist on (unrealistic) high resolutions. In my beginnings with this stuff, I thought that way, too. But my mind has dramatically changed since then. All the way down to 512*yyy is delivering very good results. And it is much, much better to have a little smaller, but artefact-free picture than a bigger one, that is full of artefacts. And in case you're still using FlasK, please turn around: (almost) everyone here will give you a friendly and educational kick in the a** I mean, if you don't know/do already, look into the AviSynth forum here. Please. Your encodings will improve a lot. Regards Didée
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
14th December 2002, 16:26 | #8 | Link |
GPL Bassmaker
Join Date: Nov 2002
Location: York, UK
Posts: 125
|
Agree entirely with Didee (sorry no accent).
I find that Qpel improves the fidgety look a lot, especially at low resolutions, so try that with CM in one of the new builds. I would say that at your bitrate Convolution3D is very likely to help. Stops random noise from jittering too. If you are using 640xX then you are going to have problems without B-frames at this bitrate. Larger resolutions are only realy practical with them in my experience. There's some stuff in the minority report thread that might help. Let us know how it works. EDIT: erm... I meant "minority report thread" not "minority report". But you all knew that, right? Last edited by sam_b; 14th December 2002 at 20:55. |
14th December 2002, 21:51 | #9 | Link |
Registered User
Join Date: May 2002
Location: Canada
Posts: 59
|
thanks for all the replies and opinions. i've been doing lots of tests on the same movie with sbc and xvid over the past couple days and will continue until i get the quality i'm looking for. i'll take everything u guys said into consideration...thanks again
KroniK oh, and Didée, i left that flask shit behind 3 months into my ripping. i agree with the kick in the ass part Last edited by kronik; 14th December 2002 at 22:03. |
14th December 2002, 22:48 | #10 | Link |
Registered User
Join Date: Oct 2001
Posts: 213
|
Oops, when I meant use a higher resolution, I meant that you should use a higher bitrate too. (Unless your original encode was already saturated with Quant 2s.) Open your first-pass stats file with Gordianknot or something, I usually aim for 60-65% (about Quant 2.9 average).
If the original source has some mosquito noise, the result is much worse in XviD, so better get rid of those noise first. Try using Undot after resizing in Avisynth. Also, temporalsoften(1,5,0) works quite well (good when using MPEG quantizers). Last edited by soujir0u; 14th December 2002 at 22:51. |
15th December 2002, 13:32 | #12 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
I did no serious compares/researches on the qpel feature lately. Furthermore, I am speaking out of pure theory now, but anyway:
In principle, qpel should deliver better compressability, because the ME can "point" more precisly on the destination block, and thus lower quants are needed, resp. the compression gets better for a given quant. The problem is (was), that with activated qpel the search distance is cut to half, and therefore the ME might not find the best possible destination block. This must obviously lead to worse compressability in mid/hi-motion scenes. Now, this problem should have become minor since XviD has dynamic qpel decision in the latest alphas: using qpel on lo motion, and take the benefit. On mid/hi motion, take classic hpel to catch the motion better. If the above is not right, *please* do correct me! I'm not into the codec's inner mysteries (as you might see from my probably not-quite-right terminology above) ... but in general, I like theoretic approaches, and I (would) like to understand how things are really working! Regards and Thx Didée
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
15th December 2002, 14:30 | #13 | Link | |
Registered User
Join Date: Jun 2002
Location: Adelaide, Australia
Posts: 1,167
|
Quote:
Qpel does not limit the range. For any frame, encoder makes a decision - how big range of motion vectors it needs. There is a value, called 'fixed code' (or fcode, iFcode in xvid sources). If qpel is active, encoder just chooses a bigger range - when fcode is increased by one, the range is doubled. However, when a vector is written to the bitstream, for every of it's components (x, y) a number of bits equal to fcode is written, followed by a VLC corresponding to the vector. If the range is doubled, two more bits (statistically) are needed for every vector. If we assume that there is one vector for every macroblock (there might be 4 or 0), at the resolution of 640x272 and 24fps and P-frames only, two bits for every macroblock take 32.5 kbps. Qpel generally decreases compressability. Although it can find a better match, it usually doesn't 'correct' this match anyway, because the errors are too small. If there is no good match, qpel doesn't help much either - the amound of texture data is still similar. I hope this helps, Radek |
|
15th December 2002, 17:37 | #14 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
[smoke coming out of my head]
Thanks very much for clarification, sysKin. I would lie if I'd say I understand it now completely However, this was a pretty good example what silly assumptions sometimes may grow! I took all the little hints that were dropped here, there and elsewhere by people with insight into XviD's technology, and tried to puzzle them together in a logical manner. The result was crap. But, sorry for being penetrant: > If qpel is active, encoder just chooses a bigger range [of motion vectors] >Qpel generally decreases compressability. Although it can find a >better match, it usually doesn't 'correct' this match anyway, >because the errors are too small. If there is no good match, qpel >doesn't help much either - the amound of texture data is still similar Reading that, I start even more wondering: - Range is increased by qpel ??? - What IS the benefit of qpel? From your explanation, I understood that it OTOH decreases compressability, and OTOH doesn't help much ??? I thought it has to do with sub-pixel accuracy? Pretty now Didée
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) Last edited by Didée; 15th December 2002 at 17:40. |
15th December 2002, 18:28 | #15 | Link |
Moderator
Join Date: Oct 2001
Location: Germany
Posts: 4,454
|
hpel and qpel _are_ sub pixel resolution.
The benefit from it is the more precise movement detection - thus possibly saving texture bits, which get consumed by bigger motion vectors usually. The error that this more precise detection produces is smaller, that's why it's considered to improve something(the amount of error correction data gets less). You can see the success of it in the sharper image you get, it has more details - even if you have to compress the material more. The search range is still the same: if in fullpel 32 pixel range is searched, this happens in hpel and qpel as well (hm. not sure about the hpel part). So the search efforts increase (think of it as if you'd blow up the image by the factor of 4 in each direction). I hope i didn't cause more confusion now %) Best regards Koepi
__________________
Koepi's new media development site |
16th December 2002, 00:19 | #16 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
No, Koepi, no more confusion. The Mud is clearing, the puzzles start to form a motive ...
So I see the idea I had wasn't totally wrong, only half-way (or so). Thanks Didée
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
16th December 2002, 07:27 | #18 | Link |
Moderator, Ex(viD)-Mascot
Join Date: Oct 2001
Posts: 2,564
|
Not really. Quarterpel can make it harder to fit a movie on one CD. Nothing to do with high motion. (Theoretically?)
You know that all unstable features aren't recommended for archieving purposes?
__________________
It's a man's life in Doom9's 52nd MPEG division. "The cat sat on the mat." ATM I'm thoroughly enjoying the Banshee - a fantastic music player/ripper for Linux. Give it a whirl! Last edited by Teegedeck; 16th December 2002 at 08:12. |
16th December 2002, 11:37 | #20 | Link | ||
Registered User
Join Date: Jun 2002
Location: Adelaide, Australia
Posts: 1,167
|
Quote:
Quote:
It doesn't mean that macroblocks with additional texture data (to fix a not-so-good motion estimation) won't benefit - they will also look better, and they _might_ have less texture data - but mostly they will just look better. Ask more questions, I'm pretty sure you're still confused, as I don't explain as clearly as I'd want to Radek |
||
Thread Tools | Search this Thread |
Display Modes | |
|
|