XviD 1.0.3

[celtic_druid]

his is XviD 1.0.3 bugfix release.

This release fixes very minor bugs. It is source and binary compatible
with the previous version.

As a sidenote, the 1.1 is maturing fast these last weeks and it's quite possible
Santa Claus could bring you an official beta release of this new tree before the
end of the new year.

The 1.1 tree brings a fair number of optimizations in the decoder, better quality
and more speed for the encoder, a brand new PowerPC port, a Linux AMD64 port...

Changes since 1.0.2:

* xvidcore
- Fixed trellis optimization overflow for quant <= 2.
- Don't read too short streams. This prevents from reading useless
stream garbage.
- Fixed 64 bit crashes because of addressing assuming 32bit integers. (Andre Werthman)
- Fixed 2 diamond search bugs (one was causing searches in wrong directions,
the other one was causing an early exit)

* VFW frontend
- Better stride calculation

* DShow frontend
- Better stride calculation

-- Edouard Gomez
http://ed.gomez.free.fr/

[Sharktooth]

For the lazy ppl here (http://ebola.gamersrevolt.it/celticdruid/) you can find some new builds from celtic_druid (including xvid 1.03).

[ookzDVD]

I better wait for Koepi's Build.
I think you know why :)

[ObiKenobi]

Originally posted by ookzDVD
I better wait for Koepi's Build.

Why bother? He's already put out a 1.1 build so why would you want to wait for a 1.0.3 build.

[Koepi]

Anyways my 1.0.3-build is up now. I couldn't check the installer since i did the compiler-switch-setting/compiling over VNC. Would be nice to get feedback if it works then :)

Regards
Koepi

[r0cket]

Well, yes, the installer does work.
But I'm very missing those DXN profiles Nic provided in his builds :(

[SeeMoreDigital]

Just tried celtic_druid's and Koepi's builds,


Just the following observations so far: -

01 - Under the "Aspect Ratio" tab, can the "Picture Aspect Ratio" please be corrected to say "Display Aspect Ratio"?

02 - By default, "Display Encoding Status" is always switched on. While the function is useful, I don't think I'm the only one, who would prefer to have it turned off, by default..... Or am I?

03 - I see the trusty old "decoder filter" is being used. What happened to the proposed new filter that could detect PAR/DAR signalling?

04 - Obviously, B-VOP encodes do not work with my Xcard ;)


Cheers guys

[celtic_druid]

01 & 02 I could fix. Wouldn't be a vanilla 1.0.3 compile then though, would have to call it something else.

03, it is v1.0.3, it isn't supposed to have the new decoder, that is only for cvs head/1.1 builds.

[niamh]

02. personally, I'm perfectly happy to have it on by default, it's the first thing I look at(and the last). A good middle way would be to have it on, but minimized , because it does behave a bit like a pop-up ad ;)

A sidenote, the thread has been up 24 hours(well, 27), and already 3750 views....WoW.

[neo75903]

Caint find koepi's build from his signature site.
Anyway, using celtic_druid's build, thx all for the binaries.

edit: found the link on an other side:
http://www.koepi.org/XviD-1.0.3-20122004.exe

[celtic_druid]

Pretty sure that this comes up every time Koepi releases something, but you probably need to refresh his site shift/ctrl+F5 to clear the cache.

edit: typo

[Koepi]

Originally posted by celtic_druid
Pretty sure that this comes up every time Koepi releases something, but you probably need to refresh his site shit/ctrl+F5 to clear the cache.

:( my site shit?

Lovely typo! :)

Cheers,
Koepi

[SeeMoreDigital]

Yep, the "refresh" page thingy has caught me out a few times in IE6. It also happens sometimes with Doom9's main site!

It's a bit weird because it still happens even when all the files in the "temporary internet folder" and "history folder" are deleted before accessing the web sites...


Cheers

[lark]

could that be a proxy issue?
even a transparent proxy somewhere...?

is there actually a different kind of HTTP get, when you do a refresh, so that the proxy could recognize this?

regards
t :)

[Uli]

Originally posted by lark
could that be a proxy issue?
even a transparent proxy somewhere...?

is there actually a different kind of HTTP get, when you do a refresh, so that the proxy could recognize this?

regards
t :)

If you use ctrl F5 in IE/FF then these two header fields are added to the HTTP request:

Pragma: no-cache
Cache-Control: no-cache

If these fields are correctly interpreted by the proxy chain you should get the contents from the server and not the cache.

If you get it from server you get
HTTP/1.1 200 OK

If you get it from cache you get
HTTP/1.1 304 Not Modified

Hope this clears things up ;)

greetz, Uli

[gpower2]

What's the differences between celtic_druid's, koepi's and Nic's builds?
I used to prefer Nic's builds since I am a P4 user but since it's been a long time for him to post a build I am a bit reluctant to use it. Am I wrong? Do all of the builds contain CVS definitions?

A big thanks to all of them for providing "little us" with such great builds!

[Sharktooth]

Usually if the builds are from CVS the differencies are in the compiler (and compiler version) used and from the date the source has been taken from the CVS.
Usually a more recent CVS checkout contains the newer code.
For Athlon CPUs Koepi's and Celtic druid builds are faster, for P4s use the Nic's build.
BTW Celtic druid has the newer compiles.

EDIT: fixed

[sysKin]

Originally posted by Sharktooth
Nic's build is a CVS compile plus DXN profiles and VBV. Koepi's is a straight CVS compile from the 1.0x branch (actually 1.03, but does not contains DXN profiles). Also celtic druid build is 1.03 from CVS.
Wait wait, something was wrong here....
Koepi's 1.0.3 build is straight from CVS' 1.0 branch. Koepi's 1.1.-127 build was CVS (at that time) with some modifications - AR in directshow, VBV, and alternative ratecontrol algo.

Nic's build is pure CVS (1.1 branch) but is much newer that Koepi's, so it includes VBV and DXN profiles. But this is because both are in CVS now.

Celtic Druid has two builds, from two branches, both unmodified CVS. Celtic Druid's 1.1 build is 6 days newer than Nic's (at this moment).

Phew :)
Radek

[celtic_druid]

Basically all of my XviD builds are compiled with ICL7.1, except for the gcc ones.

As Syskin said all of my stuff is pure cvs, other than the stuff in the test folder, however skal's trellis fix was added to the cvs, so even that is basically pure cvs now.

I never did a cvs head build for:
xmm-ed transfer8to16_2() - faster bvop-vhq
add CBP cost as soon as possible (yet another bvop-vhq speedup)

Should probably put one up.

[Enigmax]

Thanks for your CVS builds, Celtic_Druid.

Congratulations to the XviD Team. Very, very nice.

Greetings

[Sharktooth]

Uhm... i thought nic merged some 1.1 feature with 1.0 branch. My bad:)
I should have checked out the CVS before posting a reply.
Thanx for the clarification syskin.

[SeeMoreDigital]

Originally posted by celtic_druid
03, it is v1.0.3, it isn't supposed to have the new decoder, that is only for cvs head/1.1 builds. Hmmm...

It appears Nic has included the proposed (v1.1) DSdec filter in his build... which might confuse people!

Seeing as though PAR/DAR signalling has been a function of the XviD encoder for around a year now, I would have thought having a fully working XviD decoder would have been somewhat of a priority :(


Cheers

[celtic_druid]

Nic's build is a CVS head build though, so you can't compare it to v1.0.x builds. Like I said v1.0.x isn't supposed to have the new decoder that is a cvs head/1.1 feature, hence Nic's build is supposed to have it.

If you read the 1.0.3 release then it would appear that the first 1.1 beta could be out soon, with the new decoder.

As to the reason for not having the new decoder with v1.0.3, there was a feature freeze for that branch.

[SeeMoreDigital]

Originally posted by celtic_druid
Nic's build is a CVS head build though, so you can't compare it to v1.0.x builds. My appologies... my mistake!

Hopefully the new DSdec filter, will work properly with Mpeg4 streams containing B-VOP without packed bit-stream :)


Cheers

[Didée]

SMD: By then, all you'd need were a properly working XCard ... :)

[celtic_druid]

As I pointed out around here somewhere, technically it isn't packed/not packed that is the problem, it is the DivX packed bitstream tag. It will resize if you have it, although it won't decode properly with the flag there and non packed bframes. Also if you take a file that has packed bframes and remove the tag, it will no longer resize.

[SeeMoreDigital]

Originally posted by celtic_druid
As I pointed out around here somewhere, technically it isn't packed/not packed that is the problem, it is the DivX packed bitstream tag. It will resize if you have it, although it won't decode properly with the flag there and non packed bframes. Also if you take a file that has packed bframes and remove the tag, it will no longer resize. I see.... But how come "non-packed" XviD streams still AR correctly with other decoders/players, such as Nero's DSdec and VLC player?

Originally posted by Didée
SMD: By then, all you'd need were a properly working XCard ... :) Ain't that the truth....

Unfortunately Sigma have a poor track record at releasing software updates for this product. Which is a pitiful shame :(


Cheers

[celtic_druid]

Because they aren't using XviD's code. I wasn't saying that there wasn't a problem I was just pointing out that the issue isn't whether the bframes are packed or not but rather whether there is a DivX packed bitstream tag or not. If the file uses bframes and doesn't have the tag, no resizing; if it uses bframes with the tag, then it resizes.

[SeeMoreDigital]

Can anything be done to overcome this?

It's a bit of a bummer when everything Mpeg4 has to have a mention of DivX in it somewhere!


Cheers mate

[celtic_druid]

Well as far as I can tell the problem is with bitstream.c with the divx detection code.

[SeeMoreDigital]

With not knowing anything about computer code... I'm still a little confused!

Because even after removing XviD's and DivX's "UserData" references with MPEG4 Modifier, the encodes still AR perfecly via Nero's ShowTime and VLC players!

How can this be happening if there's no references to DivX?


Cheers

[celtic_druid]

Like I said, because Nero's filter is using different (in this case I guess better) code.

In bitstream.c with the divx detection code, when it finds the tag, packed_mode is set to 1. This seems to be a key to AR resizing with XviD.

In decoder.c you have
if (dec->packed_mode && seen_something) which relies on the previous code for the packed_mode. No DivX tag and it doesn't get run and no resizing is done.

Should point out that I don't really know anything about computer code either. That said I have XviD resizing properly, packed/no packed, DivX tag/no tag, just probably broke something else in the process. Well no bframe lag frame for a start either that or you can have it show with dshow to.

Guess in the end it comes down to XVID_TYPE_NOTHING from decoder.c returning S_FALSE in CXvidDecoder.cpp.

[SeeMoreDigital]

Well hopefully something can be done about it sooner, rather than later!

As Mpeg4 DSdec filters go, I think XviD's, no fuss approach is a good choice. Especially as it can be downloaded and installed in it's own right, ie: purely as a decoder filter. And it's tiny!


Cheers