KDVD Sample #2
 

Here you go people :D
Another sample, this time a Full Screen KDVD sample, WITHOUT any filters :cool: :!:

http://www.kvcd.net/ffvfw-bourne-ide...creen-test.m2v

Do we really need another encoder :?: :mrgreen:
I don't think so :!:
BTW, my Red Planet encode, multiplexed perfectly WITHOUT any overruns or underruns :!:
So there are no errors on the MPEG stream produced by this CODEC :cool:

-kwag

That's really great quality, Kwag 8O

On my first test filesize was a bit big (using filters). I'm trying to reduce CQ now. A quick calc showed a final size of 2 GB for a 90 minutes video @CQ100.

Yeah, I'm beginning to fall in love with this CODEC :mrgreen: Maybe a PAL issue :idea:

-kwag

With a CQ of 60, i would get a filesize of 495 MB for a 90 minutes movie.
A longer test confimed that with a CQ of 100 final size would be near 1.8 GB.

I'll try next with a CQ near 90.

I wonder how you achieve this without filters. I'm using the latest optimal script at the moment.

Next try will be without filters.

EDIT: Without filters, size is 40% bigger...

Hi Krassi,

The issue is probably related to PAL and the matrix.
So you'll have to lower the quality % lower than 100, as you've already done.
But how is the quality, compared to the samples I posted :?:

-kwag

Awful :twisted:
The sample you provided is much sharper, mine has mosquitos and blocks everywhere. A comparable CQ/filesize with yours would be under 60, but this is unwatchable. The only difference i have regarding your settings (the one you posted in this thread) is the "Maximum i frame interval" which i changed to 15 (PAL).
I'll do a further test with another source. Maybe its source related. Currently i'm encoding a video capture from TV (pva).

As seen in an average nice Quality on very low bitrate encodings!

But I can't copy that exhusiasm (at this point) as to me it seems that this encoder gots problems on surfaces! Do try to encode a underwater movie like U571 i.e. :arrow: fading surfaces got uneasy "stairs".

BUT Im still testing more, so that's only my answer now, but that could change when going more deep into ffwfv settings :wink:

Here some Pics:

All from the same Movie! And the same encoding turn!
- Quality 95
- 10% encoded via Slicer()
- GOP 15 IBBP Sequence
- 1/2 DVD size 352x576 PAL
- AVG 951kbit
- endsize 6852 kb

Very interesting, on complex and VERY dark parts :arrow: phantastic!
But on uneasy surfaces (even easy surfaces/fadings) :arrow: more stairs like in comparison to tmpgEnc at the same avg bitrate.


http://www.digitalfaq.com/archives/error.gif

http://www.digitalfaq.com/archives/error.gif

Even if I get up to Quality 100, the "stairs"/artifacts in surfaces won't get away!
To me it seems a strange quantisation allocation according to surfaces? :?

And, if just setting ONE B frame, the stream comes out just using IPPPPPPPP etc.

Me neither !

On the sampel of kwag (bourne identity), don't you see the blocky face of Matt Damon throught the window of the Mini ?
Don't you see all the mosquitos around the moving car (the police car at the beguinbing, and the red mini when you see it from behind before it does a sharp turn) ?

Okay these are little defaults for a fullscreen sample. The problem is that, if I undestood well what you wrote (I read quicly), this sampel is done with the maximum quality you can set ? So there is no way to have a better things, either if the size would be a lot bigger.

I have to make some tests off my own, espacially to see what happens with some filters.

You can have a larger size, and slightly quality, by making a shorter GOP.
But I compared this same movie encoded with TMPEG, and this just blew it away :!:
I would like to see this compared to CCE's MPEG-2. I think this it better too :!:
TMPEG produces FAR more artifacts around objects, at the same file size than this CODEC makes. It's an amazing motion estimation algorithm :!:
I'll try to encode a couple of clips of this film with TMPEG, so we can compare.

-kwag

These are the tests I want to make also in fact :-)
It's true that telling "the sample is uggly" means nothing if there is no other encoder that can do better.

Kwag the problem is that the GOP seq allocation is horrible! Its very arbitary, now I did again set to 15 min and 15 max with 2 B frames allocated.

I open the m2v and checked the GOP. Reslut = 8O :evil: :?:

IPPPPPPPPPPBPPIPPPIPPPIPPPIIPPPPPP and so on

Means: the B frame allocation sometimes doesent follw the settings of IBBP...

AND everytime a scenechange happens, the GOP resets to an I frame, even min 15 and max 15 of I frames in the interval is set.

To make larger streams, you shouldn't reduce the gop, but reduce the quatizers! :arrow:

http://www.digitalfaq.com/archives/i.../2004/01/6.jpg

As you can see the min Quantizers and the max quantizers.

The less you quantize, the large the file gets.

"Like" in our tmpgEncs CQ settings, where we do determin the min and max bitrates.
In here it means: Quality will be the dynamic quatizer between the min and max quantizer settings.

So set min quantizers to 2 and max quantizers to maybe 10 and you will se that with the same Quality setting the sample size will blow up :arrow: quality here rises also.

;-)

BTW, 2-pass is working for me.
Another thing to test :lol:

But CQ-mode seems to be better (IMHO).

I still cannot achieve kwags samples :roll:

That's right, and these samples speak for themselves ;)

http://www.kvcd.net/tmpgeng-test.m2v
http://www.kvcd.net/ffvfw-test.m2v

Pay special attention when to the second scene on the samples, and look at the building walls.
You'll notice more "noise" specially in the walls and small details, with TMPEG's encode, and ffvfw are far FAR cleaner.
The TMPEG sample I encoded, was using a MIN of 300 and MAX of 3,500.

Drag those mpeg files into Bitrate viewer, and look at the quality curve :!:
Look at the non-linear curve that TMPEG creates, versus the flat, "true" constant quality created by ffvfw :cool:
BTW, the file sizes are only about 150KB in file size difference, with ffvfw's sample being the largest. But 150KB is a neglgible difference for this test.

-kwag

Who Huuuuu!
Hey, I see that now we're rocking :twisted:
Just 2 or 3 guys aren't enough for the task in hands here.
I'm just so sorry I won't be able to follow up with the testing today :?
My boss gave some homework that I'll have to finish by 24:00 or else...
Anyway I'll pick it up tomorrow, and I'm sure I'll have a coffee break in 1h just to see how it's going :lol:
Cheers

:D

:?: But maybe I'm doing something wrong (but I don't think so :D), btw... 2pass crashes ... and there I think I'm doing something wrong :?:

http://www.digitalfaq.com/archives/error.gif

I think you're doing something wrong, or there's something going on with PAL :!:
My GOP is a clean IBBPBBPBBP.... etc.
Did you demux with TMPEG, and drag the .m2v into bitrate viewer :?:

-kwag

@incredible,

Try those samples you encoded with the standard MPEG matrix. See if it's any better.
There might be a problem with the combination of matrix/PAL/CODEC.

-kwag

Rumble in the Jungle :D

Well, ..... why Bitrateviewer?
See this post of mine:
http://www.kvcd.net/forum/viewtopic.php?t=8551

I do not trust Bitrateviewer, I do trust my eyes :wink: :arrow: WYSIWYG
(maybe I'm wrong) :?

EDIT: Well, lets see if that DCT is influated by the framerate, which to me that would makes no sense
(just downloading your last samples)

BUT THAT CODEC seems to be promising, I think we didn't got the optimal settings now, thats all.

Yes, I already tried that, but although the file size increases, the quality stays the same.
When I set MIN and MAX to a value of 2, the file size was larger and the MIN bitrate was also higher.
But quality wise, there was really no noticeable change.

So I stick with a MIN of 2 and MAX of 25 (25 to keep a higher MIN bitrate above zero), and this way I can forget all about prediction ;)

-kwag

True for MPEG-1. But for MPEG-2, bitrate viewer reports an accurate quality curve.You're right :!:
It's going to be a whole new ball game when we finish ooptimizing this stuff :mrgreen:

-kwag