|
|
| i4004 |
| Posted: Aug 24 2005, 07:06 PM |
 |
|
Advanced Member
Group: Members
Posts: 2432
Member No.: 4935
Joined: 24-June 03
|
| QUOTE | | It's DRFanalyzer maniac on wanting an averageDRF of about 2.8 (and it seems to want double-quad-mad bpp other than you were suggesting here) |
i like you frank!
| QUOTE | | But I made also Divx5 encode at 2000k and 1200k on the 512x384 and it gave me worse results than same bitrate on Nandub... |
and you didnt even tried the nandub_onepass
(it's trying to keep the kf quants closer to 2, and the damn i/o windows are not arranged in vertical manner.)
btw. uncheck the 'end frames correction' in drf.
| QUOTE | | btw: I think I will open a thread on nandub & ffvfw-mpeg4 settings and I hope the world's guru of msmpeg4v3 will shed light on these settings. |
and he will.
but most deafults there work quite good.
inspect the undercut's table "More details on Compression Levels and Bitrate". this can be the start of your learning curve about 1pass-limited-quants-abr mysteries.
offcourse, the aim is always to get as low average quant as possible, but this
| CODE | DivX DRF Analyzer v0.9.5 Report!
File Name: D:\Video\Finished\Muæke\Happy Returns[21st February 1984].avi
FourCC: DIV3
Codec: MSMPEG4
Resolution: [ Width: 512 Height: 576 ]
Frame Rate: 25.000 frames per second
The Video has 45763 frames [ 00:30:30 ]
Average Frame quality is MEDIUM [Average DRF/quantizer is 4.25]
Standard Deviation: Quality is MEDIUM [Std. Deviation is 0.91]
Image Resolution is MEDIUM
There are NO frame drops ( NO drops is better )
Recomended Resolution: [400x464] (Target DRF/quantizer=2.8)
The filesize should be larger!
Performance Caracteristics:
Macroblocks per frame: 1152 ( Poor Playback in Slow Computers, PIII450 or better required )
The Width is multiple of 32
Kilobits per Second: 1600.46
Kilobits per Frame: 64.00
Kilobits per Macroblock: 0.056
Bits per Pixel: 0.22
Frame Quality Statistics :
DRF=1&2: 188 0.4%
DRF=3: 8372 18.4%
DRF=4: 21485 47.3%
DRF=5: 11430 25.2%
DRF=6: 3053 6.7%
DRF=7: 856 1.9%
DRF=8: 0 0.0%
DRF=9: 0 0.0%
DRF>9: 0 0.0%
KeyF/DeltaF: 0.84%
KeyDRF<4: 76
KeyDRF=4: 270
KeyDRF>4: 33
AverageKeyDRF: 3.90
MAXDRF: 7
AverageDRF: 4.25
Deviation: 0.91
http://www.geocities.com/analyzerDRF/ |
looks just fine if you ask me.
| QUOTE |
I've read in that t3d, that card resizer are worse than bicubic filter in VD, but I think you were talking of BT chip and ONLY of it. Because Philips seems to be very good as you were saying previous you capture at 512-576-384... |
bt is (horizontally) also good...but not if image is lower than 400 (ie say 396x576 on btwncap is crap).
philips doesn't have this problem, true.
it is btwincap issue.
vertically they all suck. if u wanna use vertical resizing on capping use vdub's.
| QUOTE | It could be:
1) capture at 720x576, 640x576, 576x576...384x576
2) get the 720x576 and resize (VD lanczos3) to 640x480, 512x384 (other resizing res? 576x432?) |
in such test you shoud notice that preserving the raster (576) means more than preserving horizontal.
offcourse, we talked about compromises too. 
| QUOTE | | (Another resize at 720x576 for all res...?) |
yes. only i used 768x576.
| QUOTE | 3) output with zplayer at correct AR and capture all res at 720x576
4) compare frame in Photoshop.
The resulting pics will be worse than what you really see on TV or monitor, because of this second capture, but it is an equal mode for all the resolutions, so it should be an objective test. |
yes, that should work too.
i use irfanview.
what is "photoshop"? 
s.
| QUOTE | | it is not true that frame A with q4, looks necessarily better than frame B with q6. |
true, no doubts.
totally black frame looks same on frame 31 and 1.
stephan, you're taking this a bit too far.
drfanalyzer is not bollocks at all. suggestion it gives is just that--a suggestion. who cares. but numbers it gives are a good parameter of image quality.
have u used it? do you disagree that average drf of 2.8 has "high quality"?
perhaps if you would tranaslate that "high quality" to "transparency"?
so the suggestion it gives is a suggestion for transparent or almost transparent quality.
this tool improved the quality of my encodings the most. it essentially explained to me what quantizer is. all codecs need something like this. mpeg1/2 have "bitrateviewer". avc still doesn't have anything, i think. it is a tool to give you a feeling what codec does, when and how, and by knowing that you know how to improve the quality. you don't have to go for transparency.
it's not a tool that u use on every avi you make and then say "aha drf said it's ok, so it's ok". no, but it's a good tool. has its purpose.
you can't prove this
| QUOTE | | but not necessarily that q3 looks good |
in meaningfullway, can you?
i mean you just said q3 doesn't necessarily look good. i say that it does.
go on and prove me wrong.
take checkered frame of 720x576 dots and prove me wrong. heheh...
you can only wish all stuff anybody ever made had cq3.
also, i did few psnr tests after you said it is comparing source to the encoded versions. yes, psnr is not a good measure. why?
well, it doesn't count all the artefacts x264 has and mpeg1/2/4 don't have. 
overall video compression codec choice can be summoned as follows; which codec has best image quality OR(in other words) which codecs has artefacts i mind least.
they all have SOME artefacts. mpeg1/2 have i-frame pumping on lower bitrates (this is nasty) and generally 15/18frame gops waste bitrate, mpeg4 has problems with chroma motion estimation/compenstation (it usually has lower quants than mpeg1/2 and these make the flaw even more visible..almost as if it never really looks at chroma at all..). postprocessing helps to some degree.
avc has blocks of different shapes. so if there's any noise in video, you get disco of blocks there.
pick your poison.
i just decided i'm gonna use mencoder for my lores toons. the chroma trailing of mpeg4 is just unbarebale on simpsons.
btw. how did you realised the drawback of bpp and average quant. numbers. please tell me. your bpp experiences don't match with some that i mentioned?
you average quants. go real high and still look real good?
how would YOU suggest we asess the bitrate and other settings we need? should we make 10 different encodings, and then pick the best, and repeat procedure for every video we make?
--------------------
my signature:
 |
|
| stephanV |
| Posted: Aug 25 2005, 08:12 AM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
| QUOTE | true, no doubts.
totally black frame looks same on frame 31 and 1. |
The relation between quality and quantizer is not that straight forward. If so, any codec could achieve the perfect quality for any given file size after two, maybe three passes. Yet i doubt many codecs are trying to achieve this (maybe DivX still does). Not just my opinion BTW. (aku here | QUOTE | | But 1pass VBR video isn't there yet: Constant quality (like good audio encoders use) is not the same as constant quantizer. |
)
| QUOTE | | stephan, you're taking this a bit too far. |
maybe a little, but when DRFanalyzer says:
| CODE | Resolution: [ Width: 512 Height: 576 ]
Average Frame quality is MEDIUM [Average DRF/quantizer is 4.25]
Standard Deviation: Quality is MEDIUM [Std. Deviation is 0.91]
Image Resolution is MEDIUM
Recomended Resolution: [400x464] (Target DRF/quantizer=2.8)
The filesize should be larger! |
you say
| QUOTE | | looks just fine if you ask me. |
So either, you and I have different opinions about what "medium" quality is (DRFanalyzer nicely forgets to mention that), or you are ignoring its suggestions just as much I said one should.
Remember I said this:
| QUOTE | | I guess when using numbers to judge quality of a video (whether it be bpp, PSNR, SSIM or something else), you should realise the drawbacks of those numbers. |
I explained the drawbacks of those numbers, nothing more. Saying video is bad or good because DRFanalyzer says so IS bullocks, and you just proved that (unless you think "medium" scales to "good").
| QUOTE | i mean you just said q3 doesn't necessarily look good. i say that it does.
go on and prove me wrong.
take checkered frame of 720x576 dots and prove me wrong. heheh... |
I'll try 
| QUOTE | | btw. how did you realised the drawback of bpp and average quant. numbers. please tell me. your bpp experiences don't match with some that i mentioned? |
They do match, but sometimes using bpp for me is horribly off (in either direction)
| QUOTE | | how would YOU suggest we asess the bitrate and other settings we need? should we make 10 different encodings, and then pick the best, and repeat procedure for every video we make? |
Ideally yes, but usually the most unknown setting IS the bit rate and not the other settings. Bit rate determines at least 80% (i think) of the quality, other settings can be mostly left at (your own) defaults (when you found something you like). But everyone takes at least a little bit of a guess when choosing the bit rate, not to mention that many people always choose a certain target file size (1 movie per CD, 3 eps per CD, whatever). I don't think a lot of people are tweeking the bit rate by the 50 kbps.
So after the first encode, and stuff looks ok to your standards, keep it that way. If it doesn't, you have to do it over again anyway. But I doubt more than 3 times should ever be necessary... i guess it defines how much you care.
Personally, I can live with blocks, but not with ringing (is why I im very interested in AVC, haven't really see it ring yet), but it is not uncommon for me that I do an encode the 2nd time. (but maybe your just a better gambler than me )
| QUOTE | | overall video compression codec choice can be summoned as follows; which codec has best image quality OR(in other words) which codecs has artefacts i mind least. |
Of course! But DRFanalyzer doesn't tell you anything about that.
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| frank10 |
| Posted: Aug 25 2005, 09:23 AM |
|
|
Advanced Member
Group: Members
Posts: 148
Member No.: 14177
Joined: 19-February 05
|
| QUOTE | | and you didnt even tried the nandub_onepass |
thanks for the link. I will try it.
| QUOTE | have u used it? do you disagree that average drf of 2.8 has "high quality"?
perhaps if you would tranaslate that "high quality" to "transparency"?
so the suggestion it gives is a suggestion for transparent or almost transparent quality. |
Yes. that could make more sense, as an mp3@320kb.
It seems like I've said, it is better to assest to 3.5-4 Q in a normal encoding session.
BUT, there is something wrong in this exasperate match with 2.8Q (or better ):
If Mpeg4 are targeted to use a medium bitrate, it is a non-sense to force them to reach a Q2.8 when you get this only at extreme high bitrates (3500 for 512x384 or 5000! for 640x480, imagine a 720x576...). There we should go with Mpeg-2. Isn't it?
So, for mpeg4 codecs (like this util is for) a Q4 should be called HIGH instead of medium or the suggestion should be: change codec type
btw: what is standard deviation?
@stephan:
| QUOTE | | Ideally yes, but usually the most unknown setting IS the bit rate and not the other settings. Bit rate determines at least 80% (i think) of the quality, other settings can be mostly left at (your own) defaults (when you found something you like). |
Well, but this is strictly linked to high-low Quantizer! Are we saying the same thing here?
We found a tool that show us how much low q you have, THAT IS how much high bitrate you have. Furthermore it shows WHERE in your clip you have higher bitrates (when you have more lower Q), also with a nice graph.
So, it is only a more accurate bitrate viewer and it suggests you if you can improve q on Keyframes or on P-frames. So if you have an overall low q you should decrease the max q OR increase the bitrate.
After that number are what they are and also stats... and also the suggestions...
Maybe the only thing to test more is this: is it better to leave the Q settings and operate only in the bitrate control or the opposite or both?
I personally find interestng having control on I and P frames separately for their Q.
(like in Nandub but also in ffvfw). Of course this could led to a too time consuming test We should find a rule.
|
|
| stephanV |
| Posted: Aug 25 2005, 09:51 AM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
something is horribly wrong with divx3 encoding in ffvfw (screenshots taken in VDub):
http://www.geocities.com/grotesteph/harry-...tter-source.jpg
http://www.geocities.com/grotesteph/harry-...er-divx3-q3.jpg
http://www.geocities.com/grotesteph/harry-...-nandub1pass-q3
I think ive proven sufficiently now that q3 doesnt always look good (not really i know, this is a bug)
i used Saggis Harry Potter trailer, fcc's VirtualDub-MPEG2, internal resize filter (lanczos3 to 640x272) (with cropping top and bottom 74 first) then a constant quant 3 encoding.
Nandub 1 pass looks interesting though!
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| stephanV |
| Posted: Aug 25 2005, 04:03 PM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
| QUOTE | | Maybe the only thing to test more is this: is it better to leave the Q settings and operate only in the bitrate control or the opposite or both? |
If you need to cap quants with multi passing, it basically means your encoder has a lousy rate control (or at least something is really going wrong). I could understand it in a 1-pass scenario, although you run the risk then that all low motion is q-lowlimit and all high motion is q-highlimit, not that this is necessarily bad though. When you need to cap quants too drastically you might wanna consider doing q3 or q4 encodings and just forget about bit rate all together, because your target bit rate might not even be achieved anyway that way.
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| i4004 |
| Posted: Aug 25 2005, 04:16 PM |
|
|
Advanced Member
Group: Members
Posts: 2432
Member No.: 4935
Joined: 24-June 03
|
| QUOTE | | and you just proved that (unless you think "medium" scales to "good"). |
i find it very, VERY weird that you forgot the most important part of my stuff: the one where i say analyzer's "high" actually may mean "transparent".
and my aim is not 'transparent'.
never was, never will be. perhaps it would be if i was to watch movies on monitor.
but i don't. i watch via tv-out and from 5-6xdiagonal distance.
and i say it's good.
so indeed, i say 'medium' scaled 'good'. for me. in this case. this was 512x576, mind you.
but ok, why don't you analyze some of your files that are "medium" by you, so we see what happens?
or some file that are 'ok' by you.
this should take divx5 and xvid too.
| QUOTE | | They do match, but sometimes using bpp for me is horribly off (in either direction) |
when?
i said something about sports.
perhaps i should of said something about toons too.
hehe...
| QUOTE | | But everyone takes at least a little bit of a guess when choosing the bit rate, not to mention that many people always choose a certain target file size (1 movie per CD, 3 eps per CD, whatever). |
that is their problem, right?
burning cds in 2005 is not the stuff video enthusiasts do.
| QUOTE | | So after the first encode, and stuff looks ok to your standards, keep it that way. If it doesn't, you have to do it over again anyway. But I doubt more than 3 times should ever be necessary... i guess it defines how much you care. |
3 times 2pass of a 120' movie?
well, you encode much less than me, then. MUCH LESS (if you have that much time)
| QUOTE | | Personally, I can live with blocks, but not with ringing (is why I im very interested in AVC, haven't really see it ring yet), |
i don't really bitch at mpeg4pt2 for ringing. it doesn't really ring for me. and i have subs in plenty of my content. yes, avc rings even less ( ).
but i'm afraid 8x8dct didn't really help to avc, as the macroblocks are blocking. those 8x4, 4x8 blocks etc.
it's not a problem that avc blocks, but that it blocks in a weird way which may be more distracting than usual blocking. so one has to toy with inloop.
but the REAL problem (for me) is the speed of avc.
it's just so damn slow that any bitrate benefits seem to look silly. i have given it up. at least untill i buy much faster machine. which i dunno when it will happen, as this machine is just fine for "old" mpegs.
i mean, it's 4-5 times(!) slower than nandub, and it surely doesn't look 4-5 times better!
it doesn't really even look 30% better.
| QUOTE | | but maybe your just a better gambler than me |
i would say i encoded more stuff, so i probably become good at guessing.
f.
| QUOTE | | It seems like I've said, it is better to assest to 3.5-4 Q in a normal encoding session. |
i think so, yes.
| QUOTE | | So, for mpeg4 codecs (like this util is for) a Q4 should be called HIGH instead of medium or the suggestion should be: change codec type |
hehe...you should know one more thing.
what if average quant of 2.8 would yield 2mbit/s higher bitrate on mpeg2?
yesterday i encoded music video with nandub_onepass and mencoder(mpeg1):
both have same bitrate. nandub has av.quant of 2.18, and mencoder has 3.5.
and the av. quant of mpeg1/2 is kinda cheating.
let's say i-frames are quant2, p-frames are 6, and b-frames are 10.
the mean quant is said to be 6 in this case, but if we would to compare this to mean quant 6 on mpeg4(no b-frames), we may find out that mpeg4 looks better.
why?
well, helluva lot of them quant10 b-frames in mpeg1 mean that overall it looks blurier.
| QUOTE | | btw: what is standard deviation? |
deviation from standard?
i don't have a clue what this refers to.
wait....
http://en.wikipedia.org/wiki/Standard_deviation
http://www.robertniles.com/stats/stdev.shtml
just one more blah-blah method to asses quality, it seems.
(stephan, you liked this, didn't you? )
| QUOTE | | I think ive proven sufficiently now that q3 doesnt always look good |
was this ffdshow or the famous september '03. ffvfw?
i never use ffdshow to encode anything. and for divx3 i don't use ffvfw anyway, as it is using ffmpeg motion estimation, not divx3.
i objected to saggitaire when he used ff to make divx3 and called it divx3 in his test. no, that's not divx3. that a divx3/ffmpeg hybrid.
i think ff never can skip macroblocks, and divx3 can.
so divx3 can spare some bitrate. offcourse, ff has some other tools that divx3 doesn't have (qpel etc.)
--------------------
my signature:
|
|
| frank10 |
| Posted: Aug 25 2005, 06:47 PM |
|
|
Advanced Member
Group: Members
Posts: 148
Member No.: 14177
Joined: 19-February 05
|
Excellent!
This is a very good option in this util! So it isn't only an average Q, but it gives you precision-consistency on that average.
I think if we get 3.5-4q (medium qual) and high std. deviation we are making things very good. |
|
| stephanV |
| Posted: Aug 26 2005, 11:46 AM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
| QUOTE | just one more blah-blah method to asses quality, it seems.
(stephan, you liked this, didn't you? ) |
But its true. I'm not sure averaging quants makes any sense, if the weighting is completely off. Is q1 2 times better than q2 and q2 2 times better than q4? I don't know for sure, but I don't think so. Again, a value doesn't mean much if you don't know the meaning of it (if there is one to begin with).
| QUOTE | | I think if we get 3.5-4q (medium qual) and high std. deviation we are making things very good. |
These seems contradictionary to your method of capping quants, while I don't know if a high std means quality will be better or worse (it depends probably), with capping your quants you are actually preventing to achieve a high std. It's one way or the other.
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| frank10 |
| Posted: Aug 26 2005, 12:50 PM |
|
|
Advanced Member
Group: Members
Posts: 148
Member No.: 14177
Joined: 19-February 05
|
| QUOTE | | These seems contradictionary to your method of capping quants, while I don't know if a high std means quality will be better or worse (it depends probably), with capping your quants you are actually preventing to achieve a high std. It's one way or the other. |
I was pretty sure I was misunderstood on this.. and in fact
But it's my fault:
Look at a sample report:
| QUOTE |
Resolution: [ Width: 512 Height: 576 ]
Average Frame quality is MEDIUM [Average DRF/quantizer is 4.25]
Standard Deviation: Quality is MEDIUM [Std. Deviation is 0.91]
Image Resolution is MEDIUM |
I was trying to say that we can go good if we can have sugggestions of medium qual. on average Q and High qual. on Std. dev. (of course this mean std. dev. is lower).
So, my sentence should has been:
I think if we get 3.5-4q (medium qual) and high QUAL ON std. deviation we are making things very good.
Uh, when one writes fast, this happens |
|
| stephanV |
| Posted: Aug 26 2005, 02:12 PM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
fair enough... now to find something where q3 looks bad
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| i4004 |
| Posted: Aug 26 2005, 02:16 PM |
|
|
Advanced Member
Group: Members
Posts: 2432
Member No.: 4935
Joined: 24-June 03
|
stephan, have you at all tried this program?
please try it and tell us you objections (bearing in mind what frank i i have said so far).
thank you.
--------------------
my signature:
|
|
| stephanV |
| Posted: Aug 26 2005, 02:22 PM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
I have tried it before, and I was always frowning a bit that it called everything I made "medium", but put in the right perspective I guess it COULD work. I don't know when medium starts to get low though...
anyhow, even as chemical engineer I'm just objecting a bit to using arbitrary numbers of which the meaning seems unclear. I can take averages of a lot of things, but that won't make it meaningful. With enough goes one could say these values are probably ok and those values are probably not.
I'd just rather have something that would tell me this by understanding, not by experience.
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| i4004 |
| Posted: Aug 26 2005, 03:12 PM |
|
|
Advanced Member
Group: Members
Posts: 2432
Member No.: 4935
Joined: 24-June 03
|
| QUOTE | | I don't know when medium starts to get low though... |
well..make few clips with average quant of 31.
| QUOTE | | I'd just rather have something that would tell me this by understanding, not by experience. |
you cannot do that, my good man, as bpp and average quant. are "bollocks" for you , as you said.
it's kinda catch22 for you, isn't it? you have few theories that this can't work, and yet you can't prove it wrong, so now what will you do?
what will you do?
(and some have called me a nihilist? )
--------------------
my signature:
|
|
| i4004 |
| Posted: Aug 26 2005, 05:44 PM |
|
|
Advanced Member
Group: Members
Posts: 2432
Member No.: 4935
Joined: 24-June 03
|
few drf files here
http://i4004.net/i4004/?d=drf_analyzer_095&s=&r=
in 'other'(these are not my encodings, although my early encodings probably look even much worse than these... ) only the kpax looks good.
the 'heavy metal' toon has 'medium' quality, but 'low' dev. it also doesn't look too good (as i said, i wouldn't use mpeg4 for toons. color is everywhere, blocks too.)
only kpax was made with nandub. others are mostly vdub+divxlow and 'let iznad..' is divx3 fast motion (  ), so the poor results and poor image quality are not surprising.
my files look just ok to me.
--------------------
my signature:
|
|
| frank10 |
| Posted: Aug 27 2005, 02:52 PM |
|
|
Advanced Member
Group: Members
Posts: 148
Member No.: 14177
Joined: 19-February 05
|
the heavy drf shows how important is std.dev: it has an average q of 4.25 but std.dev of 2.23 and the suggestions give 'VERY POOR' quality.
Instead i4004 drf are near avg q but a high qual on std.dev.
This confirms what I've said earlier on the importance of this std.dev in this util.
But it seems strange that it gives HIGH image resolution on the pax drf when there is 640x272 while when you have 512x384 it gives medium (but has more px). Probably it counts only the hor-res.
Another thing: when you use b-frames the std.deviation fails to calculate.
From a real-time capture test ffvfw-mpeg4:
| QUOTE |
Average Frame quality is MEDIUM [Average DRF/quantizer is 4.88]
Standard Deviation: Quality is LOW [Std. Deviation is -1.#J]
Image Resolution is HIGH
There are NO frame drops ( NO drops is better )
This video may have some frames with VERY POOR Quality!
Recomended Resolution: [544x432] (Target DRF/quantizer=2.8)
Performance Caracteristics:
This video seems to have too MUCH Keyframes. May degrade CDROM and Processor performance.
Macroblocks per frame: 1620 ( Poor Playback in Slow Computers, PIII450 or better required )
The Width is not multiple of 32. May degrade performance in some systems.
Kilobits per Second: 3713.47
Kilobits per Frame: 146.20
Kilobits per Macroblock: 0.090
Bits per Pixel: 0.36
Frame Type Statistics :
I Frames: 3.15%
P Frames: 46.46%
B Frames: 48.82%
S Frames: 0.00%
N Frames: 0.00%
(More Advanced Codecs use B and S frames)
|
A last point for stephanV.
There are options in codec to set the quality of your session with quantizer instead of kb: move slider towards q2 encoding is better and so on...
So what's the problem with this utility assumptions if codecs themselves have this approach to set the quality?
|
|
|
