@Kwag and SansGrip,
Problems with file predictor for CQ greater than 80. Seems Tmpgenc opens the bitrate flood gates beyond this point and throws off the formula by a large amount. File prediction told me the new is CQ 85.871 (14.4% too small) after using CQ 75. Then test file size jumps from 21,406,846 (CQ=75) to 32,826,302 (CQ=86). File prediction then suggests using new CQ 66.67 ??????? I’m using 2 CD’s with a target video size of 1,425,637,201. The file size formula works with no problems using CQ_VBR. Maybe CQ reacts differently at various CQ settings to controlling bitrates. Also, is there a KVCD template for 528x480 using CQ or how can I change KVCDx3 to use CQ. Finally, has SansGrip compared 704x480 to 528x480 resolutions for CQ with same target file. I think movie length and resolution are the major factors for high picture quality using CQ. For example, if you must use 1 CD (800MB) and you video target file size is 700MB then a long movie (2+hrs) will not have the best quality using 704x480 as it would with 528x480 or 352x480. :) Thanks -black prince |
Quote:
|
Hi Kwag,
" I also confirmed SansGrip's findings that adding Blockbuster "Noise" just makes the quality worse. I believe there is a treshold point to use Blockbuster. If there is enough bit rate available for an encode, then we can use Blockbuster "noise" method to our advantage. " Does the above statement apply to CQ_VBR mode (KVCD-Plus--704x480)? What about KDVD (Full-D1)? Side issue: Is DVD Patcher only applicable to Mpeg-2? If not, we can "fool" those standalone DVD player which does not like KVCDx3 then. |
Thanks for the Mini-HowTo kwag!
8) I just found out another interesting thing. Using TemporalSmoother(2,2) even for DVD-Rips is not too bad of an idea! Try it out, it gives a little more compression than the value 2,1 and the thing that is strange to me is : Q-Level decreases from 2.66 w/ TempSmooth 2,1 to Q-Level 2.64 w/ TempSmooth 2,2. Regarding visible differences I can't give you a lot of testing because my eyes aren't that good. I don't see a difference, only that of course the higher the value, the smoother the image... that's not necessarily a bad thing i guess.... :wink: Try it out... |
Quote:
Jim |
@Kwag and SansGrip,
Quote:
the same thing is happening. At about CQ 80 or greater the file size takes a huge increase. Again I used 2 CD's for a movie that's 138 minutes and the manual prediction fails for CQ > 80. Is there anyone else having this problem :?: :?: :?: :?: -black prince |
Hi All,
Black prince wrote: Quote:
were not as good as 704x480 CQ. The Q-Matrix is probably tuned for CQ_VBR. It did produce a smaller file size, but for 1 CD and 138 minute movie, the CQ_VBR was much better. CQ definately has the better picture quality given the same file size. I just hope I can solve my problems with file size prediction :( -black prince |
Quote:
This is the only way we can measure quality of encodings. We can't judge CQ_VBR over CQ if the file sizes are different. Right now, if I make a sample test with CQ_VBR and I make another one with CQ and adjust the value until the size matches that of the CQ_VBR sample, the CQ sample runs rings on quality around CQ_VBR! Every time :D -kwag |
Quote:
well right now I'm doing another one, at 544x576 and it looks as if it would come out even better. I'm able to use almost the same CQ (only decrease by 1.2), and this way the movie will even look more sharp... more to come... :wink: |
hey all, I've been testing my butt off :lol: I finally put Pearl Harbor (~3 hrs) on one cd with the the latest LBR template and had great results.
I used CQ = 70 (much less artifacts than CQ-VBR) min bitrate - 300 max bitrate - 1000 spoilage- p-0 b-10 avg. bitrate (viewed with bitrate viewer) is ~500kbps LoadPlugin("D:\encoding\MPEG2DEC.dll") LoadPlugin("C:\encoding\fluxsmooth.dll") LoadPlugin("C:\encoding\LegalClip.dll") AviSource("D:\PEARL_HARBOR_DSC1\VIDEO_TS\PEARL_HAR BOR_d2v-vfapi.avi") ConvertToYUY2() LegalClip() BicubicResize(336,168,0,0.6,0,0,720,480) TemporalSmoother(2,2) fluxsmooth() legalclip() AddBorders(8,36,8,36) I'm much happier with precise bicubic resize at 352x240 it's more sharp than bilinear but not too sharp like Lanczos. Good results with the double noise filters too- I tried Unfilter but there were white lines on the right and left sides. Also Blockbuster made the file size grow too much. encoded the audio at 112kbps and after I cut the credits off, final file size 812mb One big problem though is that the audio gets out of synch. I have a feeling that this might be due to the fact that I disabled padding so that the min. bitrate falls well below 300kbps in spots. I'm going to enable padding and check the audio synch and I'll see if this movie will still fit. |
Hi all, hope you had a good holiday. I personally ate three times my own bodyweight of cake and pudding :).
Glad to see lots of testing has been done in my absence, and I'm keen to make some more encodes this evening. I'm not going to try to reply to every message, but I'll address some of the points that jumped out at me. First, I stand by my assertion that at least with the material I tested, CQ mode works far better than CQ_VBR at 528x480 and above, while CQ_VBR is better for resolutions below that. That said, my final decision on the matter will have to wait until I make more encodes with difference source material :). As far as the use of Blockbuster goes, kwag is quite right when he says that if you can afford the larger file size, it will improve the quality noticibly wrt to blockiness. If you're trying to cram a very long movie on one disc, however, you need all the bits you can get, and this will almost always mean dropping Blockbuster and jacking up the smoothing. It will also help if you reduce the size of the "actual" frame itself by using overscan blocks left and right, and possibly cropping a little off the top and bottom. The more black, the better. Of course all these measures will compromise quality, but that's unavoidable. Regarding automating file prediction, I'm going to release a new version of KVCD Predictor once things have stabilized a bit. I'm trying to come up with some ways of automating it further and making it easier to use. Now to test... 8) |
Welcome back SansGrip :D :mrgreen:
-kwag |
CQ 68.m1v 6.936 mb
CQ_VBR 21.m1v 7.106 mb I set max bitrate back to 1150 since 1000 barely made any difference at all. the cq sample looks a little less "mosquitoey" to me. |
Quote:
http://www.digitalfaq.com/archives/error.gif I have outlined the areas where the Gibbs is particularly noticible. In each case, the effect is worse in the CQ version. For me, this confirms my feeling that CQ_VBR is better at resolutions lower than 528x480, but am still testing that resolution and higher. |
What resolution was this SansGrip?
Edit: Never mind, I see it's 352x240. -kwag |
Quote:
|
I also think the CQ version is more blocky. Look at the cheek of the girl in the bottom-middle of the frame.
|
wow SansGrip, that was very cool of you to evaluate the two samples and actually post screenshots of the two for comparison 8) :wink: The CQ_VBR sample definitely looks better than the CQ sample in your screenshot.
I wonder if the majority of the frames in the CQ-VBR sample have less Gibbs than the CQ sample :?: I need to learn how to cap screenshots like that- how'd you do that 8O thanx, ren |
Quote:
Quote:
Quote:
Edit: This step would be unnecessary if there were an Avisynth plugin to load MPEG-1 files. There may well be; I've not looked for one ;). I then use an Avisynth script like this: Code:
clip1 = AviSource("cq-68.avi").Subtitle("CQ-68") If I want to take a "grab" of a particular frame I select "Copy source frame to clipboard" and paste it into Photoshop where I can tweak as necessary and save as an image. |
Great, I compared various frames of each sample to each other in Photoshop and the CQ-VBR sample is clearly better.
I learned something else new: the samples look better when I view them with WinDVD rather than Zoom player (I don't know why that is :?: ) Thanks, ren |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.