Hola! XviD-1.0-RC4 05.04.2004

[Sirber]

Originally posted by Soulhunter
- Maybe 1x DVD-R encodes are not good to test your encoding skills !!!

- Maybe 1x DVD-R encodes are not good for development as Koepi said !!!Maybe 1x DVD-R encodes are good to watch :D

[dandragonrage]

I get corruption in some areas when XviD decodes DivX. One of the files I have trouble with is DivX 5.02, the others are either 5.02 or 5.05. Sometimes I just get strange colored blocks. Sometimes it results in mega smearing-something will move and it will just make a really ugly trail across the screen.

I can take screenshots later this evening if needed. I'd have to uninstall DivX to do it and DivX is busy decoding right now.

[Soulhunter]

Originally posted by Sirber
Maybe 1x DVD-R encodes are good to watch :D
Of course they are... :p


Bye

[poochie2]

I was wondering if it would be so pointless the idea of a checkbox that, if enabled, allows the codec to write a very small text file in the selected directory that collects all the info such as set encode parameters and statistics (like the ones present in the status window).

Let me know, Poochie

[beezle]

My RJ1500 divx player does not support the new rc3/rc4 versions of xvid. It does however support the previous versions of the xvid codec. This sucks.

I can't believe the codec is so different that my player says "codec not supported"

I also can't believe that my player is already obsolete.

In a separate issue, when I open the avi in virtual dub, I get a message on the screen about b-frames and possible lag. If I am just using virtualdub (in conjunction with an audio decompressor) to change the mp3 audio from VBR to CBR, will my video be affected at all. I am guessing it shouldn't since I just have video set to direct stream. I saw some of the previously posted issues with virtual dub in this thread, but those seem to be related to encoding problems.

****Updated****

After further testing, it looks like the problem does not lie with the xvid rc3 codec after all. I will update as I find out more info

[beezle]

This person also seems to be having a problem with the new xvid codec on his divx player.

http://forum.doom9.org/showthread.php?s=&threadid=74752

[mikeX]

beezle:
The issue you mention with VirtualDub is a known one and should not worry you at all. The video does not get affected in any way, it's just a vfw limitation (?)
You can find more about it in previous threads...

About your standalone issue, what settings are you using with XviD?
The defaults (2 max b-frames e.g.) have changed since earlier versions of the codec. Tweak your settings in order to make your encode more DivX compatible (e.g. 1 max b-frame) and try if that's playable.
You may also find useful information in older threads and/or in the 'Hardware Players' section of this forum.
Don't underestimate the power of the 'search' button :)

[poochie2]

About the compatibility issue, I think it's something related to the codec itself. The change should have occoured between the last 1.0 beta and the RC1, as since then ffdshow had to be updated in order to correctly decode the video, and my ps2 movie player won't read them anymore... I'm about to bou a Kiss dvdplayer and I'm a king of worried about this issue :'(

[beezle]

I have read a suggestion that using 4cc to change headers might help if the standalone player is not recognizing rc3 or rc4 because of an unknown header. Is there a new header associated with the xvid codecs?

If so, what header changes would be suggested for best compliance?

Using nic's fourcc, I see there are two options, used codec and dscription code. Should I just change the description code to divx? Do I have to change the used codec to divx as well?

[lordadmira]

Originally posted by beezle
[B]My RJ1500 divx player does not support the new rc3/rc4 versions of xvid. It does however support the previous versions of the xvid codec. This sucks. You can upgrade the firmware. Check their website In a separate issue, when I open the avi in virtual dub, I get a message on the screen about b-frames and possible lag. If I am just using virtualdub (in conjunction with an audio decompressor) to change the mp3 audio from VBR to CBR, will my video be affected at all. I doubt the message had anything to do with B frames. Vdub can't process VBR MP3 audio. Even in direct stream copy. Split the audio, process the video with VDub like normal, then mux in the audio with NanDub. If u don't want to do that then ur gonna have to jettison avi altogether and use ogm or matroska. It's not a limitation of VFW per se, but the avi file container and specifically the RIFF header.

[RadicalEd]

Originally posted by lordadmira
I doubt the message had anything to do with B frames. Vdub can't process VBR MP3 audio. Even in direct stream copy. Split the audio, process the video with VDub like normal, then mux in the audio with NanDub. If u don't want to do that then ur gonna have to jettison avi altogether and use ogm or matroska. It's not a limitation of VFW per se, but the avi file container and specifically the RIFF header.

Er.. actually, xvid always displays this message (B-frame lag) when packed bitstream is off and the video is being read in through the vfw decoder :/

[dandragonrage]

No, there is a B-Frame lag message when you open files with B-frames in Vdub. It's not a popup, it is simply on the first frame of the video. It's the VfW decoder that does that. It means nothing, really.

Edit: Whoops, didn't see that we made a new page. I've been beaten to the point.

[RustyNails]

After upgrading to Hola! XviD-1.0-RC4 05.04.2004 I only get audio NO VIDEO!

Previously used version with no problem.
XviD [Koepi's build 24/June/2003] [Encoding]
XviD [Koepi's build 24/June/2003] [Decoding]



Have tried all settings (?) but still only audio.

What am I doing wrong?

[lordadmira]

I want to relate that I too have now experienced the "chops last few frames" bug/feature. I encoded a short clip with VDubMod and no filters or sound. 1824 frames on input became 1818 frames in the file. And again 2280 frames became 2275 in the output file. I can understand temporal filters eating frames but this is a vanilla encode eating frames. Anybody see this with other encoding apps?


LA

PS Just for giggles I reencoded the 2280 frame clip with MS-MPEG v3 and whadaya know. 2280 frames out. So it appears that in fact RC4 is eating frames all by itself. :devil:

[Koepi]

lordadmira:

i get the impression that you dislike reading. that point has been tracked down (several times on this very thread) to be related to the usage of a buggy vdub(mod) version (=user error). Stick with avs2avi or vdub(mod) versions 1.5.4.1 or earlier (the bug is: delay frames don't get properly interpreted in those higher vdub(mod) versions and thus to little frames get served to xvid and written back to the file).

Koepi

[lordadmira]

Ahh. Thanks. I did read back 1 page cuz I remembered that it came up but I didn't see anything about a resolution to it. The last I read it was unverified. We can't read everything each time we think our memory is working. :)

PS I went back and reread the whole thread from the beginning. There is in fact a serpentine explanation waaay back at the beginning of April. Far too long ago and nebulous to stick to my brain. :)

[bond]

latest virtualdub(mod) versions drop 1 frame when 2 b-frames are set, 2 frames with 3b aso...

lordadmira,
i assume you used a very high number of b-frames, right?

and yes avery leed knows about this problem, next vd should include a fix

[lordadmira]

Well I haven't seen a real correspondance between Bmax and the number of frames dropped. I've had Bmax set to 8 and 10 and the number of missing frames has been from 2 to 5.

[beezle]

Update

Earlier in this thread, I thought my standalone divx player had a problem with movies encoded in the new rc3/rc4 codec. I need to qualify that a little bit because I found out that some things encoded in the new codec play fine without any problems. As it turns out, it is only certain things which I think have too many b frames. It is only those things which give me the b frame lag error in virtual dub that are giving me problems on my standalone player. Here are some of the problems:

1) Won't play at all and says codec not supported (with QPEL, it specifically says QPEL not supported, so QPEL is NOT the issue)

2) Wrong colors. For example, everything has a blue shade and/or blue color

3) Garbled colors and shapes (picture not clearly shown). This is just too difficult to explain. I would have to post a sample, which I can't do at the moment, but let me know if you want to see a sample and I can put up a still image in a reply.

Everytime I see that b-frame lag error in virtual dub, it is guaranteed that I will have a problem on my standalone.

Somebody stated earlier that using one b frame is more likely to be compatible.

Is anyone else seeing this problem on their standalone?

How can I tell how many b frames were used to encode a particular backup file?

[mikeX]

beezle:
well if that's your backup you are talking about it's fairly easy if you remember which settings u used (for example, if you didn't mess with any BVOP settings then you should have 2 max consecutive B-frames.

If you can't remember, you might wanna try using ffdshow for decoding and turn on the OSD (specifically the part that displays the type of frame). You should then try and see if you can catch 2 B-frames in a row (I know this sounds stupid and there has to be another way, but I just can't think of one atm :rolleyes: )

You should experiment with small clips and various settings to see which ones work good with your standalone.
IIRC a setting of max 1 BVOP along with 'Packed bitstream' should be DivX compatible (regarding b-frames of cource)

[Koepi]

If you're having troubles if vdub shows the bframe lag message, then use "packed bitstream". It's the cure for your problem.

Koepi

[21_already]

Hello. Sorry it's a late reply but i had problems with my computer since before release candidate 4 came out and then i've been having exams since then. To make a long story short i wanted to notify who ever it is i should that the problem i seemed to have with RC3 (i was having some problem with first pass files containing nothin causing explorer crashes), seem to be resolved with RC4 and i cannot replicate the problem anymore. What's more, those old files no longer crash my explorer (they turn up as a green blank thumbnail now). In the end it may have been due to something else on my system, i just thought i should say something seen as i just read that Xvid may go final very soon :)

[amango]

@Koepi

"XviD 1.0.0 now ready?"-thread was closed. You wrote that you wanted to offer a new built from the final xvid 1.0.0-core within a few hours in this thread. That was two days ago... :(

[Koepi]

amango:

stop whining.

as long as there is no official announcement I can't release a final binary, simple as that.

[Latexxx]

Originally posted by amango
@Koepi

"XviD 1.0.0 now ready?"-thread was closed. You wrote that you wanted to offer a new built from the final xvid 1.0.0-core within a few hours in this thread. That was two days ago... :(

Compile it from sources by yourself! :D

[amango]

I already asked how to compile XVid with MS Visual C++ Toolkit 2003 (free edition, only command prompt), but nobody answered. In the XVID-FAQ only MS VisualDev 6 is mentioned. I am sorry, but I am not used to this. The free C++ toolkit edition from Microsoft is just 30 MB long and should compile it fine, I think - but I don't know how.

If someone want to test this compiler, you can download it here (http://msdn.microsoft.com/visualc/vctoolkit2003/).

[DeeGee]

How to Compile XviD with Microsoft Visual C++ 6.0 (http://www.discdude.net/xvid/compile.html)

I used that to help me compile xvid 1.0... Of course I have just started learning to programming so I have no clue how to optimize it's performance. So my compile probably isn't as fast as Koepi's.

[Latexxx]

I managed to compile Xvid using Mingw about a year ago. There are makefiles for this free compiler somewhere in the source tree.

[Arcon]

Originally posted by Koepi
as long as there is no official announcement I can't release a final binary, simple as that.
i don't know much about the internal structure of the xvid team, so what announcement has to be made before a release of the binary is allowed? and why is this announcement still in progress nearly a week after the 1.0.0 tagging?

this is not meant as pushing, whining or bitching, i'll wait patiently as long as i have to, but i'd really like to know this :)

[Koepi]

We just are nice guys and respect each other, so we behave nice amongst us. It's called etiquette. ;)
And then we had some disussion on how to properly release the "official" milestones, and this is the result of it (the first release candidates were "rushed" by me and the team didn't like that).

Regards
Koepi

[gatormac]

The final is going to basically be the same as RC4....if they were making any significant changes they would release an RC5. So don't worry about compiling it...you already have it.

[lordadmira]

Came up with a work around for that bug in the later Virtual Dubs where some final frames are dropped. If the video has n frames, create a zone in Xvid starting at frame n-1 and check Start With Keyframe. That way the video will always end with a valid GOP.

LA

[bond]

Originally posted by lordadmira
Came up with a work around for that bug in the later Virtual Dubs where some final frames are dropped. If the video has n frames, create a zone in Xvid starting at frame n-1 and check Start With Keyframe. That way the video will always end with a valid GOPgood idea :)

[RexManning]

Yes! It's there!

Be praised, XviD team!

[Nibor]

What? Where? How? Who?
:D


RexManning, what are you talking about? :)

[RexManning]

BEHOLD! (http://www.xvid.org/modules.php?op=modload&name=News&file=index&catid=&topic=6) :-)

[Nibor]

I checked xvid.org when you wrote your post but it wasn't there then!
Well, now it is!!.. :)

Congratulations, XviD team =)
and ... thank you!!!
For giving us the best MPEG-4 codec there is :D

Regards,
nibor

[RexManning]

Yeah, it's freaking awesome *jumps around happily*

Let's just hope Koepi & friends have time to compile the binaries for the few XviD users among us that are less technically skillful ;-)

[Edit:] Damn, that was fast! Thanks Koepi!!!

[Nibor]

Oh, that was very fast :)

Hey RexManning, seems we are the only ones who are happy about it ;)