01-27-2004, 02:12 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Here you go people 
Another sample, this time a Full Screen KDVD sample, WITHOUT any filters
http://www.kvcd.net/ffvfw-bourne-ide...creen-test.m2v
Do we really need another encoder 
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
-kwag
|
Someday, 12:01 PM
|
|
Site Staff / Ad Manager
|
|
Join Date: Dec 2002
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
|
|
|
01-27-2004, 02:21 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Germany
Posts: 390
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
That's really great quality, Kwag
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.
|
01-27-2004, 02:24 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by Krassi
That's really great quality, Kwag 
|
Yeah, I'm beginning to fall in love with this CODEC Quote:
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.
|
Maybe a PAL issue
-kwag
|
01-27-2004, 03:05 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Germany
Posts: 390
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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...
|
01-27-2004, 03:18 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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
|
01-27-2004, 03:24 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Germany
Posts: 390
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by kwag
But how is the quality, compared to the samples I posted 
|
Awful
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).
|
01-27-2004, 03:34 PM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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.  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
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  phantastic!
But on uneasy surfaces (even easy surfaces/fadings)  more stairs like in comparison to tmpgEnc at the same avg bitrate.
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.
|
01-27-2004, 04:03 PM
|
Free Member
|
|
Join Date: May 2003
Posts: 10,463
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by incredible
But I can't copy that exhusiasm (at this point)
|
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.
|
01-27-2004, 04:14 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
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
|
01-27-2004, 04:16 PM
|
Free Member
|
|
Join Date: May 2003
Posts: 10,463
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by kwag
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 
|
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.
|
01-27-2004, 04:35 PM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by kwag
You can have a larger size, and slightly quality, by making a shorter GOP.
|
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 =
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!
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  quality here rises also.
|
01-27-2004, 04:38 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Germany
Posts: 390
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
BTW, 2-pass is working for me.
Another thing to test
But CQ-mode seems to be better (IMHO).
I still cannot achieve kwags samples
|
01-27-2004, 04:43 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by Dialhot
It's true that telling "the sample is uggly" means nothing if there is no other encoder that can do better.
|
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 
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
|
01-27-2004, 04:44 PM
|
Free Member
|
|
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
|
|
Who Huuuuu!
Hey, I see that now we're rocking
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
Cheers
__________________
Rui
|
01-27-2004, 04:55 PM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
|
01-27-2004, 04:58 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by incredible
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 =
IPPPPPPPPPPBPPIPPPIPPPIPPPIIPPPPPP
|
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
|
01-27-2004, 05:02 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
@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
|
01-27-2004, 05:02 PM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Rumble in the Jungle
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  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.
|
01-27-2004, 05:06 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by incredible
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  quality here rises also.

|
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
|
01-27-2004, 05:09 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by incredible
I do not trust Bitrateviewer, I do trust my eyes  WYSIWYG
(maybe I'm wrong) 
|
True for MPEG-1. But for MPEG-2, bitrate viewer reports an accurate quality curve. Quote:
BUT THAT CODEC seems to be promising, I think we didn't got the optimal settings now, thats all.
|
You're right 
It's going to be a whole new ball game when we finish ooptimizing this stuff
-kwag
|
All times are GMT -5. The time now is 01:20 AM — vBulletin © Jelsoft Enterprises Ltd
|