Proposal: XviD 1.1.0 (beta3?) release

[suxen_drol]

howdy all. five months have past since the last beta, and i think it is time for a new release.

since the xvid.org forum no longer represents the majority of xvid users (did it ever?), i thought i'd post here to call for comments and opinion. in particular, i am interested to know whether there are any significant outstanding bugs. if there are no such bugs, then the next release will be 1.1.0. please refer the ChangeLog (http://www.xvid.org/cvs/chora/co.php/xvidcore/ChangeLog?r=1.13) file for a description of all cvs changes since beta2.

cheers,
-- pete

[celtic_druid]

Says "1.1.0-<beta3/final tbd>" there.
Still info->build = "xvid-1.1.0-beta2" though.

Anyway the only change to the cvs since my last build is the above changelog being updated.

http://mirror05.x264.nl/celtic_druid/force.php?file=./xvid.cvs.head.exe
Compiled with ICL9, but the intel checks have been removed so it should run fast on AMD CPU's.

[squid_80]

I'd still like to see the dshow and vfw frontends use different registry keys for their aspect ratio settings. It's a pain to open the dshow config and set it back to auto after every anamorphic encode.

[celtic_druid]

I was thinking just the same thing as I checked that the decoder worked for AR with bframes that aren't packed.

Might modify it next build.

[suxen_drol]

squid_80: fixed, i have renamed "Aspect_Ratio" to "Decoder_Aspect_Ratio".

celtic_druid: the build text will be changed upon the new release. at this stage i'am just proposing the idea, to flesh out any outstanding bugs. the ar+unpacked_bframes bug was fixed only a few days back.

[suxen_drol]

given that there has been little response, i intend to package the "1.1.0 final" release this weekend.

cheers, --pete

[Teegedeck]

? Don't know how I could've missed that thread ?

Just to let you know I appreciate it - and I guess I represent the 'silent majority' on this one! :)

The beta already is so good that only the most timid natures missed the 'final' tag on it, I guess...

BTW, thanks again for bringing us this codec. When it started out it seemed a distant aim that XviD could once be something like the LAME of MPEG-4 ASP codecs. Now it's been just that for a loooong time! :cool:

A big hello to '1.1' then!

[SeeMoreDigital]

I was thinking just the same thing as I checked that the decoder worked for AR with bframes that aren't packed.Just tried the same as you with your build....

Very nice to see XviD encodes with B-VOP and without packed bit-stream auto AR with XviD's direct-show decoder :)


I also ran an encode thru' MPEG Modifier (to remove the packed bit-stream).... and what's all this?

http://img217.imageshack.us/img217/8765/xvid4su.png


Cheers

EDIT: I'm sorry to say I missed this thread too!

[SeeMoreDigital]

And if it's possible to alter parts of XviD's GUI, can somebody please re-name "Picture Aspect Ratio" to "Display Aspect Ratio"...

http://img32.imageshack.us/img32/6831/xviddar1ft.png


It's been bugging me for years!


Cheers

[celtic_druid]

I added a build date string to some of my builds.

[Yuri Khan]

I’d like to report a small cosmetic bug. It is not even in the core, but in examples. But, seeing as one particular example seems to want to evolve into a full-fledged command-line XviD encoder (http://forum.doom9.org/showthread.php?t=98469), it might be worth fixing :)

Summary:
xvid_encraw and xvid_decraw time-based statistics are meaningless. (The further description only mentions encoding but the relevant code is duplicated in xvid_decraw too.)

Platform:
Win32

To reproduce:
Do an encode that will run for more than 36 minutes.

Expected behavior:
Total encoding time, average frame encoding time and average fps are displayed.

Observed behavior:
The numbers displayed bear no resemblance to reality and may be negative.

Cause:
The frame encoding time is measured using this code:
double enctime;
[…]
enctime = msecond();
m4v_size =
enc_main(!result ? in_buffer : 0, mp4_buffer, &key, &stats_type,
&stats_quant, &stats_length, sse);
enctime = msecond() - enctime;where the msecond() function is defined as:
static double
msecond()
{
#ifndef WIN32
struct timeval tv;

gettimeofday(&tv, 0);
return (tv.tv_sec * 1.0e3 + tv.tv_usec * 1.0e-3);
#else
clock_t clk;

clk = clock();
return (clk * 1000 / CLOCKS_PER_SEC);
#endif
}According to the C Standard, the range and precision of clock_t are implementation-defined. At least one widely used implementation (namely, Microsoft Visual C++ 7.1) defines clock_t as long, and CLOCKS_PER_SEC as 1000. So, clock() advances 1000 ticks each second, and clock_t has enough bits for 2^31 - 1 = 2147483647 ticks, which is approximately 25 days.

However, the above code multiplies the clock() value by 1000, which means that an overflow will occur in 2147483647 / 1000 ms = 2147483.647 ms = 2147.483647 s ~= 35.8 minutes. If at the moment of the overflow a frame is being encoded, the enctime measured will be negative.

Proposed solution
Since the msecond() function deals with double precision floating point numbers, it seems reasonable to enforce floating point arithmetic:
--- xvid_encraw.~c Wed Oct 05 21:29:50 2005
+++ xvid_encraw.c Wed Oct 05 21:29:40 2005
@@ -664,7 +664,7 @@
clock_t clk;

clk = clock();
- return (clk * 1000 / CLOCKS_PER_SEC);
+ return (clk * 1000.0 / CLOCKS_PER_SEC);
#endif
}

[Sharktooth]

@all xvid builders: DirectX SDK has been just updated. If you include the DirectShow decoder in your builds, please ensure you have the latest SDK before building any final release.
http://forum.doom9.org/showthread.php?p=720092#post720092

[celtic_druid]

All of the DirectShow components (Headers, Libraries, Utilities, Tools, and Samples) were removed as of the DirectX 9.0 SDK Update (April 2005) release.
As such I can't see how updating the SDK would help.

[Sharktooth]

Important bug have been fixed. That's just for the sake of "safety".

[Yuri Khan]

I stepped into another issue in xvid_encraw today :)

In short, I ran out of space while encoding. But xvid_encraw does not check if encoded frame was successfully written, and continues encoding. Of course, until I come and free up some space, the encoded frames are going to be dropped on the floor :(

My paranoid alter ego also suggests that if after that some free space mysteriously appears, subsequent writes will succeed, resulting in a stream that is both invalid and hard to fix.

I do not know what would be a good solution to this. On the one hand, I want it to stop encoding if the results are not going to be stored. On the other hand, I want to continue encoding when some space is freed up, from the point just before the failure. And on the third hand, I know it is extremely difficult to guarantee transaction semantics with file I/O.

[unskinnyboy]

In short, I ran out of space while encoding. But xvid_encraw does not check if encoded frame was successfully written, and continues encoding. Of course, until I come and free up some space, the encoded frames are going to be dropped on the floor :(

My paranoid alter ego also suggests that if after that some free space mysteriously appears, subsequent writes will succeed, resulting in a stream that is both invalid and hard to fix.

I do not know what would be a good solution to this. On the one hand, I want it to stop encoding if the results are not going to be stored. On the other hand, I want to continue encoding when some space is freed up, from the point just before the failure. And on the third hand, I know it is extremely difficult to guarantee transaction semantics with file I/O.

How does XviD VfW behave in this scenario? Never had to encounter this situation, so I am not sure myself.

[stephanV]

In the case of VFW it is the host application (e.g. VirtualDub) that is allocating space on the drive so it depends on what that does. While I have never tried it myself, I assume VirtualDub will just abort encoding.

[unskinnyboy]

I see, Thanks Stephan. Makes sense. What about mencoder? Same thing I suppose..

[Yuri Khan]

mencoder tests the output file status after each frame and aborts the encode.

[hannah]

In the case of VFW it is the host application (e.g. VirtualDub) that is allocating space on the drive so it depends on what that does. While I have never tried it myself, I assume VirtualDub will just abort encoding.


I can verify that VirtualDub stops encoding when there is no disc space left. Been there, done that.

[suxen_drol]

yuri khan: commited to cvs head.

smd and others: a new gui has been discussed by many people for long time. whilst i agree that the user interface needs improving, the reality is, that a major overhaul (as often proposed) is a lot of work. if there were a consesus on a design layout, then perhaps somebody would be willing to take up the challenge.

[708145]

I stepped into another issue in xvid_encraw today :)

In short, I ran out of space while encoding. But xvid_encraw does not check if encoded frame was successfully written, and continues encoding. Of course, until I come and free up some space, the encoded frames are going to be dropped on the floor :(

My paranoid alter ego also suggests that if after that some free space mysteriously appears, subsequent writes will succeed, resulting in a stream that is both invalid and hard to fix.

I do not know what would be a good solution to this. On the one hand, I want it to stop encoding if the results are not going to be stored. On the other hand, I want to continue encoding when some space is freed up, from the point just before the failure. And on the third hand, I know it is extremely difficult to guarantee transaction semantics with file I/O.

pipe the output of encraw to another process that only writes to disk.
if the write process gets halted due to lack of space your encraw process will pause as well.
once you free space both will continue again.

bis besser,
T0B1A5

[celtic_druid]

As reported on page 1, Picture Aspect Ratio has already been changed to Display Aspect Ratio. You can check it out yourself in my last cvs compile.

[Elias]

As reported on page 1, Picture Aspect Ratio has already been changed to Display Aspect Ratio. You can check it out yourself in my last cvs compile.Cool! I will, sorry for not reading every post, not enough time for that.

[SeeMoreDigital]

As reported on page 1, Picture Aspect Ratio has already been changed to Display Aspect Ratio. You can check it out yourself in my last cvs compile.If Druids were gods.....

http://img310.imageshack.us/img310/8167/xviddar7qy.png


Thanks mate :D

[Teegedeck]

Discussion of possible improvements of XviD have been moved to a new thread. Please continue that discussion there:
possible improvements beyond XviD 1.1 final [thread split] (http://forum.doom9.org/showthread.php?goto=lastpost&t=101346)

Please use this thread here just to discuss bugs and cosmetic improvements that should be taken care of before XviD 1.1 goes final.

[SeeMoreDigital]

By-the-way...

Given that the packed bit-stream AR issue has been sorted now, would there be any chance of having a separate direct-show decoder filter?

And during the installation process. How about an selectivity option to install just the encoder. And another option to install the encoder plus decoder?


Cheers

[suxen_drol]

By-the-way...
Given that the packed bit-stream AR issue has been sorted now, would there be any chance of having a separate direct-show decoder filter?

And during the installation process. How about an selectivity option to install just the encoder. And another option to install the encoder plus decoder?
Cheers

these decisions are left up to those responsible for compiling and packaging the releases, koepi, celtic druid and whomever else. the nsis installers scripts are not stored in the xvid cvs tree.

[celtic_druid]

Well I also offer the individual files so if you wanted just the dshow decoder you could copy xvid.ax and xvidcore to your sys folder and reg the ax. Really though since it was split into xvidcore, vfw and ax I can't see much point to just the vfw or just the dshow.

By the way, new build up with quality presets.

[SeeMoreDigital]

I hear what you say.... But given that XviD's DS decoder is so small (fixed) and simple to understand, I think it would be very useful for newbies on the hunt for "flexible" MPEG-4 decoder!

A separate DivX encoder, is out of the question (as DivX don't allow it anyway). And installing FFdshow may be too much like hard work for some people ;)


Cheers

[Teegedeck]

What is the problem about installing the few bytes more that are the encoder? For example I haven't heard anyone asking for a decoder-only MP3 codec install, yet.

Not that it would be a technical problem to have an encoder-only installer; it just needs someone to compile it. But next thing you know someone complains about not being able to edit XviD encoded files, as we hear it so often from users who only have ffdshow installed.

[Manao]

But that's just a matter of configuring properly ffvfw. Its default configuration is rather restrictive (which is good for the experienced user, not that good for the newbies)

[SeeMoreDigital]

If I remember correctly Koepi provide a separate DS decoder at one time....

And some users may find it helpful to include an separate decoder filter (or as an auto install) when sending MPEG-4 files to other people on disc, who (still) may not have an MPEG-4 decoder filter!

Not so long ago I would send out "show-reel" CD's of peoples work in 720x576 anamorphic XviD (taken from an beta or digi-beta source), and was quite surprised at how many people in the industry did not know about MPEG-4 on their PC's.... And some of them did not even know they had MPEG-4 capable stand-alone players at their premises.... but that's another story!

By the way, new build up with quality presets.Can you provide a link please I can't find it :(

[celtic_druid]

http://ffdshow.faireal.net/mirror/xvid.cvs.head.2005.10.16.7z
For those who want seperate files. Only xvidvfw.dll is updated anyway.
Installer: http://ffdshow.faireal.net/mirror/XviD.cvs.head.exe

Exactly, people will download the dshow decoder and then complain that VDub won't open their XviD files. Like I said, before there was xvidcore, it made some sense, but now it doesn't really since xvidvfw.dll adds very little to the installer.

[SeeMoreDigital]

Hi Celtic-Druid....

I think it the reason why I got confused about your Beta 3 build, was due to this: -

http://img449.imageshack.us/img449/2851/xvidbeta32mg.png


EDIT: I don't think the "Load Defaults" is functioning correctly!


Cheers

[celtic_druid]

It isn't beta3, it is just another cvs build. Load defaults seems to be working fine here or was that just a joke to get me to press it?

[SeeMoreDigital]

It does not look like I'm having a good day :(

Load defaults works okay now (after re-boot).... And can somebody alter/ammend title of this thread please.... for clarity sakes ;)

You know.... for dumb (and blind) old farts like me!

[Kopernikus]

Any News about the new GUI or a 1.1 final release?