DivX Kaukura Codec Beta

[zyrill]

all cropping and resizing was done before encoding with avisynth furthermore i did not reuse the mv-file...

[nuked]

I still think it may be a 16 bug. I just went back and looked at a couple of old avi's where I had 16 glitches. I have often found that not using multiples of 16 causes a small black box or stripe in the top left and causes teh whole colum uder it to be shifted and wierd. I remember concluding that I could get by with breaking the 16 rule sometimes if I turned fast recompress on.. strage, but that's what I remember(been awhile, don't hold me to it). Since then I ahve always used fast recompress and I think I've probably made some illegal crops, but I haven't seen the problem. Anyway, I went back and found an old encode where I had that problem and played it with kaukura. Sure enough, you guys aren't seeing things... there's the block in the lower right along with the left side effects... only my lower right block is cooler than yours... it's green. I just played a BUNCH of other avi's that didn't have this left side problem and none of them had the block in the lower right. Ok.. so your's didn't have the left side problem... but still maybe it's 16 related... obviously though whatever it is, it could be fixed in the decoder.

So i figured, hey.. if ffdshow fixes the lower right block, maybe it fixes the left side problem... nope. tried libavcodec and xvid codec with every idct... left side problem still there. but the right side block is indeed gone.

[nuked]

ps.. my problem encode did not use an mv file either and oh yeah.. it was made using 5.02.

[SeeMoreDigital]

This problem is getting stranger and stranger.

I wonder if users can confirm if this problem occured after they had cropped and/or resized their encodes!

[nuked]

well zyrill's image is 712x304 so I was assuming he cropped it... and it's a multiple of 8 but not 16.. I wonder if zyrill wants to try to encode a few minutes of it with it recropped to 720... on the other hand.. this probably shouldn't happen anyway and he already found a cure. As far I care there's nothing wrong at all with using ffdshow... kinda has alot of neat features actually.

[SeeMoreDigital]

Hi nuked,

This is a wierd problem. I generated some cropped and resized encodes using MPEGMediator and did not experience any problems at all!

I'll do some more tests tomorrorow.

Cheers my friend!

[nuked]

it is strange. I just looked again.. the one clip, I can find a problem with is 652x272. 652 is not even divisible by 8... I kinda thought I might have remembered there actually being an issue with 8 even more than 16... but then zyrill's clip is divisible by 8. Oh yeah.. of course being an avisynth guy.. I always had my clips cropped and resized before sending them into vdub... not using the vdub filters. Who knows what diference this makes. Good luck with the tests.

edit: and back when I made that one.. I probably really wsa using vdub, not vdubmod

[dTb]

I just discovered with my clip that enabling 'YUV Extended Mode' fixes the problem so give it a try on your files guys and see if you get the same result.

I have other clips that are not multiples of 16 or 8 which don't exhibit the problem so I'm unsure if that really is the cause.

[nuked]

no dice... YUV doesn't fix it for me.. still a green block. I don't know that it's size related... but I do know that my left side probelm was size related. I could very reproducibly crop or resize to a mulitple of 16 and it would go away without changing anything else. All I know for sure about this green block was that out of about 15 divx's that I tried.. the only one with the green block happened to be the same one with a left-side problem... coincidences do happen, but more often they don't happen.

[zyrill]

what the? now my block is green as well! alright something is really really weird! it used to be black... i don't understand this... maybe because i installed the matroska filter again? well unfortunately i don't have the source files anymore because at first when i checked the file in vdubmod there were no visible errors so i deleted the vobs :( i might be able to rip it again but it'll take time. anyway: i also used avisynth 2.5 (nuked seemed to believe i didn't) for cropping and resizing.

[fccHandler]

Just a comment: I used to have a little flickering green line (maybe 8 pixels wide) in the upper left corner of all my DVD2AVI to Mpeg2Dec3 to VirtualDub encodes, and I wasted a lot of time trying to track it down. It vanished when I installed the latest version of Avisynth, and I haven't seen it since.

I don't know if this is related to your problem, but it demonstrates how difficult it can be to place the blame when so many components are involved...

[zyrill]

well when i watch the plain avisynth-created file, there are no errors and even if i play the encoded file with vdubmod there are no errors - only kaukura decoder creates those nasty blocks. did i mention the blocks are not there when watching the movie with ffdshow?

[nuked]

zyrill... I was referencing SeeMoreDigital about the avisynth cuts.. not you, not that it matters. fccHanlder.. that thing you're talking about in the upper left is exactly what I've been talking about. I should find a screen shot of it. That is an equally elusive little bugger.. I think they are all combinations of issues.. as are most bugs. I mean.. you probably never saw that little bar in vdub before you encoded.. so you can't say it's entirely an avisynth issue if vdub could view the avisynth's just fine. I think it's a subtle combination of a at least a couple of things. Of course the new avisynth works in yv12 if by new you mean the 2.5 versions... and I found that using fast recompress helped the issue and fast recompress is also a color space issue. Might be related... who knows. Maybe Gej has ben unresponsive recently casue he's working on getting all these little issues hammered out for the final release.

[valipod]

This is really strange:

With slowest performance, Q-Pel makes encoding more than twice faster than without Q-Pel, while with standard performance, things are the other way around, it takes a little longer to encode with Q-Pel. I have tried this with several movies (BiDi and GMC always used, no MV).

Wether we like Q-Pel or not, this another story. I never use it, and this is why this thing with speed kind of annoys me...

Anyone have an idea, it feels like a bug...

[mikeson]

@valipod: Qpel is deactivated in slow and slowest modes ATM.

[calinb]

Originally posted by Gej
My favorite’s settings so far:

Common setting:

Home Theater profile: on
B frames: on
Psy: fast (no chroma hack)
NO MV file

1st pass
performance: Standard

2nd pass
performance: Slowest
Gej, Just curious--would these be your favorite settings, if you didn't care about simple profile-only hardware playback? Seems like there isn't much of a downside (other than hardware playback) by using GMC. As you said in your 5.02 guide:Originally posted by Gej in his DivX 5.02 guide on www.divx.com

Beside possible incompatibilities with some simple profile only hardware device, this option has the green flag for everyday use.

[nuked]

GMC is "compatible" with my laptop... but it runs the battery down like twice as fast last I checked(which wasn't recently).

[valipod]

Originally posted by mikeson
@valipod: Qpel is deactivated in slow and slowest modes ATM.

Well... I don't know. Since I have made several encodes with slowest performance, in pairs, with and without QPel, and first: there is a big difference in speed, QPel being faster, and second: there is a clear difference in quality (the "having a life of their own" artifacts apear when using QPel). So I am quite sure, QPel is not deactivated when using slowest performance.

[SeeMoreDigital]

Originally posted by calinb
Gej, Just curious--would these be your favorite settings, if you didn't care about simple profile-only hardware playback? Seems like there isn't much of a downside (other than hardware playback) by using GMC. As you said in your 5.02 guide: I am happy to announce that hardware players, such as Kiss range and the SigmaDesigns Xcard will now spin DivX files encoded with GMC. However, Qpel has not been implemented as yet!

Cheers