Selam! (XviD-1.0-Beta3-26122003)

[Koepi]

Merry Christmas everyone (...who celebrates it).

We have an christmas gift for you!

XviD-1.0-Beta3-26122003 (Selam):
- Large filesizes now work correctly in 2pass.
- Fixed possible out-of-bound-reads in 2pass.
- Bframe decoding fix - sometimes bframes were referencing wrong future macroblocks.
- Checking "use keyframe" in a zone now only makes the zone starting frame a keyframe.
- Internal pixel aspect ratio fixes - added display aspect ratio (for anamorphic encoding).
Currently you'll need mplayer, vlcplayer (or 3ivx/Nero DShow filters) for correct playback.
- Colour space fixes.
- Directshow updates: brightness slider, postprocessing, output colour space choosable.
- Some more sse2 optimization for P4s.
- 2pass ratecontrol overhauled, including fast first pass.
- User selectable turbo mode.

Known bugs (do not report them):
- Weight zones don't work properly - if you need zones, use quant zones instead.
...

Best regards
Koepi

[mikeson]

Thanks a lot, Koepi and Merry Christmas! ;)

[raz0r]

thanks koepi!
but what is "Turbo ;-)" and how does it work?

[mikeson]

@raz0r:
but what is "Turbo ;-)" and how does it work?
It is a feature that turns off some ME flags thus encoding is faster (roughly said).

[raz0r]

will the quality go down when using turbo mode?

[mikeson]

Test it and share your results... ;)

Honestly, I'm not sure about this.

[Koepi]

Turbo should give a very marginal (unnoticable) drop in quality (it enables fast flags in the xvid core) for a very noticable speed boost.

Regards
Koepi

[iago]

Selam, dostum!

What a fantastic name for the new beta! This one should be especially for me! I might even no longer upgrade and use this one for good! ;)

Thanks a lot,
iago

[Raptus]

The new decoder has performance problems when deblocking is activated. FPS drops on a XP2400+ :rolleyes: tested with a 704x304 clip.

the brightness slider has no effect in any of the possible colorspaces.

[Leak]

Originally posted by Raptus
The new decoder has performance problems when deblocking is activated. FPS drops on a XP2400+ :rolleyes: tested with a 704x304 clip.

the brightness slider has no effect in any of the possible colorspaces.

Whoa - I was just going to write almost the same, only that this happens here on a P4 2,4GHz... so it can't be CPU optimization-specific. :(

The clip in this case was 720x400.

Dering alone does work without slowing the video down, as does "Film Effect" (even though I don't know what it's supposed to do... :confused: :))

But then again, deblocking did work perfectly with Koepi's prerelease beta3 decoder, so a bug must have crept in there... :)

np: St. Germain - What's New? (Boulevard)

[Koepi]

Hm. The decoder is currently absolutely un-optimised, it doesn't compiler with any ICL anymore. Maybe i should tweak the settings for M$ compilers ... ;)

Regards
Koepi

[sysKin]

Oh, again?
I had problems with deblocker the first time I compiled it (on ICL8.. and yes, it worked *then*).

When I used deblocker the second time it was perfect - slower than ffdshow's of course, but imho it was the best deblocker I've ever seen. It was just so beautiful ^_^.

I'll try figuring out what makes it go fast/slow/fast etc all the time.

Radek

PS. Deringer is fast because it's not implemented ;)

[Leak]

Originally posted by Koepi
Hm. The decoder is currently absolutely un-optimised, it doesn't compiler with any ICL anymore. Maybe i should tweak the settings for M$ compilers ... ;)

Well, I don't really care much if encoding goes below 24 fps, but it *does* get a bit distracting when watching the result and having the video play half as fast as the sound... *wink* *wink* *nudge* *nudge* :p

And I really have to agree with Syskin - the deblocking of the prerelease beta3 decoder was superb.

(Also, wouldn't *not* using the Intel compiler slow down both Intel *and* AMD CPUs, given that the optimizer of the VS compiler is hardly worth anything?)

And to Syskin - I've only seen it go slow, without speeding up anywhere... :p

np: Jah Wobble & Deep Space - They Were Planning Murder (Largely Live At Hartlepool And Manchester)

[gino25]

I have problems to download this beta3.

I use mozilla and explorer and no download manager, but i have always a message of error

[bond]

i saw packed bitstream is now default! why that?

[raz0r]

made to quick tests, one with and one without Turbo. It wasnt any faster at all and quality was also same, so i think its (now) useless.
oh and it now plays on ESS players, thats very fine :)

[sysKin]

Originally posted by raz0r
made to quick tests, one with and one without Turbo. It wasnt any faster at all and quality was also same, so i think its (now) useless. All "turbo" optins are related to b-frames and qpel. It won't make Simple Profile faster.
It won't make any differnce in first pass either.

Radek

[raz0r]

ah ok then its clear, cuz i didnt use bframes/qpel/gmc

[Leak]

Originally posted by bond
i saw packed bitstream is now default! why that?

<conspiracy theory>
Probably to make people use and test the new DirectShow decoder instead of ffdshow which can't play packed bitstream correctly... ;)
</conspiracy theory>

Still, it's the first thing I turn off after a "Load defaults...".

np: Jah Wobble & Deep Space - Forgetting Myself (Largely Live In Hartlepool And Manchester)

[Koepi]

Ffdshow will be fixed soon I think. It's no xvid bug that ffdshow doesn't playback packed bitstream correctly. Head over to the ffdshow thread in new a/v formats(codecs) and file a request there :)

Regards
Koepi

[bond]

damn i dont like packed bitstream too ;)

[Leak]

Originally posted by Koepi
Ffdshow will be fixed soon I think. It's no xvid bug that ffdshow doesn't playback packed bitstream correctly. Head over to the ffdshow thread in new a/v formats(codecs) and file a request there :)

I'm not really sure that'll help - according to the statistics from SourceForge, it's been dead since sometime mid-October, according to the CVS mailing list:

http://sourceforge.net/mailarchive/forum.php?thread_id=3308307&forum_id=22740
(that's the last CVS checkin)

:(

np: Rechenzentrum - Slate (Director's Cut)

[jarthel]

I must say I'm terribly suprise on the encoding speed. It previously takes 1.5 to 2 hours. Now it's less than an hour. In fact it's about 40 minutes.

Thank you Xvid team.

jayel

ps. not using turbo. It must be the SSE2 optimizations.

[m99]

Why is XviD-Dec-1.0-Beta3.exe bigger than XviD-Dec-1.0-preBeta3.exe?

[mikeson]

@jarthel:
No, it is because FAST1PASS.

@m99:
Why shouldn't it be?

[Assault]

@ m99

What mikeson tried to say is that XviD-Dec-1.0-preBeta3.exe is not the xvid codec but only the directshow decoder. ;)

EDIT: Forget what I wrote....I just realized that you wrote XviD-Dec-1.0-Beta3.exe and not XviD-1.0-Beta3-26122003.exe. So both files are only the decoder.

[Koepi]

I previously UPXed the files - now I don't do that anymore (minimal speed impact). OTOH, as I wrote earlier, the dshow palyback filter isn't compile'able with ICL anymore and I didn't tune the M$ compiler flags for smaller binary/faster code.

Regards
Koepi

[symonjfox]

Wow. I just tried to encode a DVB capture using Xvid Beta 3 and Anamophic resolutions.

Here's my results:
Source MPEG2 352*575 progressive.

A simple AVS script:
Loadplugin(".../mpeg2dec3.dll")
Mpeg2source("dvb.mpv")

Reencoded using Bframes, Qpel, ... , 3:4 AR.

Results:

Perfectly muxed into MP4 container and Perfectly resized on playback!! I'm very very happy.

I'll remove one of my requests in my signature :) :D :D

[Koepi]

Silent binary update (both full installer and standalone decoder):
- recompiled dshow decoder with small optimizations - now it's smaller again, and faster of course.

Regards
Koepi

[PowerMacG4]

With low bitrates in 2-pass mode (200kbps target) I am getting some pretty obvious differences when there is a keyframe. I believe keyframes should be favored a little more so that they aren't such a harsh blocky transition all the time (for low bitrates). Is there a way to improve this sample?

http://s91752438.onlinehome.us/public/uglykeyframes.png

[Koepi]

There isn't much you can do except for 2 things which come to my mind:

- use iframe boost (10 or 20% for starters) and stay with bframes or
- use a matrix which produces nice iframes even at low bitrates (i.e. h263? hvs good picture?)

Regards
Koepi

[bond]

some guys on the german dvdboard.de (http://www.dvdboard.de/forum/showthread.php?s=&threadid=64112) reported problems with the packed bitstream option on the new mediatek chipset (which is said to be the best atm, can decode qpel, gmc), lets hope that this get fixed...

Originally posted by symonjfox
Reencoded using Bframes, Qpel, ... , 3:4 AR.

Perfectly muxed into MP4 container and Perfectly resized on playback!! I'm very very happy.note that you need to use the 3ivx mp4 muxer when muxing "packet bitstream" files into mp4 (pb is used in divx5 and now also is default in xvid), as the 3ivx muxer is the only one who can unpack them again

otherwise your mp4 files wouldnt be spec compliant (it should also work to untick packet bitstream in xvid to get "real" mpeg-4 streams)

[Zhnujm]

Originally posted by bond
some guys on the german dvdboard.de (http://www.dvdboard.de/forum/showthread.php?s=&threadid=64112) reported problems with the packed bitstream option on the new mediatek chipset (which is said to be the best atm, can decode qpel, gmc), lets hope that this get fixed...


Then it was a feature request by Sigma/ESS :D
The problems with packed bitstream and MediaTek are also there with older xvid builds, its not that it has changed in the latest beta.

[Isibaar]

Originally posted by sysKin
Oh, again?
I had problems with deblocker the first time I compiled it (on ICL8.. and yes, it worked *then*).


Hm, really? That's strange because I also have ICL8 installed and never experienced any problems when trying to compile the postprocessing sources. Also, for me there wasn't a huge speed difference between using the Intel or the Microsoft compiler for the deblocking code. Actually the deblock c-code is already pretty much optimized so it shouldn't rely that much on the quality of the compiler...

Originally posted by sysKin

When I used deblocker the second time it was perfect - slower than ffdshow's of course, but imho it was the best deblocker I've ever seen. It was just so beautiful ^_^.

I'll try figuring out what makes it go fast/slow/fast etc all the time.



The deblocker was mainly designed for quality, speed came second. So it's 'normal' if you experience a drop in decoding speed. From my experience, XviD with deblock enabled is decoded only at a little bit more than half the speed than without deblocking. However this should still be more than enough to conveniently watch a XviD clip on a modern CPU. So I have a cpu usage of about 12-15% when watching a 640xXXX clip on my P4 2.4 GHz. That's slow but now I at least know that it was a good investment to buy a faster CPU ;-)

BTW: I have an additional speed-up for the deblocker almost ready, however don't expect any wonders. XviD's deblock will _never_ become as fast as the ffdshow one...

Originally posted by sysKin
PS. Deringer is fast because it's not implemented ;) [/B]
;-) yeah, we have a slow deblocker but the fastest deringer in the whole world ;-))

[symonjfox]

Originally posted by bond
note that you need to use the 3ivx mp4 muxer when muxing "packet bitstream" files into mp4 (pb is used in divx5 and now also is default in xvid), as the 3ivx muxer is the only one who can unpack them again

otherwise your mp4 files wouldnt be spec compliant (it should also work to untick packet bitstream in xvid to get "real" mpeg-4 streams)
I forgot to say that I disabled "Packed Bitstream". Is it wrong?

AFAIK, the only issue that appends if I doesn't enable it is only the "B Frame Lag" at the beginning, but it's not a problem for me.
In second I have no standalone player, so I've no need to enable them.
PS: I mux it using MP4ip, I have never used 3ivX muxer because I'm not able to use graphedit ... :(

[cipher]

Because of avi's slight incompatibility with B-frame, I would say it's theoretically better in avi to enable the "Packed Bitstream". And I would even suggest alway enable this option :). The format MP4 wouldn't have such problem, so it's not necessary to check packed bitstream if u decide to contain the video stream in .mp4.

[Leak]

Originally posted by Koepi
Silent binary update (both full installer and standalone decoder):
- recompiled dshow decoder with small optimizations - now it's smaller again, and faster of course.


And quite a bit faster, let me add... :)

Playing back the clip I mentioned before now takes around 20% CPU without deblocking and takes up about another 10% for each deblocking option (i.e. 30% and 40% in total) - which means it's perfectly usable. :)

np: Kid606 - Total Recovery Is Possible (Kill Sound Before Sound Kills You)

[amango]

Originally posted by Zhnujm
Then it was a feature request by Sigma/ESS :D
The problems with packed bitstream and MediaTek are also there with older xvid builds, its not that it has changed in the latest beta.

The MediaTek based DIVX-Players just do the same like the old xvid decoders if you use packed bitstream: Playback is stuttering. Without packed bitstream the MediaTek-Players plays like FFDShow and the old decoders: Smooth. ;)

[Soulhunter]

Before doing unless stuff again... ;)

Has someone interest for some tests with XviD's cartoon-mode on some anime stuff ???

I thought I could use one chapter of Animatrix...

Is "World Record" good for testing purpose ???

Suggestions for the setup and the filter chain ???

Bye

[Leak]

I've noticed one thing about some post-beta2 versions (at least one build from gamr and this beta) - the second pass has problems hitting the size I set:

I've encoded the four episodes on the first DVD of Last Exile and wanted them to come out at 170 MB (so all 26 of them will fit on a DVD+R), and this worked really good with beta 2, where all files differed only ~32kB in size (alas, I didn't keep those files as the IVTC/deinterlacing was a bit lacking).

Now using beta3, file sizes in bytes were as follows:


Ep. First pass Second pass
1 213671936 178210816
2 180004864 166291456
3 244750336 178288640
4 187039744 171317248


which seems rather, uh, off target to me.

Settings used were Adaptive Quantization, H.263, 2 BVOPS (Ratio 1.5, Offset 0.75), Closed GOV, no level restriction, default 2nd pass settings, 1 zone with weight 1, Chroma Optimizer and BVOP sensitivity -15, MSP 6, VHQ4, Chroma Motion, Cartoon Mode, Trellis, no restricted quantizers. Target size was 150427 and all episodes are between 24:21 and 24:28 minutes long, and the audio was 128 kBit/sec CBR MP3, which should have roughly given 170MB all in all.

Has anybody else encountered this? *wonders*

np: Monolake - White II (Momentum)

[Chainmax]

What about making an avisynth filter out of the deblocker? Wouldn't that solve speed issues since the decoder wouldn't have to carry that extra burden?

[kadajawi]

uh, I don't see the reason in doing that. The CPU power used would be the same at the end, and I prefer watching the video just as it is and not through Avisynth.

[Chainmax]

What I mean is that such filter could be used in the encoding stage.

[Leak]

Originally posted by Chainmax
What I mean is that such filter could be used in the encoding stage.

Maybe if you want to reencode something, but you'd still need it in the decoder used for playback since it's meant to correct flaws in the encoded material which encoding itself generates.

Actually, using the DirectShow decoder in conjunction with DirectShowSource in AviSynth will already do what you want. I'd say using the postprocessor on a source that's not MPEG-4 is not very useful as I'm sure the postprocessor uses information from the stream that just isn't there in a simple sequence of decoded images (motion vectors, quantizer information and the like).

np: Ulrich Schnauss - On My Own (A Strangely Isolated Place)

[gldblade]

Target size was 150427 and all episodes are between 24:21 and 24:28 minutes long, and the audio was 128 kBit/sec CBR MP3, which should have roughly given 170MB all in all. I don't think you're taking into account the fact that the amount of space taken up by audio will also vary. Maybe this is why you're seeing variation in your final filesizes. How closely does the video portion of the encoding meet your target?

[knight_inferno]

Bug??

Installed XviD-1.0-Beta3-26122003, now everything plays upside down! :confused:

Went back to XviD-1.0-Beta2 and it's all fine again :p

Anyone else have anything like this?

I don't use Ffdshow ever, Only have the Gordian Knot Codec pack installed (untick ffdshow), and Divx 5.1.1

Besides that, I am very happy with all encoding results of the XviD 1.0 beta's, and want to say good work to the dev's :)

[gldblade]

Installed XviD-1.0-Beta3-26122003, now everything plays upside down! Haha, I have the same problem. You can flip it back to its original orientation in XviD's decoder properties.

But I'm wondering why it's suddenly happened. I've never had this problem before, even way back when with DivX 3.11.

[GolovachLena]

SSE2 rocks! Got more the two times speed boost comparing to beta2 with same settings.

[knight_inferno]

haha, odd :p

Well it's good that it is easily fixed :D, never even thought of looking in the decoder options to change it, since I hadn't needed to do so before :p

Ah well, "Tick" up the right way now :D kewl stuff

[Koepi]

leak: encode the audio later and mux it then, you'll see that xvid hits the size - and as far as i can tell, the encodes are staurated.

Always encode sound and video in separate steps. Then you can see what's to blame in such situations - and if you have the size of the soundtrack, you can calculate the video size you need to fill up exactly the file size you want.

. o O ( the very basics of ripping... )

@all:

The picture can be flipped because the output colour space changed. If you try different colour spaces you'll see that some are flipped, some others aren't. This is either a vga software or hardware error - try different vga drivers then or use the "flip image" option in the directshow filter.

Koepi