View Full Version : Aloha!
Soulhunter
2nd December 2003, 21:23
BIG THANKS TO KOEPI !!!
Great work this beta, and a really nice X-Mas present too... !!!
I have done some sample encodes with different settings, but Ive found not a single bug so far... :)
Quality is very pleasant... :D
Only thing I'm waiting now for, is a PSNR-decision based 2Pass mode !!! ;)
Bye
Chainmax
2nd December 2003, 21:30
I have a couple of questions:
1) Is devapi4's implementation of QPel any different than in devapi3?
2) Does Trellis still imply a slight IQ drop (thereby not making it a good option for mid-to-high bitrate encodes)?
3) Is Chroma Optimizer still there?
4) Can QPel be used with custom matrices now? [edit: from reading Tueurne's and wannabe's posts, it seems like it doesn't]
BTW, did anyone have a chance to test the cartoon mode, especially on anime?
LigH
2nd December 2003, 21:45
About 3): Yes, but you have to 'Edit' the frame range.
And yes, I tried to test the cartoon mode - unfortunately on ANIMATRIX, which has a horrible I-P/B-Frame pumping and bad quality - when the source already is blocky, the copy will be, too (especially in the scene where the robot corpses are thrown into the sea); will need to look for other sources.
http://www.ligh.de/software/XviD/pumping.avi
BoNz1
2nd December 2003, 22:20
Originally posted by Chainmax
I have a couple of questions:
1) Is devapi4's implementation of QPel any different than in devapi3?
2) Does Trellis still imply a slight IQ drop (thereby not making it a good option for mid-to-high bitrate encodes)?
3) Is Chroma Optimizer still there?
4) Can QPel be used with custom matrices now? [edit: from reading Tueurne's and wannabe's posts, it seems like it doesn't]
BTW, did anyone have a chance to test the cartoon mode, especially on anime?
1) Yes, some bugs were fixed + isibaar's qpel was merged into dev-api-4 quite a while ago so it should be a little faster and a little better quality.
2) Use trellis always.
3) Chroma optimizer is in the zones.
4) you can use it with custom matrices.
EDIT: I tried cartoon mode on some of my simpsons dvds and it looks very good. It skips quite a few frames lowering the bitrate quite significantly but the visual result is good, no ghosting or any other nastiness.
riggits
2nd December 2003, 22:27
Originally posted by BoNz1
.....
2) Use trellis always.
...
What is trellis, and what does it do? Technical details would be nice! I've read this whole thread trying to find out.
I'm doing X2 on 1 CD as a test, and it's almost done .. 2h06min without trellis. I'd like the best possible settings for low bitrate, high-action, somewhat-dark video. I tested with and without BVOP, and BVOP certainly makes a huge difference (unlike DivX 5.1.1). Is there anything else I should do?
Thanks!
rigg...ts
KpeX
2nd December 2003, 22:43
Originally posted by riggits
What is trellis, and what does it do? Technical details would be nice! I've read this whole thread trying to find out.
I'm doing X2 on 1 CD as a test, and it's almost done .. 2h06min without trellis. I'd like the best possible settings for low bitrate, high-action, somewhat-dark video. I tested with and without BVOP, and BVOP certainly makes a huge difference (unlike DivX 5.1.1). Is there anything else I should do?
Thanks!
rigg...ts
Hi riggits, and welcome to the forums,
Background info on trellis quant:
This thread (http://forum.doom9.org/showthread.php?s=&threadid=53383) was the first public build with trellis, Koepi's post explains some of how it works. Here (http://forum.doom9.org/showthread.php?s=&threadid=53308) are some early trellis quant tests by mf and CruNcher. Search button is powerful isn't it ;).
Also see my test results (http://forum.doom9.org/showthread.php?s=&postid=406347#post406347) on beta 1 from earlier in this thread, and note files 16 vs. 17 and 36 vs. 37. In my tests, trellis quant provides slightly smaller file size (makes the codec more efficient) and decreases speed slightly as well, for both MPEG and H.263 quant. Therefore I would recommend using Trellis under any conditions except when going for extremely high speed settings.
outlyer
2nd December 2003, 22:46
I've just noticed the number of zones is limited. Any good reason for this? Any chance to raise the limit in the public builds?
Alxemi
2nd December 2003, 22:59
2) Use trellis always.
always means Always?
Even when trying to increase size/quality with codec saturation?
iago
2nd December 2003, 23:06
Even when trying to increase size/quality with codec saturation?No! ;)
P0l1m0rph1c
2nd December 2003, 23:50
Hi guys!
I've made new tests. This time with XviD 1.0, DivX 5.1.1, VP6 (i know it's b0rked, but give it a try anyway) and 3ivX 4.5.
Results:
3ivX 4.5
Average PSNR: 39.6499
Average SSIM: 0.935640
Average Scaled SSIM: 58.73138
Average VQM: 0.922518
DivX 5.1.1
Average PSNR: 40.4819
Average SSIM: 0.949206
Average Scaled SSIM: 65.89975
Average VQM: 0.859133
VP6
Average PSNR: 41.7322
Average SSIM: 0.947302
Average Scaled SSIM: 64.84965
Average VQM: 0.855174
XviD 1.0
Average PSNR: 41.0088
Average SSIM: 0.951314
Average Scaled SSIM: 67.07970
Average VQM: 0.820282
I aimed for 910 kbps, 2 pass in every codec.
Chainmax
3rd December 2003, 00:50
Originally posted by BoNz1:
2) Use trellis always.
Originally posted by Iago:
quote:
--------------------------------------------------------------------------------
Even when trying to increase size/quality with codec saturation?
--------------------------------------------------------------------------------
No! ;)
So, what would you guys say is a good turning point of sorts for using/not using Trellis? 1000kbps? 1200kbps?
gizmotech
3rd December 2003, 01:06
Good Day guys,
I'm wondering if there has been any discussion concerning xvid automattic solutions to codec saturation in 2pass encoding?
It's quite frustrating ATM to perform an encode and have to perform manual codec setting reconfiguration over and over again to reach target file size. (through max i-frame adjustments, removing of most compression assistants).
I was wondering if there are any options that xvid developers could add which would perform file padding? Dynamically increasing key-frame count would be greatly appreciated.
Thanks Guys, And great work with the new cartoon mode.
Gizmo.
PS: And before people start replying "but why should you pad out the video. It's better if it uses less", I've heard all the arguments before, and I appreciate the advice and believe it myself, however there are too many people out there still fixated on certain file sizes in encodes.
iago
3rd December 2003, 01:07
So, what would you guys say is a good turning point of sorts for using/not using Trellis? 1000kbps? 1200kbps?Depends (on many factors such as resolution, target-size, compressibility, etc.). Bitrate alone doesn't mean anything and is no measure by itself for anything...
For example, personally, I wouldn't use Trellis (and neither Adaptive Quantization nor b-frames) for a q2 encode, where I aim for the highest possible quality regardless of the file/frame size.
I suppose Trellis, Adaptive, and B-frames are most useful for 2-pass scenarios.
But these are only my thoughts of course...
regards,
iago
Sigmatador
3rd December 2003, 01:11
XviD Dev-api-4 fresh CVS checkout:
CM+VHQ4+BF1/1/0 @Q2
Decoding with xvid --> PSNR: 45.0192 47.7236 56.5961
Decoding divx5.1.1 --> PSNR: 45.5070 47.9361 57.5104
now CM+VHQ4+NOBF @Q2:
Decoding with xvid --> PSNR: 45.3652 47.8114 56.6605
Decoding divx5.1.1 --> PSNR: 45.5255 47.8518 57.4761
it seems to have a decoding problem (specially with bframes)
ps: PSNR with avisynth and compareyv12
Arcon
3rd December 2003, 01:30
Originally posted by BoNz1
I tried cartoon mode on some of my simpsons dvds and it looks very good. It skips quite a few frames lowering the bitrate quite significantly but the visual result is good, no ghosting or any other nastiness.
does that mean it doesn't add new ghosting or does that mean it magically removes the ghosting present on the dvd (examples (http://vektor.ca/dvd/dvd/simpsons.html)).
ookzDVD
3rd December 2003, 03:46
@forum,
I think the best why to test a codec is try to encode at the low bitrate (below 500kbps), isn't it ?
Lot's of people is test with the high bitrate :( all codec should be
good in high bitrate isn't it ? :(
gizmotech
3rd December 2003, 03:55
OokzDVD;
you'd figure that would be the case, but try doing the same work that XviD does in 200MB at 1100kpbs in WMV 9 and you'll understand why that isn't the case.
All codecs will perform beautifully at 2-3K kpbs, but at 1-1.5 there are still some questionable contenders.
Gizmo.
sysKin
3rd December 2003, 06:08
(About trells)
Originally posted by Alxemi
always means Always?
Even when trying to increase size/quality with codec saturation? OK it's not that easy. Both h263 and mpeg quantization tried to achive some kind of R-D optimum by use of fast and easy approximations. The results were a little bit different, however: h263 quantization type was rather throwing details away, while mpeg quantization tried not to throw them away (on average).
As a result, trellis quant when used with h263 is bringing some details back rather than throwing away more, so it increases filesize and quality at quant 2.
When used with mpeg quant type, it rather throws more details away than brings back (again, on average) - so it reduces filesize and psnr at fixed quant 2.
In any case, trellis quant is much more efficient than non-trellis approximations. If you saturate the codec, you should rather use high-quality custom matrix instead of disabling trellis.
Radek
mazzo
3rd December 2003, 07:22
@forum
Well, since there is no adequate answer to why my first encode with XViD 1.0 took over 30 hrs (!), I think I have to kick it out and return to the old one (if it's possible) or use DivX 5.1.1. XViD is better, but I'll have to weigh cost / benefit here.
m0rtal
3rd December 2003, 08:01
Originally posted by Koepi
when decoding with ffdshow you have to set the IDCT in ffdshow configuration to XviD IDCT. Simple IDCT decoding will show these artefacts.
yep, turning on XviD IDCT turns off artifacts :)
thanks!
Tuning
3rd December 2003, 08:25
Originally posted by sysKin
As a result, trellis quant when used with h263 is bringing some details back rather than throwing away more, so it increases filesize and quality at quant 2.
When used with mpeg quant type, it rather throws more details away than brings back (again, on average) - so it reduces filesize and psnr at fixed quant 2.syskin, please explain what is done under adaptive quantization.
Is trellis prefered when using adaptive quantization ?
Thanks.:)
Teegedeck
3rd December 2003, 09:14
@tuning: sysKin alread has explained it thoroughly in this thread. It must be on page 3 of it or something.
And BTW, Trellis and AQ seem to perform beautifully with almost saturated encodes. For my eyes (again, how subjective! different from most users, I prefer going for anamorphic resolution over switching off b-frames when it comes to high-bitrate encodes) the gain provided for the overall quantizer in two-passis realizable, i.e. more details seem to have been discarded without Trellis and AQ than with them. It is really fascinating to study those block-based quantizers with ffdshow. Nothing wrong as far as I can see. (I was close to submitting a negative report until I realized that the artefacts actually were present in the source and rather looked more unobstrusive in my encode due to changed block-boundaries.) Encoded at 1800 kbps, 704x550 resolution, HVS-best matrix, default b-frame-setting, Trellis, AQ, GMC, VHQ=4 (edit:) and quarterpel.
This file wasn't really apt for a test, but it wasn't meant to be one, I just wanted to encode it when 1.0 came official. Next one will be a bit more demanding.
Cyfer
3rd December 2003, 09:25
Firstly I'd like to thank Koepi and all xvid team for this wonderful codec!!!!
I'm having a little problem with this new build. I can't perform a compressibility test using Gknot.I mean when I perform a compressibilty test, no numbers appear at the bottom of the Gknot page.I tried all the other previous builds but they all work fine. what am I doing wrong here? has anyone had this problem too??
m0rtal
3rd December 2003, 09:30
reading all these posts I've reach a conclusion: XviD is not beta, it's release candidate! :D
good job, guys!
mazzo
3rd December 2003, 09:33
@m0rtal
I figure you read about my 30 hrs experience, too. If I do something wrong here, I really like to know, or else I will not draw the conclusion that this is a release candidate.
m0rtal
3rd December 2003, 09:38
mazzo
yes, I remember about your issue and trying to figure out what's wrong...
still no ideas :(
have you loaded default settings after installing?
Tuning
3rd December 2003, 09:43
Thanks Teegedeck, I'm currently doing encoding with AQ, trellis, vhq2 and single pass. Which is a movie. I have done test encode and found this combination is good in preserving details.
@Cyfer
Please look
here (http://forum.doom9.org/showthread.php?s=&threadid=66098)
Rober2D2
3rd December 2003, 09:46
ffdshow can't use xvid.ax for decoding the content. set it to use libavcodec for decoding xvid and you'll succeed with ffdshow decoding.
Thanks Koepi, but some of my films where encoded with 3 B-Frames and Packed Bitstream (Yes, I know I shouldn't have done that). Xvid.ax seems the only able to properly decode that, while libavcodec shows frames in wrong order. I'm afraid I'll have to wait until ffdshow is ready for the new API or use a dev-3-api version for the moment.
mazzo
3rd December 2003, 09:48
@mortal
No, I haven't, actually, I just installed it and ran GKnot as if nothing new had happened. Maybe that's where I should start.
And try with smaller files .... ;)
Koepi
3rd December 2003, 10:08
Maybe you shouldn't use GKnot but setup the avs and vdubmod "manually". I haven't a movie at hand, even my 3 hrs movies, which would take as much as 15hours. max total time for 2passes is 16hrs here - and that's with heavy filtering in AVS.
Regards
Koepi
mazzo
3rd December 2003, 10:11
@koepi
Would it be possible for me sending you the avs that GKnot has made in this particular case? I am not very familiar to avs scripting.
m0rtal
3rd December 2003, 10:16
mazzo
post it here :)
Hylas
3rd December 2003, 12:15
Originally posted by Koepi
Interlacing is broken currently (I think it's missing for bframes).
Regards
Koepi
Thanks for the info.:(
But according to this thread (XVID - interlaced encoding) (http://forum.doom9.org/showthread.php?s=&threadid=62485) the problem is already fixed.:confused:
And, I can't even get a proper encode without B-frames.
bilu
3rd December 2003, 12:23
Originally posted by bilu
I've now been trying to use the Interlaced option (after load defaults) with a Telecined clip, using AVS2AVI. It crashes after encoding 4 frames :confused:
I got the same problem.
bilu
3rd December 2003, 12:26
Originally posted by iago
Though I don't know how long that'll go with 60 cigarettes a day!..
You could start by changing your picture :D
Bilu
m0rtal
3rd December 2003, 12:29
bilu
are you turning postprocessing of the frames off? I mean, telecining usually decombs frames too, and after that you are trying to save interlaced frames...
maybe that is the problem...
Hylas
3rd December 2003, 12:55
Originally posted by bilu
I got the same problem.
I'm not sure about that. It doesn't crash here, but the output is screwed:
interlaced-xvid-dev3.jpg (http://stud4.tuwien.ac.at/~e0025119/video/interlaced-xvid-dev3.jpg)
interlaced-xvid1b.jpg (http://stud4.tuwien.ac.at/~e0025119/video/interlaced-xvid1b.jpg)
Manao
3rd December 2003, 13:16
There was a bug with dev-api-3, concerning transcoding of XviD to XviD, when the quant matrices used were different. A friend of mine tested that case with dev-api-4, and he encountered the same issue ( described here (http://forum.doom9.org/showthread.php?s=&threadid=57872) )
His system was (alas) linux + avisynth ( avisource ) + virtualdubmod + wine + athlon 1.4 Ghz. I can't make same the test right now on windows, I'll confirm later.
Tueurne
3rd December 2003, 13:21
Some options seem not to have been explained, could you explain it please ?
Reduced resolution
BVOP sensitivity
cweb
3rd December 2003, 14:26
(Searched for this problem, there's no reference to it in the forums)
I loaded the new XviD 1.0 beta... it looks great. Set it to defaults.
My encodes are simply a black screen when virtualdubmod encodes to a Matroska file. When it encodes to avi it's ok... The speed was around 90fps, hope I saw that correctly as it seems much faster to me than dev api 3 - amazing.
Will now try muxing from avi using some other tool to see what happens...
Thanks to Koepi and everyone else involved...
sysKin
3rd December 2003, 14:39
Originally posted by Manao
There was a bug with dev-api-3, concerning transcoding of XviD to XviD, when the quant matrices used were different. A friend of mine tested that case with dev-api-4, and he encountered the same issueYes, it was fixed a few hours after beta1 was released. I guess you have to wait for beta2 :)
Originally posted by Koepi
Interlacing is broken currently (I think it's missing for bframes).Nope, the bframe support was added some time ago. The bug which you all see was fixed one day after beta1 release.
Radek
bilu
3rd December 2003, 14:45
Originally posted by m0rtal
bilu
are you turning postprocessing of the frames off? I mean, telecining usually decombs frames too, and after that you are trying to save interlaced frames...
maybe that is the problem...
I wasn´t decombing at all, I was trying to encode without any filtering from a pure FILM source (Telecined 24fps -> 30 fps)
Bilu
m0rtal
3rd December 2003, 14:51
bilu
sorry, I was thinking about inverse telecining :)
mf
3rd December 2003, 15:39
Originally posted by Tueurne
Some options seem not to have been explained, could you explain it please ?
Reduced resolution
Not bothering reading all replies, are we? :sly:
http://forum.doom9.org/showthread.php?s=&threadid=65913&perpage=40&pagenumber=1#post405504
:D
Chainmax
3rd December 2003, 15:57
iago, syskin: most of my encodes are made with two-pass mode and hover in the 1100-1800kbps range (so the codec will probably never be saturated), so I guess that always enabling Trellis will benefit IQ. Thanks for the answer :).
gizmotech
3rd December 2003, 16:07
Chainmax,
It is very possible to over saturate the codec at 1000kbps.
Believe me, I do it on a regular basis w/ no compression assistants enabled.
Gizmo.
JimiK
3rd December 2003, 16:13
Sure that's possible. But there is no way the codec is handling this. Quant2 is maximum and that's what's used in first pass. So you will always have to increase resolution or use a sharper resize by hand.
Best regards,
JimiK
iago
3rd December 2003, 16:18
It is very possible to over saturate the codec at 1000kbps.Man, I really don't know how many times it should be repeated to make some sense! ;) Still, one more time, I wanna point out that bitrate alone doesn't mean anything. It depends on many other factors as well, such as resolution, compressibility, etc.
And believe me it is sometimes very possible not to get the codec to be saturated with a bitrate of even 2000kbps... :D
regards,
iago
arno
3rd December 2003, 16:27
Does anybody have any recommendation what settings to use for encoding credits. I haven't got the slightest idea what weight-factor is reasonable or what my old XviD api-3 codec's default quanitizer for credits is.
wannabe
3rd December 2003, 16:31
Weight 1.00 = Desired Rate 100% / thats the normal
Weight 0.5 = Desired Rate of 50%
I would say something between 0.5 and 0.3.
Btw if i understood well u have to have 2 Zones if u have Ending titles. And 3 if you have a sequence after credits right ? And 4(or +1) if you have an opening credits as well ?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.