|
|
| frank10 |
| Posted: Aug 6 2005, 09:41 AM |
 |
|
Advanced Member
Group: Members
Posts: 148
Member No.: 14177
Joined: 19-February 05
|
I've read this link that fccHandler gave me on another thread:
http://forum.doom9.org/showthread.php?p=65...4100#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?  |
|
| jazzzy786 |
| Posted: Aug 8 2005, 09:30 PM |
|
|
Advanced Member
Group: Members
Posts: 105
Member No.: 12723
Joined: 14-November 04
|
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. |
|
| frank10 |
| Posted: Aug 9 2005, 08:04 AM |
|
|
Advanced Member
Group: Members
Posts: 148
Member No.: 14177
Joined: 19-February 05
|
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...t=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? |
|
| stephanV |
| Posted: Aug 9 2005, 08:19 AM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
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.
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| i4004 |
| Posted: Aug 9 2005, 01:52 PM |
|
|
Advanced Member
Group: Members
Posts: 2432
Member No.: 4935
Joined: 24-June 03
|
(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.
--------------------
my signature:
 |
|
| frank10 |
| Posted: Aug 9 2005, 08:56 PM |
|
|
Advanced Member
Group: Members
Posts: 148
Member No.: 14177
Joined: 19-February 05
|
@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? |
|
| stephanV |
| Posted: Aug 9 2005, 09:15 PM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
| 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. 
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| i4004 |
| Posted: Aug 9 2005, 09:46 PM |
|
|
Advanced Member
Group: Members
Posts: 2432
Member No.: 4935
Joined: 24-June 03
|
| 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.
--------------------
my signature:
|
|
| frank10 |
| Posted: Aug 10 2005, 10:44 AM |
|
|
Advanced Member
Group: Members
Posts: 148
Member No.: 14177
Joined: 19-February 05
|
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? |
|
| stephanV |
| Posted: Aug 10 2005, 11:36 AM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
1.7 mbit/s, 2 mbit/s... whats the difference (your calculation was correct)
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| i4004 |
| Posted: Aug 10 2005, 12:47 PM |
|
|
Advanced Member
Group: Members
Posts: 2432
Member No.: 4935
Joined: 24-June 03
|
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 ffvfw-mpeg4, 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).
--------------------
my signature:
|
|
| frank10 |
| Posted: Aug 24 2005, 02:48 PM |
|
|
Advanced Member
Group: Members
Posts: 148
Member No.: 14177
Joined: 19-February 05
|
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? |
|
| stephanV |
| Posted: Aug 24 2005, 03:09 PM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
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.
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| frank10 |
| Posted: Aug 24 2005, 03:59 PM |
|
|
Advanced Member
Group: Members
Posts: 148
Member No.: 14177
Joined: 19-February 05
|
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? |
|
| stephanV |
| Posted: Aug 24 2005, 05:13 PM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
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)
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
|
