Quote:
Quote:
http://www.saunalahti.fi/sainki/excel.jpg |
Quote:
Quote:
I really think that "full" mode is a bad thing (no offence Luis). |
Quote:
|
Check the HC.log after you encode the clip.
It will tell you the encoded average bitrate. Isn't that what you're looking for? Cheers |
Quote:
|
You see, that's what I've been using since I started using your spreadsheet ;-).
I love to see you both working on this multi-movie proportional OPV with HC :D. Keep it going and I'll try to stay close if I manage to get some time. Cheers |
Quote:
|
@Phil
The original HCEnc zipfile distributed by Hank with his ftpd, already comes with a file named Template_HC.ini inside. Change that filename to HC.ini and edit it. You will see that it have the settings for a logfile. Edit the path and the name for the logfile. Open it after you encode search in the end of the logfile and you'll find the figure for the avg bitrate. BTW, if you keep encoding with that HC.ini, you will see that every encode will be added to that file! So beware because the file can have the logs for zillions of test encodes :idea:. Cheers |
Quote:
|
Re: Noob question about drag&drop (don't work in my case
Quote:
|
Quote:
My thought was, if we use complexity mode only, the bitrate differences will asign more space to the stream that need it, related, not only with complexity but with movielength also. But I still can't round it completely in my mind. |
Quote:
The samples are encoded in CQ mode (not cq_maxbitrate), as if I want a complexity analisis, I can't to cut those spikes because the sample wouldnt be representative. So ProCalc Lite manage HC to encode samples in CQ mode (not cq_maxbitrate). |
Quote:
But I think that a stream in CQ will have more size that one in CQ_maxbitrate, with same source, despite the avgbitrate be the same. |
Quote:
But maybe this is why ProCalc Lite gives you different values (a programtion error) as I used final sample size as value for the calculation. |
In my opinion, the complexity should be measured with the final settings in mind. That is, the same matrix, same bitrate boundaries, GOPs etc. That way you can ensure that there'll be a fair result for all clips involved. As Phil's sample showed, there can be huge spikes which can then cause a serious bias towards the clip regarding bitrate. In the final encode, you always have to clamp to the max bitrate anyway :wink:
|
Quote:
Don't worry Phil. In a previous post you can read that could be a programmation error. What is for you the better way then, complexity mode maybe? I think fixing full mode it would be still the better way. I noted (now I explain myself why) that was better to put similar time movies. Also it is not convenient to put fullscreen together with widescreen, as fullscreen movies eats excesive bitrate. |
Hi,
That's true that I didn't try to d&d various selected file... :oops: (And I just see that you put AVSs ... ) I think the problem with the full mode is that you are already using a sample, which have a length proportional to total frame number (5%) So you encode 2 movies, one 2 time longer than the other, your encoded samples will already consider 2 times more frames, and so, with igual complexity, will have a sample 2 times bigger... So I think that the complexity mode, which use the sample size, should already take into account the length of the movie and the "complexity", and should be enougth. Salu2 Fabrice |
Quote:
Quote:
Do you have in mind that for the same bitrate, the longer movie will already take more space than the other ? So if you also give to it more bitrate, it's completly amazing. Return back to my two movies that have the same complexity : with the same bitrate, the 2hours long will take 66% of the DVD and the shorter will have 33% (2/3 - 1/3) With aspa that gives the double bitrate to the two hours, this one will take 80% of the place (4/5 - 1/5). Can you tell me what in your mind justify this for two movies with the same complexity ? I want to understand. Taking two movies that are close in time just reduce this effect but do not justify it. Quote:
|
Quote:
|
Quote:
|
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.