mpeg-2 v/s mpeg-4, quality concerns [Archive]

grovsnus

5th April 2002, 10:04

This question isn't really limited to XviD, but since this is what I'm using and you seem much more skilled than me, I'm posting the question here :)

I've been trying to obtain very high quality encodes using XviD, but no matter what I do, it seems impossible to get the same quality as you can get with a good mpeg-2 encode. Why is this, really? It seems to me that mpeg-4 is only supposed to work at "low" bitrates, e.g. below 3000kbps, since any rise in bitrate doesn't necessarily increase the picture quality.

Mpeg-2, however, requires a lot more bitrate, but it also significantly increases the quality at those higher bitrates (6M-9Mbps). Is it really not possible to achieve the same kind of broadcast quality using mpeg-4/XviD ?

I've been testing XviD a lot lately, and even at 100% Quality or Quantizer=1 or 2, the perceived quality is quite lower than that of the original source (which is a DVD, mpeg-2 VBR between 3-9.8Mbps). I'm using the original resolution (720x480), and do not employ any filtering (which usually just degrade the quality).

Am I missing something here? From the testing I've made it seems that mpeg-4 is not really comparable to mpeg-2, which surprises me a bit.. It's superior at lower bitrates, but quality-wise it doesn't come close?

Any opinions on this would be most welcome :)

[-g-]

-h

5th April 2002, 14:43

Not sure what you mean by less quality.. have you tried quantizer=2 with the MPEG quantizer? I'm honestly not sure how much more quality you're after..

And if you say quant=1 is lower quality than MPEG-2... I'm going to have to doubt you :) MPEG-2 is technically inferior to MPEG-4 in every way (apart fom supported colorspaces, for the time being) - there is just no way, apart from creating custom matrices, that you can squeeze more quality out of either one.

-h

Koepi

5th April 2002, 14:58

Another reason why the quality will suffer is that you add errors of compression. MPEG2 is already compressed. It has errors. Well, not visually noticable for you maybe.
But the new compression with XviD/MPEG4 adds new errors.
That degrades quality.

Then I have to question your method of transcoding... many errors are in there. If you use flask, don't ask us why the quality is shitty ;)

Just my 2 € cent,

Koepi

trbarry

5th April 2002, 16:09

I've been testing XviD a lot lately, and even at 100% Quality or Quantizer=1 or 2, the perceived quality is quite lower than that of the original source (which is a DVD, mpeg-2 VBR between 3-9.8Mbps).

No matter how you recompress it using any lossy method it will always degrade slightly each time. For a more fair test why don't you also recompress with mpeg2->mpeg2 and compare with mpeg2->mpeg4.

Even the first one won't likely be equal to the original.

- Tom

grovsnus

6th April 2002, 00:20

-h: What I mean with "high quality" is the ability to take an original broadcast quality mpeg-2 signal and encode it in mpeg-4 without *any* noticeable degradation. This just doesn't seem possible :) Whatever I do it seems the result is always inferior to the original, and given what you say that mpeg-4 is technically superior to mpeg-2 (and I agree), this somehow surprises me! I would think that, given enough bitrate, an mpeg-4 encode should in theory be able to *perfectly* reproduce an mpeg-2-originating signal.

Koepi: I understand what you mean, though what I'm meaning with my original post (which perhaps was written too early in the morning! ;)) is that I can't seem to reproduce the same quality as my original mpeg-2 stream, which I believe I should be able to, given the technical superiority of mpeg-4. And no, no Flask here :) I'm using SmartRipper/DVD2AVI/Virtual Dub :)

trbarry: Yep, I know what you mean. See my reply to -h.

Thanks for your replies :)

Please note by the way: I'm not nagging about XviD being bad or inferior, I'm just curious and am trying to understand things! In fact, I really like XviD so far! It's much much better than DivX4 that I used before... :)

[-g-]

-h

6th April 2002, 01:11

-h: What I mean with "high quality" is the ability to take an original broadcast quality mpeg-2 signal and encode it in mpeg-4 without *any* noticeable degradation. This just doesn't seem possible :) Whatever I do it seems the result is always inferior to the original, and given what you say that mpeg-4 is technically superior to mpeg-2 (and I agree), this somehow surprises me! [B]I would think that, given enough bitrate, an mpeg-4 encode should in theory be able to *perfectly* reproduce an mpeg-2-originating signal.

Nah, you'd need lossless for that, it's the nature of a block-based codec. Or find a non-block-based codec.. but ruling out MPEG-4 kinda limits your choices.

If I lose all sense and reason, I'll try writing a transcoder to digitally convert MPEG-2 streams to MPEG-4 without loss of quality - just looking at the ffmpeg sources, it seems "possible", as long as the source MPEG-2 file is in the 4:2:0 colorspace. Should cut file sizes by a nice amount (well otherwise there'd be no point..)

-h

trbarry

6th April 2002, 01:31

If I lose all sense and reason, I'll try writing a transcoder to digitally convert MPEG-2 streams to MPEG-4 without loss of quality - just looking at the ffmpeg sources, it seems "possible", as long as the source MPEG-2 file is in the 4:2:0 colorspace. Should cut file sizes by a nice amount (well otherwise there'd be no point..)

While I would not know how to make one of these I would very seriously like a copy of it if you ever actually write it.

But even if you don't write it, could you explain where the space savings would come in? I've never understood that part.

- Tom

avih

6th April 2002, 01:38

-h: pls do loose all sence and reason :)

that would be awesome! (the transcodin part i mean :) )

u're working on so many projects :)

i appreciate your work a lot.

cheers
avi.

grovsnus

6th April 2002, 03:37

-h: I'd want nothing further than you losing control of your senses!! :D Is there a technical explanation to what you're suggesting, I'm not quite sure I follow your reasoning here, i.e. are mpeg-2 and mpeg-4 that similar that you could in theory "convert" the frames? I'm still a newbie to the theories, so if it's not too complicated I'd love an explanation :)

Thanks for your time and efforts btw! :) I wish I was better at maths so I could help out..

[-g-]

-h

6th April 2002, 03:56

Space savings (if any) will be in motion vector storage and coefficient scanning (we have more zigzag patterns / prediction modes / vlc codes).

I have to take a good look at MPEG-2 dequantization though, it might not be possible if it's not the same as MPEG-4's kooky inter-block addition. Who knows.

Anyway, it's all waiting on B-frames :) Unless we're feature-compatible with the vast majority of MPEG-2 streams out there, it's kinda useless.

-h

trbarry

6th April 2002, 18:16

Anyway, it's all waiting on B-frames

B-frames would be nice too. :)

- Tom

grovsnus

6th April 2002, 21:03

Ivion

6th April 2002, 22:31

Humzzz, if you have the 2 GB limit, you're probaly using the FAT32 system (or even maybe the FAT16 system, I only don't think so :D). As far as I know there is no solution to that problem, except converting to a NTFS system. Wich can only be done when using Windows 2000/XP.

grovsnus

6th April 2002, 23:10

Nope, it's the 2GB-limit in the AVI file format.. You can't play back avi-files larger than 2GB.. Just doesn't work.

[-g-]

avih

6th April 2002, 23:33

i've captured and played avi of more than 2GB on win98SE with fat32 and vdub.

i think u should have opendml installed. my compy is crashed now, so i can't give u any links :( but opendml avi extensions supports more than 2GB.

cheers
avi

Hanty

7th April 2002, 00:44

I've gotten better quality XviD/DivX encodes than their DVD sources with the right tweaking and filter application. Granted those sources were bad for DVD but it just goes to show that the potential is all there in the codec(s).

I could give actual comparassions, but that would only get me on the SVCD zealots hate list. ;)

trbarry

7th April 2002, 05:21

Some new input here.. I tried today to do a quant 2 encode and disabled resizing.. MUCH better! I wasn't resizing that much before (720x480 down to 704x400, crop-only on horizontal), but now I just cropped it vertically and removed the BicubicResize and there is a major difference in output... Interesting, don't you think?

When you downsize a video you can introduce high frequency components that make it hard to compress. I think that's why, except for SimpleResize, most of the resizers have (rightly) been designed with a bunch of built-in filtering.

But much video source has already been excessively filtered to hide film grain, interlace, warts, etc. So when you downsize only a small amount then you can just end up with an over-filtered video.

YMMV, but I too just crop or use SimpleResize for those cases, especially where the source already looks soft.

- Tom

temporance

8th April 2002, 23:27

Originally posted by -h
Space savings (if any) will be in motion vector storage and coefficient scanning (we have more zigzag patterns / prediction modes / vlc codes).

I have to take a good look at MPEG-2 dequantization though, it might not be possible if it's not the same as MPEG-4's kooky inter-block addition. Who knows.

Anyway, it's all waiting on B-frames :) Unless we're feature-compatible with the vast majority of MPEG-2 streams out there, it's kinda useless.

-h
I suspect the interlaced MC of MPEG-2 is not replicated in MPEG-4. Even progressive MPEG-2 sources like DVD use field prediction.

-h

9th April 2002, 01:15

I suspect the interlaced MC of MPEG-2 is not replicated in MPEG-4. Even progressive MPEG-2 sources like DVD use field prediction.

MPEG4 supports field-based motion estimation/compensation, as in 2 16x8 field copies which can reference either the top or bottom reference frame. I'm working on implementing this.

It doesn't support field duplication as in MPEG2's "repeat top/bottom field" flag or whatever it is, that'd have to be a big set-all-blocks-not-coded hack.

-h

movmasty

9th April 2002, 01:24

but wasnt the limit at 4gigs with opengl?
and, how to install it?

Koepi

9th April 2002, 01:40

wtf has opengl to do with

a) xvid
b) file size limitations of filesystems
c) filesize limitations of container formats
d) mpeg2 vs mpeg4 specs
... (and so on)

if you could explain why you think you have to give an unproductive, unnecessary, useless answer like this again somewhere where _real_ productive conversation is done, it would be appreciated.

But maybe you insist on being on probation forever :(

snol

9th April 2002, 02:13

i think maybe he meant opendml... i don't know if it's correct or not anyway

gldblade

9th April 2002, 04:05

>but wasnt the limit at 4gigs with opengl?
and, how to install it?

Yes, I think the limit is 4gb with OpenDML. I don't think you can install it, your encoder just has to support it. For example, Flask (that old hunk of junk?) came with an OpenDML plugin. And I think I read somewhere that VDub supports it to, but I have nothing to back that up at this point.

gldblade

9th April 2002, 04:06

>if you could explain why you think you have to give an unproductive, unnecessary, useless answer like this again somewhere where _real_ productive conversation is done, it would be appreciated.

Ow. That hurts.

Zhnujm

9th April 2002, 21:29

opendml has no filesize limitation. of course, if you use fat32 the limit is 4gb.

movmasty

9th April 2002, 22:27

NOTE: mine was a question, not an answer

i always heard of that "thing" that increase the avi limit to 4g
as opengl, now you say openDML, ok :)
(btw, opengl is also open gnu licence(?)

avih

10th April 2002, 00:09

opengl (=open graphics language) is a ghraphics api (2d/3d graphics). some display cards (especially with 3d acceleration) support the opengl api (they can understand opengl 'commands'). it was developed buy sun for their graphics workstations. it's now a widely graphic language.

opengl usually has nothing to do with opendml. u totally mixed them up.

omol

10th April 2002, 01:06

Originally posted by avih
it was developed buy sun for their graphics workstations. it's now a widely graphic language.

I guess it should be SGI (http://www.sgi.com/software/opengl/). Or you may say Nvidia. You know what I mean...;)

regards,
omol