Ok.
Yes it is, because this type of frames are build from previous and next frame so this is like "two step forward one step backward" process.

Not necessarily, because I'm almost positive that when you play on a standalone, the mpeg decoders just read the first header, and set up the decoding for the rest of the material. The sequence header is a 32 bit field, hexadecimal 000001B3
After that, you have two 14 bit fields, which identify the horizontal size and one for the vertical size.
Next you have one 8 bit field, where the high nibble (4 most significant bits) are the aspect ratio information, and the low nibble is the frame rate code.
Next a 18 bit field, which is the bitrate value.
Next is a one bit field, the marker bit, which is always set to 1.
And the next field, the one we want, is the VBV biffer size value, which is 10 bits.
So to put it in English words :lol:, the byte offset (counting from 0 ) after the sequence header, the least significant 4 bits of byte offset 6 and the 8 bits of byte offset 7, is where the VBV value is stored.
Hope you got all of that ;) Nope. Any MPEG stream can be "signed"( AKA inserting comments ), but that is in a "System Video + Audio" and not on an elementary stream, such as a .m2v. So you could use VBVPatcher with TMPEG files too. That's right, there's no need :D One day ;)

-kwag

Yea, that is another reason why i chose a wierd resolution to encode my earlier test..I knew that it could be easily patched to a standard resolution...the same applies to VBV as well...

No, it's not the same principle :!:
It's not the same to "pre-load" the parameters from the first sequence header, than to "fool" the DVD player to think the complete video is X resolution, when in reality it's going to be Y resolution.
So that trick just won't work on many players. I've already experienced that, and chances are that if you make an MPEG at 528x480 (patched to 704x480 or 720x480 ), it will work on some, but not all players.
The VBV issue is another story. Once the MPEG decoder sets it's internal buffer to the specified size on the header, it will have enough buffer space to process the data, basically "branding" the mpeg file to the correct requirements.

-kwag

I finished some testing....Here is a jpeg to see the results...

http://rstuff.home.texas.net/testing.jpg

I think the results are a good start - I would like to get some more input on the settings for the second pass - they are obviously based upon Xvid..

I actually tried two Xvid stat readers - on which was from Nitrogen - it read the file correctly, (no crashes) but it only returned the number of frames in the stream.....I haven't done Xvid encoding in a long time..I am a bit rusty...

yea, patching the file works fine for me...I think that my Malata is not such a bad player afterall - just maybe the drive is garbage (it will not read store bought - pressed CDs!!!) - I am curious if anyone has ever switched out the drive of their DVD player with a better one....just curious..

ah, everybody is sleeping like a baby in the old country....

At 6:44am I wasn't. But I was...a bit occupied to be here posting with you :wink:
Again I wish we all were in the same timezone :)
At lunch time guys in New York are get off bed...
This way we loose many posting time :evil:
C ya at lunch time

Nice screenhots poerschr. I am, myself, used to judge the quality of an encoding on tv screen, not by static images but I guess they look pretty good. It shows here and there some blocks but , anyway ...
How they look on your tv?
As maybe many people noticed already it's unlikely to have a straight Q line with second pass
bye

:(

Less or more :lol: Great to hear that I don't have to dig this by my self :mrgreen:

For sure (?) If it's the way that standalones will eat movies. that'g great. I already could use hexedit for VBV repair :banghead: :lol:

Well, maybe I'm talking about something else here but when I first started ever to make KVCD's, last summer, using tmpegenc, at the first attempts my player weren't able to do any fast forward, it messed up the image with green blocks after a fast forward even though it started to play the movie corectly. I finally managed to find the problem in the setting of 0 for "Output interval of sequence header " and I changed to 1. Since then I never had such a problem. So I guess my player needs to read the header at every GOP to play corectly.
bye

That's true, but probably only for VCD/SVCD playback.
Have you tried a DVD(KDVD) made with TMPEG on your player with the value set to 0 :?:

-kwag

No, I don't have a DVD writer yet. (I assume I need one in order to make a KDVD)
marcellus

You can do mini-DVD that are DVD burnt on CD media.

Hey Phil, I thought that you would be happy that I used a French film for my testing???

All in all, the movie was a little dark...but since it was 100% digital, this took precidence....I am still curious if anyone has had some experience with Xvid and how we can tweak the settings..

Hugh. Didn't noticed that. In fact I do not really read this thread, I just give soma glance at it to stay "up to date" in the discussion.

What do you mean ? Xvid as source ? Or as target ?

PS: note that Vidocq was almost completly digitaly rendered. None of the picture is 100% natural.

8O
I surely learned something new today! Do you know a burning software able to do that trick?
Many thanks!
marcellus

@marcellus
The latest Nero version has a Mini-DVD option.

@vmesquita
:cluebat:
thanks a lot
marcellus

Hya,
Yep, I started my tests on KDVD with mini(K)DVD using Nero.
Now I also use ImgTool along with DVDDecrypter.
ImgTool needs to know where the VOBs are and it builds the image to be burnt with DVDDecrypter.
Although I sense that maybe Nero is more accurate than these two, both are freeware :wink: .
Cheers

I noticed that most of the settings on the second pass are very similar (if not exact) to an early build of Xvid...I thought that sence Xvid was far more testing, we could play with the settings of Xvid to improve the second pass in ffvfw (mpeg)...however, I am a bit rusty in Xvid, I did a few encodings about a year ago, and would like some help from someone how has some more experience...for example. what curve aggression is best, I chose medium - linear becasue it would provide a nice balance between high and low bitrate scenes...but maybe high is better for more compression??? also, if I frames are busted by 10% will this make a better encoding, or does it come as too much of a cost to the P frames....

I thought that maybe an Xvid stats reader might provide some help...but, I testing the one made by nitrogen, it would read the file correctly, but would only return the number of fames in the stream...I am still searching for something that might help....but, a tweaked stats reader for ffvfw would be great...

also, I wanted to ask...I just received a copy of some video dubbed on two crappy VCRs (I hate it, but it is the only option)...most of the video is static scenes that flicker alot, it seems to me that somehow the field order got reversed...has this ever happened to anyone on VCRs??

Hi all,
... sorry, after 140 posts in this thread, I shouldn't ask this question, but...
2 pass is not working for me.
My settings:
Encoder: MPEG2 FOURCC: MPG2 Mode: two passes - 2nd pass int
Size (Kbytes) 570000
Generic: Max I frame interval: 15 Min I frame interval: 1 max consecutive b frames: 2
Motion estimation: ---
Quantization: Quantization type: MPEG Min Q 2 2 2. Max Q 25 25 25 Trellis activated
Custom tables: grayed out (default)
Masking: ---
Ratecontrol: grayed out
Credits. ---
Two passes - 1st pass: grayed out (Stats file: D:\Temp\video2.stats --- grayed)
Two passes - 2nd pass: First pass stats file: D:\Temp\video2.stats
Second pass stats file: (grayed out) D:\Temp\videogk.stats
Max bitrate: 9800
Rest: default ---
Output: Store frames to external file Raw frames D:\Temp\ffvfw2pass.m2v
Libavcodec stats: Don't use (grayed out --- D:\Temp\video.ffstats)
...
what wrong? :?: :?:
Using ffvfw last version (Jan 13 2004)

Trying 2 pass because after trying mencoder two pass,... buff really nice (even with double encoding time: hope we'll manage some day to speed it up :wink: )

@digitall.doc
First do the first pass (select it in the pulldown menu and choose the localtion where you want to store the stats file) and then do the second pass (select the stats file you stored with the first pass). These are two different steps you have to do manually.

Should work now.....

Thanx staigerpaip, didn't know :roll: .
I'll try :roll:

@digitall.doc
If you have some experiences with XVID or DivX 2pass encoding, it is pretty much like it. First pass collect informatrin of movie (and therefore in the output tab you can deselect "store frames" of any kind, it will save you some space on HD). Second pass uses stat file to beter redistribute bitrate and quantize alocation. This is whole idea of two pass encoding, and it is proven that this produces better quality than one pass. Of course not all the time. For instance TMPG produces better quality ant CQ 1pass mode, also I can't force ffvfw to produce better quality, that with one pass setings. Major improvement is that 2pass produces sharp fitted file size and respect max bitrate limit.

@Rui
Can you write mi small how2 on miniDVD mastering with this programs :?: Thx. (might be throught PM)

EDIT:
We must to split this post. It is to much about everything :lol:

Thanx all for your help, now also working for me (I never had made divx, so I was lost in two passes).
I think I already read this in other place, maybe even in this thread, but ffvfw takes 2 seconds or else of the encoding to balance Q value (begins at 4.36 and finally it levels at 2), but maybe I didn't set correctly the parameters.
I made a comparison with same source with mencoder, and mencoder was faster, and with Q leveled at 2 since the begining. About bitrate peak, was almost the same, slightly higher in mencoder.
But again, maybe is due different parameters in two tests (but same script and source).
Keep testing.