Unofficial VirtualDub Support Forums [Powered by IB Forums]

Printable Version of Topic
Click here to view this topic in its original format

Unofficial VirtualDub Support Forums > Codec Discussion > Resolution Vs Compression

Posted by: frank10 Aug 6 2005, 09:41 AM

I've read this link that fccHandler gave me on another thread:

http://forum.doom9.org/showthread.php?p=654100#post654100

and i4004 gave me this suggestion:

QUOTE

"But in fact, the 352 x 480 version looks visibly worse to me. There is some blocking and compression artifacts which I don't see in the 720 x 480 version!"

but this comes as no surprise to me(perhaps as i did a lot of lores encoding) : it is nothing unusual to see codec perform worse at lower res then at higher res. EVEN if you apply same bpp rates (or to go even further; even if you apply HIGHER bpp at lower res, it will still look worse). 8x8 block is just more visible at 352 than at 720 pixels, as simple as that. (that brings us all the way back to how jpeg is a lot less effective on lores than on hires images)
also, i think he doesn't filter his vhs sources at all (he's converting music videos, so that's understandable), so that makes things even a bit tougher on encoder.(downsizing can make that vhs noise look grainier to encoder, so some efficiency may be lost there too. i think fcc is doing laced mpeg2, so perhaps some efficiency is lost there too, as i imagine motion compensation(esp. of laced mode) will work better on higher res. etc.)

So now I want to ask in this appropriate thread, what is the best approach with laced material captured from TV?

I mean, is it better to maintain the 720x576 and compress directly? From i4004 answer it seems you get the best quality. Only with Mpeg2 or also with divx codec?
But if this is true, why should be good to resize? For time-compression at a quality drop?

Generally I use these clips with tv-out from PC into TV, so interlacing shouldn't be a problem, but I was thinking also in a future I could get them in a digital TV (LCD or plasma) or just now could see in a pc.

So could be safer to deinterlace just now? I was deinterlacing with the trick of resizing at 512x384 but effectively I see a loss using the same bitrates-codecs regards the original 720x576. Maybe it is better to use a deinterlace filter at 720?
Is good this final progressive 720-clip on an interlaced TV?

Or could be a better possibility to leave the clip interlaced and rely more on a good de-interlacing real-time decoder like ffdshow?

What are your hints, you codec-resolution-wise men?

Posted by: jazzzy786 Aug 8 2005, 09:30 PM

Generally speaking each time you encode you deteriorate the video quality. The higher the resolution the better the quality. If you are planning to get a plasma screen you want the best quality/highest resolution possible. Try using something like huffyuv (a lossless codec) so your picture quality doesn't deteriorate. This may produce quite a big file so really its about only compressing it if the file is too big to fit on a dvd (if that is what you want to do). Ffdshow is very good at what it does so I'd say stick with that.

Posted by: frank10 Aug 9 2005, 08:04 AM

Yes, I capture files with huff at 720x576.

QUOTE

so really its about only compressing it if the file is too big

What I wanted to know is understand more how successive compression with lossy codecs influence quality at different resolutions.

In the doom9 link they made assumptions at pixel-compression ratios. ie if you compress at 720x576 @ 2000bps, if you lower the res, you get more bit per pixel at the same 2000bps. So in theory you could lower the data-rate. But in practice it seems not to be so.

As i4004 said it seems that higher the res, ALWAYS the compressed clip look better, even if you apply higher bpp at lower res.

If this is true, the consequence of this are in my first questions:

1) With laced material, is this true for all codecs, divx, Mpeg2...?
2) What resize is useful for if it gives you worse quality? (Maybe I understand for speed up things, but I would like a confirm)

And then the de-interlacing problem as I used the trick explained by fccHandler here:
http://forums.virtualdub.org/index.php?act=ST&f=2&t=7494
, of resizing at 512x384 to obtain also a deinterlacing.

3) If I can't resize at 512x384 to deinterlace because I want max quality at 720x576, is it best to de-interlace with filters and then compress a progressive clip or could it be fine to leave the clip interlaced and use ffdshow to de-interlace in real time while playing?

The problem arise because I'm seeing clips on a CRT Tv interlaced now (so leaving interlaced it isn't a problem), but if I change it in a future with a digital progressive one or if I watch clips both on CRT and PC screen?

Which is the better coding approach with laced material? Is it more efficient if there is a progressive clip?

Posted by: stephanV Aug 9 2005, 08:19 AM

1,2) This is true for any kind of material. That's why bpp is a bad value to determine how much you can compress a source. The lower resolution you have the higher your bpp needs to be. Note that an encode at 384x288 doesnt need as much *bit rate* as 720x576, only a higher bpp. So resizing still makes sense... even if the bpp needs to be 2 times higher for the low res clip, it still would come out about 2 times smaller.

3) It depends on your CPU too... real time deinterlacing adds to your decoding needs and moreover, interlaced material doesnt compress as efficiently as progressive material. I think, unless people output to a TV, they all deinterlace.

Posted by: i4004 Aug 9 2005, 01:52 PM

(frank politely asked me to reply here, so i must...

)

s.

QUOTE

That's why bpp is a bad value to determine how much you can compress a source. The lower resolution you have the higher your bpp needs to be.

yeah, bpp may not be constant (regarding the different resolutions) but it's still a good measure once you find out what res. is ok with a particlar bpp rate and a particular type of source.

now to address f.'s questions;
as i understand it , you are essentially asking do you need to deinterlace or not.
the answer is easy, really. in order to preserve best quality, you won't deinterlace, but will encode as laced on relatively high bitrates (as for codec choice, you should use laced mpeg2 if you wan't best compatibility; if you don't care about compatibility, then you can use mpeg4 codecs in laced mode; this presumes you got thte laced tv-out working ok)

but the answer get to be a bit more complicated when you establish that interlaced playback on tv-out is not a walk in the park(it is not as robust and easy as a laced mpeg2 played via dvd-player), and you find out that laced is munching more bitrate, and you find out (finally) that only a few types of content really have a visible benefit from laced encoding.(also a worry of "will future be all progressive?").

so depending on your sources, you should decide; if you do a lot of sports with a moving camera, then laced my be beneficial. if you do films, tv-series and such, then you won't see a big benefit from laced encoding.(plenty of that stuff is progressive to start, so it won't need any deinterlacing)

for example i'm currenty capping 'only fools and horses' bbc-series. it is what's known as 'hybrid' (film and video mixed content). i just do (for example)

CODE

kerneldeint(order=1,sharp=false,threshold=6)

to deal with laced portions (ie to deinterlace them) and i'm fine with the results.
(encode it as mpeg4 at 0.2bpp(or even less) on 512x576)

when resizing to 512x384 (which is not a bad resolution, for sure) you should always remember it is worse than vhs. but perhaps for some content you're willing to make a compromise. (i know i am...for some content.)
but i know that i'll be keeping 576 lines when i cap few monty python episodes from vhs. (probably will just cap at 512x576, deinterlace(python is hybrid just as 'only fools and horses') filter and encode at 0.23bpp (2mbit/s))

i wasn't really satisfied with ffdshow's on-the-fly deinterlacing. on some content it wasn't really deinterlacing at all.

Posted by: frank10 Aug 9 2005, 08:56 PM

@stephanV

QUOTE

Note that an encode at 384x288 doesnt need as much *bit rate* as 720x576, only a higher bpp. So resizing still makes sense... even if the bpp needs to be 2 times higher for the low res clip, it still would come out about 2 times smaller.

yes. I now understand better the ratio resolution-bpp, but I asked about quality with resizing. As in my question 2.

So to make an example:

720x576 @ 2500 kbps has a 0,241 bpp
then a
384x288 should be around 0,48 bpp that is 1205 kbps

Are you saying that a 720x576@2500 is comparable to a clip resized at 384x288@1205 ?

Because from what I have understood, it is impossible to get this... Also i4004 says that going 512x384 is worse than VHS, and in fact you will lose half of the original resolution at 288.
Yes you get 2x files smaller, but at the price of half quality or even worse than half if you recorded from TV and not from VHS (you don't loose only vertical res 576->288, but also horizontal res, that from live TV is there, surely more than 384).

So what do you mean?

Thanks i4004 for examples of interlacing. Now it's clearer to me.

Only this:

QUOTE

if you do films, tv-series and such, then you won't see a big benefit from laced encoding. (plenty of that stuff is progressive to start, so it won't need any deinterlacing)

Yes, the source is not interlaced at the beginning, but with the broadcasting and the recording through the capture card it gets fields.

So why shouldn't be useful to deinterlace this stuff? What's the difference from original interlaced material?

Posted by: stephanV Aug 9 2005, 09:15 PM

QUOTE

Are you saying that a 720x576@2500 is comparable to a clip resized at 384x288@1205 ?

First of all, i have no idea how bpp scales with resolution (if it does at all). All I am saying is that the 384x288 encode is 2 times smaller in size. There are two aspects two quality here we are discussing here:

1. The resolution, or the amount of details.
2. The (lack of) encoding artifacts.

For point 1 720x576 clearly wins over 384x288. For point 2, we cant tell. If 720x576 turns out to be a block fest at that bit rate, I might very well prefer the 384x288 encode.

I was actually answering your question #2 though:

QUOTE

2) What resize is useful for if it gives you worse quality? (Maybe I understand for speed up things, but I would like a confirm)

Answer: a smaller file size. No one has unlimited storage capicity so quality has to be sacrificied somewhere. How much storage someone has varies from person to person, therefor also the amount of quality that has to be sacrificed. I assume you don't store your caps at full resolution with Huffyuv.

Posted by: i4004 Aug 9 2005, 09:46 PM

QUOTE

No one has unlimited storage capicity so quality has to be sacrificied somewhere. How much storage someone has varies from person to person, therefor also the amount of quality that has to be sacrificed.

very well said!

QUOTE

So why shouldn't be useful to deinterlace this stuff? What's the difference from original interlaced material?

i knew even before this thread (based on something you said) that you didn't grasp the film vs video difference.
to put it simple, if we're receiving broadcast made from film sources, we can restore the progressive frames that broadcasters started with.(we talked a bit about pal phase shift....when there's no phase shift we don't have to do anything, we have the progressive stream right there)
but if we're receiving a video, then we only have a succession of fields, and there is no progressive frame to recover, as there were none at the broadcaster anyway.
so if we deinterlace the video we're losing half the temporal data. so on sports deinterlaced images will flicker and jerk.
if we restore progressive film frames, we're losing nothing.

i think that enthusiast will have a best explanation if he just runs separatefields() on a video and on a film sources.
that will explain it to him. it surely explained it to me. and you don't seem that different.

(if i remember correctly, i used eurosport footage of some past tour de france or such as an example of video).
just do separatefields() in avisynth, and advance the timeline frame by frame(or in this case field by field), and i think you'll see it. you wanna inspect the motion parts of the footage.

look carefully.

Posted by: frank10 Aug 10 2005, 10:44 AM

Well, thanks stephanV and i4004.

(for the interlacing, I had a similar answer in mind, but I'm one that loves confirming

in fact you explained it very well. thanks)

Now, I think it is clearer on both questions.

Only last things:

i4004:

QUOTE

will just cap at 512x576, deinterlace(python is hybrid just as 'only fools and horses') filter and encode at 0.23bpp (2mbit/s))

you say 512x576 at 0.23bpp is 2mbit/s

I'm new to this bpp thing, but I do this way:

I have 512x576 that is 294.912px
if I want a bpp of 0.23 I should do:

0.23x294.912x25/1000 = 1695,7 kbps it seems distant from 2000

How do you calc bpp?
As I may very well calculate it wrong.

(btw: Do you cap directly at 512 not at 720 and then resize it?)

And if bpp doesn't scale with res as stephanV said, what hints you give me to adjust bitrates after a resize? Could it be remaining on a bpp of 0.25? Or what?

Posted by: stephanV Aug 10 2005, 11:36 AM

1.7 mbit/s, 2 mbit/s... whats the difference

(your calculation was correct)

Posted by: i4004 Aug 10 2005, 12:47 PM

1- http://clzm.veganismus.ch/html/english.html
(btw. your calculus is good, and i was (by mistake) on 29.97fps in greenx...

)
input 0 on ar spot to get 'free' ar.
2- yes, i cap directly to 512x576, as cards usually have ok horizontal resizers. offcourse, i don't always cap to that resolution. i also use 384x576/2 (using vdub's vertical reduction while capping), 576x576 and 768x576.
3- well (these are no exact numbers but more of a orientation) let's say that on 384x288 you may need 0.36bpp, and on 720x576 you may need 0.25bpp. those should be safe values for most content (sports excluded!!!) with a bit overhead (ie there will surely be times when you could go a bit lower with bitrate.)
for 512x384 1.2mbit/s is a good bitrate which is 0.24bpp.

the mentioned monty python got 0.25bpp(so cca. 1840kbit/s) and it's ok. (cleaned with peachsmoother)
but i'm not satisfied with how deinterlacing affects it, esp. the subtitles, which become rather noisy after deinterlacing, so i may resort to laced encoding (mpeg2 or ffvfw-mpeg4) for next episode.
i want this to look good. REAL GOOD.

btw. divx3 via vdub is crap. divx3 can only look good if you use it via nandub. you can also try http://forums.virtualdub.org/index.php?act=ST&f=6&t=10160&st=15, and xvid, and see what you like the best.
as for mpeg2, last time i tried hc(with a gui) it was crashing. mencoder (command line) was excellent, and quenc should also be ok on relatively lower bitrates (ie the bitrates that usually don't work so well with cce and tmpgenc).

Posted by: frank10 Aug 24 2005, 02:48 PM

After this very exahustive answer I was reading more about mpeg4-nandub-ffvfw, and testing a bit.

1) for compression-bpp:

I found out a thread in which i4004 and narler talked about quantizers and I downloaded the very good utility http://www.geocities.com/analyzerDRF/

I tried it on some clips, but I discovered strange things:
Using a 4' clip from a normal TG footage (still-medium movements):
Nandub - medium res of 512x384, drf: 2-5, I:4-31, 1pass:

512x384@1200 drf 2-5 gives me quality-frame:medium, deviation:medium, bpp: 0.30

only raising to 2500kb it gives me high quality frame with a bpp: 0.52
but it suggests having a larger file or to reduce resolution

only at 3500 I reached a high frame-quality with good filesize for this util :
512x384@3500 drf 2-5 gives me qual:high , dev:medium, bpp: 0.68

Of course this is an absurd data-rate, I tested only where this util says it is high quality and all is good.

If I raise the drf to a range of 2-9 it is even worse of course (at 2500k it gives medium quality).

If you use higher res 640x480:
640x480 drf2-5 @2700k, bpp 0.36 you get medium qual. You must go at 5000(!!) to reach qual:high with 0.66 bpp

So what's wrong?
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) or it is something wrong with nandub codec settings?
But I made also Divx5 encode at 2000k and 1200k on the 512x384 and it gave me worse results than same bitrate on Nandub...

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.

So, it seems true that bpp it's not as valuable as it depends a lot more on the distribution of drf-quantizer, that is, on which are your codec settings, especially in nandub.

2) for resolutions:

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...

Anyway I agree that when capturing there is a 1st resize (hardware) and that it shouldn't be good to make a second one (software).

I was thinking of the resolutions of 640x480 and 512x384: shuldn't be better to capture at 512x576 instead of capturing at 720x576 (maybe it could be slighty better to capture at 640x576) and resizing at 640x480? They have a difference of only 12.288 pixels.

For 512x384 could be 360x576 or 720x288 (they both have more pixel) or 384x288 (it has 86016 pixels less, BUT there is no further resize).

I was thinking to make a capture test at different resolutions to test these.

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?)

Then extract a frame and compare them. Here it's a bit difficult with Photoshop or other pic-progs not AR aware. Any suggestions? (Another resize at 720x576 for all res...?)
Or I could do this to test also the complete path of tv-out:

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.

Any thoughts-suggestions?

Posted by: stephanV Aug 24 2005, 03:09 PM

Using drf analyser to asses quality is just as quirky as using bpp. While it is true that for any given frame a lower quantizer gives higher quality, it is not true that frame A with q4, looks necessarily better than frame B with q6. Roughly said, quantization is nothing more than removing details from a picture and you can imagine that for a less detailed picture higher quantization will be less destructive than for a higher detailed picture. What's more: a different quantization matrix could completely change the quantizer scale (q2 becomes q4, or the other way around).

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.

Posted by: frank10 Aug 24 2005, 03:59 PM

Ok, I'm certainly not expert on quantizer, but if someone made an utility to analyze an entire clip to make an average of quantizer, macroblock in frames, bpp and a lot of other parameters, it should give at the end a reasonable guess of the overall quality of that clip.
This util shows also if you have too few or too much keyframes, it suggests other resolutions... So are those suggestions useless?
Of course these are numbers... and visually it could be a lot different or also ininfluent @25fps in fast moving scenes...

QUOTE

What's more: a different quantization matrix could completely change the quantizer scale (q2 becomes q4, or the other way around).

But here I tested the SAME clip with different datarates and the SAME settings on the SAME encoder. (Yes I made also that test with divx5, but it was only to see if I was very wrong in my first codec settings. But it was very similar result, only slightly worse.)
So it seems I'm not comparing apples with oranges.

QUOTE

it is not true that frame A with q4, looks necessarily better than frame B with q6.

Yes, but the same frameA at q4 is better than q6. I tested the same clip, so the codec should be changing the Q on the same frames (as there are same settings) on different kb.

What I mean is this utility never gives me a good looking pic with their stats until I reach exagerated kbps.
Is this util useless or am I making something wrong?

Maybe instead of seeking for an average of Q2.8 could it be better on a Q3.5-Q4?

Posted by: stephanV Aug 24 2005, 05:13 PM

What i was trying to say was: quantizer unequals quality. It's great if you have an average quantizer or 3, 4 or 5, but it doesn't say anything about the quality. If you encoded the same clip with q3 or q5 it only means that q3 is better, but not necessarily that q3 looks good or q5 looks bad. So for a tool to suggest the quality is "medium" or "high" just by calculating the average quantizer is complete bullocks.

(I thought you already concluded that yourself, reading your previous post)

Posted by: i4004 Aug 24 2005, 07:06 PM

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 http://www.undercut.org/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"?

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?

Posted by: stephanV Aug 25 2005, 08:12 AM

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 http://forum.doom9.org/showpost.php?p=566156&postcount=9

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.

Posted by: frank10 Aug 25 2005, 09:23 AM

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

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.

Posted by: stephanV Aug 25 2005, 09:51 AM

something is horribly wrong with divx3 encoding in ffvfw (screenshots taken in VDub):

http://www.geocities.com/grotesteph/harry-potter-source.jpg
http://www.geocities.com/grotesteph/harry-potter-divx3-q3.jpg
http://www.geocities.com/grotesteph/harry-potter-nandub1pass.jpg

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!

Posted by: stephanV Aug 25 2005, 04:03 PM

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.

Posted by: i4004 Aug 25 2005, 04:16 PM

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

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.)

Posted by: frank10 Aug 25 2005, 06:47 PM

QUOTE

wait....
http://en.wikipedia.org/wiki/Standard_deviation
http://www.robertniles.com/stats/stdev.shtml

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.

Posted by: stephanV Aug 26 2005, 11:46 AM

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.

Posted by: frank10 Aug 26 2005, 12:50 PM

QUOTE

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

Posted by: stephanV Aug 26 2005, 02:12 PM

fair enough... now to find something where q3 looks bad

Posted by: i4004 Aug 26 2005, 02:16 PM

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.

Posted by: stephanV Aug 26 2005, 02:22 PM

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.

Posted by: i4004 Aug 26 2005, 03:12 PM

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?

)

Posted by: i4004 Aug 26 2005, 05:44 PM

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.

Posted by: frank10 Aug 27 2005, 02:52 PM

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?

Posted by: stephanV Aug 28 2005, 06:03 PM

QUOTE

you cannot do that, my good man, as bpp and average quant. are "bollocks" for you , as you said.

Well then something else needs to be thought of.

QUOTE

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?

The problem is that the experience cannot be brought back to a workable model. Sure you can say q3 always looks good, but what use is it to me? Files turn out too large that way in any case. To drift off a bit, I can always assume something falls down on the ground when I throw it up... until I go into space. So the question is: Is there a "space" for video, and if so, where is it?

To restate the problem: I cant go and encode a video, use a bpp and have a targeted average q as result. Maybe if you make a q range of +/- 1 off the middle. But how useful is that? YMMV i guess...

QUOTE

what will you do?

Being a nihilist it seems.

But that's ok, I'm just one of those people that attaches more value to understanding something than actually using it.

@Frank

QUOTE

Another thing: when you use b-frames the std.deviation fails to calculate.

B-frames are meant to "over"-quantized, meaning they will normally have 1.5 to 2 times the quant value a p-frame would have. B-frames are designed for this purpose and normally have only a small reduction in quality compared to the p-frame that would be encoded, but a high reduction in frame size. Note that this will not only throw off your std, but also your average quant... although I'm not sure how DRF analyzer deals with this.

So now we already need at least to use different values if we want to also accomodate for b-frames. But b-frame behaviour is rather impredictable and depends highly on settings...

QUOTE

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?

You only set the quant, not the quality. If a codec calls constant quant constant quality this is rather silly.

Posted by: i4004 Aug 28 2005, 07:37 PM

QUOTE

Well then something else needs to be thought of.

because drfanalyzer said you're mediocre?

we said that "medium"="nice".
for us.
on our tv-outs. on average quant. of 4 on 512x576.

(hehehe..talking about the variables!)

QUOTE

If a codec calls constant quant constant quality this is rather silly.

because akupenguin said..something..somewhere?

constant quant mode indeed is constant quality.
please feel free to prove me wrong.

i think you failed once in this thread (as you said quant3 can look bad), let's see if you can do it again.

please be aware; xvid encoding with b-frames and 5/8 quant(for example) is not constant quant. mode.

QUOTE

B-frames are designed for this purpose and normally have only a small reduction in quality compared to the p-frame that would be encoded, but a high reduction in frame size.

could you tell us what does "high reduction in frame size" means?
how much is the bitrate reduced, and how much is the image spoiled?
(one more tough one, no?

)

Posted by: stephanV Aug 28 2005, 11:12 PM

QUOTE

(hehehe..talking about the variables!)

indeed

QUOTE

please feel free to prove me wrong.

I can show you some stuff q3 stuff that actually looks pretty bad relatively speaking (on my monitor (=TFT), dont know about TV). Its a space shuttle in blue air. Its especially bad when watched in motion, dont even try full screen (res of vid is 624x352 BTW). Now you can say codecs do bad on gradients, but if codecs are bad on some stuff and good on other then they cant possibly give you constant quality on constant quant.

QUOTE

please be aware; xvid encoding with b-frames and 5/8 quant(for example) is not constant quant. mode.

Hey, I'm stubborn, not stupid.

QUOTE

could you tell us what does "high reduction in frame size" means?
how much is the bitrate reduced, and how much is the image spoiled?

This would depend very much on settings... but ill use XviD with defaults ok?

Posted by: i4004 Aug 29 2005, 12:35 AM

QUOTE

but if codecs are bad on some stuff and good on other then they cant possibly give you constant quality on constant quant.

i wanna see this clip. it was divx, or xvid, right?

one can reason in this way; if that codec will always give same artefacts on same quant on same source, it's constant quality. you may not like that quality, but it's constant.
(we can't change the fact mpeg is lossy, and that it hates some things, so no need to discuss that. we also can't change the fact that divx4/5 and xvid are crap.)

we're playing word games now, but i wanna see the clip. divx and xvid can crap-out on sky like no other (recent) codec. they band quickly, and produce false motion.

QUOTE

Hey, I'm stubborn, not stupid.

plenty people call such enc. cq, i'm afraid, so i was just checking.

QUOTE

This would depend very much on settings... but ill use XviD with defaults ok?

use whatever you want, but pick some tough source from here
http://www.ldv.ei.tum.de/liquid.php?page=70
or here
http://index.apple.com/~singer/sequences/testseq.html
(if you can get them in container you want...

)

i mean...you didn't thought i would be interested in re-encoding the dvds?

Posted by: TechMage89 Aug 29 2005, 03:29 AM

Describing CQ as giving constant quality is a bit misleading. Saying it gives constant detail would probably be closer.

After all, what ever sort of (ugly) noise your video had when you encoded it would be included in your definition of "quality."

Posted by: stephanV Aug 29 2005, 08:48 AM

QUOTE

i wanna see this clip. it was divx, or xvid, right?

It was made with that nandub 1-pass tool. I just capped the quants to 3-3 range (which worked pretty well, although it was a bit heavy on the i-frames). If you don't agree with this method, you can suggest other settings. I will look for some space to upload a small clip and post it later on.

QUOTE

one can reason in this way; if that codec will always give same artefacts on same quant on same source, it's constant quality. you may not like that quality, but it's constant.

The point is that the complete video wasn't just the space shuttle in the sky, there were also people talking and that looked far less annoying to me, so I say quality is not constant. But if you are gonna define constant quality with such restrictions, then yes, you are right.

QUOTE

i mean...you didn't thought i would be interested in re-encoding the dvds?

Source is source; you cant make general comments about things if you only are interested in your specific use. But ill pick one of those.

Posted by: frank10 Aug 29 2005, 10:02 AM

Apart from a q3 looking bad or good, it's the theory behind this that we're interested in.

We also don't have so many variables as you said:

Let's say we take a clip and a codec (doesn't matter which one with its weakness) with ffvfw (that has constant Quantizer option), some resolution (doesn't matter which one) and some other settings fixed.
Then we change ONLY the quantizer setting.
Let's say we choose a q4. Then we change it at q3 and so on...

Which final clip will be better (or will have a better quality, detail, look, psicovisual-acustic appearance

).

For sure it's not the better compression efficiency in filesizes but here we're talking about quality (Can we use this word?

)

I mean if frameX in this clip has a q4, how can that same frame be better with the same settings-codec? Only with a q3 or q2. Simple. And that is linked with a gain in kbs (as you said earlier this gains quality).

So it seems to me that generally speaking different analysys of the same clip tweaked several times to gain lower average-std dev makes sense and the one with the lower q will look better.

Posted by: stephanV Aug 29 2005, 10:35 AM

clip is here --> http://www.savefile.com/files/6087410 (0.5 MB)

QUOTE

Let's say we choose a q4. Then we change it at q3 and so on...

I never argued that for the SAME source q4 was better than q3. My argument is about two things:

1. While for the SAME source q3 is better than q4 (or definitely not worse), it doesn't necessarily mean q3 looks good. There is big difference in concept between 'better <-> worse' and 'good <-> bad'.
2. When different sources are compared, it might be that q4 vid is better than the q3 vid. (The clip I posted above looks pretty poor in my opinion and I can show you other clips at q4 that are more acceptable to watch then that.)

Posted by: i4004 Aug 29 2005, 02:17 PM

techmage, sod off.

stephan; load this clip straight to vdub(i used 1410), and hit 'play input'. now rewind and hit 'play output'. now load via dshowsource (ffdshow decoding) and hit 'play output'.

you know, i was also recently tinkering with gradient (because i run into http://forum.doom9.org/showthread.php?t=99246 ).

it's a colorspace limitation(namely, output colorspace limitation, as you saw different playback methods change things).

get this;
http://i4004.net/i4004/gradient/imagereader_3.m2v
load to vdub-mpeg2. how does it look?
play in (for example) windvd or with elecard. how does it look?

QUOTE

Source is source

certainly not.
if you use dvd as a source, then you're just recompressing the already smoothed video.
it is already smoothed for 2 reasons:
-it is a film source
-it passed one compression already

use something sharp that video camera produced.
or something that was artificially produced and has sharp edges etc. (graphics ..you know, the stuff that rings

)

QUOTE

2. When different sources are compared, it might be that q4 vid is better than the q3 vid. (The clip I posted above looks pretty poor in my opinion and I can show you other clips at q4 that are more acceptable to watch then that.)

wohoo..wait; you'll be comparing different quants on different sources?
what will that tell us?

talking about taking things too far.

Posted by: stephanV Aug 29 2005, 03:36 PM

QUOTE

it's a colorspace limitation(namely, output colorspace limitation, as you saw different playback methods change things).

Partly, since different codecs behave differently on this (ffvfw seems to have less banding). In any case, its highly annoying. Some guy from ateme said it was because codecs all optimize for PSNR and it is this what causes it... we'll see if it ever gets better though.

QUOTE

wohoo..wait; you'll be comparing different quants on different sources?
what will that tell us?

Exactly what I have been trying to tell you: constant quant is not constant quality. Constant quality is not: "quality changes every time there is a scene change"

Posted by: i4004 Aug 29 2005, 05:02 PM

QUOTE

we'll see if it ever gets better though.

as soon as luma and chroma planes get to be 16bit.
that should give it enuff levels.

(i just laughed at our priv. forum how zx-spectrum was 8-bit.)

but i would say this is a rare problem. i'm not complaining.

cquant is constant quality in the mpeg context.
offcourse, as you've pointed out here, mpeg context is not the best (or absolute) merit for the reasons you mention.
yes.
i can't say that mpeg is compressing everything equally good. indeed.

but let's focus on the mpeg sequences test. i (still) don't have these sequences (should tell somebody to dload and send them to me) so i'm interested to hear about your attempts to decode these. perhaps a mere yuy2 decoder of huff could do. or ms' (from directx).

Posted by: frank10 Aug 29 2005, 05:23 PM

QUOTE

Well, stephanV, both points seem obvious to me: it always depends on the source. For example, if you get a noisy one, how can you compare to a clean one? There's no q (and nothing else) at all!

But i4004 and me were never saying to use this tool this way. I started this thread to ask how to adjust a clip regard the resolution and bpp; then I saw this drfAnalyzer and I thought this could help to find out when you are in the good way to get the best from THAT SAME clip. That doesn't mean of course that clip will look good (it's always a source thing), but that you're getting out the best you can from it. That's all.
At least here we are converging.

I agree someone could be using this util wrong comparing different clips, but they aren't us.

btw: in your shuttle clip DRFanalyzed it could have been some clue on poor quality because of bpp with the relative warning...

Posted by: stephanV Aug 29 2005, 06:49 PM

@ivo:

QUOTE

i can't say that mpeg is compressing everything equally good. indeed.

I'm glad we have some sort of understanding then.

QUOTE

but let's focus on the mpeg sequences test. i (still) don't have these sequences (should tell somebody to dload and send them to me) so i'm interested to hear about your attempts to decode these. perhaps a mere yuy2 decoder of huff could do. or ms' (from directx).

Its raw YUV data. use avisynth with rawsource:

CODE

loadplugin("d:\avsplugins\rawsource.dll")
rawsource("e:\downloads\720p50_mobcal_ter.yuv", 1280,720, "i420")

syntax is: rawsource(filename, width, height, colorspace)

@frank:

QUOTE

Well, stephanV, both points seem obvious to me

Good!

QUOTE

btw: in your shuttle clip DRFanalyzed it could have been some clue on poor quality because of bpp with the relative warning...

Well I cant go any higher in bit rate as q1, and q3 is already quite high if you ask me.

And now I'm off to do some b-frame testing. Not with XviD, but x264, since I dont want to install things anymore I won't use anyway.

eeeeeeerrrrrrrrrrr - wait, theres no WAY i can play h264 720p@50fps, so i have to use XviD after all

(or do libav b-frames not crash anymore)

Posted by: i4004 Aug 29 2005, 09:20 PM

ftp://ftp.ldv.e-technik.tu-muenchen.de/pub/test_sequences/601/

use that and deinterlace.
i mean, do we care about 720p?
i don't.

btw. saw this
http://forum.doom9.org/showthread.php?p=687136#post687136

my experience is simillar; they don't really help. they can bring bitrate down, but with it the quality too.

Posted by: stephanV Aug 30 2005, 12:18 PM

any other wishes? resizing? deinterlacing method?

Posted by: i4004 Aug 30 2005, 03:14 PM

no, not really.
you do it like you would do it for yourself regarding res. and deint. methods.

Posted by: stephanV Aug 31 2005, 01:52 PM

ok, finished a small test with parkrun.yuv using this AVS-script:

CODE

loadplugin("d:\avsplugins\rawsource.dll")
loadplugin("d:\avsplugins\kerneldeint140.dll")

rawsource("e:\downloads\576i25_parkrun_ter.yuv", 720,576, "i420")
kerneldeint(1)
crop(16,0,0,0)
lanczos4resize(624,352)

I did three encodes with x264cli rev291, setting can be found in encoding info.tx as well as the x264 output (bit rates and such). (QP24 H264 ~ QP 4 MPEG4 ASP)

I uploaded JPGs, PNGs and MKVs for people to watch and mplayer from latest CVS in case you dont know how to play the MKVs.

encoding info: http://www.geocities.com/grotesteph/encoding_info.txt (2.5 kB)
vids: http://www.savefile.com/files/5207998 (14.5MB)
mplayer: http://www.savefile.com/files/2597717 (2.1 MB)
picspng: http://www.savefile.com/files/1482877 (1.6 MB)
picsjpg: http://www.savefile.com/files/6847466 (761 kB)

To me they (the vids) all look the same but you probably have a different opinion.

NOTE: use mplayer with -fps 25, cause timing is completely screwed in mplayer.

Posted by: i4004 Aug 31 2005, 04:43 PM

QUOTE

(624,352)

on 3.5-4mbit/s?

that is about 0.63-0.72bpp (

).

h264 codecs' target bitrates should be under 0.2bpp.

with such high bitrates, you would have the transparency with mpeg2 too.

perhaps we misunderstood each other; i wasn't interested in cquant. encodings; never was, never will be;
cq is either too big (and looking good) or looking bad(and too low bitrate).
almost impossible to get a good balance on cquant. encodings.

perhaps i'll do a test with tmpgenc and mencoder with mpeg1 to show you what i mean when i say b-frames do more harm than good.
perhaps not..uploading anything bigger than 1mb is such a pita for me that it's incredible.
(test would include ibbp and ippp (15 frame) gops on simillar bitrates of about 1.2mbit/s for lores clips(in abr mode))

btw. looking at the
http://www.geocities.com/grotesteph/encoding_info.txt

->i-frames have different q than p and b frames
->when p and b frames had same quant. ratio, you spared almost no bitrate.
->encoding with usual usage of b-frames (ie b-frames with higher quant than rest frames) has worst psnr.

offcourse all those points are moot(esp psnr

) as you ended up with such a (too) high bitrate clip.

Posted by: stephanV Aug 31 2005, 04:48 PM

rate control on a 10 second clip will always fail, so i dont know why you suggested those sources then? and i dont feel like doing things over and over again till they have the same bit rate. to give you an example, when i used nandub on the clip and set it to 1100 kbps it came out as 2400 kbps. all quants were 8! as set as the limit and it looked like crap to. 1100 kbps is the 0.2 bpp you were hoping for. sorry, not with this source.

I asked you for settings, you said everything would be fine... so... you asked yourself how much bit rate b-frames would spare, I cant do that with a bit rate based encoding.

a misunderstanding then yes...

QUOTE

perhaps i'll do a test with tmpgenc and mencoder with mpeg1 to show you what i mean when i say b-frames do more harm than good.

no one is interested in mpeg1 b-frames, its not the same as a mpeg4 asp b-frame and not even close to a h264 b-frame. If you base your experience on that... well ok...

QUOTE

i-frames have different q than p and b frames

blame aku for the ipratio 1.2 default, i saw no reason to change it.

Posted by: i4004 Aug 31 2005, 07:01 PM

QUOTE

rate control on a 10 second clip will always fail,

it will?

you wanted to say "rate control failed on this source which is hard to encode".

QUOTE

you asked yourself how much bit rate b-frames would spare, I cant do that with a bit rate based encoding.

your test served its purpose; it showed that b-frames are not really saving anything. if they utilise same quant as p-frames, then there is no saving.
b-frames are increassing the compression ratio, and with it they deteriorate quality.

no news there, i'm sure.

QUOTE

no one is interested in mpeg1 b-frames, its not the same as a mpeg4 asp b-frame and not even close to a h264 b-frame.

so are you saying that b-frames of these two look better or the same as p-frames while having higher quant. at the same time?
if not, then in what way are they better than b-frames
of mpeg1/2?

i presume you read the 3 standards' specs so you can say this?

QUOTE

blame aku for the ipratio 1.2 default, i saw no reason to change it.

i imagine it is incredible hard to change it to 1.0?

Posted by: stephanV Aug 31 2005, 07:17 PM

QUOTE

you wanted to say "rate control failed on this source which is hard to encode".

No.

QUOTE

But is the detoration worth the gain in file size, or not? You cannot possible answer that like this. I could not see a difference, so i'd say yes. Of course I'd have to do a P-frame only clip on qp 26 to just to be sure.

QUOTE

so are you saying that b-frames of these two look better or the same as p-frames while having higher quant. at the same time?

I didnt recall me saying that? But at the same quant h264 b-frames are actually better than p-frames (but i didnt use multiple references, which surely would have helped the p-frame only encode).

QUOTE

if not, then in what way are they better than b-frames
of mpeg1/2?

They have more tools perhaps? (wpred, b-pyramid, more block sizes). Or do you want me to prove that each of those things actually helps? Well, no thanks.

QUOTE

i presume you read the 3 standards' specs so you can say this?

You can just ask people, no need to read a whole spec for that. Thats nonsense.

QUOTE

i imagine it is incredible hard to change it to 1.0?

I don't see the problem in keeping it 1.2. If you could explain how it would affect results?

Posted by: i4004 Aug 31 2005, 09:52 PM

QUOTE

No.

so if i show you a 10sec clip which hits the target, what will you say?

or a 75frame clip?
http://www.geocities.com/wilbertdijkhof/analog_comp/comparison.htm

now what?

can you still claim

QUOTE

rate control on a 10 second clip will always fail,

QUOTE

But is the detoration worth the gain in file size, or not?

you mean "is the deterioration worth the bitrate savings?".
i say it's not worth it. i say savings are so small that it's just not worth it.
btw. can i suggest you a good reason why mpeg1/2 has (and needs) b-frames, and why mpeg4 doesn't?
gop-size.
but the price(of b-frames) IS payed, you know.

the savings (via b-frames) on mpeg1/2 should be higher as i-frames are so close.

QUOTE

But at the same quant h264 b-frames are actually better than p-frames

b-frames better than p-frames?
how can they be better than p-frames if they are (partially)predicted from p-frames?

QUOTE

You can just ask people

ask them what?

here, ask this bloke
http://forum.doom9.org/showthread.php?p=687136#post687136

you're providing simillar sort of answers as sharktooth....and you deserve http://forum.doom9.org/showthread.php?p=689374#post689374.

what people say? people were saying vhs is 320x240.
people are saying xvid is perfect codec. people are saying .mp4 will play in hd standalones because bond has mp4 standard datasheet and he can tell future.
people.....

QUOTE

I don't see the problem in keeping it 1.2. If you could explain how it would affect results?

well, if you wanted to do cq, then it's not cq if i-frames have some different quant. remember what we said about b-frames on xvid, when you said you're not stupid.

oh, btw. why am i not doing b-frame tests with xvid, divx5/6 and x264?
you know about the first two, and x264 is too slow on cel1.3ghz.
i did few tests with ffvfw b-frames. didn't liked it at all.
they (i also did few tests with xvid..just because i'm curious) just make the encoder not reach the target bitrate (bitrate stays too low...encoder is saturated), and spoil the image with higher q. b-frames.

so i don't see why would i ever use them with mpeg4. to spare few % of bitrate, and destroy image by few %?
i think not.

i think i'll do that mpeg1 test, as that has some value for me, because i'll be doing toons with mpeg1, so if i find that b-frames don't yield big enough sparing, and that they spoil too much, i won't use them there either. mencoder's mpeg1/2 is halfway mpeg4 anyway.

btw. i'm not saying that mpeg4 encodings with b-frames necesarilly look bad, or something. just that encodings without them look better. or (in other words) more compression=worse quality. that is the rule either way you look at it.

damn, i missed the beginning of the 'leolo' because i was writing this.....but ok...i'll get it in the rerun.

Posted by: stephanV Aug 31 2005, 10:24 PM

QUOTE

now what?

Even if you allow for 5% devation only one of those clips is within the range of 1200kbps. Where i come from 1019 unequals 1200... so now what?

QUOTE

you mean "is the deterioration worth the bitrate savings?".
i say it's not worth it. i say savings are so small that it's just not worth it.

But you show no proof of it. I gave you samples and you refuse to look at them, what can I do more? Put a gun on your forehead and maje you watch them?

QUOTE

b-frames better than p-frames?
how can they be better than p-frames if they are (partially)predicted from p-frames?

Ok lets rephrase: "The encode with b-frames with the same quant as p-frames was *slightly* better than the encode with p-frames only."

Happy now?

QUOTE

you're providing simillar sort of answers as sharktooth....and you deserve same answer.

If you think providing three samples and pics is a short answer (which is more than that "bloke" as he only gave opinions)... then ok... realize that you have offered me nothing more than your short answer. I ask your honest opinon about those samples and you repeat the things you already said without even looking. So I should still bother here?

Exactly.

Posted by: i4004 Aug 31 2005, 10:52 PM

QUOTE

so now what?

now you get the title "un grandiouse nitpicker".

only one, yes. the only one.

QUOTE

Put a gun on your forehead and maje you watch them?

you did cq test.

QUOTE

Ok lets rephrase: "The encode with b-frames with the same quant as p-frames was *slightly* better than the encode with p-frames only."

Happy now?

you mean 36.77 vs 36.78?

you don't see a difference between 36.25 and 36.7x(

) and you're now calling clip with cq b-frames "slightly better"?

uhm....

you said you don't see a diference...and i believe you.
at over 3.5mbit/s on 624x352, who would?

QUOTE

I ask your honest opinon about those samples and you repeat the things you already said without even looking. So I should still bother here?

i'm not interested in any cquant. samples, esp. x264 samples. i already told you this.
no, you don't have to bother (or get insulted, for that matter; who insulted you? ) anymore....i said i'll try to do a lil bit more 'real-life' sample of what i ment when i said what i said.
your 3.5/4mbit/s x264 samples serves no purpose whatsoever. (unless you're actually encoding in that mode, and in that case i apologize for saying the preceding sentence.)

i don't "refuse" to look at your samples, but i don't wanna dload 14.5mb pristine looking x264 cquant. on very high bitrate. i DO believe you it looks excellent!
ie that they ALL look excellent.
but i'll try to show you (with short clips...150kB/s of vcd bitrate is not too bad for upload) what i ment.

you may say that that test(i'll do) is theoretically worthelss, but i assure you it'll be very usefull for me and my encoding practice.

oh yeah, and thanks for your test. it helped me confirm my thoughts on b-frames.

Posted by: i4004 Sep 1 2005, 12:21 AM

ok, i did a short test with mpeg1. here's what i saw:
encoding with b-frames got cca. 230kbit/s less bitrate, and i can't tell the difference between the two.

now if you can do same thing with mpeg4 codec you're using(not just you stephan...

) then sure: go right ahead.

(i hope that concludes it nicely.

)

for me , business as usual, though; mpeg1/2 with b-frames, and divx3 without them(definitely divx3 without them!

).

ps/
i just tried simillar thing with x264(vfw); the result is different this time. encoding without b-frames looks better (notice the green board behind the man, and the wall (to the left)when camera 'unzooms'..also the green floor infront of the desk in same time).
how do you hide the fact that quantizer is constantly changing between b and p frames on flat surfaces like this?
http://i4004.net/i4004/?d=b-frames[x264]&s=&r=

Posted by: stephanV Sep 1 2005, 08:38 AM

QUOTE

now you get the title "un grandiouse nitpicker".

only one, yes. the only one.

Uhm... a difference of 180 kbps at those bit rates probably means something like 1 point of PSNR difference... do you know how many people codec developers would kill for 1 point improvement? (yes, this is a figure of speech). This is not nit-picking at all.

QUOTE

you did cq test.

I asked you what I should do... you said its up to me. Now the results don't suit you, you say the settings are not to your liking? Thats low.

QUOTE

you don't see a difference between 36.25 and 36.7x and you're now calling clip with cq b-frames "slightly better"?

Same quality at slightly lower bit rate = slightly better.

QUOTE

you said you don't see a diference...and i believe you.
at over 3.5mbit/s on 624x352, who would?

Must i remind you that nandub at 2400 kbps looked like utter crap?

QUOTE

or get insulted, for that matter; who insulted you?

You did when you compared me with Sharktooth. And now you did it again by calling me a nit-picker where its completely out of place. Yes that is insulting, you don't need to use curse-words to insult someone.

QUOTE

ps/
i just tried simillar thing with x264(vfw); the result is different this time. encoding without b-frames looks better (notice the green board behind the man, and the wall (to the left)when camera 'unzooms'..also the green floor infront of the desk in same time).
how do you hide the fact that quantizer is constantly changing between b and p frames on flat surfaces like this

The difference in bit rate is a nice 20% between the samples, you can make look anything bad like that. And youre not gonna tell me the board doesnt get fuzzy with the p-frame only encode, or that you dont see moving blocks on the wall with the p-frame only encode? Knowing you, you probably turned pp on too with b-frames.

Posted by: i4004 Sep 1 2005, 07:09 PM

QUOTE

do you know how many people codec developers would kill for 1 point improvement?

on 10sec (or 75frames) 1pass clips?
none.

QUOTE

I asked you what I should do... you said its up to me. Now the results don't suit you, you say the settings are not to your liking? Thats low.

come on. you knew i don't encode in cq mode, so why should i care about it?
what do you mean results don't suit me?
they do. you did a good test that shows how if b-frames are on same q. as p.frames there is almost no advantage from b-frames.
you also shown b-frames bring bitrate down. and you shown that b-frame on quant22 looks beter than b-frame on 24, and that p-frame on 22 loks better than either b-frame(22 or 24). you also shown that on high bitrates differences get to be smaller.

but these are not some breath-taking news. just one test that shows and proves the general rule.

QUOTE

Same quality at slightly lower bit rate = slightly better.

cool!
but who is doing 3.5-4mbit avc?
on such a low resolution.

your test is good, but it's not 'real-life' test.
(unless, as i said, you actually encode in this way, in which case i apologize.)

QUOTE

Must i remind you that nandub at 2400 kbps looked like utter crap?

you mean this;

QUOTE

to give you an example, when i used nandub on the clip and set it to 1100 kbps it came out as 2400 kbps. all quants were 8! as set as the limit and it looked like crap to. 1100 kbps is the 0.2 bpp you were hoping for. sorry, not with this source.

well, set it to 4.1mbit/s, and set drf span to (say) 3-11.
and yes, for some sources 0.25 is not enuff. i have said that long time ago.

QUOTE

You did when you compared me with Sharktooth.

no, truth can never be insult. i will come back to this a bit later. (and francesco is not a bad person, is he? i have compared you as you two seem to hold a simillar point about b-frames)

QUOTE

And now you did it again by calling me a nit-picker where its completely out of place.

would you say nandub did a good job considering it's a 75frames clip?

QUOTE

Yes that is insulting, you don't need to use curse-words to insult someone.

no, it is not insulting. i'm a nitpicker too.

that's why we're having this conversation.
because we're both nitpickers.

QUOTE

ok, now i'll come back to that 'sharktooth insult issue'.
i hope that by now some things should be clear about b-frames;

1-they were invented to bring down the bitrate(back in the mpeg1/2 days, as they needed to fit video and audio(mpeg1) to 1500kbit/s of cds...74 min on 74min cd. this was the aim they set to do.)
2-if they have higher quant. than p-frames, they look worse than p-frames, and if they have same quant as p-frames, there there is no point in using them, as they won't bring down the bitrate (as your test nicely shows)
do we agree so far?
so in essence b-frames are a compression tool. they try to increase the compression. that's why i used them in this test in that way(i lowered bitrate when i used b-frames on x264), and i tried to see if they bring perceptable quality decrease. they do, because all of the things i said.

now i must go back to mpeg1; why don't they bring a havoc there; well simplest answer may be "because i/p frame pumping already brings its havoc, so it's harder to see the p/b deterioration".
i want to say this; p/b sequence on mpeg4 is not unlike the i/p sequence on mpeg1/2.
both produce a sharp jump in quantizer, and sharp jump in quant. MUST be visible. it is visible either like in this toon(more blocking) or like more overall blur.

in this respect, you didn't prove any of this wrong, ergo his and your answer of 'people have agreed on it' does not satisfy me.(now i'm nitpicker, see.)

i think you agree with me if i say; b-frames increase the compression and decrease the quality.
this should be (by now) factual.

(i think that a stream with p-frames alternating quant/two quant+2 frames would be very,VERY simillar to stream with b-frames of quntb=quantp+2)

how much they decrease it and is it worth it?
i left this to codec users. they know the best what is acceptable to them, and what is not. i just wanted to state the facts about b-frames.

i have found those to be the facts after plenty of tests i did, and after reading the codec specs (yeap, i read the specs.). there is no way for b-frame to bring anything other than compressability and image deterioration. b-frames are not some magic that brings frames that look beter than i/p frames they are derived from.
(offcourse, i'll do any test you suggest that may prove me wrong.)

and to address the last two sentences i quoted above;
1-b-frames encoding blocks more
2-you obviuosly don't know me if you think i use pp on codecs that use in-loop. in fact i don't use pp <period>
(see, that was some sort of insult as you accused me of some sort of cheating and amateurism...but...it's cool...no problem...

...in the heat of discussion....)

do we agree now? be aware that i have put accent on the bare facts about b-frames, and not so much about ways to balance with bitrate and b-frames in respect to quality-loss, which is a legitimate subject too, for sure.

Posted by: Tommy Carrot Sep 1 2005, 09:19 PM

QUOTE (i4004 @ Sep 1 2005, 08:09 PM)

there is no way for b-frame to bring anything other than compressability and image deterioration.

Apologies to bluster in your debate, but i must have a comment on this.

The concept of the b-frames is that they save more bitrate than the quality degradation they cause (for example: 20% bitrate saving, 5% quality degradation), so if you increase the bitrate back to the original quantity, you'll get better quality (not necessarily measurable with metrics, but visually anyway). And this concept is working indeed.

Another possible advantage is that the motion estimation is better with b-frames, he motions are most fluid and more precise, at least this is what i noticed with xvid and x264.

Posted by: stephanV Sep 1 2005, 09:42 PM

QUOTE

on 10sec (or 75frames) 1pass clips?
none.

Its completely unthinkable that devs use test 10 second sequences like foreman, right?

Right?

Guess again.

It doesnt even matter if its a 10 seconds clip or a 1 hr clip, the difference will remain roughly the same. 20% deviation is just unacceptable.

QUOTE

no, truth can never be insult. i will come back to this a bit later. (and francesco is not a bad person, is he? i have compared you as you two seem to hold a simillar point about b-frames)

Not at all. His standpoint was this:

QUOTE

It has been discussed to death and the final conclusions is B-frames definatly help compression (and so final quality).
Obviously there are scenarios where b-frames arent needed/wanted (for example lossless encoding).

This not my standpoint at all. Do you actually think I would test this if I already believed in this dogma? What would there be in it for me then? Absolutely nothing. Never accuse me of being dogmatic.

QUOTE

no, it is not insulting. i'm a nitpicker too.

Yes it is insulting. And someone who thinks 20% is not a big deviation cant possibly be a nit-picker.

QUOTE

so in essence b-frames are a compression tool. they try to increase the compression. that's why i used them in this test in that way(i lowered bitrate when i used b-frames on x264), and i tried to see if they bring perceptable quality decrease.

This is completely flawed logic... if you would have lowered the bit rate on the p-frame only encode, would you have seen a decrease there too? Yes, I presume.

QUOTE

it is visible either like in this toon(more blocking) or like more overall blur.

QUOTE

1-b-frames encoding blocks more

P-frame only encode with 20% lower bit rate blurs and blocks more too. Fact!

If you want some PSNR results, here. If not, they are still here:

CODE

E:\SUBARU>x264 -p 2 -B 3500 -o test.mkv test.avs
avis [info]: 624x352 @ 25.00 fps (252 frames)
x264 [info]: slice I:4 Avg QP:21.50 Avg size: 38329 PSNR Mean Y:42.53 U:45.79 V:46.72 Avg:43.41 Global:41.62
x264 [info]: slice P:248 Avg QP:25.23 Avg size: 17159 PSNR Mean Y:35.72 U:39.35 V:41.06 Avg:36.74 Global:36.69
x264 [info]: slice I Avg I4x4:49.7% I8x8:0.0% I16x16:50.3%
x264 [info]: slice P Avg I4x4:0.0% I8x8:0.0% I16x16:0.0% P:73.3% P8x8:19.4% PSKIP:7.3%
x264 [info]: PSNR Mean Y:35.83 U:39.46 V:41.15 Avg:36.85 Global:36.74 kb/s:3499.0

encoded 252 frames, 5.02 fps, 3499.10 kb/s

E:\SUBARU>x264 -p 2 -B 3500 -b 3 --weightb --b-pyramid -o test.mkv test.avs
avis [info]: 624x352 @ 25.00 fps (252 frames)
x264 [info]: slice I:4 Avg QP:21.00 Avg size: 37570 PSNR Mean Y:42.41 U:45.38 V:46.51 Avg:43.26 Global:39.52
x264 [info]: slice P:128 Avg QP:23.95 Avg size: 25753 PSNR Mean Y:36.77 U:40.01 V:41.53 Avg:37.72 Global:37.67
x264 [info]: slice B:120 Avg QP:26.07 Avg size: 8010 PSNR Mean Y:35.72 U:39.92 V:41.40 Avg:36.80 Global:36.69
x264 [info]: slice I Avg I4x4:49.7% I8x8:0.0% I16x16:50.3%
x264 [info]: slice P Avg I4x4:0.6% I8x8:0.0% I16x16:0.0% P:67.8% P8x8:29.6% PSKIP:2.0%
x264 [info]: slice B Avg I4x4:0.0% I8x8:0.0% I16x16:0.0% P:23.0% B:37.0% B8x8:7.8% DIRECT:9.5% BSKIP:22.7%
x264 [info]: PSNR Mean Y:36.36 U:40.05 V:41.55 Avg:37.37 Global:37.20 kb/s:3498.2

encoded 252 frames, 6.07 fps, 3498.36 kb/s

(both are a 3 pass.)

Of course PSNR doesn't mean everything, but the difference is pretty big (0.46 dB for global)

Posted by: i4004 Sep 1 2005, 10:20 PM

QUOTE

The concept of the b-frames is that they save more bitrate than the quality degradation they cause

yes. during the cause of this thread i'm just claiming that they indeed _cause_ degradation. i don't agree with 20%&5% though.

but numbers are not very important here. i just wanna establish that b-frames deteriorate image quality. and by the time they don't, they actually _increase_ the bitrate, not decrease it.

QUOTE

so if you increase the bitrate back to the original quantity, you'll get better quality

well (simillar as always really), compression gains you more acceptable quality on lower bitrates, indeed, BUT it usually also mean that a higher bitrate clips _without_ these compress.tools looks better than lower bitrate clips with these tools.

for example (numbers irrelevant here, i'm just showing a principle): if you have non-b-frames and b-frames endcoding at (say) 700kbit/s, encoding with b-frames may look better than 700kbit/s with p-frames only.
BUT if you have encoding at 1200kbit/s, then p-frame-only looks better than b-frame 700 AND better than 1200 with b-frames.
the rationale of this can be derived from stephan's tests: to look better than p-frames, b-frames would need to have quant lower than p-frames. in this case b-frames have higher bitrate than stream with p-frames only.
stephan has produced images that show p-frame at quant 22 looking better than b-frame on quant22(which is to be expected). and that means that b-frame can look better than p only if it uses lower quants than p-frames.
by that time, there is no bitrate savings whatsoever.

QUOTE

Another possible advantage is that the motion estimation is better with b-frames

i didn't notice this at all. last time i tried xvid, i was hoping that perhaps b-frames could help the "chroma trailing" that mpeg4 exhibits so readilly. but they didn't really. and neither did "chroma me" option, unfortunetaly.
but then again, x264 doesn't exhibit these problems of old mpeg4 codecs, so i guess it's more of an implementation problem, than some inherent standard issue.

QUOTE

he motions are most fluid and more precise, at least this is what i noticed with xvid and x264.

perhaps they're "more smooth", quite literally, as higher quant of b-frames smooths more.

the film sources can't look _that_ smooth anyway (they're not supposed to look smooth at 24 or 25fps. they're supposed to flicker at pans with high contrast inside the frames...and they do flicker but as you say..probably less with b-frames, as these will blur slightly more, and make it more 'fluid' as you said.)
the b-frames are trick simillar to in-loop. blur a bit and hope viewer won't notice it.

you know, i said this
http://forums.divx.com/groupee/forums/a/tpc/f/401101651/m/622109642/r/673101742#673101742
ages ago on divx forum, so i dunno why is stephan surprised etc.

you know, i'm looking at these bitrates(i get on capping) and thinking this way: if i had blue-ray disc, i would just leave my stuff as mjpeg at about 16mbit/s.
i woudl still fit more than 3hrs per-disc. (i would compress the audio, though....audio compression is soolved better than video compression)

Posted by: i4004 Sep 1 2005, 10:58 PM

QUOTE

s. by this time i don't like they way you're arguing. you're switching the focus to totally irrelevant things.
do you want to discuss target bitrate 'respect' by different codecs now?
ok, open new thread.
but i dunno what will we discuss?
a knowledgeable person can do a excellent filesize predictability in 1pass, while 2pass can be used by anyone with excellent predictability.
so it beats me why would you wanna talk about that.

QUOTE

This not my standpoint at all.

ok then. i apologize if i insulted you in that way.

QUOTE

Yes it is insulting. And someone who thinks 20% is not a big deviation cant possibly be a nit-picker.

20% deviation of what exactly?
what are you talking about?
divx4/5 and xvid clips can't do target bitrate at 75frames clip?
yes, i agree:these are crappy codecs.

(why in the world you brought that one up?)

QUOTE

This is completely flawed logic...

how come?
please explain.

QUOTE

P-frame only encode with 20% lower bit rate blurs and blocks more too. Fact!

you mean p frame vs b on 800 on this source?
i dunno, i didn't do that test.
do you want me to do it?
p-only on 800?

QUOTE

If you want some PSNR results, here. If not, they are still here:

please, please, quit making avc 3.5mbit/s 624x352 tests.
pretty please!

do you want me to do 9mbit/s mpeg tests?
well?
you think these hold some value, it seems?
send me the test clips u used and i'll do mpeg2 at 9mbit/s?
and?
will that make us any wiser?

psnr means exactly nothing, i would say. it's not detecting the artefacts at all.

i have made mpeg1 vs divx3 vs xvid vs x264 test (on same bitrate, mind you)where x264 has by far the highest psnr, and yet it looks the worse.
psnr didn't saw x264 blocking-silly.

looking at psnr, i get
-x264
-xvid
-divx3
-mpeg1

looking at video, i would put divx3 and mpeg1 on the top.
(and please don't mention dloading the clips again(as i discard the psnr and yet i don't wanna dload your clips). i'm not interested in avc on 3.5mbit/s. the highest i go is usually 2.5mbit/s.)

Posted by: i4004 Sep 1 2005, 11:28 PM

http://i4004.net/i4004/b-frames[x264]/3_NO2b_800.avi

still less blocking than b-frames clip.

Posted by: stephanV Sep 2 2005, 07:12 AM

QUOTE

f you have non-b-frames and b-frames endcoding at (say) 700kbit/s, encoding with b-frames may look better than 700kbit/s with p-frames only.

If you say this, I have no idea what we are discussing. You said before that b-frames never helped.

2.

QUOTE

my experience is simillar; they don't really help. they can bring bitrate down, but with it the quality too.

Now you are saying that at the same bit rate an encode with b-frames might look better. This is beyond me. If you had said the first sentence the very first time we discussed b-frames in this thread, we would have never had an argument.

But it is the same thing as with "constant quality". I guess.

Oh and about this

QUOTE

s. by this time i don't like they way you're arguing. you're switching the focus to totally irrelevant things.

Don't even dare go there. You were trying to convince me that codecs have good rate control on short clips by showing me "1200 kbps" clips, where actually non of them even was close to 1200 kbps. Don't even dare go there. My comment for not using bit rate was just factual (you could have just agreed) and you proved it by providing the link you gave me. Thank you.

QUOTE

please, please, quit making avc 3.5mbit/s 624x352 tests.
pretty please!

ok... ill resize it to 256x144 and do a test at 1000 kbps. Ill bet youll say then that your not interested in such low resolutions. The result will be the same anyway. If you fail to grasp that there is no sense in doing this clip at 2500 kbps, then please stop arguing about it.

Posted by: i4004 Sep 2 2005, 02:25 PM

QUOTE

If you say this, I have no idea what we are discussing. You said before that b-frames never helped.

i said they help compressabilty, but not the quality.
my standpoint from a get-go.

QUOTE

Now you are saying that at the same bit rate an encode with b-frames might look better. This is beyond me.

ok, then it is beyond you. it is a fair simple concept of higher-compression=>higher image deterioration i tried to explain. fcchandler and avery have (tried to, it seems as you surely didn't got it) done this in past too.

please note; b-frames=higher compression.

QUOTE

If you had said the first sentence the very first time we discussed b-frames in this thread, we would have never had an argument.

i have been saying the both things since the beginning.
even the quote you gave here says it.

i guess you didn't grasp this;
the b-frame encoding on low bitrate looks worse than p-frame only encoding at higher bitrate.
it doesn't look "the same". it looks worse.
got it?

QUOTE

i'll go wherever i like. what is the bitrate of nandub clip?
and what do you think this

QUOTE

in this case k = 1024 bytes, therefore the used bitrate is 1200 kpbs / 1.024 = 1172 kbps

means?
(for the life of me i can't understand why did YOU go there. because you ...wanted another fight without ending the first one? and why did you turn this into a fight? you can't love b-frames THAT much?)

QUOTE

If you fail to grasp that there is no sense in doing this clip at 2500 kbps, then please stop arguing about it.

yes, thers is sense in it, offcourse there is, only it never occured to you that lower bitrates (even too low bitrates tests) are ways more interesting than near-transparency tests you're trying to push.

one more thing is beyond me; essentially, we both have same results in our tests (only your tests is at higher bitrate so the visual impact should be less (less deterioration)when b-frames are used), ie results that prove what i've been saying all along. so why are we arguing?
i have told you that "how much b-frames deteriorate" is a good subject to some other discussion, BUT there shouldn't be (by now) arguing about "do b-frames deteriorate image or not". they do.
and the person that minds the banding problem in respect to cquality encodings is telling me "b-frames are ok"? person encoding lores at 3.5-4mbit/s is telling me "b-frames are ok"?

now what do you want to do for us to settle this?
do you want me to do the test with natural source(ie not toons)?
but you do understand that all i need (to prove my standpoint) is the b-frames clip looking 0.1% worse than p-frames clip on 20% higher bitrate?
as you are aware that during this thread, i was _never_ disucussing "how much deterioration b-frames bring", aren't you? i'm just saying they bring deterioration.
in other words, compressabilty interests me less and less, and quality more and more, so i go up with the bitrate(but not avc on 3.5mbit/s..hell no!), rather than trying to find ways to compress more...and lose more quality in doing it.

and oh yeah. calm down! our lives don't depend on this.

Posted by: stephanV Sep 2 2005, 03:38 PM

QUOTE

'll go wherever i like. what is the bitrate of nandub clip?

1167kbps, and dont say it got very close to 1172 then, because VirtualDub doesnt use 1kb = 1024 b. If you dont believe me substract overhead and do a calculation on raw data. 1167 is still quite a bit of from 1200.

QUOTE

i have told you that "how much b-frames deteriorate" is a good subject to some other discussion

It is the only point of discussion, saying a quant 4 frame looks better than the same frame at quant 6 is so obvious that I thought we were already beyond that. That doesn't need any discussion.

The main question is what you just said, and I asked you before in this thread, to which you answered

QUOTE

you mean "is the deterioration worth the bitrate savings?".
i say it's not worth it. i say savings are so small that it's just not worth it.

And I disagree. It is worth it.

QUOTE

now what do you want to do for us to settle this?

Since all you wanted to say is that a frame at quant 4 looks better than the same frame at quant 6 you don't have to do anything. I agree.

Posted by: i4004 Sep 2 2005, 06:43 PM

QUOTE

And I disagree. It is worth it.

ok, that's fair.
in a time of dvdrs i feel freedom not to save in such ways.

your standpoint is valid, my standpoint is valid.

Posted by: stephanV Sep 2 2005, 08:53 PM

QUOTE

in a time of dvdrs i feel freedom not to save in such ways.

see, i still dont have a DVD burner...

Posted by: i4004 Sep 2 2005, 10:42 PM

well, YOU should have said THAT at the beginning!