Xvid 1.2 cvs

[IgorC]

http://celticdruid.no-ip.com/xvid/

cleanings in code spotted by sparse (ed dot gomez at free dot fr>
update cvs-head to reflect xvid-1.2 development status:
set build string to "xvid-1.2.0-dev"
set XVID_VERSION to 1.2.-127
set XVID_BS_VERSION to 40
set XVID_UNSTABLE

What's new? :)

[sysKin]

What's new? :)

Nothing *yet* :devil:

[ChronoCross]

so...we can expect 1.1 final soon right? since dev on 1.2 is started obviously heh

[DeathTheSheep]

XviD 1.2 started. A fresh new XviD coming up. This is nice...

(*mumbles under breath*insanemodeinsanemodeinsanemode*)

Good luck to the dev.s!

[ChronoCross]

XviD 1.2 started. A fresh new XviD coming up. This is nice...

(*mumbles under breath*insanemodeinsanemodeinsanemode*)

Good luck to the dev.s!

what do you mean by insane mode? you mean that lame attempt by divx to increase quality by dropping the speed 400% and then do nothing? If so then I will have to say no to that lol. but a new Adapt. Quant would be sweet.

[Sharktooth]

well... it's not divx network fault if USERS asked for an "insane mode" some time ago...

[DeathTheSheep]

Ah, whatever do you mean, gentlemen?

(*COUGHcheckthis (http://forum.doom9.org/showpost.php?p=721353&postcount=18)outCOUGH*)

[DeathTheSheep]

No, nothing like that at all.
The so-called "Ultra" motion search precision preset doesn't even enable Advanced Diamond 8/16, EXTSEARCH8, etc.
As far as I can tell (and that's not very far, believe me ;)), a bit more can definately be milked out of it even before we go exhaustive...

[DeathTheSheep]

PS: In my second post in this thread, I gave a link to some Insane mode stuff... and here are my results:
Given these results, it's actually more than a 16% quality increase with Helium [insane mode over balanced mode]. So, a 16% filesize decrease and a 0.1db PSNR increase is absolutely worth it, and such a mode would help XviD tremendously.
Nice thesis, eh? ;)

[IgorC]

Speed of Xvid 1.1 is already lower than of 1.0. But there was a big impovements since then.
However something has happened with Xvid 1.1 beta 1 -> beta 2. Speed has gone down.
Developers said that there was quality improvement for very low bitrate, but for low (middle low >500 kbps) and high bitrates there wasn´t any quality change. SSIM and OPNSR are almost identical for beta 1 and beta 2.
Maybe it can be fixed or reworked.

Implementing of very slow settings shouldn´t be a problem, while they aren´t enabled by default. ;)

[DeathTheSheep]

I think there were a few quality increases for the higher bitrates, too. VHQ for B-frames is the most noticeable, I believe. But you're absolutely right--that's the development path, I suppose. Figure out your priorities then implement them, steadily improving everything else on the way. As development progresses, quality goes up steadily. But in the mean time:

Implementing of very slow settings shouldn´t be a problem, while they aren´t enabled by default.
My thoughts exactly ;)

[IgorC]

VHQ for B-frames was already impelemnted in alpsha cvs builds.
I was talking about speed down on beta1 -> beta 2 without any impovements for bitrates >500 kbps . :devil:

[DeathTheSheep]

Oh, woopsies :p I thought you were talkin' 'bout XviD 1 to XviD 1.1. hehe
Yeah, yer absolutely right then.

Yeah, y'all know me, I'm obsessed with low bitrates. I think XviD did something along the lines of logarithmic quantization adjustments for high quants back in beta 2, yeah.

Good stuff. Can we all look forward to any more quality bolsterings in the low-bitrate area or have priorities shifted more to the higher rates?

[sysKin]

VHQ for B-frames was already impelemnted in alpsha cvs builds.
I was talking about speed down on beta1 -> beta 2 without any impovements for bitrates >500 kbps . :devil:

There was defnitely NO code change from beta1 to beta2 that would affect speed.

[ChronoCross]

I never saw a slowdown between the two. I'd like to see improvements to speed through HT/multithreading. the quality is already better than any of the other asp encoders out there.

<Here's where my rant on how I think an INSANE mode is a waste of time was supposed to go>

All I'll say about it is that PSNR isn't a end all be all of measurement for how something looks. Things with lower PSNR values have many many times looked better than things with a higher one. This is back to the arguement that quality is subjective.

[IgorC]

I remember some people said that speed of beta 2 was lower. I also notice it.
http://forum.doom9.org/showthread.php?t=92511&page=6&pp=20&highlight=beta+slow

And there was hot dicussion about improvements beta 1 -> beta 2.
There was RD changes since beta 1.
http://forum.doom9.org/showthread.php?t=92511&page=2&pp=20&highlight=beta+slow

I´m agree PSNR isn´t ideal metrics. But SSIM and OPNSR together are good tests. Visually I also can´t see difference between beta 1 and beta 2.

[sysKin]

I remember some people said that speed of beta 2 was lower. I also notice it.
http://forum.doom9.org/showthread.php?t=92511&page=6&pp=20&highlight=beta+slow

OK this is weird, and probably worth checking. However, I was telling the truth - no algorithms changed that would explain this.

I remember a thread about XviD beta2 (I think) not detecting CPU features correcly. If you can reproduce the slowdown, could you check that? Just compare beta2 with auto and manual CPU features.


And there was hot dicussion about improvements beta 1 -> beta 2.
There was RD changes since beta 1.
http://forum.doom9.org/showthread.php?t=92511&page=2&pp=20&highlight=beta+slow

I´m agree PSNR isn´t ideal metrics. But SSIM and OPNSR together are good tests. Visually I also can´t see difference between beta 1 and beta 2.
Yes but these changes were strictly in RD constants (lambda). Just differrent values in the same equations, they can't change speed.

[sysKin]

OK I'm disappointed with you guys.

One, yes, beta2 is 5% slower at defaults than beta1.
Two, but who cares about it if quality has gone down the drain???

You actually did not catch such a huge regression? :/

[Didée]

He-heheh, at home still using a celtic's build from "before beta2" :D

What did go wrong with beta2 ?

(edit: Frankly, I can't pretend to actually have spotted a difference, but always had the impression that there was, well, ~something~ about beta2. Guess I'd have gotten tared and feathered when asking about that ...
Poke in the blue: perhaps something with AQ thresholding?)

[IgorC]

Sorry , Syskin. I´m preparing for exams now. Later I will run some video for Beta 1, Bet2 with different cpu flags with diferent setings.

So for what bitrate there is quality change between Beta 2 and Beta 1? :(
maybe for extreme settings there is no change?
weird

[sysKin]

Sorry , Syskin. I´m preparing for exams now. Later I will run some video for Beta 1, Bet2 with different cpu flags with diferent setings.
No don't worry about that, I can reproduce the speed difference easly. There's quality difference too, but not that big with VHQ (very big without VHQ).
This was not supposed to happen ;) and I'm unsure what actually did happen, yet.
Working on that now.

[IvS]

I don't quite understand. By quality regression from beta1 to beta2 you mean quality of the default settings or generally of the encoder itself?

[Teegedeck]

There's quality difference too, but not that big with VHQ (very big without VHQ).Oh, sugar!

Would you care to elaborate on the not-that-bigness of the quality difference, maybe by means of one or two screenshots?

And thanks!

[sysKin]

Would you care to elaborate on the not-that-bigness of the quality difference, maybe by means of one or two screenshots?

No actually, I take that back. The quality is a tiny bit better (*with* VHQ), it just didn't look like it because filesize is much larger at fixed quantizer*.

The slowdown is a waste though. The good news is that I found a way to improve quality, still having this slowdown. If I perfect it I'll keep it.

*so all you "compressablity" people should scream bloody hell now, because your "compressablity" just dropped. Good for you :P

[IvS]

Again I don't quite get it :). If quality is a bit better with VHQ, then that means the output looks a bit better at the same size, right? So what is that "compressabiliity just dropped" comment, is that regarding fixed quantizer only?

Edit: or maybe by "dropped" you mean "rose"? :)

[Teegedeck]

Relief, relief, a relief it is. Not that I had done many encodes with b2, I updated to it at a late date, but I certainly would have thought about doing these encodes again, had there been a notable flaw in beta2's quality.

Edit: I understood that XviD Beta 2 produces larger files at fixed quant (yes, come to think of it, I wondered whether I had more 'big' first passes than usual as of late) but it is quality at a fixed filesize (two-pass) that counts. The 'compressiblity' bit might have been directed at me. :sly: ;) 'Cause I like to compare codec quality by encoding at constant quantizer; tough for me to not think of this as 'constant quality'.

BTW, it is so nice that you return to this project in your holidays - we just cannot keep you away, can we?

[Leak]

BTW, it is so nice that you return to this project in your holidays - we just cannot keep you away, can we?
Well, I don't think that we should try to even if it were possible... ;) :D

np: The Dolls - Sunbird (The Dolls)

[Zero1]

Would nth pass be of interest to anyone else?

[ChronoCross]

Would nth pass be of interest to anyone else?

I thought that xvid's 2 pass was better than anything nth pass could come up with. SO I don't think it would be necessary.

[DeathTheSheep]

so all you "compressablity" people should scream bloody hell now, because your "compressablity" just dropped. Good for you :P
BLOODY HELL!! :p

Will this, eh, CQ "development" ever...ehm...change? (Just curious, ya know)...

[Didée]

"nth pass" processing is hardly a topic for XviD, I'd say. This doesn't mean it's current 2-pass system is perfect, however. The decisions of how to distribute bits in 2nd pass perhaps could need some tweaking. Or even better, options:

In particular, one thing I'd like to see is something like "Penalty for Bframe sensitivity in dark scenes" : The usual setup of 2 (or even 3) max. consecutive Bframes at times is counterproductive during dark scenes, regarding perceived quality ... sure many Bframes during dark scenes "compress like hell", but they just don't look good. And usually the max. Bframe usage is reached much earlier in the dark than it is in the light ...

But then, rate control is not amongst syskin's playthings, IIRC ;)

[IgorC]

what about AQ for bframes? Libav asp has it.

[DeathTheSheep]

what about AQ for bframes?
Yeah, exactly. I found out it was causing the terrible flickering in my B-frame encodes over quant 4. The picture flickers terribly when AQ Ps are followed by non-AQ Bs, especially at low resolutions.
Funny how it didn't happen like that in Xvid 1.0.3...

[Kopernikus]

AQ for B-Frames is a mess. When the lumimasking is changed from AQ to lambda-based, it will be able to modulate quality on B-Frames.

[Didée]

On top of that, AQ for Bframes would (atleast should) hardly lead to any mentionable benefit.
Bframes are already so thin, you won't gain any more weight from them. Degrading their quality would be possible, however.

[DeathTheSheep]

It's not the size of the B-frames that concerns me: it's the flickering problem I mentioned. I'm convinced that consistant AQ (between Bs and Ps) will lead to less fliclcering while preserving the AQ-ed filesize.

[CruNcher]

The flickering problem is allways existing (low bitrate) it's less noticeable without b-frames, but it's allways there.

[SeeMoreDigital]

When using Beta2 to generate some "test card" encodes (from PNG still images), I have noticed that some of the encodes contain N-VOP's, even though "simple profile" settings were selected....

I'm keen to see if XviD 1.2 CVS will fair any better. I followed IgorC's link to Celtic_Druid's site but was unable to find "1.2".... Is it still available?


Cheers

[Sharktooth]

http://www.aziendeassociate.it/cd/XviD.cvs.head.exe

[SeeMoreDigital]

Thanks Sharktooth... I was looking for builds with "1.2" somewhere in the file name!?!?



Cheers

[Sharktooth]

1.2 is cvs head :)

[Elias]

I've been trying this CVS out for a couple of days. Can't find any bugs whatsoever. What's keeping it from being released as stable?

[IgorC]

did you read this thread?

[Elias]

did you read this thread?Oh sorry, I confused sharktooth's post.... I need sleep, it's late here :) My fault.

[bond]

When using Beta2 to generate some "test card" encodes (from PNG still images), I have noticed that some of the encodes contain N-VOP's, even though "simple profile" settings were selected....n-vops are not incompliant to simple profile

[Elias]

n-vops are not incompliant to simple profileThis is true. N-Vops are specs compliant, and they play great in QuickTime. Still though, I don't like that XviD produces N-Vops by default. I've been through this on another post (use search if you want to check it out), and there ought to be a turn off N-Vops feature. Dropping frames is not cool.

[SeeMoreDigital]

n-vops are not incompliant to simple profileI don't understand why they are there though. And can't work out how to get rid of them....

It pains me to say that it does not happen with any of the DivX codec's I've tried :(

[Elias]

I don't understand why they are there though. And can't work out how to get rid of them....

It pains me to say that it does not happen with any of the DivX codec's I've tried :(Yes. I've many times considered switching to DivX5/6 because of these N-Vops. I believe it's a bug in XviD that causes this.

[skal]

Hi,

Yes. I've many times considered switching to DivX5/6 because of these N-Vops. I believe it's a bug in XviD that causes this.

Is this a joke?!

DivX *introduced* used of N-Vops for the packed b-frames hack one has
to stick to now.

-Skal

[Elias]

Hi,



Is this a joke?!

DivX *introduced* used of N-Vops for the packed b-frames hack one has
to stick to now.

-SkalWith DivX simple profile, there's no N-Vops nor Packed bitstream. I only use simple profile anyway.

[bond]

n-vops are simply frames which tell the decoder to show the last frame again. they are perfectly spec compliant and its perfectly fine to use them. they are not "dropped frames" in the sense that you will have less frames in the output stream

they play great in QuickTime.really? cause qt6 didnt handle them

[Elias]

n-vops are simply frames which tell the decoder to show the last frame again. they are perfectly spec compliant and its perfectly fine to use them. they are not "dropped frames" in the sense that you will have less frames in the output streamsounds like dropped frames to me.

really? cause qt6 didnt handle themI've had no problems playing *.mp4 files containing N-Vops in QT6 nor QT7. When was the last time you tried QT6?

[celtic_druid]

I don't think DivX uses N-VOP's other than for packed bitstream. So the fact that DivX doesn't drop frames and insert them is because it can't not because it works better than XviD.

Only way to prevent XviD from inserting n-vop's is to enable bframes, which you can't for SP. But then I can't really see what the problem with N-VOP's is. They are there presumably because there were some duplicate frames. Still I agree that there should be a way to disable them.

[Elias]

Only way to prevent XviD from inserting n-vop's is to enable bframes, which you can't for SP.No. I get N-Vops even with B-Vops enabled.Still I agree that there should be a way to disable them.Can this be a request in the new CVS?

[bond]

I don't think DivX uses N-VOP's other than for packed bitstream.indeed

Still I agree that there should be a way to disable them. why?
i would love to see the combination of b-vops and n-vops being possible (not with packed bitstream), as after all n-vops help saving bitrate

sounds like dropped frames to me.for me "dropping frames" means getting 99 output frames on 100 input frames and thats definitely not the case with n-vops

I've had no problems playing *.mp4 files containing N-Vops in QT6 nor QT7. When was the last time you tried QT6?long time ago

edit:
I get N-Vops even with B-Vops enabled.with packed bitstream you get these fake n-vops, which are not comparable to real n-vops i am talking about
without packed bitstream, but with b-frames, you dont get n-vops

[Elias]

long time agoFigures. It's fixed nowadays in QT.

[SeeMoreDigital]

No. I get N-Vops even with B-Vops enabled.Can't this be a request in the new CVS?Me too ;)

Here are some samples (http://81.98.148.105/Uploaded_Files/Doom9_Forum_files/XviD_N-VOP_Tests.7z).

[Elias]

for me "dropping frames" means getting 99 output frames on 100 input frames and thats definitely not the case with n-vopsIn MP4Box when importing an XviD file with N-Vops, that's exactly the case. There shouldn't be a need of using the -nodrop command just because XviD has issues with outputting simple profile without N-Vops, because come on, what if I don't want to use N-Vops?with packed bitstream you get these fake n-vops, which are not comparable to real n-vops i am talking about
without packed bitstream, but with b-frames, you dont get n-vopsThis is not always true. I've seen XviD files with B-Frames and with N-Vops and without packed bitstream. Real N-Vops or not (and N-Vop might be a very good thing), I still am of the opinion that there ought to be a disable N-Vop feature. By the way, what's the difference between fake and real N-Vops?

[SeeMoreDigital]

The XviD N-VOP issue certainly does not make sense to me!

Generating encodes from a still frame source, should provide a perfect example as to how N-VOP's can work!

If you have a look at the 30 second 750 frame XviD samples I provided, I would have expected to see hundreds of N-VOP's, not just 19No....

The reason why I want to get to the bottom of this is because I want to see how well N-VOP's work in stand-alones.

It's not going to be much use generating say, a 30 second encode with N-VOP's, if the stand-alone player ignores the N-VOP and only plays the remaining frames :eek:


Cheers

[bond]

In MP4Box when importing an XviD file with N-Vops, that's exactly the case. There shouldn't be a need of using the -nodrop command just because XviD has issues with outputting simple profile without N-Vopsoutputting n-vops harms nothing, so plz stop acting like they do...

mp4box creates a vfr stream by dropping the n-vops (saving even a little more bitrate). again this harms nothing, but changes the xvid bitstream of course

i have the feeling that people fear something they dont even have a clue about

I've seen XviD files with B-Frames and with N-Vops and without packed bitstream.show me an example file and tell me the build used which created such streams

Real N-Vops or not (and N-Vop might be a very good thing), I still am of the opinion that there ought to be a disable N-Vop feature. By the way, what's the difference between fake and real N-Vops? real n-vops are frames as defined by the mpeg-4 specs (i already described what they do here)
fake n-vops are abused for packed bitstream for being able to have streams with the same framenumber as the input as described here (http://forum.doom9.org/showthread.php?s=&threadid=80430)

again, before you form your opinion about something, read things up so you at least know what you are talking about :p

[SeeMoreDigital]

I've seen XviD files with B-Frames and with N-Vops and without packed bitstream.show me an example file and tell me the build used which created such streamsI can't admit to seeing XviD generate such files.... but if you're interested I have a Nero Recode2 example with 700 N-VOP's.

And as we all know, Recode2 generates MPEG-4 ASP streams directly to .MP4.... so there's no packed bit-stream anywhere in the food chain....

Anyway.... here's an sample (http://81.98.148.105/Uploaded_Files/Doom9_Forum_files/Recode2_N-VOP_Tests.7z).

From my particular view point, it's not that there are N-VOP's in the encode. It's just that we don't have any control over when they are used. I would prefer an "on/off" option!


Cheers

[Elias]

again, before you form your opinion about something, read things up so you at least know what you are talking aboutI can acknowledge that I don't know everything about N-Vop. SMD took the words right out of my mouth. N-Vop doesn't have to be a bad thing. An on/off option would rock.

[bond]

From my particular view point, it's not that there are N-VOP's in the encode. It's just that we don't have any control over when they are used. I would prefer an "on/off" option!well you also dont have control over what frames are written as i/p/b-vops...

an encoder that uses n-vops is superior to one that isnt able to use them. nero using them too only shows that this is not only some fancy thing of xvid...

[SeeMoreDigital]

Does it not seem strange to you that Recode2 was able to generate 700 N-VOP's when XviD could only muster up 19?


Cheers

[Elias]

Since this has gotten very off topic, here's an old thread where these N-Vop posts can be moved to:

http://forum.doom9.org/showthread.php?t=93263