You should better "overclock" your other activities this week which do steal your time and do keep you away from 24h testings on this here!

5 postings more and I receive my first golden watch from Kwag

@ All others:

Noone else posting pic samples in here???? Come on! We want to see results from diff. users and their success or failures which could enlighten some more possibilities

Hi Inc,

Yesterday, I was also trying a GOP structure of IBBBP (3 B frames), and I think the results are better than with 2 B frames. Still to be confirmed, but I think this CODEC does produce better quality and compression!, with a 3 B frames.

-kwag

Hello everyone!

I just found this thread and I am very impressed by the screenshots and samples... If this gives such good results, maybe then it could replace CCE in D.I.K.O. as a option for MPEG2 encoding. Or maybe for real-time KDVD encoding, this would be great too (I always wanted to do that and MainConcept does not work as it should... And I won't even mention the other options). I am starting my own tests right now. (My vacation is getting over... I have to enjoy the last days!) I'll post if I find anything interesting.

Same here.

-kwag

No, not yet.

-kwag

Save as AVI, and that will start the encode.
The end result is "test.mpg", which you have to demux with TMPEG, run pulldown.exe on the .m2v (which creates "pulldown.m2v"), run DVDPatcher to fix the reporting bitrate, and mux with your 48Khz encoded audio.

-kwag

At this pace, maybe

-kwag

So you do als confirm like me that its better to use 3 Bframes in ffvfw mpeg2? Cause of the "but" in your line above.

At now I still can participate indirectly as Im at my MAC in the Office.

ok. more B Frames do give more compression in case of ffvfw mpeg2, but still we have to solve that problem on dark fading surfaces and also the fast movement-part issue. The last one "could" be solved (if its not possible within ffvfw) by MA, but this only will affect frames with full movement and where blur does not harm quality. But whats about "parts" in static frames where in case of movement that ffvfw mpeg2 comes out crispy/blocky ... well we'll see tonight! mabye...
And to me it seems that the encoder handles the DCT matrix different compared to TmpgEnc or CCE.
That "crispy-fast movement-encoded-frames" phenomenom I still remember from FFmpegX where its encoding engine in 2002/03 also did base on mpeg2enc's algorythm, maybe still it also optionally bases on mpeg2enc.

Kwag, any suggestions on my muxing problem?

Hi Kwag,
Don't have the slightest idea of what is pulldown.exe and what it does to the video stream.
Could you enlighten me on that please?
Is it only for NTSC or do PAL guys need it too?
Thanks and C ya all at page 8

__________________
Rui

@rds_correia
Pulldown is only for NTSC. There is a utility called pulldown.exe that can be found on doom9 software page. This utility enables a pulldown flag in 23.976 FPS mpeg2 files, what makes the DVD player "create" 29.97 out of 23.976 fps to play on a NTSC TV.

@all
Encoding can go a little faster (jumps from 8 to 9 fps for me) using Fast Recompress instead of full processing mode in VirtualDub.

Yes I can, "but" at a very slight file size iincrease (about 300KB per minute)
So that's about 18MB per hour. So for KDVDs, that's fine. For KVCDs, NO Shame on you. I still think this is a PAL issue, because my encodes are less blocky than with TMPEG. Yes it does. As I said before, it's a completely different motion estimation algo. There are barely any visible artifacts around objects, even on low bitrate scenes. I think the encoder is not going up high enough in bitrate. I've tried to change settings, but can't get it to work at high bitrates. Even setting MIN and MAX quality to "2" and macroblocks to 2/2. Can't say
I just finished muxing "The Bourne Identity" with MPlex, after running pulldown.exe and DVDpatcher, and it muxed without any errors. This is the second movie I've encoded with this CODEC since yerterday, and the result is flawless. But you know I'm on NTSC, so maybe that's why I don't get errors (or blockier picture ).

-kwag

As far as I know, there is only two diff between NTSC and PAL : the framerate and the resolution.
For the resolution we can't do anything. But if the problem is in the framerate, you can try to encode with a "AssumeFPS(23.976)" in the script and as you are in DVDPatcher, set back the fps to 25.
This way the encoder will be fooled and think it encodes NTSC but the player will see a regular PAL to play (remember to use a valid PAL resolution).

In my case the opposite as you see above, in general I got less filesize and therefore more compression + Quality with 3 B frames must be the colder weather in germany
Well as I tested it also on 23.976 encodings, therefore same in NTSC as in PAL, ...... BUT we'll see this evening more, I hope you all will be online.

Exactly that I did Dialhot, Assuming the FPS to 23.976, resizing to NTSC specs. and did several encodings.

Ähm ... are you shure your workout above with simple mpeg patching will restore the playback speed afterwards? I don't think so.
That would mean you just take a 23.976 enoded DVD m2v - doing the FPS patching - pitching the audio to 25fps - burn

How can a player know the framerate to use if it is not by reading it in the header ?
The video stream by itself do not contains information about the speed you have to read the information. That is the purpose of the header !
No ?
I said taht there are two differences
You can't do that because of the resolution.

Well (generally) the header does not provide everything, also many thing are in the encode itself, thats why a Pulldown flag with pulldown.exe won't be applied just in the header as Pulldown.exe rewrites (not reencodes) the specs. in the whole stream .... and thats I think not only a thing of seq headers. Also the 23.976 to 25 (patching) won't correspond good with the timestamps(timeline) in the mpeg stream as that you also can set in CCE for example, .... but that are all estimations, ... so we should check this out .... cause I've never heard about such a patching method elsewhere

EDIT: in my Cyberhome Player the resolution won't be a problem as its also be able to play back 480x480 or 704x480 streams at 25 FPS

I was thinking about distort on the TV set. How is the image on your TV when you do such things ?

Just did my tests. I got a 3m04s chapter from the Lawnmover Man DVD and encoded with the latest MA script at 704x480 using:
- FFVFW - quality 100, Max quantizer 25, B frames 2, KVCD notch matrix, I frame interval (GOP) 18. Using Fast Recompress. Size: 33.504 kb.
- CCE - my 704x480 template, also using kvcd Notch, at Q40: 33.353 kb.

Both encodes took about 8 minutes, what surprised me a lot, since I espected FFVW to be a lot slower.

I tried to used the script below to find any difference in quality, scanning frame by frame:

c=mpeg2source("test_ffvw.d2v")
d=mpeg2source("test_cce.d2v")
return(stackhorizontal(c,d))

But nothing called my attention in respect of quality. So I decided to use SSIM (http://forum.doom9.org/showthread.php?threadid=61128), which is a avisynth filter that computes the quality metric, based on perceived distortion and not only on mathematics. According to the author, it should correlate very well with the human eye. This filter receives two clips as input (the original and the encoded) and gives a table with the coeficients for every scene and a median of all of them.

To compare, I create a huffyuv version of the chapter, already processed by the MA script.

The results were very surprising. The final value is between 0 and 100, and the bigger the value, the great the quality. Check this:

CCE:
SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 55.22

FFVFW:
SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 83.64

It' scary how better FFVFW performed agains CCE according to SSIM. I'll tried to create the same clip with TMPGENC but forgot to change the template and did it at 720x480. But I'll do it again and post the results. To me, looks like this is THE encoder for MPEG2.

@ Phil

Well the cyberhome to me seems that he just simply reads out of the Header the Aspectratio and increases whatever he gets to the pal 704x576 which will be delivered to the Tv Set.

Ok, as NTSC doesn't got that much pixelinformation/resolution like PAL, it doesn't look that detailed, because its resized to 704x576.

But motion is smooth and appears ok, but I do not see that advantag to go from 480x576 to 480x480 both 25FPS. Maybe 480x480 will give a little more CQ but on the other side it has to be stretched afterwards the more little artifacts cause of less size and therefore more CQ will be again scaled afterwards and sometimes do look if you would have directly encode that at less CQ from 480x576 but its not that sharp!. Ok, it depends of the Tv Set quality.

For those of you looking for more speed the 20039027 build is faster.

Hey Kwag, I don't know about Milan but I do know Athos (he did the more recent builds) is active at doom9. Cheers.

__________________
-Dano

Not scary at all
It confirms what my eyes have been seeing in the clips I've been encoding

-kwag