This forum is for users to exchange information and discuss with other users about a TMPGEnc product.
In case you need official support, please contact TMPG Inc.
Pegasys Products BBS [ Sorted by thread creation date ]
Hi,
I'm using 2.52 for MPEG-2 VBR coding and I've faced a number of serious issues:
First of CQ_VBR seems to generate the same exact output as CBR, given that they are both set to the same bit rate; no matter how I vary the quality of CQ_VBR. How can this be??
Secondly, how do I get a CBR coded video at nominal 4000kbps with peaksof 4435kbps. It really does not sound that constant...
Thirdly, I'm using JNDmetrix software from www.sarnoff.com for subjective video quality analysis, and no matter what I try, all vbr combinations turn out with worse quality than cbr. To my knowledge, all theory points to the exact opposite. I'm pretty sure JND isn't the problem as I've seen it used by a number of companies in a number of white papers.
these are all problems with the older versions,most of these problems have been solved in the new "2.53.130.plus" version,try it, it is not only better but faster,and has many more options....i have allways had better results with "cbr"
unless I use multiple passes,but for multi pass encodeing I like to use "cinema craft" cuz it can do up to 9 pass encodeing at 10 times the speed,but it costs $2000,so your better off with "tmpgenc" unless you got money to burn....later sherlock
Hi,
I am in fact using 2.53.35.130 plus...and the problems are still there.
Secondly, it doesn't make much sense that cbr achieves better quality than vbr. video is inherently variable bit rate. This means that generally cbr has to contend with an added limitation, namely that of re-enforcing its bit rate limit on a per GOP basis. this means it has to use the same amount of bits for every GOP. VBR on the other hand, generally boast rate control algorithms that allow it to use more bits on fast changing GOP sequences and less bits where the GOP sequence is relatively still, hence achieve a much better quality. this is why I am doubting TMPGenc's VBR coding.
Finally, multi pass is not really an option to me. My final setup would involve real time encoding for transmission over a network. Multi-pass is therefore not an option is such a scenario as the coding delay would be unacceptable.
Victor....the 9 pass encodeing is exelent,and it is better that cbr,but they are 2 different programs"tmpgenc"and cinema craft" but in tmpgenc I haven"t noticed much differance....
That sounds like a load of interesting waffle you just spouted Joseph, but you obviously don't know how to use the bitrate settings in TMPG.
Ofcourse VBR will give better quality than CBR if you set it it right!
There are three settings you must take care of. One is Maximum bitrate, one is Minimum bitrate and the other is Quality.
The quality slider is probably the equation which you are leaving out.
Lets say we want to create a movie with a lot of action. This movie is going to create a lot of high bitrate peaks. So what we need to do is up the maximum bitrate to a point which will create an acceptable looking movie without many macro blocks. Now you cant just up the bitrate and expect TMPG to use this bitrate. What you must do is push up the quality slider. The higher you push the quality slider the more bitrate will be used to encode high bitrate scenes.
If you don't up the slider when you up the bitrate then TMPG won't use the maximum bitrate because you have told it to keep it at a certain quality. For instance you could set the bitrate to 10000kbps, but if the quality slider is set low say 50 the full bitrate will never be used and will be kept at something like a maximum of 5000kps.
The opposite is also true of the slider if you set say a maximum bitrate of 2000kps and up the slider to 100 then this won't give you any better quality than if the slider was at 50, because you have 'capped' the quality by reducing the maximum bitrate ,so the slider will lose any effect after 50.
The same goes for minimum bitrate if you set it too low and set the quality low then when a a particular scene in a movie only needs a low bitrate the bitrate used may be to low for the actual scene, macro blocks will then appear. If this is the case then the minimum bitrate needs to upped to ensure TMPG allows enough bitrate for the scene so the bitrate doesn't go short and macro blocks start to appear.
With CBR the Bitrate is kept at an 'average' constant. I say average because the bitrate isn't absolute it still varies by a few hundred kbps it's just whats called a nominal bitrate.
Using CBR if the movie requires more bitrate and the bitrate is set for a nominal 1150kbps, the result will be capping and the picture will have macroblocks due to the fact that there is not enough bitrate allocated for that scene.
The way to set the Maximum and Minimum is to find two points in the movie. One with low action and detail the other with high action and lots of detail.
Encode a minute of the low action using a particular bitrate minimum of say 300kps and see if this is acceptable quality if it isn't keep encoding with higher minimum bitrates until it looks acceptable.
The same goes with High action. Encode a minute and check the result if everthing looks ok you may be able to reduce the bitrate, if not up the bitrate, but remember upping the bitrate also requires an increase with the quality slider.
This way you will be able to encode a movie that uses acceptable minimum and maximum bitrates.
On a final point the maximum bitrate for MPEG1 is set at a nominal 3500kps, so to achieve this the quality slider needs to be 100. No matter if you set the bitrate to 10000kps, this much bitrate will never be used. This is not the fault of TMPG, but this is set as the MPEG1 standard.
If you want my advice use 'Constant quality (CQ)' as this will give much the same results as a 2 pass encode and better than 'Automatic VBR (CQ VBR)', but works in almost the same way.
Hi Ashy,
Thanks for your detailed reply :) there are a couple of points however maybe I was not clear about. First of all, I was aware of the quality bar...What I did was the following:
1) encoded a sequence of 15 secs with 4mbps cbr.
2) encoded the same sequence with CQ: quality =100, min bitrate = 0, max. = 4Mbps.
In this was, I am applying the same cap as cbr and i'm telling the encoder to throw in the best quality possibly (bar = 100), given the 4mbps limitation. At worst I would therefore expect the same subjective quality as the CBR file. The result however demonstratesthe oppisite, as when I used my subjecte quality analysis program, it reported a worse quality for vbr!!!
Also note that when encoding in this way, the output vbr file was larger in size than the cbr one (the encoder spent more bits). Hence one would expect a better vbr output!!! This is why I'm questioning the vbr implementation of TMPGenc.
Two other questions now:
1) Do you know what CQ_VBR actually is? No matter how I varied this, it have me the same output as CBR...
2) Do you know whether CQ in TMPGenc implements the capping at the GOP level? I know thaqt CBR does so, but don't know about CQ.
Cheers,
Joseph
I don't know if this is the root of everyone's tmpgenc crashes (the common problem with mpeg files), when using windows xp, but I checked to see what was causing the problem and it was a .dll file called mplam6.dll which is part of a Ulead package I had installed.
The file was in C:Program FilesCommon FilesUlead SystemsMpeg on my xp machine and after I renamed it to mplam6.dll_ it no longer causes tempgenc to crach.
I'm not 100% on this Techno may have a better idea, but I think I'm on the right lines.
The operating syetem cache works in a way to speed up file access.
What happens when a program requests a file, is that the operating system reads ahead of that file and 'guesses' what part the program wants next and puts it into memory ready for the program while it finishes what it is doing with the current part of the file.
This speeds up the access to the file rather than having to read it off the disk thus speeding up encoding within TMPG. So don't turn this function off or you will get slower performance.
I don't think its a bad file.
this fault comes on all files with this resolution,
everytime when the result mpg file is approx. 230MB on the HD.
(-> the fault comes always approx. after 65% encoding)
I use already separate audio and video files
(My normal way:
- PVACut
- PVAStrumento to demuxe audio and video
- DVD2AVI to make project file
- TMPGEnc
)
By the way, I can't use TMPGEnc to encode files with
the resolution 720x576 in W2K, the program terminates after a few
minutes completely without any error message.
Other user told this too, what could be the reason for this?
Any solution?
This looks like it's an area of memory that TMPG is trying to write to which can't be accessed and is already being used by something else.
Have you been playing with your BIOS by any chance. Try turning off any shadowing in your BIOS. i.e BIOS shadowing or Video card shadowing as these use certain parts of memory.
If anything tries to write to this address in memory you will get the 'Write address' error. Also shut down any programs running in the background such as memory managers or task schedulers as these may be hogging memory.
When given an .m2v file extracted from a directivo (see www.dealdatabase.com direct tivo extraction discussion for tools and data) format is 480x480 mpeg 2 progressive vbr. Tmpgenc only sees 1/4 of the true number of frames. For example: In a one hour clip with 100,000 frames (approx) it will report the length as 25000 frames and length as 15 mons. In a encoding pass, only 25000 frames will be processed. If the preview is used, you can see the entire file (1 hour worth) but again it reports the last frame as 25000 not 100000 and ending time as 15 mins not 0 mins even hough the pictures seen in the preview at the end of the clip are the correct end of the 1 hour clip.
If audio is multiplex'd in before transcoding usinf mpeg tools, simple mux, tmpgenc correctly sees the true frame count and time in the mux'd file.
Hi,
I've come across this too just this morning. I'm using sequences .m2v available at ftp://ftp.tektronix.com/tv/test/streams/Element/MPEG-Video/625/. the sequences are 375 frames in size. When encoded to cbr 4Mbps (i used the 40Mbps ones as a source from tektronix) the frame size was reduced to 350..., basically chopping off the last second of the sequence.
Joseph
I encoded an AVI with this program at mpeg1..and used Nero to burn it...but it doesnt work...is there a way to play these in PS2...can someone send me a guide or something...thanks
A choppy playback is indeed what's happening. I use a DVDplayer to play de VCD's I make. I'm using the template which gives 'Video-CD PAL (MPEG-1 352x288 25fps CBR 1150kbps, Layer-2 44100Hz 224kbps)' which fits the Dutch television standard.
Maybe it is caused by the template? I'm using the right template. So all the VCD I'm using have this problem.
Ashy wrote:
Now there is a way to acheive the correct framerate for your T.V. system without the choppy playback and have perfect A/V sync, but I'm not going to post the instructions on how to do this unless you repost and request them as I don't want to waste my time posting incase you do not read this post.
My answer:
I'm very interested in your post. I've read it and I hope you wil post the instructions. So do others? Thanks in advance...............
By example, a Star Trek avi file:
Source: MPEG-1 640x480 23,976fps CBR 1500kbps, Layer-2 44100Hz 192kbps
Destination: Video-CD PAL (MPEG-1 352x288 25fps CBR 1150kbps, Layer-2 44100Hz 224kbps)
What's all this re-install. TMPG doesn't install. It runs from the executable.
First have you actually unzipped the files in the TMPG zip. It won't work correctly if you just run it from inside a zip file.
Next if that doesn't sort it then delete this file CurrentCfg.tpr from your TMPG folder and if non of the above works, you've got a dodgy copy. Download it again.
1. I ripped it using Smartripper 2.41, which automatically
creates a .d2v (DVD2AVI) project file.
2. Installed (ran) DVD2AVI 1.76
3. Installed (ran) TMPGENC 2.53.35.130
4. Ran VFAPI batch file
5. For the audio file, I used XMPEG 4.2a's extract to WAV file feature
6. Opened the D2V file in TMPGENC
7. Set the audio part to use the extracted WAV
8. Loaded the NTSC VCD template
9. Hit "start"
After an hour, the video was off synch with the audio.
I resampled the audio from 48 to 44.1 khz but the results
were the same.
Can anyone help? The audio is correct (26 mins) but the
video seems to be going too fast (20 mins instead of 26).
Where do I make the adjustment on the frame rate and what
value should I put in? 23? 29? It's driving me crazy.
the frame rate should be the same as the source avi. file,and maybe try de-multiplex and multiplex.....I used to have sync problems but now I encode at 2000kbs for vcd,and for some reason the sync problems are gone and the quality is awesome.......
>Hi, just wanted to ask about my problem:
>
>Can anyone help? The audio is correct (26 mins) but the
>video seems to be going too fast (20 mins instead of 26).
>Where do I make the adjustment on the frame rate and what
>value should I put in? 23? 29? It's driving me crazy.
When using DVD2AVI you need to check the force film option.
No DONT use the force film option this will give you the wrong frame rate. Who the hell told you to do that.
The output frame rate should be the same as the source frame rate other wise the movie will be jerky. If the source is NTSC at 29.97 then the output should be the same.
If the movie is MPEG1 make sure the audio is 44100khz.
The audio should not de-sync, so check the length of your wav first. It may be that the Xing encoder is producing a different length wav than the original movie or what can happen is the movie has not encoded properly as has happended to me. If you are seeing a lot of strange blocks and glitches on your movie then this can sometimes shorten the movie as these errors are missing bits of information.
Ignore Ashy....Going by the information you have provided indicates that the REAL frame rate is probably 23.976. If you know the length should be 26 minutes and your audio is 26 minutes then the audio is also probably correct.
Now if we do some simple math: 26 mins x 60 secs =1,560 secs.
Lets assume the 23.976 theory. 1,560 secs x 23.976 = 37,402 frames
Now if we decoded 37,402 frames at the wrong frame rate (29.98)
37,402/29.98 = 1,247 secs or guess what...about 20.5 minutes
Everytime I try to open an mpg the program crashes, this is a great program and i hate to lose it just because I've switched to XP, Please can someone help me!
How do you set "compatability mode"? I do not see this as an option under Environmental Settings. TMPGEnc crashes every time about 1/3 of the way into a MPEG2 to MPEG1 mux session. I have tried everything. I am running a PIII-850 with 768M RAM and using Win2000 Pro. TMPGEnc runs fine with my Athalon 750 under Win2000. Thanks.
Thanks for the reply Techno, Tried all you suggested but still no joy,
Mpeg1 is what I'm trying to open and it's any I try, I have a big problem some where, Or I have something missing, But I'm all outta clues!
I have the same problem. I've used tmpgenc in XP before when i first got it. But now when i try to load an mpeg, it kill the program and want's to send an error report. I've tried compatability mode too and that didn't work. Please Help!!
Fixed it! kranky22 you need "Nimo Codec pack 5" I found and installed it and no more crashing, Something to do with "DirectShow Multimedia Files reader" which
TMPGEnc uses being over written, Either way it worked!
I am encoding an avi that was captured from a miniDV camcorder using Microsofts capture program tah comes with WinXP. Vertical lines like the corner of a wall or cabinet look fine in the original avi. When I encode the avi using the DVD template in TMPGEnc at 8000kbps (all default settings) the vertical lines are wavy when the camera pans. Any help in correcting this would be greatly appreciated.
I think that only using one field would reduce the resolution by 1/2, no? I am trying to find a way to eliminate the wavy verticals and keep the resolution.