@ Nic's XviD Binaries

[Shayne]

Hey Nic will we see any more builds come off your site?

Been at XVID - 13/05/02 for some time now.

Thanks

[Nic]

I know :( Ive got so little free time at the minute, but you will see some soon as ill fix the "green frame bug" in the filter :)

My site should be pretty active soon as well, as I have other things to put up (i.e. DVD2AVI_NIC & its ascociate source code & bits & bobs :) )

Thanks for interest :)

Cheers,
-Nic

[Razor04]

Hey Nic...

I know you are working on fixing the green frame bug, but I also had a related problem. When using a build with the DShow filter that has the green frame bug my CPU usage is very high (100%) when first opening files. It doesn't do this in any of the older builds without the green frame bug or the newer builds that don't use your filter. I just thought I would mention it as I really like your filter a lot and would like to get back to using it. Keep up the good work Nic!

PS- Any chance we will see any more sliders in the filter to change things like Contrast, Hue, or Saturation?

[Shayne]

DVD2Avi Ala Nic sounds very interesting

[Shayne]

Thanks Nic was going thru download withdrawl

[sherpya]

Nic I've seen into standard xvid cvs sources, why your job over dshow filter is not merged with the xvid dshow filter? It seems reasonable.

[Nic]

Its because isibaar wants it in the Core (so linux users etc can benefit). But I dont really want to start doing my own core changes to the API (as Id need to control it thru the API, until certain things are finished (i.e. B-Frames & Qpel) Also im seriously lacking on time...(& I was gonna work on the filter tonight, but Im supposed to be organising a friends stag night as well as going to see SoulFly live) Busy Busy :)

-Nic

[avih]

nic, if you DO want to do that, u can have a look at my postproc build, that did all the stuff in core. the only problem was that it's controlled via the registry (the encoding pannel changed the registry, and the core read and mod the level of postproc).u'll have to use a standardized api for that.

cheers
avi

[primitive]

I don't know if this has been covered before, but why do you want postprocessing in the core? ffdshow on both windows and linux is already a fantastic postprocessing tool, and it seems to me that since xvid is becoming more and more mpeg4-compatible it'd be a cleaner solution to let general, cross-platform mpeg4 postprocessing filter sets (ffdshow) do all the work.

Or is xvid going to use Nic's postprocessing filter during the encoding process? I vaguely remember reading a thread earlier about an encoding technique that passes each encoded frame through a postprocessor before using that frame to generate the next frame. Is this where xvid's going?

-p

[Nic]

@avi: Thanks I will :)

@primitive: Well, it can be there as an option for decoding, people could still, of course, use ffdshow instead. My filtering wouldnt be used for pre-processing. And anyway Isibaar wants it in the core, so thats what he'll get :D

Take Care,
-Nic

[avih]

@primitive:
ffdshow is NOT cross platform. it's strictly windows direct show stuff.
although the decoding libs are based on ffmpeg project (whisch IS open source) and some of the postprocessing filters are based on mplayer (open source as well), i believe milan has added many features that cannot be found in ffmpeg or mplayer. i guess he MAY be able to make it a cross platform decoding/postprocessing module, but imo, it's NOT a top priority for this project.

mplayer does a fine job with decoding and postprocessing i believe (never tried it myself).

@nic:
if u need clarifications, don't hesitate to contact me ;)


cheers
avi

[primitive]

Yikes!

Excuse my ignorance. I was of the impression that ffdshow was nothing more than ffmpeg ported to DirectShow. I have experience using ffmpeg in the context of Mplayer and I know it's a good performer; in the past it used separate libavcodec and opendivx modules for div3/4/5+xvid+generic mpeg4 decoding, but now it uses just ffmpeg. I can't recall what exactly Mplayer used for postprocessing back then (perhaps internal routines?) but I believe most of those have been rolled into ffmpeg.

(I may be totally talking out my ass at this point, but I think Mplayer uses ffmpeg for all mpeg1/2/4 playback.)

I guess my point was made in reaction to where Nic said that Isibaar wanted it in the core so that Linux users could benefit; my point was that excellent postprocessing was already available for said platform, and as long as xvid is mpeg4 compatible Linux users won't ever have motivation to install an xvid library with integrated postprocessing because they've already got ffmpeg. However, at this point I am way, way outside of my level of expertise, so I'm going to take a step back and let the wizards make their magic again.


With interest,
-p

[Nic]

I think isibaar just feels that post-processing should probably be quite an integral part of any DCT codec & it would be nice to have. Its not really that important, the reason I did the post-processing code was because, at the time, XviD could never look as good as DivX, because you couldnt use MPEG quant & DivX post-processing. & Hence I made my filter.

But I think thats all been supersueded by ffdshow. But I fixed (hacked a fix) for the green bug (which is purple on my system at home? :) ) tonight & should get a chance to release it tomorrow.

Cheers,
-Nic

[Koepi]

Uh, nice job Nic :)

Can you send me the ax to my mail-account please then? :)

Regards,
Koepi

[Nic]

I will do before I release it :) (cant now though :( )

@all:
BTW my new mail account is: nic@everwicked.com
(nic@vampirehunter.com has died :( )

-Nic