mpeg2 quality check

[45tripp]

Say I've encoded a divx/avi sample clip to dvd compliant mpeg2s with many different option variations.
What would be the best way to cross check for the best quality?
Should I just author to DVD and stick the dvd to play on the bigest tv screen I can find?
What should I be looking for? Apart from the subjective general impression of overall clip output.
Are there any good technical tests to be done on the clips while on the pc?

ty

[guns1inger]

http://www.compression.ru/video/quality_measure/video_measurement_tool_en.html

[45tripp]

Looks interesting.

Unfortunately I can't use it.
I tried frameserving my mpegs to it but no luck.
I found out that I can't load mpegs to VirtualDub either.

I've used both:
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\DGdecode.dll")
mpegSource("Proc15-q1-21min.m2v")

and
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\Mpegdecoder.dll")
mpegSource("CCESP2-q1-11.3min.mpv")

All I get are colored lines
pic attached

What am i to do?


For the subjective viewing test I'll probably author to dvd go to a friend and use his 42" tv and his eyes to compare the clips.

untitled.bmp

[guns1inger]

You can load mpegs into virtualdubmpeg2

[45tripp]

Yeah I know.

And can capture specific bmps and compare them in MSU.
But as msu takes avs files I should be able to load the entire mpegs via frameserving and compare them.

Should be able to load mpegs with avisynth anyway...
Any ideas what is wrong?

[guns1inger]

Use DGindex to create a d2v file.
Then use mpeg2source to load the .d2v instead of the mpv file.
Make sure you load the dgdecode.dll from the dgindex installation so everything matches up.

[45tripp]

Thanks.

I'd tried it but typed mpegsource instead of mpeg2source


Any reason why these won't work?
Is it a common occurence?

I've used both:
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\DGdecode.dll")
mpegSource("Proc15-q1-21min.m2v")

and
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\Mpegdecoder.dll")
mpegSource("CCESP2-q1-11.3min.mpv")

[guns1inger]

I rarely process mpeg source, but as a general rule when using avisynth, it is good practice to open your scripts in virtualdub or media player classic, as these will generate error messages for bad scripts.

Is there a reason you won't use mpeg2source ?

From the author's site comes this template structure for avs

loadplugin("...\DGDecode.dll")
mpeg2source("pathtovideo.mpv",cpu=6)

Give it a try

[45tripp]

hi

none work with vdub alone.
If I use mpeg2source vdub gives me an error saying input is not a D2V project.
If I use mpegsource, it creates a d2v file of it's own and i get images like the one i attached.

I can use mpeg2source with a d2v file created by dgindex and mpegsource with the mpeg as long as i've already created a d2v file with dgindex.

[manono]

Hi-

If I use mpeg2source vdub gives me an error saying input is not a D2V project.
If I use mpegsource, it creates a d2v file of it's own...

My first thought is an old and obsolete version of AviSynth installed. What version are you using? If you're not sure of your version number, make an .avs and name it Version.avs. Inside have just this one line:

Version()

Open in VDub(Mod) and check. I think you probably have a very old version of AviSynth, because there isn't even any longer an MPEGSource command, as near as I can tell. We're up to Ver. 2.5.7. If you don't have it installed, get it, install it, and use it:

http://sourceforge.net/project/showfiles.php?group_id=57023

If you really do have an up-to-date version of AviSynth installed, I'd start over if I were you. Get the latest DGMPGDec package (containing the latest DGIndex and DGDecode.dll) Make a fresh D2V file using the latest DGIndex, and make sure your paths point to the new DGDecode.dll. The stripped down version of your script will go something like this:

LoadPlugin("C:\Path\To\DGDecode.dll")
MPEG2Source("C:\Path\To\Movie.d2v")

Again, check carefully for names and paths. Remove any old versions of these from your system. Don't use MPEGSource.

http://neuron2.net/dgmpgdec/dgmpgdec.html

There's always a chance, I suppose, that your AviSynth is corrupt or incomplete or something, although I've never had that problem. You can install a new version on top of an older version.

Good luck.

[45tripp]

Thanks for the help manono
I have the latest versions of all listed software.

Get the latest DGMPGDec package (containing the latest DGIndex and DGDecode.dll) Make a fresh D2V file using the latest DGIndex, and make sure your paths point to the new DGDecode.dll. The stripped down version of your script will go something like this:

LoadPlugin("C:\Path\To\DGDecode.dll")
MPEG2Source("C:\Path\To\Movie.d2v")

I've already had this procedure work for me.

For those interested.
The problems I had were due to starting out with trying to load mpegs directly with mpegdecoder like this:

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\Mpegdecoder.dll")
mpegSource("CCESP2-q1-11.3min.mpv")

And because I was using older documentation.

When doing the above a d2v file is automatically created when inserting the avs into vdub or another program. However the output you get is corrupted images like the one I attached.
From the mpegdecoder documentation:

Bugs

When creating d2v files for MPEG-1 files the, number of frames determined is wrong. either use -2, or enter the correct number of frames. (if you want to find to find the correct number of frames exactly, load the mpeg-1 into VirtualDub and it will tell you the number of frames through File->File Information)

When seeking, sometimes the video looks corrupt, ignore this as it will not look corrupt when encoding

I found that the video looks corrupt during playback as well.
Encoding was not my goal and I'm not likely to try encoding relying on a d2v file created by mpegdecoder. I doubt it would work.
If however you use a d2v file created by DGindex mpegdecoder works.

Is there a reason you won't use mpeg2source ?

Neglect.
I started trying to load my mpv and m2v files directly with mpegdecoder and mpegsource. I then transformed the scripts to DGdecode and missed adding the 2 to change mpegsource to mpeg2source.
Since then I've been able to do what I want. Thanks gunslinger

From the author's site comes this template structure for avs

loadplugin("...\DGDecode.dll")
mpeg2source("pathtovideo.mpv",cpu=6)

DGdecode will work only with d2v files created with DGindex.
You can't directly load m2v, mpv or any other mpeg files.

[guns1inger]

Like I said, I rarely process mpeg-2 source with avisynth, which is why I pm'd Manono and asked him to take a look. It had started to stray out of my area of expertise.

Glad it is now working. I would be interested to get an update on your findings in due course, to see if a quantitative analysis of quality can actually be done.

[manono]

What would be the best way to cross check for the best quality?

The way I check for quality is to run the MPV through Bitrate Viewer, checking the Q-Level. For NTSC it's always too high, but as long as you know that, you can adjust and get an idea of how well your encode turned out. Personally, I choose a quantisation matrix in order to make my Q-Level come out within the range I want. That is, I don't buy the common belief that the lower the better. Not if you're always using the default Standard Matrix, which removes way too much detail for my liking. Checking the Q-Scale in CCE does something very similar, but you can't get an overall average doing that it that way

[45tripp]

I would be interested to get an update on your findings in due course, to see if a
quantitative analysis of quality can actually be done.

Almost anything can be quantified.
The MSU team seem to be doing a good job of it already.
Lately I've had a look at a few documented video tests that use some of the metrics that
are available with the MSU software. There seem to be quite a few. Most seem to include
subjective analysis as well, and a comparison of objective metrics with subjective methods.
It seems the general rule is that with subjective methods quality is more or less predicted,
but sometimes lower metric values can correspond to perceived higher quality, and vice
versa.
Also attention seems to be payed to the metrics that best correlate with subjective
analysis. My guess is that for most, quick subjective analysis is most effective in quality
comparisons. From what I've seen the objective metrics are very good though. There's a
wealth of information for the taking. Tests are time consuming though and I'd say extracting
useful results is probably a sophisticated activity, an activity better suited to the
mathematically inclined, programmers or hardcore encoders.

Me, I'm just stumbling through the dark with all this.
My goals are to a.play, b. out of interest perhaps devise a simple procedure for finding a
bitrate threshold that provides 'good' quality and that requires a significant bitrate
increase for minimal increase in perceived quality.

Looking at some tests I'm now interested in trying the NTIA general method.
I'll have to complete the evaluation license agreement sometime for the software located
below.
http://www.its.bldrdoc.gov/n3/video/index.html

Checking the Q-Scale in CCE does something very similar, but you can't get an overall
average doing that it that way

I see the Q scale as something for quick inspection before encoding, unless one plans to
re-allocate bits. It doesn't seem to have other practical uses.
How exactly do you use it?

The way I check for quality is to run the MPV through Bitrate Viewer, checking the Q-Level.
For NTSC it's always too high, but as long as you know that, you can adjust and get an idea
of how well your encode turned out.

I meant to ask about bitrate viewer. I wanted to read a bit more and try it more before
asking though. Then I forgot
CCE seems to produce mpegs that have higher q.levels than other encoders. The quality is
usully better though.
I don't really understand the visual presentation of bitrate and q.levels when reading a
mpeg. Sometimes the bitrate curve is plotted above the q.level curve and sometimes below.
Basically the higher the bitrate of your mpeg the more likely it is to be plotted above the
q.level curve. Am I to assume that the bitrate at which the bitrate curve and q.level curve
are plotted in the same area is the bitrate at which you are striking a good balance between
quality and space?
Also on the right side are the B and Q bar. With the bitrate curve above the q.level curve
the B bar is more likely to be higher than the Q bar throughout the clip, but there are
still points where the green Q bar is higher than the yellow B bar even when encoded at high
bitrates. Are these the seconds where an even higher bitrate would have been beneficial?
What are you looking for when looking at Q and B bars?
I don't really understand bitrate viewer.

Personally, I choose a quantisation matrix in order to make my Q-Level come out within the
range I want. That is, I don't buy the common belief that the lower the better. Not if
you're always using the default Standard Matrix, which removes way too much detail for my
liking.

What level are you aiming for?
Which quantization matrices do you use? Do you prepare your own?
Which matrix for which occassion?
Maybe you could list a few, I'd give them a try.
The once I used a diff matrix to standard lately, the result was considerably worse.

thanks

[manono]

Hi-

I see the Q scale as something for quick inspection before encoding, unless one plans to
re-allocate bits. It doesn't seem to have other practical uses.
How exactly do you use it?

You can't inspect it at all until at least after the first pass. I don't use it much unless, as you said, I plan on doing some bit reallocation. But by scrolling around after the encode is finished, using the Q-Scale, you can get a pretty decent idea of the quality for the settings you used.

CCE seems to produce mpegs that have higher q.levels than other encoders. The quality is
usully better though.

Apples to oranges, if you ask me. Other encoders may have different default settings and filtering, or may even be doing things under-the-hood that you can neither inspect nor control (Procoder).

I don't really understand the visual presentation of bitrate and q.levels when reading a
mpeg. Sometimes the bitrate curve is plotted above the q.level curve and sometimes below.

So? The lines for the yellow bitrate curve each represent 1Mbps. Each line for the green Q-Level represents 1. Whether one line is above the other or not doesn't mean much.

Basically the higher the bitrate of your mpeg the more likely it is to be plotted above the
q.level curve.

I suppose there's a loose correlation there. Different movies compress differently, though. One movie with, say, an average bitrate of 4Mbps might be above the Q-Level curve, while another with the same bitrate might not.

Am I to assume that the bitrate at which the bitrate curve and q.level curve
are plotted in the same area is the bitrate at which you are striking a good balance between
quality and space?

In my opinion, you're on the wrong track. It's not about bitrate, but about quality. You find a Q-Level for your settings (among the most important of which is the quantisation matrix, in my opinion), a Q-Level that gives you good quality results, and you aim to have all your encodes in the same general vicinity.

but there are still points where the green Q bar is higher than the yellow B bar even when encoded at high

The bars only tell you the Bitrate and Q-Level at a given point in the graph. They're not too useful, in my opinion.

What level are you aiming for?

Depends on the matrix used, but generally around 7, which is really around 5.5-5.75, since, for NTSC anyway, the Q-Level figures (and the Bitrate figures) are inflated.

Which quantization matrices do you use? Do you prepare your own?

Except for a couple I've modified from ones I got elsewhere, the ones I use are all either from CCE or (mainly) off of retail DVDs.

Which matrix for which occassion?

I use a matrix that will give me the Q-Level results I want.

The once I used a diff matrix to standard lately, the result was considerably worse.

I don't know which other matrix you used, or how compressible your source was. You can't just replace the Standard Matrix with whatever you want, no matter how good the matrix is. A matrix that retains more detail and sharpness is also, by definition, less compressible. If your source doesn't compress well to begin with, and you use a "high bitrate" matrix, the Q-Level is liable to zoom, and you're liable to get compression artifacts, such as mosquito noise, color smearing, and in the worst cases, macroblocking. You match your matrix to your source, your encoder, your AviSynth script settings, and your bitrate, in order to achieve a final Q-Level you want.

If you use CCE, you don't even have to know anything about matrices. Just uncheck the "Disable Adaptive Q-Matrix Switching" box, keeping the Standard Matrix. Me, I prefer to fit the matrix to the source, but lots of movies on DVD use that very same setting these days. Other than that, I'd suggest collecting matrices from DVDs and experimenting with them. When I was learning, I decrypted a chapter from a DVD, one that had all kinds of different conditions, static sections and action sections, dark sections and light sections. Then I made a bunch of CQ encodes (1-pass VBR) with the different matrices for a chosen Q-Level (35 is good). I compared the final file sizes to get a good idea of their relative compressibility. After awhile I tossed out the ones that I didn't want and kept the ones I wanted. I have about 7 I use regularly now.

[PuzZLeR]

Here's a quick suggestion, however by no means "technical" or conculsive, but simple and easy.

To compare quality open more than one window with VLC Video Lan media player (which is a nice free app). With a little practice you can compare more than one clip at the same time to test quality.

Best way is if one clip is about a second ahead, then you can look to the other one to see the difference in that scene.

Of course, you still have to depend on your own eyes and perception with this, but still comes in handy.

[45tripp]

You can't inspect it at all until at least after the first pass.

I know. I run the 1st pass of VBR to get the vaf file and check.

I don't use it much unless, as you said, I plan on doing some bit reallocation.
Do you find it worth the effort?
Or rather when do you find it worth the effort?

Other encoders may have different default settings and filtering, or
may even be doing things under-the-hood that you can neither inspect nor control (Procoder).

What does Procoder do?

In my opinion, you're on the wrong track. It's not about bitrate, but about quality.

My concern is quality. I'm interested in the quality I can get at a certain bitrate,
because it's a measure of proportion.

Depends on the matrix used, but generally around 7, which is really
around 5.5-5.75, since, for NTSC anyway, the Q-Level figures (and the
Bitrate figures) are inflated.

I haven't noticed inflated bitrate values.
Why are the figures inflated?
I have just looked at bitrate viewer out of interest. I haven't used it in any way to evaluate.

I don't know which other matrix you used, or how compressible your source was.

Reverting from compressed.
I'm converting mpeg4 at the moment with the goal of finding at which bitrate exactly
the conversion has ~zero quality loss. And to then see how much lower one can go without
a 'noticable' degradation in quality. What the patern of degradation
I haven't backed up a DVD in a while. And it's been even longer since I've encoded.
Transcoding usually suffices. I'll have to dig up a tricky one and give encoding a spin.
I don't deal with DV. I'd like to give a DV source a few tests though.
I expect the basics of the procedures to be similar/the same, so I'm dealing with what
I have in front of me. I'm sorry if I haven't mentioned source, but I think the investigation
procedures will be the same and maybe even a lot of settings, despite source change.
Of course it could mean the world of difference but still the info gathered should be relative
to a great degree.

You match your matrix to your source, your encoder,
your AviSynth script settings, and your bitrate, in order to achieve a final Q-Level you want.

Sounds like I'll have to play around with it. (a lot)

To compare quality open more than one window with VLC Video Lan media player (which is a nice free app). With a little practice you can compare more than one clip at the same time to test quality.

Sure. I'll try it.
I'll not limit myself to VLC though as I don't use it and most players are capable of running
in multiple instances.

ty

[manono]

Do you find it worth the effort?
Or rather when do you find it worth the effort?

I just look sometimes. It doesn't tell me much I can't learn while watching CCE encode.

What does Procoder do?

Softens the picture. That's good for certain kinds of sources, I guess, but not for what I do.

I'm interested in the quality I can get at a certain bitrate,
because it's a measure of proportion.

I'm not sure I understand. Why, if you do 2 different movies at the same bitrate and other settings, can you then have two very different Q-Levels? I find nothing proportional about that. If you're saying that you can do one movie at 4000, and a different movie at 5000, the Q-Level should be 25% better for the second movie, it's just not true. If you're saying that boosting the bitrate for the same movie from 4000 to 5000 also lowers the Q-Level by 25%, then you're just stating the obvious. But like I said, maybe I'm not understanding you.

I haven't noticed inflated bitrate values.
Why are the figures inflated?

I've been told it has to do with pulldown. Maybe that's part of it, but my experiments don't really confirm that theory.

[Nelson37]

Just to ask a basic question.

What if the software says Version A is "better" than Version B, but when you actually watch the video, Version B looks better to you. What will you do?

What if Intermediate File A looks or measures better than Intermediate File B, but Final Encoded File B looks or measures better than Final Encoded File A?

[45tripp]

Softens the picture. That's good for certain kinds of sources, I guess, but not for what I do.

And you mostly do DVD to DVD?
I guess Procoder is a matter of taste, but strictly speaking it's of a poorer quality than other
encoders as it never provides you with the option of an output that approximates the source.
Unless it's effects tailor to your needs/likes 90% of the time another encoder will always be
better. Where you can use filters to try and replicate a procoder effect when you want one.
I'd like to see what procoder does with DV as I've read it handles it well, as well as interlaced sources.

If you're saying that you can do one movie at 4000, and a different movie at 5000, the Q-Level should be 25% better for the second movie, it's just not true.

I know. I'm not.

If you're saying that boosting the bitrate for the same movie from 4000 to 5000 also lowers the Q-Level by 25%, then you're just stating the obvious. But like I said, maybe I'm not understanding you.

I guess I'm stating the obvious.
To re-phrase.
I'm converting at the moment with the goal of finding at which q-level exactly the conversion has ~zero quality loss. And to then see how much higher one can go without a 'noticable' degradation in quality. What the patern of degradation.
As you can't compare one encoder's resulting q.level with another one's ("Apples to oranges, if you ask me.") and as I don't trust bitrate viewer to measure anything, what's left is the easily measurable bitrate. I don't see how you can compare encoder A against encoder B if not by setting encodings at the same bitrate. Perhaps there are other ways but they can only be needlesly complicated.
Also once selecting an encoder of choice, I'd like to set an upper quality limit and a lower one using constant quality encoding, to form loose brackets to work within. Once within a range I'm obviously going to be using bitrate steps, rather than anything else to to see the range of quality within the brackets.
Anyway. Something like that.

What if the software says Version A is "better" than Version B, but when you actually watch the video, Version B looks better to you. What will you do?

You keep Version B.
The software I'm using, mostly compares output A&B vs the source. So the better output is the one that stays closer to source. The bigger the change the worse the score. Assuming however that the change is desirable to you, then the score is irrelevant. If the change is part of your goal and not unwanted distortion to the image, fine.
Procoder is a good example. It will always score lower than most encoders. And it's the truth, as far as I'm concerned, procoder is worse. If however you have a soft spot for the output that procoder provides you should keep it.

It's my understanding that objective metrics correlate with subjective analysis.
So if the sofware says A is better than B it's right and if you ask 10 people, at least 8 will agree.
If you happen to be the exception, fine.
It seems the general rule is that with subjective methods, quality is more or less predicted,
but sometimes lower metric values can correspond to perceived higher quality, and vice
versa.

What if Intermediate File A looks or measures better than Intermediate File B, but Final Encoded File B looks or measures better than Final Encoded File A?

It depends on what you mean by intermediate.
You always want the better final product though.
Assuming the same basic approach was used, A should be better than B in the final product.
There are the possibilities of making mistakes that reverse the quality result, but you should trace back and find the source of your problem.
Time permitting. 8)
If you get bored you can always keep B and forget you ever tried A

[manono]

And you mostly do DVD to DVD?

Yes, only DVD2DVD. So I want an encoder that can give me output as close to the source as possible. I don't mean to denigrate Procoder. Lots of people swear by it, and I freely admit that for some kinds of sources it may even be superior to CCE. It's just that I have no use for it.

I'm converting at the moment with the goal of finding at which q-level exactly the conversion has ~zero quality loss.

A worthy, if impossible, goal. MPEG-2 encoding is lossy. The best you can do is to minimize the quality loss. And if you're converting DVD9s to DVD5s, it's even more difficult.

And to then see how much higher one can go without a 'noticable' degradation in quality.

Even that's tough. Can you tell the difference with your eyes between a Q-Level of 4 and one of 5? I'm not sure I can. Not without a heck of a lot of zooming in and studying. That's why I do the best I can with my settings and then let the Q-Level tell me. I do trust Bitrate Viewer, though, wrong numbers and all. It's consistently wrong, so it tells me what I want and need to know.

I don't see how you can compare encoder A against encoder B if not by setting encodings at the same bitrate.

Did you ever read the big encoder comparison thread at this site? There were just about as many opinions as there were people that posted:

https://forum.videohelp.com/viewtopic.php?t=235665&highlight=encoder+comparison

CCE has come a long way since the 2.50 days. It had a few problems back then. It was still the best (in my opinion), but it's definitely gotten better. Maybe the others have as well.

Something like that.

Sounds good.

[45tripp]

MPEG-2 encoding is lossy. The best you can do is to minimize the quality loss.

Yeah...that. 8)

Can you tell the difference with your eyes between a Q-Level of 4 and one of 5? I'm not sure I can.

Prooooaoaaaaly not.
I'd like to find out at which level I can though.
Eventually.
Right now I seem stuck, messing about.

Did you ever read the big encoder comparison thread at this site? There were just about as many opinions as there were people that posted:

Several times.
I have an opinion too

CCE has come a long way since the 2.50 days. It had a few problems back then. It was still the best (in my opinion), but it's definitely gotten better. Maybe the others have as well.

I've always used CCE myself.
And in the end, the few files I want converted (if converted) will be done by CCE.

I don't think there's been much improvement.
Probably hardly any at all in the final product. Encoding time is similar too.
I don't think any encoder has had noticeable improvement aside from TMPG.
I've tried TMPG several times in the past and I know that TMPG Xpress is considerably faster than the older TMPG. That's what I call improvement. And it's interface is greatly improved, easier to use. Generally I find it user friendly.
I wouldn't have any trouble recommending it.

cheers