Will do right now :D

You bet! It happens at the beginning of the movie, when the transition from the movie logo changes to the actual movie. I can't have a bit rate lower than 300Kbps on my players, if I do, it stutters on black parts of a movie. When luminance picks up again, everything is fine. Try MIN=400Kbps on your player and see if that stops it. Just find the minimum value your player supports, so that you don't waste bit rate on dark parts.
:mrgreen:

Cool :).

That's not when it happened for me, but now I think about it I believe it did happen during low-luma periods.

I have a Panasonic CV-52 (basically the same as an RV-32 but with a 5-disc changer) so I'll check the compatibility list to see if it has any notes. If not I'll keep re-encoding that first 5 minutes until I find the minimum. Hope it's not too high :?.

@SansGrip,

Ok, tested your mpeg. On my HDTV, viewed at 3 feet, you can see the artifacts ONLY on the movement scenes. The effect is like a noisy picture. On still scenes, it looks very sharp. There's some motion present on the background objects on stills parts, but I guess that's part of the high compression. Nothing that bothers(from far view point). Viewed at 6+ feet, I can perfectly watch a movie like that :D
Now on my 60" Magnavox rear screen projection, I can see NO artifacts at all. That of course is because it's an older (non-HDTV) TV. So there it looks just like if I put a DVD and play it 8)
I just wonder what your original "Untoucheables" DVD looks like in a HDTV. Maybe it's a poor mastering in that section, and can only be seen on a HDTV :?:

-kwag

Yes, that's definitely when it's most noticible, particularly when "object of interest" (i.e. what you're looking at) is small relative to the TV screen.

hehe well I do see artifacts on my analog, but it is a relatively expensive model and nowhere near 60".

I did notice some EE artifacts on the original (when faces are silhouetted against the sky, etc.) so it's definitely not a perfect transfer. It's also a fairly old movie, but I'm not sure when the transfer was done.

Edit: I just remembered that I used LanczosResize in this encode. I'm guessing if I'd used a neutral bicubic or a bilinear that the Gibbs would be less noticible. Might have to test that tomorrow :).

By the way, while I was watching it I re-encoded at 352x480 just in case ;). Was able to up the CQ_VBR to 15.6 or so. Not sure I'm going to need it now, but I'm definitely still going to burn it tomorrow and compare. I love this hobby :).

@kwag: Incidentally, I assume you made a conscious decision not to use 480x480 in your templates. What was your reasoning?

Non standard resolution for future encodings to DVD(+-)R and compatibility problems with many standalone DVD players in VCD mode :wink:
All other resolutions we use here, 352x240, 352x480, 704x480 are valid DVD resolutions. And the difference in quality from 352x480 to 480x480 is very small, but 352x480 file size is smaller, and we can take advantage of that. Also I believe that the rigid GOP size for DVD of 18 for DVD specifications could be "Cheated" in the future with some DVD authoring program. Right now, every DVD authoring program you try to use, will give you errors if you try to read an MPEG-2 with GOP larger than 18 frames. I believe this limitation is not in all DVD players ( does this sound familiar :lol: ) so we have a future DVD playground to push MPEGs into DVDs with other GOPs to take the same advantage we are doing now with KVCDs.

-kwag

Where 704x480 is a valid still resolution, correct?

I agree. I could only bump the CQ_VBR up by a few when going from 528x480 to 480x480, but could nearly double it when going to 352x480.

Ah, the future is bright :D.

Now running some sample strips for Resident Evil (100m) with x3, the new GOP, and my frame-based prediction method. Hopefully will get to encoding before sleep overcomes me ;).

It's a valid VCD still resolution. And for the same reason, most DVD players play MPEG-1 stills when we put them "in motion" as KVCD 704x480 mpeg files :D That's our added bonus. In reality, I've had many comments from people telling me that their DVD players that support VCD can only play back 352x240 and 704x480 KVCDs. But they can't play 352x480, 480x, 528x 544x, etc. As for DVD, I believe 704x480 is also a valid resolution, because I have the Panasonic DMR-E20 DVD recorder, and I can record MPEG-2 at 6 hours (352x240), 4 hours(352x480), 2 hours( 704x480) and 1 hour (720x480) and it makes DVDs at any of those resolutions. One of the tricks I'd like to pull is try and burn a 704x480 MPEG-1 KVCD in a DVD by fooling some authoring program to believe it's MPEG-2 :D . If that works, we're going to have fun :lol:


-kwag

I'm not totally sure that would be possible, but then again I would've said it's not possible to pretend an MPEG-2 file is MPEG-1, and we know that it is ;).

I think there's tons of room for tweaking even if we can't stick with MPEG-1. While it's true that MPEG-2 is designed for higher bitrates, the designers of SVCD obviously thought that 2.5mb/s was a good maximum at that resolution. I think with lots of q.mat. and GOP optimizations we'll be able to sqeeze a lot out of it.

But this is straying pretty far from the point of this thread. Maybe we should move it somewhere else ;).

The good thing about all of this is that most techniques and methods we develop, we'll be able to apply them to MPEG-2 :D
So when the time comes to do DVDs, we'll be way ahead of everyone using "Standard" DVD burns. Imagine if KVCDs existed at the time when VCD came out :?: Wonder what kind of impact it would have caused in the industry. Everone making 80 minute CBR VCDs, against this :!:
For what I see, we have an advantage right now :idea:
I have to work on the KDVD templates. It's been a while since the last update. They still run on CQ, not CQ_VBR :roll:

-kwag

That's good, because by next summer I'm going to start looking into getting a DVD burner ;).

Whew, finally done prediction for x3 of Resident Evil (the manual way is slow... ;)). Target video size: 716,523kb. CQ_VBR: 9.47.

It's now encoding, and I'm going to bed after one more smoke :).

I think over the next few days I'm going to really rack my brains to come up with a much faster way of doing prediction... We should be able to get much better than this.

Check the Panasonic models. They're great! I have the LF-311 DVD-R/DVD-RAM in my PC. So I can transfer my DMR-E20 captures just by talking the DVD-RAM out of the DMR-E20 and taking it to my PC. It's very cool. OK, I am going to bed 8O. Can't stay awake any longer.

Se'ya all later :D
-kwag

Hmmm, Resident Evil came out way over target at 760mb :?. I'm running some more strips now with 75/48 to see if that helps.

This seems to be a very difficult movie to encode: lots of metal (hence lots of areas to add noise if we don't want blocks) and very dark and fairly high-action. I tried at both 704x480 and 528x480 and the Gibbs was very noticible along with quite a bit of blockiness even with variance=1, so now I'm testing at 352x480. I managed to get the CQ_VBR up to 17 and it's starting to look decent now...

I did discover something, though: when getting close to the target size it's just as effective to change the parameters to Blockbuster or the smoother in order to change the file size slightly :).

I thought this thread might turn into twenty pages too with a title like to crap or not to crap :lol:

I agree- there was very bad Gibbs effect in my Pearl Harbor encode when I used Lanczos but bilinear just seems too soft to my eyes :( I guess I'll try bicubic next.

-ren

Maybe it will be a good practice to do ~2 hour movies at 352x480 if I want it on one CD, unless the movie is low to medium action and around 90-100 minutes. Then it's fine at 528x480 on even 704x480 if it's a medium action movie. Maybe we should have the following rules for the best results:

How does that sound :idea:

-kwag

@All,

Just finished Minority Report in approximately 12 hours. Here's my stats:

Movie Stats = WS (16:9), time=2hrs 19 min, source=DVD
Resolution = KVCDx3 (528x480)
Actual Audio = 139,392,000 (128kb)
Actual Video = 1,430,813,365
Total A+V = 1,573,673,833
CQ_VBR = 12.34

Test Video Calc = 1,434,281,833
Diff % = 0.24%
Prediction Factor = .95555
GOP = 1-12-2-1-24
Resize = Used Tmpgenc
AddBorder = Used Clip frame (Tmpgenc)
Encoding Time = 12:05:48 (hh:mm:ss)

Picture quality is excellent. :D In place of avs script's resize and addborder,
I used Tmpgenc's resize and clip frame. I was able to
increase CQ_VBR from 11.4 to 12.34 and also increase audio from
64kb to 128kb. My process is very manual, but the results are well
worth it. :D :D :D


-black prince

Well I had good luck with Untouchables at 528x480 on one CD, but Resident Evil is a much different type of movie... The almost constant camera movement is obviously very difficult for the encoder to handle. Edit: What I mean to say is it's not really suitable for 528x480 even though it's only 100 minutes.

Of course there's a large element of judgement in which template to choose -- if I were to come across another movie like Resident Evil I would not attempt 704x480 and wouldn't persevere so long with 528x480 if I wasn't getting adequate quality.

As far as file size prediction goes, I just did another encode using 75/48 and it's now 726,236kb instead of the desired 699,729kb. That's less of a difference, but still way out. I'm going to redo now with 125/48.

Edit: Actually I decided to try 100/72.

Try encoding some sample strips with that Avisynth script I posted (including a crop) instead of masking in TMPGEnc. I think you'll find the results to be almost identical to the extra compression you obtained through masking.

@SansGrip,

SansGrip wrote:
I did and except for using Tmpgenc's resize the results were similar. :D
I tried to figure out how you determined the resize and crop values, but
was at a loss. Still, adding Tmpgenc's resize decrease file size even more,
so I went for it. 8) I gained ~1.5MB per 90 seconds of encode time and
that allowed for a significant increase for CQ_VBR. :)

-black prince

Very important:
I got tired of this "Unpredictable" file size, depending on the resolutions. I did a test at 352x480, and the file size was WAY off 8O. So here's my latest findings and analysis. Just like the sampling theory, where you sample "at least" twice your highest frequency, a higher sampling rate with smaller windows should give a higher resolution than less samples of a larger window. The principle is that you have a finer grain resoution, the higher you go in sampling, and more "visibility" of the real material analyzed So I'm now testing 256 snapshots of 6 frames each 8O. It seems to give me almost the same sample file size, no matter what resolution I use :wink:
So theoretically, this should be more than enough for ANY film of just about any size. You might as well set prediction factor to 1.0, because what I see is that the final size is now almost 100% accurate with the formula.
Here are my three tests at different resolutions:

Feedback please. Please try this as soon as possible and let us know your results :!:

My own feedback. This doesn't work!. 256/6. Back to the drawing board. Now trying 128/24 ...

-kwag

I used FitCD :).

In my tests it didn't -- it increased the file size slightly, at least compared to Avisynth's bilinear. When you say it decreased, which of the resize filters were you comparing it to?

Then something's still not right ;).

I was going to reply and say "shouldn't the sample length be closer to the GOP?" but now I realize that since we're not using scene-change detection it doesn't matter what size the sample is provided it's not too short. We're concerned about the GOP after encoding, not before it. Do you see what I mean?

Unfortunately the method I used for Resident Evil worked great for both American Pie and Untouchables, so it seems to depend on the source material too.

My tests will have to wait until tonight, since we're going to my brother-in-law's place for supper and I think they'd frown upon me using my laptop at the dinner table :D.

@SansGrip,

SansGrip wrote:
I used FitCD and tried to adjust left and top borders to match Tmpgenc's
mask settings. The numbers would not take and defaulted to 0. :(
For DVD 3/4 small a output (528x480) and TV-overscan 2 the resize
is BilinearResize(496,352,22,0,676,480) and AddBorders(16,64,16,64). :?
Not sure how to get this setting in FitCD. :? I tested Tmpgenc's resize vs
avs script resize with no filters and there is a decrease. I will test another
movie and see if the results are them same. :)



@Kwag,
Kwag wrote:
I'm confused. How should I setup file prediction test :?: :

IL = Framecount / 50
SL = round(Framerate) * 2
SelectRangeEvery(IL, SL)

Are the CQ_VBR values a starting point :?:

-black prince

Start a CQ_VBR of ~20 and use:

Here you're taking 256 samples of 6 frames each. Try it and let me know :wink:

-kwag

Yes, but the thing I see is that very small samples are very random. So the more, the better. Each "window" can hit more B and P frames, because there are more Bs and Ps than I frames. Still, there should be I frame hits too. I tried 300 snapshots of 6 frames, and got basically the same result. So I think 256 is a pretty good amount of sampling points on a movie. We just need to find out if the results are consistent with different types of movies. Maybe I'm wrong :roll: :!:

How about using a small PocketPC or PALM to evaluate formulas under the table. It's small enough, and you can hide it under the napkin 8O 8) :lol:

-kwag

Hi SansGrip,

SansGrip wrote:
Here's my latest resize tests:

Test #1
Using avs resize LanczosResize(496,352) and AddBorder(16,16,16,16)
with Clip Frame only in Tmpgenc.

File Size = 18,547,704

Test #2
Using Tmpgenc's resize of 496x352 and Clip Frame. LanczosResize and
AddBorders are commented and not being used.

File Size = 17,252,889

The savings are 18,547,704 - 17,252,889 = 1,294,815 or 1.3MB 8O

Picture quality and resolution are the same and of course excellent :mrgreen:
I'm using LanczosResize and maybe that's why it decreases :?:

-black prince

Hey Kwag,

Kwag wrote:The file prediction formula must have changed:

Old = ((movie length / 100) * (test file size * .95)) = Total Video file Size

New = ((movie lenght / 256) * (test file size * .98 )) = Total Video File Size :?:

-black prince

Yep... I think that you are right.
LancosResize gives more sharpness, and that increase the file size.

That would be right if SL was 1 sec (framerate). But the SL is just 6 frames.
You can calculate the Total Video File Size like this: (sample size / sample lenght ) * movie lenght * .98

note: movie lenght and sample lenght in seconds

I just finished my first squeeze of a 120+ minute film onto one disc.

KVCD Predictor predicted 796 mb (CQ_VBR10.5), actual size 820mb (d'oh!).

Used TMPGEnc's resizing, clipping, encoded at 480x352 (widescreen), new GOP.

Quality is decent -- blocks are apparent on my 27" HDTV -- but for a 133 minute high-action film squished onto ONE 80-minute CD-R, I'm pleased =) It looks alright if you sit at a normal distance from the TV (6-8+ feet).

I'll probably do two discs to improve the quality.

EDIT: WOW! I was finally able to post on the board! =)

Welcome grivad :D

-kwag

Enter the "real" width and height first. For example if you have 16-pixel borders left and right, the real width is 688. You'd enter that in the "film pixel" box.

Hmmm... Might want to check the Avisynth forum... :)

Ah, I wish. Mine was the victim of an unfortunate washing machine incident ;).

I might be starting to sound like a broken record, but if you're getting that much of a difference between Avisynth cropping/resizing and TMPGEnc masking/resizing then your Avisynth script isn't right :).

Make sure you crop ALL borders from the source in Avisynth before running any filters on it (to reduce the work they have to do and thus speed things up significantly) and then resize within Avisynth using FitCD's suggestions.

I'm certain that if you do this you'll find only a very slight difference in the two methods (and the difference will be due to the different resizing algorithms being used: TMPGEnc's is apparently slightly less "soft" than bilinear, at least according to my tests).

Testing.... Testing ..... Encoding..... 8)

-kwag

Just watched Resident Evil (352x480, CQ_VBR 15.55) and it looks very good -- not DVD quality due to the relative softness, but still very watchable and of course a lot sharper than standard VCD. Also the bitrate was high enough that there was hardly any noticible Gibbs...

Again, though, I had that freezing at the beginning of the disc. However this time there was very bad corruption at the end, video and audio, but only in the last 5 minutes or so.

Is this another symptom of too-low minimum bitrate?

Hi SansGrip,

SansGrip wrote:
Finally figured out how to get FitCD to crop and the results were the
same as yours. I used LanczosResize which add sharpening, so when
I commented it and used Tmpgenc's resize the file size decrease was
due to no sharpening. I'll switch to BilinearResize in the future. :?
Thanks for being patient in answering my questions :)

-black prince