1.0final release problems, suggestions and solutions

[Koepi]

As the title says, since the announcement thread is a huge "thank you" collection which is nice that way, some users don't want to ruin that thread.

So if you have issues not discussed in crusty's FAQ, not solvable with a little search effort and a little usage of common sense, feel free to post here ;)

Regards
Koepi

[sysKin]

If you've got playback problems, make sure to tell us what decoder is being used (no, there is quite a chance it's not xvid).

If you experience crashes with explorer.exe on winXP, just help us trace it. We know it happens for some people, but we don't know why, just saying that it happens to you is not helping.

VBV control, VHQ5, better GUI, directshow encoder, etc, etc, will happen when someone codes them. We know you want them, and we need them to take over the world as well, but someone has to do the coding.

OK, I run out of ideas - your turn to do some posting. :D

Radek

[virus]

...ok, let's start with a "solution"... :D

Remember the problems with seeking in MP4 files reported for RC4 (and confirmed by bond, thx for taking care!)? Yeah? No? Well, it ain't important. They seem completely solved now (checked with graphedit & MPC). Support for mp4v seems perfect now. Thanks for the fix!

cheers :)
virus

[maciek_m]

I have already asked the question, but got no answer. Is there a reason why in setting the bitrate for second pass and using the ogm container format and the ogg audio format and choosing the "size" option for selecting pre-compressed audio file, ogg-type files are not included among the audio ones (you have to select "all" to get access to ogg)?

It's a minor though, I'm fussy becouse I like ogg so much.

[atreya2011]

Although this is not an XviD problem, I was trying to find an answer to this but it has been completely ignored.

Here is the thread (http://forum.doom9.org/showthread.php?threadid=74731)

[sysKin]

Originally posted by maciek_m
Is there a reason why in setting the bitrate for second pass and using the ogm container format and the ogg audio format and choosing the "size" option for selecting pre-compressed audio file, ogg-type files are not included among the audio ones (you have to select "all" to get access to ogg)?Eh no, someone just missed it. Easy to fix...

Radek

[SeeMoreDigital]

I realize many people on the forum tend to use ffdshow for playback instead of XviD own decoder. But I just wondered if maybe some other features could be added anyway. Such as: -

* An interlacing/de-interlacing mode
* An aspect ratio 'output' setting (auto / 4:3 / 16:9)


Cheers

[gatormac]

Originally posted by sysKin
VBV control, VHQ5, better GUI, directshow encoder, etc, etc, will happen when someone codes them. We know you want them, and we need them to take over the world as well, but someone has to do the coding.

I would be interested in seeing what gruel is working on regarding VBV....do you guys map out code with flowsheets or do you just shoot from the hip?

[Soulhunter]

About the decoder...

Remember the old "blocky red" issue ???

I for my self have no problems with this anymore coz my GC takes care of correct chroma upsampling.

But after cabining a PC for my dad from some of my outdated equipment this issue returned...

Btw, this PC has a old GF2 model as GC n' WinXP as OS !!!

After installing the XviD codec (RC4) all files where decoded with wrong chroma upsampling...

With ffdshow they look perfect (right upsampling) !!!


Guessing...

While ffdshow uses WMR9 for rendering, the XviD decoder uses not !!!

When my guess is right, could you add a checkbox to make use of WMR9 ???


Bye

[Magno]

I have a question.... why has "deringing" been deleted from the postprocessing options in the decoder? I think it was a great improvement to the final quality of the video. Only was an opinion.

And last, but not least, i have a doubt since i begun coding with Xvid; whenever i code a movie from a DVD, despite of the bitrate i use to encode, i always get distortioned border in blue and red surfaces. I attach here a sample where you can see what i say; see carefully the horizontal lines that appear as you approach the border of the suit.

http://magno.nekein.com/simpson.jpg

I thought it was codec fault, but it seems that it has nothing to do with the version... BTW, i encoded the same video using DivX, with the same filters, the same resolution and the same bitrate, and i got smoothed and good-looking borders. I think it is the same problem SoulHunter said about the "blocky red" issue, but instead is the "blocky blue" issue ;)
My decoder is Xvid, though I have used ffdshow too, but this last showed too many big blocks in the video (and yes, it was properly configurated).

[Sharro]

God shall curse anyone who posts about problems without running at least 3 searches on different words relative to their problems.

Sharro

[Doom9]

I have a question.... why has "deringing" been deleted from the postprocessing options in the decoder?To my understanding that option never worked in the 1.0x decoders.. so removing it makes sense as people kept asking about it. I think it'll be back in the 1.1 releases, but this time checking it actually does something.

[Teegedeck]

On behalf of vispgraedde, who posted about his problem in the release-thread, I'd like to ask if XviD can be brought to completely ignore in 2nd pass the b-frame options set in the GUI as frame decision is made in 1st pass anyway. ATM changing b-frame settings between passes (which is of course a no-no) simply triggers a division-by-zero.

[xygenix]

Unfortunately, I have a small problem with playback.

http://webhome.idirect.com/~hbyun/xvidmz1.jpg
http://webhome.idirect.com/~hbyun/xvidmz2.jpg

Above clip plays fine with Nic's standalone decoder, but it shows blocks and smudges when playing back with the decoder included with Koepi's 1.0.
All other XviD clips played fine. :)

[celtic_druid]

Been covered before, but... your vertical res is 360 which is not mod 16. Adding a bitstream version header of XviD0001 should sort it.

[virus]

Originally posted by sysKin
VBV control, VHQ5, better GUI, directshow encoder, etc, etc, will happen when someone codes them. We know you want them, and we need them to take over the world as well, but someone has to do the coding.
ok, I took the challenge and finally managed to d/l some msys & nasm goodies in order to compile the puppy. I've immediately started hacking the GUI to add that "log stats to file" option I'd really love to see in XviD.
Things went quite smoothly but right now I need help. How can I retrieve the PSNR for the current frame? I recall that hacking the "stats" field here:

xvid_encore_func(codec->ehandle, XVID_ENC_ENCODE, &frame, &stats)

can do the trick, but right now xvid.org (together with the API quick reference) is down and I can't figure out what to set here. Some help anyone? :D

virus

[sysKin]

Originally posted by xygenix
Unfortunately, I have a small problem with playback.

[...]

Above clip plays fine with Nic's standalone decoder, but it shows blocks and smudges when playing back with the decoder included with Koepi's 1.0.
All other XviD clips played fine. :) Like celtic_druid said, it's a known and difficult problem. Very old XviD versions did three things: did not support non-mod16 resolutions, did not identify themselves as XviD and did not encode non-mod16 resolutions correctly.

XviDs that are simply "old" can be identified by their mpeg-4 userdata string, and a workaround can be applied. The ones that are "very old" can't be identified, so XviD decoder has to assume they are just some unknown mpeg-4, and normal ISO-compiliant decoder is used.

In theory, it is easy to add this userdata stream - just 12 bytes to the beginning of first frame. However, there is no program that can be simply hacked to add it... esby is currently working on a solution, if it works, you'll just have to re-mux the avi with the right tool.

I have a couple of videos like this myself, and I spent some time to create one keyframe, fake the bitstream number and append the rest of the movie to such keyframe. Worked.

Radek

[iradic]

hi

i was using ".video.pass" to definge pass file location (to put it in the same dir as source) - is this legal?

if it is it's not working as it should be ... just try to set custom-matrix and load one -> encoder will put pass file in matrix dir not source dir... though it did encode (dont know how) when set to do 2pass enc with avs2avi - doing just 2nd pass wont work ("stats file not found")...

bye

[snorre]

I still have trouble with XviD 1.0...

http://asylet.org/VirtualDubModGCS0001.png

As toy can see, the chroma-signal is 1 frame ahead of the luma-signal... The image is 544x400 (wich is mod16 compliant). The movie was encoded and decoded with XviD 1.0 final. Is it because of the Kernel Deinterlacer option in GK (v0.28.8)?

[Koepi]

That's no codec error, try another codec and you'll see. It might be your kerneldeinterlacer.

Koepi

[snorre]

Originally posted by Koepi
That's no codec error, try another codec and you'll see. It might be your kerneldeinterlacer.

Koepi

True... I was thinking correctly, but though of the wrong solution... I had this problem before, and recalled mod16 being the solution... WRONG! It was the "crop by 4's"...

Remember that kids, CROP BY FOURS!

(Dons the DUNCE-hat and sits in the corner...)

[jon.schaffer]

Hi,

I'd like to suggest a feature for the next releases (Hey... I assure you I'm not complaining about anything ;) - I'm a recent, but more than satisfied, XviD user...).

Can we imagine an "improvement" of the Zones Options great possibilities? I.E. can we imagine settings like Q-pel, Adaptative Quantization, maybe even Cartoon Mode? (I saw this request with the example of movies such Kill Bill which present cartoon sequences)

Indeed, these settings (I especially think to Q-pel and AQ) are globally very interesting, but I often encountered particular scenes in many movies which did not fit to these options... this could be avoided by disabling a particular setting in a particular zone...

I don't know if this is technically possible (IIRC, for example, a movie-segment with Q-pel can follow a segment without Q-pel...).
I don't know either if such possibilities would be used by most users... this could be boring for certain to set more than 2 or 3 zones in a movie... Or... we could see the opposite: I would be too lazy to join several sequences of a movie, each encoded with particular settings!
Maybe, also, the MPEG4-compliance is more important and would be broken by such an option?
In the end, maybe is it too heavy: it would imply too much modifications (almost everything would be based on this Zones...)?

Anyway, I think it would make XviD even more powerful, and that's the reason why I allowed myself to make this suggestion...



Thank you all (Devs and Doom9-Forum Members) for your great work,

Jon

[Koepi]

Originally posted by jon.schaffer
[...]Can we imagine an "improvement" of the Zones Options great possibilities? I.E. can we imagine settings like Q-pel, Adaptative Quantization, maybe even Cartoon Mode? (I saw this request with the example of movies such Kill Bill which present cartoon sequences)
[...]

Hey jon,

some of those options can make it into zone options.

There's a problem though: I don't think that these "more important" options are found by everyone who's looking for them anymore if they're in the zones setup.
(We're getting closer to the general GUI overhaul, aren't we? ;) )

QPel can't be a zones feature though, it's like "modulated quant", it would result in an non-mpeg4-compliant bistream.

Adaptive quant and cartoon mode should be possible to move into zones. Also things like trellis quantisation and amount of bframes. It's really much work though as the encoder structure has to be greatly modified for that (namely the API and the encoding queue).

Let's see what we (sysKin? are you there? ;) ) can code into 1.1 :)

Regards
Koepi

[P0l1m0rph1c]

I recall sysKin putting a 'cartoon mode' in zones, when someone asked him...

[Zep]

Originally posted by Koepi


Let's see what we (sysKin? are you there? ;) ) can code into 1.1 :)

Regards
Koepi


is 1.1 gonna save the 2nd pass stats to disk so we can
have fun seeing with our cool graphing apps what and where
Xvid did stuff? :D

Is there a way to get the current 1.0 2nd pass stats to save to disk?

[virus]

Originally posted by virus
How can I retrieve the PSNR for the current frame?
I'd like to rephrase that... :)
Whenever I ask for SSE computation (enabling the XVID_VOL_EXTRASTATS vol_flag for the current frame in vfw/src/codec.c) I get a crash in xvidcore. What am I doing wrong? :(
I think I'll release my "log-everything-to-file" patch without PSNR functionality for now ;)

virus

[Lord_KiRon]

May be it's a newbie question but I have something strage , I descided to make some RIPs from NTSC DVD 16:9 source (some series) , usually I do "Full Recompress" in VDub , however this time I decided to do "fast recompress" (I understend that if I do not need filters it preserves quality better).
Well the result was strange , no matter what bitrate I set each file always result in different bitrate far lower then the one I requested.
For example I set 1000kbps and get one file 900 another 680 and another 830 ... (set 2000, 3000 - the resulting files same have bitrate/file size :confused: )...

Is it strange or not ?

I haven't tested yet with prev. version of XviD and did not tested with "Full recompress" yet , I will later today , but for me is very strange .
Btw: the quality of resulting encode is still very good. :confused:

[sysKin]

Originally posted by Koepi
Adaptive quant and cartoon mode should be possible to move into zones. Also things like trellis quantisation and amount of bframes. It's really much work though as the encoder structure has to be greatly modified for that (namely the API and the encoding queue).

Let's see what we (sysKin? are you there? ;) ) can code into 1.1 :)
Actually, the number of b-frames cannot, because it's something that is needed to know during codec's creation (xvid allocates memory for "maximum" number of bframes).

As for everything else, yeah, it can be moved to zones, and doesn't even involve API change ;) Just vfw dll change.

In fact I was thinking that all these options should be available in some "general" tab, and zone options can set them to something else or just leave unchanged ("grey tick" if you know what I mean).

Radek

[Zep]

Originally posted by sysKin
Actually, the number of b-frames cannot, because it's something that is needed to know during codec's creation (xvid allocates memory for "maximum" number of bframes).

As for everything else, yeah, it can be moved to zones, and doesn't even involve API change ;) Just vfw dll change.

In fact I was thinking that all these options should be available in some "general" tab, and zone options can set them to something else or just leave unchanged ("grey tick" if you know what I mean).

Radek

yes keep them global but the zones will override with its their own settings.

That is the way to go IMHO :D

[M7S]

In syskin's sign
1.1 bugs invented so far:
- better SKIP decisions make walls move less and prevent some rare b-frame artifacts
Is this as great as it sounds? :)
If the moving walls are more or less gone, nothing can stop Xvid from world domination ;)

EDIT: typo

[Leak]

Originally posted by sysKin
Actually, the number of b-frames cannot, because it's something that is needed to know during codec's creation (xvid allocates memory for "maximum" number of bframes).

True, but you could still impose a hard limit on the number of B-frames using zones that is lower than the global maximum number - this might be more intuitive than the B-VOP sensitivity as it'll guarantee there won't be more then n B-frames in a row. Of course, this would probably also mean that the zone must start with a P- or I-frame, but that shouldn't be a problem, right?

np: Autechre - Ccec (EP7)

[Leak]

Originally posted by Lord_KiRon
Well the result was strange , no matter what bitrate I set each file always result in different bitrate far lower then the one I requested.
For example I set 1000kbps and get one file 900 another 680 and another 830 ... (set 2000, 3000 - the resulting files same have bitrate/file size :confused: )...

This just means that the encoder was "maxed out" with your video, i.e. unless you up the resolution, do less filtering on the source, choose a matrix that keeps more detail, use no B-frames or do something similar, the codec just can't produce a bigger file as it has already compressed the video with the highest quality possible...

I'm always wondering why people always seem to think of this as a problem - it just means that with luck you can fit more episodes on a disc (of course, I'm talking about DVD+/-R[W] here), or extra material, or whatever. No harm done IMHO if the file doesn't hit the target size. :) (Maybe adding a note to the "target size" box tooltip that explains this might be a good idea?)

For example, when encoding the first DVD of Witch Hunter Robin, only one of the five episodes hit the 170MB limit I set, while all others came out at 120-130MB (with 128kbps CBR MP3 audio), as there just weren't enough high motion scenes in these. Still, that meant that I didn't even have to run a second pass (as a kept full quality first pass equals an encode with fixed quantizer 2) and I can up the target size for other episodes that exceed the 170MB size limit in the first pass...

So with a bit of maths, you can take a 26 episodes series, run a fully-quality first pass for all episodes (and of course keep the files it produces), do some simple calculations and add the space you've gained by undersized files to the target size for the episodes that weren't undersized --- which gives you a quality gain with almost no extra work... plus you don't even have to run a second pass for all episodes. :)

np: Funkstörung - Disconnected w/ Enik (Disconnected)

[Lord_KiRon]

Originally posted by Leak

I'm always wondering why people always seem to think of this as a problem - it just means that with luck you can fit more episodes on a disc (of course, I'm talking about DVD+/-R[W] here), or extra material, or whatever. No harm done IMHO if the file doesn't hit the target size. :) (Maybe adding a note to the "target size" box tooltip that explains this might be a good idea?)




Well usually I am OK with detecting when codec "maxed out" , however this time it was veried to get a 16:9 42min DVD encoded to 580x288 (or something like that , mod 32 on x , mod 16 on y) with 72MB of sound into 670kb/s 280MB AVI.
So I got scared :)

Well , anyway , so I can "push" more quality now disabling "chroma motion" , right ?

[Leak]

Originally posted by Lord_KiRon
Well , anyway , so I can "push" more quality now disabling "chroma motion" , right ?

I doubt it - Chroma Motion means that XviD not only takes luma into account when looking for motion, but chroma as well. Sure, it might increase your file size if you disable it, but I doubt it'll mean better quality.

Try disabling GMC and B-frames or switch to an MPEG matrix.

EDIT: really meant file size there...

np: Lamb - Gold (Lamb)

[Lord_KiRon]

Originally posted by Leak
I doubt it - Chroma Motion means that XviD not only takes luma into account when looking for motion, but chroma as well. Sure, it might increase your file if you disable it, but I doubt it'll mean better quality.

Try disabling GMC and B-frames or switch to an MPEG matrix.

np: Lamb - Gold (Lamb)

Thanks , sorry I took this descussion completely off topic , but I have GMC and QPel disabled and MPEG matrix on , BFrames >= 2 That's why such small file size surprized me so much...
So the only thing I can do is to set B-Frames to 1.

[Zep]

Originally posted by Lord_KiRon
That's why such small file size surprized me so much...
So the only thing I can do is to set B-Frames to 1.


or force b-frames to a lower Q value. On under sized file
The default is

I=2
P=2
B=4

I force mine to

I=2
P=2
B=2

when file is undersized and i do not what to increase rez
and where dropping the number of b frames would cause a Q
average to go above Q=2.

The middle ground is to keep your b-frames but adjust their
quality.


IMHO of course :D

[pogo stick]

Originally posted by Lord_KiRon
So the only thing I can do is to set B-Frames to 1.
You can run second pass again with all min quantizer=1 to increase filesize.

To get back to topic I have a little suggestion:
When 1.1 decoder (with deringer, brightness) will be stable enough, it can be released as separate update for 1.0 version. I tried substitute xvid.ax from Koepi's compil with xvid.ax from Gamr's XviD-pentium4-200404302056 compil. Deringer, brightness works if I configurate it before opening video, but decoder configurator dosn't show up in filters properties. And video plays slowly, with pauses.
By the way, the same thing happens if I add Koepi's xvid.ax to Jawor's compil. So, I am thinking, am I doing something wrong?
ffdshow is what I use usually, but XviD decoder's postprocessing would be nice. :)

[DarkDudae]

I just want report some issue with XviD bitrate calc.

It is regarding Overhead calc for MKV container. I have been revising the code, and I found that an overhead of at least 300KBytes is allways added. If you want to encode a clip of 200KBytes... the calc would suggest a final video size of at least 500KBytes. It is a minor "bug".

About overhead for AAC audios in avi files, I gave syskin the correct formules. It would be a good add for next versions since a lot of people is using great AVIMUX for muxing aac audios into avi files.

(OFF Topic: thanks for this final version 1.0)

Greetings

[steelman]

Hello.

Sometimes I lost sense of this forum so if this was answered before don't beat me.

Will there be again in decoder options brightnes slider?

[Koepi]

Even if you don't read the forum "every day" you're better off with... :search:

It's been asked and answered _very_ often.

Regards
Koepi

[Chainmax]

Originally posted by snorre:
As toy can see, the chroma-signal is 1 frame ahead of the luma-signal... The image is 544x400 (wich is mod16 compliant). The movie was encoded and decoded with XviD 1.0 final. Is it because of the Kernel Deinterlacer option in GK (v0.28.8)?

Originally posted by snorre:

quote:
--------------------------------------------------------------------------------
Originally posted by Koepi
That's no codec error, try another codec and you'll see. It might be your kerneldeinterlacer.

Koepi
--------------------------------------------------------------------------------



True... I was thinking correctly, but though of the wrong solution... I had this problem before, and recalled mod16 being the solution... WRONG! It was the "crop by 4's"...

Remember that kids, CROP BY FOURS!

(Dons the DUNCE-hat and sits in the corner...)
What do you mean with "crop by 4's"? I am trying to encode the same DVD. Check out the thread I posted a while ago on Avisynth Usage, it seems that the source is just FUBAR, with combing on the fields themselves and some more stuff.

[odysseus]

Koepi's 1.0 build, 0905
Virtualdub 1.5.10

players
tried MS media player 9
mplayer (win32, build mplayer-20031126.exe)
mplayer (Linux 1.0 pre3)


I've been observing some really strange things.
all of these encodings are dvd2avi --> vfapi --> vdub, using 2 pass.

Whenever I get an all-black video the filesize is less than 100k. while the correctly encoded file size is 20M.
For the blacked videos Virtualdub's File-->infomation shows the correct time length, shows that video is XVid, and the frame sizes are below 5k for keyframe & delta frames)

I encoded a test with packed bitstream off, the video shows up black. Turn packed bitstream on, video came up fine. Next recording, ONLY change was reduced bitrate by 100kbps (to see how much the quality suffered), video all black. Set bitrate back to original, video all black.

After screwing around with several settings The encoding works a few times. Then I turn on an option and the video comes in all black, so I think , oh, okay, that option makes the video all black ... turn that one option off (bringing the system back to a set of options that worked), and ... and the video is still all black.


I've gotten all black with these settings
Adaptive Q on or off
Qpel on or off
GMC on or off
packed bits on or off
(have not ever changed closed GOV)

This effect seems to be completely random.

I just (tried to do) another run. I encoded a 500 frame test clip to see if the encoding is working. It worked.

Then I changed the start and end frames to what I wanted (NO CHANGES TO ANY OTHER SETTINGS) and again it came out black. What I expected to be a 300 meg avi (60 minutes) is 44meg.

Can anyone suggest something else to try?
Should I post this on the vdub forum as well?

[odysseus]

Looking over the data I provided I failed to mention
Windows 2000 sp4

[Koepi]

Your first pass file is supposed to be black and small. It's for saving space.

Please read Doom9's excellent xvid-1.0 guide here: http://www.doom9.org/

You should also consider using avisynth instead of vfapi, vfapi is "forbidden" for more than 2 years now for proper encoding :) You'll find that on the Doom9 guides too.

Regards
Koepi

[Zep]

Originally posted by pogo stick
You can run second pass again with all min quantizer=1 to increase filesize.




overkill and your b-frames would be Q=3


IMHO do not ever do that. better to keep min quantizer=2
and force b-frames to Q=2

if it is STILL undersized so what? a file does not have to be
exactly 350 or 700 megs etc...

boost audio to 6 channel surround sound if you want a bigger file :D

[Zep]

Originally posted by Koepi


You should also consider using avisynth instead of vfapi, vfapi is "forbidden" for more than 2 years now for proper encoding :)

OUCH! :D

[odysseus]

I've successfully made hundreds of 2 pass encodings in the last 2 years.

I'm absolutely SURE I'm not confusing things on that point.

I tried avisynth about 8 months ago & got audio synch issues I couldn't get rid of on some Bollywood movies. Wasted several weeks tweaking & playing & eventually Had to come back to dvd2avi ---> vfapi ---> XVid.

I'll try again.

Originally posted by Koepi
Your first pass file is supposed to be black and small. It's for saving space.

Please read Doom9's excellent xvid-1.0 guide here: http://www.doom9.org/

You should also consider using avisynth instead of vfapi, vfapi is "forbidden" for more than 2 years now for proper encoding :) You'll find that on the Doom9 guides too.

Regards
Koepi

[odysseus]

Hello again.

I did some more test runs,
instead of my usual practice of saving the 2nd pass using the same name as the 1st pass (thus losing the 1st pass), I saved the 2nd pass under a different name.

results - 5 encodings (10 files counting both passes). 3 encodings were small (1000 frames), 2 large (50 minutes worth, 1st and 2nd half of an entire movie) all black (1st and 2nd passes).

This was the 1st time I've had all turn out black.

And the sizes of the 1st pass and 2nd pass were different but the differences were not large, like this for the 2 large encodings - (the GOOD version is 2nd pass)

22/05/2004 04:58a 13,649,920 LRG1-GOOD.avi
22/05/2004 04:26a 11,718,656 LRG1.avi
22/05/2004 06:02a 13,875,200 LRG2-GOOD.avi
22/05/2004 05:30a 11,909,120 LRG2.avi

I dont' know if this data will help anyone, the vdub job control tells me, but for these 4 files above

LRG1 1st pass 31 minutes
LRG1 2nd pass 32 minutes

LRG2 1st pass 32 minutes
LRG2 2nd pass 32 minutes

[odysseus]

a little clarification to the above post about the tests, these are the times that it took to do the encoding, not the length of the clip.

Can someone tell me How can I test if either of the following situations is happening ?

1. Virtualdub is "losing " settings (I'm thinking vdub is not setting up the parameters correctly for pass 2)

OR how can I tell if

2. XVid is remembering previous settings, or refusing to let Virtualdub set new settings for the 2nd pass?

[gatormac]

I seem to be having trouble getting anamorphic encodes to play correctly after encoding with the final version. I used to encode setting the pixel AR to 16:9 NTSC and still have those files and they play back perfectly, but when I try to encode with the 1.0.0 the playback remains squished even though I am encoding them with the same settings as before.

Is anyone else having this problem? I can produce log files, but my encodes are all pretty default otherwise.

[mikeX]

gatormac:

Do you happen to use the AVI container, for those encodes you are refering to, in combination with a directshow player (such as WMP, MPC, etc)?
If that's the case, then what you are experiencing should be normal!
Hacking Aspect Ratio information into AVI was not supposed to be a feature of XviD 1.0, but it somehow slipped through into a couple of Koepi's builds (latest RCs)! Normally that should be gone in 1.0 final (although I haven't checked myself, there is more information on the subject in some thread I'm too bored to look for atm).
The 1.0 decoder however supports the hack, so you will still be able to play those older encodes correctly.
If you want to make proper use of the Aspect Ratio feature of XviD 1.0, use a non DirectShow player (mplayer (www.mplayerhq.hu) for example).
If you prefer DirectShow players but still want to encode anamorphically, you can use the AR feature of the Matroska (www.matroska.org) container.

[gatormac]

Hmmmm....thats weird that they would add a function in an RC and not in the final. Why wouldn't they want to hack avi in that way? I guess its time to look at mp4 or matroska. Thanks for the info.

[celtic_druid]

My understanding is that "they" never added it. It was never in the 1.0 cvs branch. It just somehow ended up in Koepi's compile also only RC3 I think and not RC4.

The AVI should playback at the correct AR if you use mplayer or VLC.

[odysseus]

from vfapi and the problem seems to have vanished. No more random all-black encodes.

18 2 pass test encodes so far and all seem OK.

I just hope I don't run into the same audio sync problems I had last time. None so far, knock on wood.

[SeeMoreDigital]

Can we have an 'stream output selection mode', where by XviD can puke out an elementary .mp4v stream.

I realize most encoding applications will not allow this, so we would end up with 2 streams. One in .avi and the other in .mp4v


Cheers

[communist]

Except the jumping sliders in the GUI (which IIRC are M$ faults) no problems yet :)

[crusty]

I would like all people reporting bugs to read the sticky on top of this forum on 'How to report Bugs properly'. It will be so much more helpful if you actually supply us with enough information to give you a proper reply. Thank you.

@xygenix:
The first picture with the F-14 looks like typical GMC errors. Are you sure you are decoding with XviD and not with DivX?
Do the pixels swirl and travel across the picture quickly? Or do they just 'spring' into existence and slowly maim the picture, with the picture resetting itself after a while and then corrupting again?
Use a tool called DRFAnalyzer (Google for it) and copy&paste it's analysis here. (it's text-based analysis)
The first is usually a GMC issue while the second is more likely data corruption.

The picture with the carrier looks like the Simple/Walken ICDT issue.

@Soulhunter:

Your old Geforce 2 could be responsible for the chroma upsampling bug. It's a known issue with older Geforce cards.

When my guess is right, could you add a checkbox to make use of WMR9 ???
AFAIK, you can also set this in the options for both MPC and WMP 9.

@Snorre:
Can I use your picture in my FAQ? It's a nice example of filter issues.

@Lord_Kiron:
For example I set 1000kbps and get one file 900 another 680 and another 830
Could be simple saturation. The codec doesn't need more bits than that. But you need to give us much more information to expect a proper answer.
Give us this:
-Hardware specs
-Operating System with DirectX version and used Media player(s)
-General Info on the source (DVD, TV-capture, dark/light reallife/anime/disney/pixar, etc etc )
-Avisynth script
-XviD options used (at least ALL that are NOT default)
-ALL the tools you used throughout the proces WITH version numbers.

Some things to do if you get undersized files:
-Use Qpel. Might decrease or increase size but will always improve quality
-Use less filtering (avisynth or virtualdub filters) Take the ones that create the most artifacts out first
-Use a higher resolution (unless you're already at the original's resolution)
-radical: Use sharpening filter to increase the sharpness of the image. Even very low sharpening will increase size dramatically.


@Koepi:
Maybe a low priority, but perhaps a new decoder-only version? The latest you have on your website is a 1.0Beta-3, which is outdated by now.
Just to give people some more flexibility...a decoder-only XviD maybe just small enough to fit on a CD next to the avi (701MB avifile+ 500Kb decoder). Just some thougths...

@Chainmax:
What do you mean with "crop by 4's"?
IIRC, it's a requirement for using the 'decomb' avisynth filter.
That means that using MOD16 resolutions for MPEG-4 will always work with decomb as well, but that decomb will not always work with MPEG-4.
it seems that the source is just FUBAR, with combing on the fields themselves and some more stuff.
You can tell decomb to use a override file. You need to sift through the source using virtualdub(mod) and write down the frames that still look combed after decomb has done it's work in a text-file.
Then you can redo the pass, and tell decomb to use the 'manual overrides' from your textfile for the uncorrected frames. I've used it on NTSC DVD before and it works like a charm. BTW, NTSC is crap.
I pity Americans... :)

@odysseus:
You may have failed with avisynth before because your DVD2AVI version wasn't correctly matched with avisynth and vdub. I recommend the GordianKnot package, because the program versions in it behave well together. Just remember not to use the XviD codec from that package.

@MikeX & Gatormac:
http://www-user.tu-chemnitz.de/~noe/Video-Zeug/AVIMux%20GUI/en_myths.html

Myth:
"AVI does not support anamophically coded movies and storage of aspect ratios"

Fact:
"Totally wrong. The Open-DML AVI standard includes a VIDEOPROPERTYHEADER for video streams, which allows to indicate the output resolution in the sense of Matroska's DisplayWidth and DisplayHeight elements.

The problem is that DirectShow does not read those values (at least the DirectShow documentation does not mention support for this feature). But this is another flaw in Microsofts attempt to support AVI files. It is not a flaw of the AVI container."

Hope this helps some people...

Cheers,
Crusty

[gatormac]

@MikeX & Gatormac:
http://www-user.tu-chemnitz.de/~noe...I/en_myths.html

Myth:
"AVI does not support anamophically coded movies and storage of aspect ratios"

Fact:
"Totally wrong. The Open-DML AVI standard includes a VIDEOPROPERTYHEADER for video streams, which allows to indicate the output resolution in the sense of Matroska's DisplayWidth and DisplayHeight elements.

The problem is that DirectShow does not read those values (at least the DirectShow documentation does not mention support for this feature). But this is another flaw in Microsofts attempt to support AVI files. It is not a flaw of the AVI container."

I really don't care what container is used, I just want one that works. I'm not sure that avi will ever have anamorphic support with standalones so I am just encoding with square pixels for now.....otherwise I have no problem with avi.

[SeeMoreDigital]

Originally posted by crusty
@Koepi:
Maybe a low priority, but perhaps a new decoder-only version? The latest you have on your website is a 1.0Beta-3, which is outdated by now.
Just to give people some more flexibility...a decoder-only XviD maybe just small enough to fit on a CD next to the avi (701MB avifile+ 500Kb decoder). Just some thougths...

Cheers,
Crusty I like this idea. Would this mean we can freely distribute the decoder?

For some reason, the guys over at DXN don't like their DSdec filter being distributed. And your's works much better anyway :D


Cheers

[Koepi]

Taken the number "500kb", it would only be 113 kb less than the installer has now. I consider that small enough.

Btw., my 700mb rips still have plenty of space for an ac3-filter, oggds filters, xvid filters _and_ ffdshow (which I always pack on the cd in a "codec"-directory to make sure to be able to properly playback the content on that cd later.

(700MB CD-Rs usualy have space for 703 MB without any overburning).

I'll look into standalone decoder stuff if I find some time for it.

Regards
Koepi

[Valky]

Hey! This codec seems to do much better image and quality on the same movie and avs-script than the other famous codec I tried.
However filesize went little bit wrong only 691mb instead of 700mb.
So I would only like to ask if I can still use GKnot to calculate filesize or is there something changed in codec?

The other thing I would like to ask:

I use software called DRFAnalyzer to examine my encoded videos and it has worked very well so far. No I made my first encoding with this latest release and it shows that "Average DRF = 1 and dropped frames = 7" for this file.

Since this can't be true, I would like to know if anyone else who has used this software has noticed the same thing?
Seems to me that software was trying to rise this number at first, but then it just stuck on this one after these 'dropped frames'. Is there something changed in this codec, so that this tool can't be used anymore to analyze these files?

[powerslave]

Using the latest gordian knot (.28.8), i havent had any problems with the filesize estimation using 2 pass encodes. Make sure you get the latest Gknot. Last time i checked, the codec pack still didnt have the new 1.0, so install 1.0 after gordian knot.

[amango]

I have some problems with the current XVID 1.0.

Look at this two pictures:
Sample 1 (http://people.freenet.de/amango1/pixel-xvid1-sample.JPG)
Sample 2 (http://people.freenet.de/amango1/pixel-xvid2-sample.JPG)

Those flashing pixels can only be seen for one frame. Is this a bug?

My settings:
H263
BFrames (2/1.50/1.00)
Motion Precision 6
VHQ 4
Trellis On
Chroma Motion On
1-Pass Quantizer 3

[AS]

I was wondering would be possible to add the ability to insert keyframes via statreader and/or raise the limit for number of zones?

The reason being recently I found myself having to reinsert a lot of keyframes and particularly, number of quant 2 keyframes. Currently I am experiencing a limit of 64 zones in RC4, which I can only insert 63 keyframes at where I like. If I were to insert N q2 frames, I need 2N+1 zones.

If this limit was lifted in the xvid 1.0 final and then I apologise. Otherwise I would like to put down a much higher limit for number of zones as a suggestion for the future builds of xvid.

[Didée]

I assume it could turn out difficult, or even impossible, to raise the max. numbers of zones.

But, here is one suggestion I already thought of many times:

In the Beta releases of XviD 1.0, there was a 'bug' that made a zone to be encoded to only I-frames, if a zone's option "begin with keyframe" was checked.

Could this behaviour be brought back? So, in addition to "start with keyframe", make another checkbox "only keyframes".
For the cases when someone needs to force, say, 20 I-frames in a row, this would make things much easier, and moreover would keep much more zones "free" for other purposes, where they would be "eaten up" by all those 1-frame zones otherwise.

Just a thought.

- Didée

[AS]

That's indeed correct and is the current workaround I am using. I just open the respective stats file and simply copy the entries. The build was beta 2.

Nevertheless, I believe this option would be very helpful if made available in future builds.

[marcobdivax]

Hi.
I've an avi just encoded with the new release, but I've noted that if I enable B-frames (with default values) ffdshow plays it in "slow motion" (not so slow, of course); if I don't use B-frames, or if I use B-frames with xvid 1.0 standard decoder, all is well.
I know, I could use xvid... but ffdshow postprocessing is very helpful to me, specially for sharpening (videoprojector...) and deinterlacing (dv).
Any suggestion?
Thanks a lot, guys.
Marco

[Sharktooth]

You need a newer ffdshow (http://athos.leffe.dnsalias.com/).

[marcobdivax]

I've the last one from sourceforge... but it seems that if I turn off "Packed bitstream" flag, all is well.

[celtic_druid]

Unless things have changed, then the latest on sf is still well old.

[marcobdivax]

Obvious question...where's the site from which I can download a newer version?
Thanks
Marco

[springl]

Look at the post of Sharktooth (3 posts above your)
Greetings,
Springl

[Prettz]

Is there an ETA yet on a new official Xvid build with the trellis fix?

[celtic_druid]

Shouldn't be that long now I would not think as the cvs was marked 1.0.1 the other day.

[loni_blues]

Yes, and xvid 1.0.1 has been officially announced. Check www.xvid.org.