Niltze! (XviD-1.0-RC1-26012004)

[RadicalEd]

Originally posted by crusty
@all: try encoding with the DivX-compliant profiles if you're having trouble with your encodes not playing in DivX 5.XX, Nero or ffdshow.
Also, when reporting bugs, please state the profile you use and if you use weight zones (with weights or quants).

Actually the DivX profiles were removed after beta2, and the profiles themselves do nothing but set a few header flags (no effect on RC, vbv etc).

[sysKin]

I agree that defaults should be safe - overflow treatment should be 10/10/7 or more. It's power users that can lower it.

I'm a bit worried about quant-1 frames. They shouldn't happen if second pass is smaller, at all.
As Koepi noticed before, they hapen if second pass is not much smaller, and this is because 10% keyframe boost. It's still wrong, but at least I know the explaination.

I'll try to find a reason for q1 frames in lower bitrates.

BTW the default quantizer ranges changed to fight the most common n00bish question - saturation. It's a good solution, just 2pass2 has take care not to use them if there is no need.

Thanks for testing, everyone!

Radek

[Jaw3000]

Originally posted by Human_USB
GK does not work with the new XVID 1.0.
Originally posted by crusty
@Jaw3000:
Try setting minimal Quantizer to 2 instead of 1 and see if that fixes filesize prediction.

Ok, that's what I'm trying to find out! Some say Xvid 1.0 does work with GK and others say it doesn't. I don't know if it does or not. Above are two conflicting answers to my question. Maybe there are certain settings that don't work right. I know that it seems to work sometimes, since it was working fine (file sizes were correct and compression test worked) until something happened. What I'm trying to figure out is, since sometimes it obviously works, what settings might need to be changed? I haven't had a chance to try the above suggestion yet. Any definitive answer on this subject? Also, any idea when GK (and AutoGK) might be updated to work "better" with Xvid 1.0 (RC1)?

Thanks!
-Jaws

[stook]

As crusty said, "Packed bitstream is basically only usefull when saving to avi". So if OGM format is used, there are any advantages in using Packed bitstream???
Someone has choppy playback when overlay mixer is used or it's only in my system (XP SP1, P4 3.0GHz, DX9 & G4Ti4200)?!?

[crusty]

Not surprisingly, without b-frames the content plays perfectly with every decoder.
Have you tried using ogm or mkv, with b-frames and without packed bitstream?

Actually the DivX profiles were removed after beta2, and the profiles themselves do nothing but set a few header flags
Well I guess stuff like more-than-1-b-frame and GMC have to be turned off when using those types of profiles, if they ever come back.
You could also make an option called DivX-compatability-mode which would pop-up a reminder every time you did something non-divx-compliant (saying 'No !!! Don't do it!! Don't use DivX!! or something like that :D)
BTW the default quantizer ranges changed to fight the most common n00bish question - saturation.
Got it: - 'I get undersized files! What's wrong?' ;)
Some say Xvid 1.0 does work with GK and others say it doesn't. I don't know if it does or not. Above are two conflicting answers to my question.
I hardly call them conflicting...anyway you could better say:
GK does not work correctly with the new XVID 1.0.
That means sometimes it does, sometimes it doesn't.
Try to use GK only for the introductory stuff, let it create the avisynth script for you, and then do your own encoding.
Also, any idea when GK (and AutoGK) might be updated to work "better" with Xvid 1.0 (RC1)?
Try one forum up. Possibly two. :)

[GolovachLena]

Originally posted by stook
Someone has choppy playback when overlay mixer is used or it's only in my system (XP SP1, P4 3.0GHz, DX9 & G4Ti4200)?!?

I personally often had choppy playback after using packed bitstream, avi of course, different sources and settings. (Actually, not only me, my friends confirm the bug too). Think it's big no-no to use this feature. Sadly, devs don't listen and don't do anything about that.

[GolovachLena]

Originally posted by Koepi
1 consecutive bframe, packed mode, and ffdshow and divx mess up?
Damn.
Someting to think about, and sorry to judge that post "too early" without understanding what you meant.

How pathetic! You DIDN'T LISTEN when i told you THE SAME two days ago.
Any apologies? ;)

[fccHandler]

Originally posted by crusty
Have you tried using ogm or mkv, with b-frames and without packed bitstream?
Well, I just tried Matroska. The RC1 content plays fine without packed bitstream, but with packed bitstream it's still choppy. (Same results as with AVI container.) I'm truly at a loss to explain what's happening, but I've found a temporary workaround so I'm happy.

BTW, did I mention the quality of RC1 is fantastic? Great work! :cool:

[puschpull]

Thanx Koepi!

XviD 1.0 is excellent !!
:)

I Made Little Guides for Works and Setting XviD 1.0,
but in Czech Language.
:-))

brand-new:
http://puschpull.org/xvid_v.1.0.rc1_koepi.php

one month old:
http://puschpull.org/xvid_v.1.0.beta3_koepi.php

:p

[BoNz1]

Originally posted by GolovachLena
I personally often had choppy playback after using packed bitstream, avi of course, different sources and settings. (Actually, not only me, my friends confirm the bug too). Think it's big no-no to use this feature. Sadly, devs don't listen and don't do anything about that.

First of all, everybody is doing this on their own free time. Everyone knows it is a bug, but _not_ with xvid. The fix for this bad decoding is in the ffmpeg cvs so hopefully milan could update libavcodec in the ffdshow cvs. Then you will get a new ffdshow build and everything will be peachy.

Originally posted by GolovachLena
How pathetic! You DIDN'T LISTEN when i told you THE SAME two days ago.
Any apologies?

Huh, nobody will apologize to you if you have this kind of attitude I suggest you take a look at this http://forum.doom9.org/showthread.php?s=&threadid=52597 read it though carefully. And yes, shockingly people do make mistakes yes even the mods and yourself try to be aware of this and things will go a lot more smoother for you.

[GolovachLena]

Originally posted by BoNz1
Everyone knows it is a bug, but _not_ with xvid.

Oh really? Why then when Xvid simulates Divx work (1 consecutive bframe, packed) it produces wrong output?

Huh, nobody will apologize to you

It was kinda joke, i used a smile anyway.

[stook]

As I wrote, with or without packed bitstream, with all options off, the result is the same, choppy playback when overlay mixer is active, only when I change Video Render to VMR9, the problem is fixed... (It happens in Zoom Player 3.30 and MPC 6.4.7.6 and it doesn't happen with fddshow and Divx 5.1.1 decoder). Can anyone confirm that!!!
It's not a packed&bframesproblem...
By the way, I don't have problems with packed bitstream&bframes>1 because I use Xvid RC1 decoder...
I asked before too if there are any advantages in use packed bitstream when the output format is OGM!!!
Thanks to anyone who answer me...

[crusty]

Stook:
Packed bitstream is meant to fix avi's not handling frame order correctly when using b-frames. More modern formats don't need it.
I'm not 100% sure about Ogm, but you can bet it's not needed with mkv.

[stook]

Thanks crusty for your quick answer... :)
So, can anyone confirm the same problem I have with overlay mixer...

[Manao]

stook : are your video drivers up to date ? I also have a GF Ti 4200, and I've no problem at all with overlay mixer and xvid decoder.

[SanatClaus]

Hi all, thanks for all great Xvid-work :):).

I am replacing my VCR by doing recording on the fly, single pass (real time recording) with excellent results using Xvid on my AMD 2400+ (I am aware that I will get better result with 2 pass post processing).

Unfortunately RC1 yields a hanging recording application when I press stop recording, whereas Beta3 and all previous did not :(. Windows Task Manager says No Response in 3 apps I have tried (Leadtek expert WinPVR, iuVCR and VisualVCR). However, recording is done properly to the file. VitualDub (1.5.4.1 and 1.5.10) does not hang (can this be because it uses vfw-filters/drivers?). This happens with default settings and also if I reduce MSP to 5 and VHQ mode to 0 (to reduce CPU load).

I have no empty entries in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32

I have removed and reinstalled all video decoders responding to FourCC XVID. Gspot reports four codecs

XviD MPEG-4 Codec:
DSH Driver or Wrapper C:\WINDOWS\System32\qcap.dll

DivX Decoder Filter (5.1.1.1031 pro):
DSH Driver or Wrapper C:\WINDOWS\System32\divxdec.ax

XviD MPEG-4 Video Decoder:
DSH Driver or Wrapper C:\WINDOWS\System32\xvid.ax

DivX Decoder Filter (5.1.1.1031 pro):
DSH Driver or Wrapper C:\WINDOWS\System32\divxdec.ax

and renders video with divxdec.ax

Hope you lot can help me
/SantaClaus

[Aqa]

Originally posted by stook
As I wrote, with or [B]without packed bitstream, with all options off, the result is the same, choppy playback when overlay mixer is active, only when I change Video Render to VMR9, the problem is fixed... (It happens in Zoom Player 3.30 and MPC 6.4.7.6 and it doesn't happen with fddshow and Divx 5.1.1 decoder). Can anyone confirm that!!!

I’ve got exactly the same “Problem” there got to be an explanation for it, just haven’t figured it out yet!

[Koepi]

stook:

well, OggDS muxes the video frames directly from avi into OGM - so it has the same advantage as in .avi: there won't be a decoder lag. (The avi container doesn't know about "packed bitstream" and neither does OGM, so it's not possible yet to "unstrip" the packed frames and just timestamp them correctly).

@all:
If you have troubles with packed bitstream, can you please check as stook(i think) described, use another overlay mixer, en/disable dvobsub or any other weird filters during playback - and verify that the problem still exists after doing that?
I can't imagine yet what's wrong with the overlay as nothing should've changed in dshow affecting this - but wait, we do set aspect ratios now, maybe that's the catch?

Regards
Koepi

[stook]

Thanks for answers Koepi.
I verified that my nvidia drivers are up to date...
I made some more few tests with a movie(xvid RC1,ogg,no bframes and no packed bitstream) and the conclusion is:
-with overlay mixer:
Divx 5.1.1 or fddshow plays smooth
Xvid RC1 play very choppy
-with VMR9
all decoders play smooth

I tested in Zoom Player 3.30 and MPC 6.4.7.6
Windows Media Player 9 with Xvid RC1 decoder play smooth. I presume, but not sure, that WMP9 use VMR9.

I hope it helps...

PS1 - With VMR9 and packed bitstream and bframes-2 I have no choppy playback.
PS2 - In "Max consecutive BVOPs" I put 10 but it only used a maximum of 2! Anything wrong?!?

***EDIT (IMPORTANT)***

Now I'm really confused... I made some more tests... I reencode 30seconds at 600Kbps with all options on (packed, bframes-10 (it used a maximum of 2) and others) and with all options off.

Conclusion is:

In ZoomPlayer 3.30 Standart & MPC 6.4.7.6
With overlay & Xvid RC1 decoder
all on - play smooth
all off - play choppy

With overlay/VMR9 & fddshow
all on - play choppy (as I'm waiting)
all off - play smooth

With VMR9 & Xvid RC1 decoder
all on - play smooth
all off - play smooth

Can anyone confirm that?!?

[stereozulu]

first of all great work on rc1!

maybe someone can help me explain why the video is flipped only with bspayer in overlay mode 1, decoded by xvid.

i encoded a movie without bframes, without gmc, without qpel etc. and tested several playback scenarios:

- VLC and WMP play it back fine using ffdshow OR XviD decoder
- BSPlayer plays it back fine with ffdshow in overlay mode 1 or 2 OR xvid decoder only in overlay mode 2

has anyone tested it with zoomplayer?

So why does BSPlayer in overlay mode 1 decoded by XviD flip the video?
It seems to be a decoding issue, which has nothing to do with the encode itself. XviD 1.0 Beta3 didn't have this problem ...

So is this a BSPlayer issue or a xvid decoder issue?

[sapient]

I think I found a bug.
With the new RC1 (just this build) virtualdub crashes when I try to scan into or jump to a frame that belongs in a constant quantizer zone. Vistualdubmod and nandub give no error message, they just shut down. Virtualdub 1.5.10 reports the following:

An out-of-bounds memory access (access violation) occurred in module 'xvidcore'...
...while decompressing video frame 204339 with "XviD MPEG-4 Codec" [biCompression=44495658] (VideoSource.cpp:1772).

On the other hand, the whole file plays just fine with the latest version of media player classic.

[Assault]

@ sapient

It seems you are the third person that has found this bug within the last two days. Read those threads for further information. ;)

thread 1 (http://forum.doom9.org/showthread.php?s=&threadid=69582)
thread 2 (http://forum.doom9.org/showthread.php?s=&threadid=69728)

Assault

[nanga parbat]

Niltze!

Loking good here so far...

Just one small thing - I was running a second pass with no b-frames and not using quant 1. Quant ranges were 2-3 for i-frames and 2-4 for p-frames, so 2-4 in total.
Now status window showed sth. like 2.50 in avg quant for i-frames and 2.25 for p-frames - which both are right - whereas total avg quant reported was like 1.34 - which is wrong.
Sorry for not giving you exact values, 'auto-close window' was turned on.
Seems like it's calculating a wrong value for total average...
Surely not a problem, just that you know of it.

[edit] Also avg framesizes get calculated wrong: 27166 avg for i-frames, 11980 avg for p-frames and 6512 avg total.
Seems to me like quant 0 or framesize 0 for (not used) b-frames get somehow taken into account.

Guidance, nanga.

[jkwarras]

Originally posted by sysKin
This was a perfectly good start for a perfectly good encoding session, or at least that's all I can tell from what you said.

Next time i will keep my mouth closed. i've run the second pass again and turn just perfect and hit the exact target size. I really don't know where my ideas come from.

Don't confuse people with posts like that. Finish your move and if it is wrong, oversized or something, *then* tell us.

Sure. You're right. Sorry about that.

BTW. Excellent work! My encode looks really great with this build.

Just a suggestion: This would be nice if it was possible to adjust the film effect (in the decoder) like in ffdshow or DivX (a slider for ex.). Decode works good for me in MPC, for this 3 b-frames and packed bitstream enable encode (in an avi).

[crusty]

PS2 - In "Max consecutive BVOPs" I put 10 but it only used a maximum of 2! Anything wrong?!?

The codec makes an intelligent (ahum) decision about when to make a frame a b-frame or a p-frame.
You can basically tell it that it can use 1000 in a row if it wants to, but if it doesn't need more than 2 you won't get any more.

[Gazza]

Please below the results from my first test of XviD-1.0-RC1-25012004;

First I hit Load Defaults and then set the following;
Qpel on, Packed Bitstream Off, 2 Bframes, Mpeg, Chroma Motion, Turbo all other parameters are default.


Results;
Target file size 1,318,285 (2 cd's)
File size achieved 2,089,150

This represents a file over sized by 770,865. After the encode, I noticed that I had profile AS @ L5 set. This profile is set as a default.

I haven't had this problem with beta 1,2 or 3 with profile 'unrestricted', so I am assuming that the profile 'AS @ L5' is what is causing the file size blowout.

Testing again with the 'unrestricted' profile (can you make that the default?). Does anyone know if there is a problem with 'AS @ L5'?

Gazza

[Human_USB]

I don't think it's just AS @ L5. I had a large size differents when using Quant 2 and 1.


In my post on the second page;


I loaded up a 30 second video and set the Kbps to 10000 and encoded. Below is what I got;


Min I, P, B 1 - Video size 9.46MB, 403Kbps
Min I, P, B 2 - Video size 2.53MB, 108Kbps



I don't know if they want it to balloon so much or it's just a careless bug. I have yet to read pass page 5, so I don't know if the problem has been addressed yet.

-Jason

[Manao]

Gazza : Is it possible that you made a mistake while setting up the codec ?

If not, could you tell us the movie on which the test was made, its runlength, the resolution to which you encoded, and if you used different zones.

[Gazza]

@ Manano,
I checked back to the codec settings and they look good (except for using the profile AS @ L5). I don't think I made a mistake.

The test was 'Signs' which is quite a dark movie. Runlength is 1:42.08 (from the encoded avi), encoded resolution is 704*368. I used the default zones settings which where frame # = 0, Weight/Quant = W 1.00, no modifiers.

edit - I also had Turbo switched on

[Human_USB]

Just change the I, B, and P Quant to 2 and your video will encode fine.

[Gazza]

@ Human_USB,
Of course. I will test again. Can I suggest that the these settings ('unrestricted' profile, I, B, and P Quant set to 2) be the defaults in the future to prevent potential problems?

Thanks for your help here.
Gazza

[iago]

Gazza,

Read my previous post in this thread. I'm almost sure that your first pass size (you can check it out with StatsReader2.1 that comes with XviD) is lower than your target size. In other words: saturation!

In this case, quant 1 frames are used to compensate for the undersize and reach the target size, which produces hugely oversized files with the default overflow treatment values (5/5/5).

Change the overflow treatment values to something like 10/20/20, leaving the quant ranges at the defaults 1-31, and do your second pass again. You'll see that you hit your target size accurately, the only difference being the use of quant 1 frames in your encode.

It has got nothing to do with 'AS @ L5' profile.

regards,
iago


edit:

Human_USB,

If the problem is saturation in Gazza's case (I think he'll confirm it soon), capping quants 2-31 will only lead to an undersized file this time!

If not, there's something completely different going on then... ;)

[seewen]

Just to say that I always used AS @ L5 profile (don't know if it changes anything), 2/3 B-frames, Packet Bitstream, VHQ 1 or 4, Turbo, Adaptative quant or not, Chroma ME, Chroma Opt, Cartoon or not, Trellis or not, Min Quant 1 or 2, H.263 or HSV-better/good matrixs.

I tried with 1 Zone of W 1.00 or Differents Zones (With constant Quant, 0.5 W, etc.. ).

I often used the "Quant 2 Zone trick" for the first pass.

I aimed differents bitrate (between 500 and 2000 ).

And XviD ALWAYS reached the correct size (700 Mb, 1400Mb, 2000Mb).
(I tried with 10-12 differents movies. Not small clips. 1h30-3h00 long movies).
---------

I must add that my KISS DP-450 player played the content perfectly. Even with "unrestriced profile" (but again.. does it change anything?).
In fact with the new builds (RC1 & gamrdev builds) the FF/FR feature of the kiss works LIKE WITH DVD !! It's excellent !

I don't know why I had problems with Beta 3 and some movies.. I maybe used a damaged CD-RW or something.. :o


And bravo for the speed. With my P4C, it's not unusual to reach 70fps during 1st pass ;) ( 2-10x more than DivX 5.1.1, for a better result (smaller filesize, same/better quality)

[Gazza]

@Iago,
Thanks for the advice. I have set the overflow treatment values to 10/20/20 and reset the quant ranges back to the defaults of 1-31. I will have to do the first pass again as I had already started a retest with quant values 2-31 and the original stats file was overwritten.

I will let you know my results when finished (which takes about 9 or 10 hours with a 1GHz pentium)...

Cheers

Gazza

[DevilsChild]

Originally posted by crusty
The codec makes an intelligent (ahum) decision about when to make a frame a b-frame or a p-frame.
You can basically tell it that it can use 1000 in a row if it wants to, but if it doesn't need more than 2 you won't get any more.

Is this really true? I've always heard that you shouldn't use more than 3 or 4 max consecutive b-frames.

[sysKin]

Originally posted by DevilsChild
Is this really true? I've always heard that you shouldn't use more than 3 or 4 max consecutive b-frames. Crusty's "ahum" explains that. The decision is smart but not smart enough, you sometimes have to prevent stupid decisions by setting max to 2.

BTW if you want to have more b-frames, use b-frame sensitivity in zone settings. Try 10 or 20 and you'll get more b-frames (great for end credits).

Radek

[JJ2335]

Hi! Thought I might put in a request and share the latest finidngs on this issue.

Flip video occurs with XviD 1.0 RC1-B3 + Dvobsub 2.23. As stated the flipped video is limited to dvobsub usage regardless of container in question (avi, ogm, mkv). Versions prior to XviD 1.0 clearly had no flip issues. Bottom line check your filters; MPC can state filters loaded also look for the green arrow task tray icon.

I have graciously forwarded gabest, developer of vobsub of this issue but he has yet to reply. Many changes have been made in XviD 1.0. Is it possible a fix or workaround be made by the developers instead?


Keep up the great work!

[sapient]

@assault

I read the threads you quoted. Now, If *you* 've read my post you would see that the circumstances are completely different. So that's why I think this is a new one.

[Gazza]

@ iago,
I terminated the second pass as the finished file size reported by VDubMod was about 2300mb after 40 minutes into the second pass. For this test, I had returned the min/max quant's for I,P and B frames to 1-31 and set the following;

Overflow control strength (%) - 10 (default was 5)
Max overflow improvement (%) - 20 (default was 5)
Max overflow degradation (%) - 20 (default was 5)

There must be something else at play here. What other information can I give that could help finding the problem?

Gazza

[Koepi]

Gazza:

a second pass always reports weird things. You can stop it if you already have 1GB after 40% of the movie, but only because reported estimated filesize shows 2GB there isn't necessarily anything wrong.

So please finish the 2nd pass completely and see for yourself.

Another thing, did you set any quant zones by any chance? If you do a first pass at fixed quant 2 and forget to reset the zone to be a weight zone on 2nd pass, the file will be identlical to the first pass....

Regards
Koepi

[Gazza]

Hi Koepi,
I agree that the second pass can throw up some weird results. I tried un-installing RC1 and re-installing Beta 3. I ran this for about 30% and it seemed to be hitting the correct file size. The overflow controls where 5/5/5 (default) and the quants where capped at 2-31 (default for beta 3).
I then un-installed Beta 3 and re-installed RC1. This time the overflow controls where 5/5/5 (default) and I changed the quants to 2-31 (the default values are 1-31 for RC1). I have ran about 5% but these early observations are identical as to those I saw for the test with Beta 3. I will continue the test to see what the end result is but my gut feel is that is will be OK. Therefore (at this early stage) it looks as if quants capped at 1-31 will give you overlarge files and the default values should be 2-31.

[Ark]

Hi all!!

this is my first post in this great forum that helped me a lot of times, so thank you all for your great help!!

(and sorry for my so-so english :) )

I want to report that on my comp seems that the 1-31q oversize problem seems to exist only at times.

I've made a test with LOTR Extended Edition (of which i made a backup with every new beta release :) ),only the first disc, with the same settings:

- Default profile (AS @ L5)
- Adaptive quantization
- Qpel
- Default B-VOP (2/1.50/1.00)
-------
- some zones for start credits, and for the movie: Weight 1.00 (of curse :) )and Chroma Optimizer
- Motion Search Precision 6
- VHQ 4
- Chroma Motion
- Trellis Q

only changing the quantizer range at 1-31 for first encode and 2-31 for the second, aiming for a 795mb Xcd with Ogg vorbis audio @ 2.00q.

Overflow at default values.

The AVS used is very simple:

source = Mpeg2Source("C:/...../LOTR.avs)
return source.Crop(2,78,-2,-78).Lanczosresize(640,272).Undot()

The target video size is 747123 kbytes.

The result was:

1st encode (Q @ 1-31)= 747030 kbytes
2nd encode (Q @ 2-31)= 747024 kbytes

...so the target filesize is reached successfully on both encodes!

but, with other little tests with some DV footage captured I got heavy oversized files, something like 150%-175% of a 2-31Q encode with same settings...

Sorry for the long post, I hope to be of any help for you developers, and keep up with the fantastic work on Xvid!!

[Jaw3000]

As I have posted before, I too am getting oversized files. I've tried encoding some DVD Backups of Italian Job and Tomb Raider 2 as well as a TV show I've captured, and have gotten oversized files (of about 2GB when I set it to 698MB) with both beta 3 and RC1. I used the standard default profile.

I've tried encoding the above movies again once with "Discard First Pass" off, and it seemed to produce undersized files. I'll now try the Italian Job again with both "discard first pass off" again and with Quant set to 2 instead of 1. Compressibility test did finally work when I turned of "Discard First Pass." I wonder what will happen if I use "Discard First Pass" off and Quant 2 or just quant 2? Maybe I have to run it twice for both settings! As a newbie, do I set every Quant that's currently 1 to 2? Anyway, I'll post the results tomorrow.

Btw, how does setting Quant from 1 to 2 affect the image quality?

Koepi: Have you (or the Xvid team) figured out what's causing this phenomenon yet? Has a definitive fix been found yet? I've seen things here and there on the forums (such as doing the above), but it's always nice to hear it from the source! :)
-Jaws

[Ark]

In my test of LOTR_SEE, the encode with quantizer range of 1-31 looked slightly better to my eyes, I mean a very very little less mosquito noise around edges and a bit less blockiness on backgrounds and on fast moving objects

[Assault]

@ sapient

Just wait for the next release or even better try gamer's (http://xvid.gamrdev.com/) latest build and report if your problem still exists.

Assault

[m0rtal]

about new bitrate calculator, embedded in xvid...
it's cool, thanks a lot, but why there is only avi and mp3?
what about mkv, ogm, ogg, mp4, etc...?

[bond]

Originally posted by m0rtal
about new bitrate calculator, embedded in xvid...
it's cool, thanks a lot, but why there is only avi and mp3?
what about mkv, ogm, ogg, mp4, etc...? because i guess it would bloat the whole thing, avi+mp3 is still the most widely used combination
it would be pretty much work if you want to calculate all possible combinations with avi, mkv, ogm, mp4 + possible audio formats: vorbis, aac, he-aac (mutlichannel maybe makes a difference), mp3, ac3 aso...

[Leak]

Originally posted by Assault
Just wait for the next release or even better try gamer's (http://xvid.gamrdev.com/) latest build and report if your problem still exists.

By the way - does the xvid.ax that comes with Gamr's builds work for anyone? It hasn't been working for me for a while now...

(I meant to say the installer reports "Unable to load xvid.ax", and regsvr32ing it manually does work, but at home ZoomPlayer then used the vfw wrapper for XviD and at work it just crashes... of course, installing sysKin's bugfixed version works, but I guess it wouldn't hurt if Gamr's builds would ship with a working decoder... :))

np: El-P - Deep Space 9mm (Fantastic Damage)

[sysKin]

Originally posted by m0rtal
about new bitrate calculator, embedded in xvid...
it's cool, thanks a lot, but why there is only avi and mp3?
what about mkv, ogm, ogg, mp4, etc...? Add it add it add it! :)

I wish I knew how to add it :(

[m0rtal]

bond ok than, maybe devs should allow us to enter audio stream size using "open existing file" option - right now I can insert mp3 files only :(
but I don't use mp3 at all, I use Ogg Vorbis only...