Filtering tools in codec is a bad idead.

[athos]

I think DivXNetworks is on the wrong track when including tools for deinterlacing, cropping, resizing, smoothing etc in the codec. Even if the included tools where good enough to use, the do not belong in the codec. These are tools for manipulating the video _before_ encoding it. Therefore they belong in video editing tools such as VirtualDub. The codec should only concern the encoding and decoding (maybe including postprocessing, but perhaps this should also be moved out into a separate directshow filter?), but do it well.

my 0.02€

[Nic]

For someone that states they've been around for a while & just haven't posted, your new threads are quite irrelevant & irratating.

Please, if you have nothing useful to start a discussion on, just add your thoughts to another thread.

Cheers,
-Nic

[athos]

im sorry if you feel that way. i do apologize for not using the search function when i should, but how are my other two threads irritating and irrelevant?

I posted my suggestion for the xvid format because i thought id share and idea that i thought was good with the people actually implementing the codec and maybe do my share to the development.

I started this thread because i wanted to share my opinion on systems development as a computer science student. i think components should be focused on a limited number of tasks, but do these good. again, im sorry if this annoys you.

[ppera2]

Why not put everything in codec ? For me it would be ideal solution.
Not bother with frameserving etc.

For example there is a real, practically nothing difference between resize in diverse programs, especially when use downsize, what is used most of time.
All it is based on same algorithms, open source code etc.
One of best things in DivX 4 was built in deinterlace. It gave me best results for PAL video, and worked fastest of all.

Best thing will when we will have framerate conversion built in codec. Because Mpeg4 uses very sophisticated motion search functions, I think that combine them with framerate conversion would give best results.

[athos]

finally, something constructive. you have a good point, but i think i need to clarify myself. i do not discuss the quality of the tools, but the coupling between the tools and the codec. i think the codec should only be used for coding/decoding, but it could be "bundled" with useful tools for video manipulation, much like it comes bundled with the divx player now. just imaging if divx was released not as a codec, but only as a proprierety player and you could only watch divx video in this player. now, you dont have to use the included tools when you encode divx, but you have to install them. at this point this might not be a big problem, but if this development continues, we could end up with bloatware (look at Microsft Windows or Mirabilis ICQ).

it is my opinion that it would be better if dxn released a specialised editing tool, comparable to virtualdub, and separated it from the actual codec.

[Nic]

Maybe I was too harsh,

But individual threads should have a point, rather than an open statement just containing an opinion.

Cheers,
-Nic

[Doom9]

I do agree with athos that this is basically not the job of the codec.. however, it makes life easier for a lot of people and I guess that's the motivation behind the inclusion. No experienced encoder is going to ditch all his avisynth commands... but all the xmpeg junkies might find especially deinterlacing useful as xmpeg can't do that atm.

[athos]

Nic> I understand your critisism when you put it this way. perhaps i did not write it the right way (english is not my native language), but the reason i started a new thread here was that i wanted to start a discussion on what parts should be included in the codec and which should not. i can see that it looks more like an opinion out of nowhere than an attempt to start a discussion

Doom9> I agree that one often have to compromise architectual simplicity in the interest of practical usefulness. After all, it is not the blueprint of the system that is actually being used =)

I am not sure how much the postprocessing filters are specialised for a given decoder, but would it be possible to use for example Nic's postprocessing filters (good work btw!) with the DivX5 decoder?

[Nic]

Thats ok Athos, its turned into a good discussion anyway :)

Well, my DShow filter post-processing is just a cleanedup version of OpenDivX's so infact DivX5 (or at least DivX4) does use the same Post-Processing.

But I don't quite understand your question, if you mean can you play DivX5 movies using my filter then, yes, just use AviC to convert the movies FourCC to XVID

If you mean will DivX incorporate the changes ive made, no they wont :)

(And Post-processing isn't very difficult to port to different decoders, unless the source code is badly done (yes linux mplayer im looking at you :D )

Cheers,
-Nic

[athos]

Nic> I read the DivX manual for the postprocessing and saw the similarities to your filter. Now i understand what the C and Y stands for (hey, maybe i should have used the search function here too;)). I also see that your filter is more configurable.

What I was thinking was, in a pseudo-graphedit-notion:

AVI-FILE -> AVI Splitter -> Divx Decoder -> Nics filter -> video renderer

From what I understand, the filter is in the decoder, so it would not be possible? If the (post processing) filter was separated, maybe it would be possible to disable the built in postprocessing of divx and use yours?

At this point i guess this might not be of much practical importance, because, as you say, the postprocessing is pretty similar. But maybe in the future, Xvid will have a vastly superior postprocessing filter, but might not be as good at decoding DivX5+ content because of some secret "trick" that DXN uses? Then again i guess this shouldnt be, since both are ISO MPEG-4 compliant.

[Nic]

It is possible (and not that difficult) to make a post-process only filter that would do what you specified.....but as you stated, theres no need for it & hopefully there never will be.

Cheers,
-Nic

ps
actually Y & C aren't very good explanations....My fault.
When I say Y I mean the Y component of YUV also called the luminance
the C is the chrominance (U & the V part)
Just to clear up any confusion :D

[timmyg]

If the internal functions were done right couldn’t the codec gain information from the unprocessed video, things like motion prediction and GMC are probably hindered by spatial filters and resizes which only operate on single frames and will discise what is happening. also if a vieo contain true 30fps video (no repeated frames) couldn’t this assist a codec in motion prediction as the motion would be smooth instead of jumping where the video the codec had been sent had frames missing.
just a thought

[athos]

timmyg> this is a very good point you have. if such things are possible (im sure there are, not sure if they are used in DivX though) this would obviously motivate the inclusion of such tools in the codec. same thing goes for the post-processing, if this is related to the specific codec. to my understanding, the current postprocessing filters (admittedly very much alike) are, at least conceptually, interchangable.

with the comments to my post i would like to change my statement to:
as a rule of thumb, only things that are directly related to the codec (or any component) should be included in the codec/component. practical reasons might motivate an exception from this rule, but developers should beware of including too much and risk turning the component into bloatware.