Log in

View Full Version : XviD. Quality over compatibility.


oddball
18th October 2004, 19:14
I think it sucks that the people who are developing XviD are not making any effort to make it more compatible with stand alone players. Surely an option 'Maximum compatibility' instead of the rather cryptic profiles would be better? Most folks encoding don't understand half the options there. For instance even the simple profiles still have packed bitstream enabled (Does not playback correctly on MT1389 chipsets).

I believe XviD should have that as a tick box right on the frontend of the encoder so people who want to play it on as many devices as possible just have to tick that in order to do so.

Just my opinion since I am getting rather fedup of having to load up MPEG4 Modifier for every movie in order to see if it will playback on my stand alone Elta.

Ark
18th October 2004, 19:51
There's a time for tuning quality and a time for tuning compatibility, and remember, it's all FREE.

Think at all the efforts made to make XviD as it's today, you really want a codec that flawlessly play on all standalone players but that can't stand up even with DivX 3?

If you want a "max-compatibility" button you can implement it yourself no?

(Sorry for being a bit rude but I think some people forget the efforts made by developers.. :) )

chilledoutuk
18th October 2004, 19:56
Just my opinion since I am getting rather fedup of having to load up MPEG4 Modifier for every movie in order to see if it will playback on my stand alone Elta.

No one asked you to use XVID in fact if it bothers you that much don�t go and use DIVX instead as that�s designed for ***** like you.

EDIT: censored a bad word. Koepi

Gaia
18th October 2004, 20:02
You're obiviously talking about scene releases. Try to contact those release groups and ask if they care about standalone support.

If you're talking about files you encoded i can't undertand your rant. It's not developers fault that you don't know what settings to use.

Koepi
18th October 2004, 20:04
Good point Gaia.

@All: Remember, no warez/piracy talk here.

Sorry for editing ChilledOutUK's post.

Regards
Koepi

Sharktooth
18th October 2004, 20:08
oh oh oh... no efforts for compatibility? There is nothing more MPEG4 compatible than xvid...
It's not xvid developers fault if chipsets are buggy...
However xvid developers spend so much time in making xvid the BEST mpeg4 ASP codec ever, and since the next version (1.1) it will have a VBV buffer for standalone compatibility.
Now, it's up to you to inform yourself and next time buy a better standalone player.
At least you should read what it can and cant do and encode your movies accordingly or download AutoGK and it will make xvid encodes at maximum standalone compatibility.

oddball
18th October 2004, 20:32
I did not mention they are not my own encodes because of the rules. I thought that would be clear in my wording. Not blaming anyone really just a little frustrated at how a lot of XviD encodes won't play on my stand alone (Unless I encode them myself). Sorry if this is breaking the golden rule but I could not think of a way to get what I wanted to say across to the XviD folks without breaking that rule. Obviously now I have broken it. I hope admin don't send me a nasty warning because of that. :/

One thing. DiVX 5.x is commercial product I know (But free for basic encoding options). They do have a certification scheme being pushed forward. I find it a shame that XviD being open source does not have any way of pushing it's own certification scheme.

Sharktooth
18th October 2004, 21:00
Uhm... coz xvid is an EDUCATIONAL purpouse codec...

Teegedeck
18th October 2004, 22:36
Yeah, officially you shouldn't be allowed to use XviD except if you use it for educational purposes or pay your MPEG-4 license-fees directly. ;)

See it like this: You're lucky enough to have found maybe the best MPEG4-ASP codec somewhere for free. Officially it has never left the laboratory but you happen to have found it. Like a prototype for X-Ray-spectacles just lying on the sidewalk. You pick them up, you can use them. If you are fanatic about quality (as we are) you can use XviD - but that's it.

No service hotline included. None at all. Sorry.

bond
18th October 2004, 22:42
dont the new xvid versions include setting the DXN profiles, which than disallow setting anything that breaks dxn profile compatibility (including forcing the divx fourcc)?
i think that would be the easiest and straight forward solution to this and it would even show how smart xvid is :)

GrofLuigi
19th October 2004, 00:31
Why make life easier for stupid people and more complicated for others? Former will screw up anyway on something else, so either educate them or kill'em. :)

Sorry, just my opinion.

GL

Sharktooth
19th October 2004, 00:54
You/we/I cant kill ppl... but there are GUIDES and FAQ (and then the forums) so ppl can get informed.
BTW i agree xvid needs a more easy interface for n00bs.
But that's a secondary "objective". When the codec is "done" then maybe the developers will play with the GUI.

nexx
19th October 2004, 01:10
Originally posted by GrofLuigi
Why make life easier for stupid people and more complicated for others? Former will screw up anyway on something else, so either educate them or kill'em. :)

Sorry, just my opinion.

GL

How will a big 'Compliant Mode' tick box make life more complicated for anybody?

My opinion is I couldnt care either way, but I can understand where the original poster is coming from.

dragongodz
19th October 2004, 01:27
more compatible with stand alone players.
hmm and since different players have different capabilities ? and some are buggy ? so i assume you mean make it to the lowest commen form.

ok well how about adding a button called "hardware player defaults" which would act like the "load defaults" button. infact it could be right next to it. what it would do is set all settings to the lowest hardware players type settings, so no Qpel, no GMC etc etc etc. then when people complain it doesnt look as good they can told to blame their player. :)

Sharktooth
19th October 2004, 01:32
A "Lock settings for Hardware Players" would be better (and n00bproof).
A sort of button that will disable Qpel, GMC, Custom Matrices, Enable VBV etc, set max cons. bframes to 1 and enable Packet bitstream... and make those settings locked so you cant play with them.

dragongodz
19th October 2004, 01:39
and n00bproof
is there such a thing ? :eek:

locking those settings/options is probably not a bad idea though. then the button would change to unlock aswell of course.

GrofLuigi
19th October 2004, 01:46
Originally posted by nexx
How will a big 'Compliant Mode' tick box make life more complicated for anybody?

Probably it would start something like this:

Originally posted by Sharktooth
A sort of button that will disable Qpel, GMC, Custom Matrices, Enable VBV etc, set max cons. bframes to 1 and enable Packet bitstream... and make those settings locked so you cant play with them.

@ Sharktooth: sorry, nothing personal.

GL

bond
19th October 2004, 01:55
as i said: this could all be done by using the profile option (basically divxnetwork defines not much more than private mpeg-4 profiles for their divx certification), it prefectly fits into the gui

Sharktooth
19th October 2004, 02:00
Yes but ppl just doesnt know what profiles and options to choose to have their econdes DXN compatible (AS@Lx doesnt lock GMC, QPEL etc. and is not a familiar name)...
The "button" or adding DXN profiles will only make things easier.

bond
19th October 2004, 19:58
well in divx5's gui you also only choose from a list of profiles, which after chosen disable some features, enable vbv aso... its the same way as if adding a DXN@... profile to xvids list, also beaware that nero will soon also come up with their own profiles including nero certified players, so people have to take care that the gui doesnt become a mess IF all these private profiles (and they are not more than private profiles) are wanted to be supported

anyways, talk is cheap, the discussion is worth nothing if none of the devs thinks about implementing this :D

SeeMoreDigital
19th October 2004, 20:08
I honestly don't think the XviD codec is at fault at all.

In my opinion, the sooner chip-set/stand-alone manufacturers start thinking outside of DivX's limited "certification", the better for all of us!

The current Mpeg4 SP and ASP profiles are there for everyone to follow... shame then that DivX like to create its own!


Cheers

Sharktooth
19th October 2004, 20:43
DXN just convinced chipset makers to follow their profiles.
I dont think they will get rid of the "DivX certified" logo coz of the Mpeg standard profiles...
If ahead guys have the intention to make their own profiles, i wish them a big GOOD LUCK.
Maybe the AVC market is still open, but DivX 6 is not so far away...

gotaserena
19th October 2004, 21:07
playing devil's advocate for a sec, there are two events which in my view collaborated to the whole mess we see today:

- the appearance of a lot of movies based on the divx 3.11. The train was basically set in motion by the hacking of m$ implementation of MPEG-4 which, alas, is not MPEG-4 compliant (<jarring chords sound>). That put pressure on a large number of HW producers to make "DivX compliant" chips, whilst slowing the support for true MPEG-4 specs. More importantly, that also made words like "AP" and "ASP" more of an abstraction that nerds like us and tech people like to babble about but marketing and consumers-at-large ignore or loathe (or both.) And I am not going to touch the "video for windows" legacy (VBR in AVI, packed bitstream, etc.) because it has already been beaten to death.

- Many companies complain about the fact that ASP decoding is just too CPU intensive to be put on cheap chips that they want to put in standalones. And to be fair, odds are that the 90% of people that would buy these devices would conect them through a composite cable where the difference between quarter and half pixel is imperceptible. IMHO the standard was set with something other than playing 1 (or 2) CDs DVD backups in mind. But by the reason above, and some others we are not really open to discuss here, IMHO the playing of 1 (or 2) CDs DVD backups is exactly what these devices will end up doing. This is exactly the type of terrain fertile to "standards" like DivX certification.

Ok, enough rant for a day. Back to trying to make my Xcard chip decode some anamorphic (sans B-VOPs) encodes!

dragongodz
20th October 2004, 01:58
I honestly don't think the XviD codec is at fault at all.
of course it isnt.

the point is if you have a button to set all options off that dont work on the lowest hardware player then it should be compatible with all. then newbies can just use that and make an encode they know will work, not best possible.

it would save a lot of "i cant get my xvid encode to play on my hardware plaer" type questions for sure.

stephanV
20th October 2004, 09:41
Originally posted by gotaserena
- the appearance of a lot of movies based on the divx 3.11. The train was basically set in motion by the hacking of m$ implementation of MPEG-4 which, alas, is not MPEG-4 compliant (<jarring chords sound>). That put pressure on a large number of HW producers to make "DivX compliant" chips, whilst slowing the support for true MPEG-4 specs.
What really slowed down the support was the lack of a good MPEG4 implementation. Why would you make chip sets for anything if no one in their right mind is going to use them?

And I am not going to touch the "video for windows" legacy (VBR in AVI, packed bit stream, etc.) because it has already been beaten to death.
You'd better not touch it, because it hasnt got anything to do with this. Why would VBR MP3 in AVI slow down MPEG4 developers? It's the lack of proper MP4 support that made things like packed bit stream "necessary" (it isnt really though). In the contrary, take AVI away and we still wouldnt have a descent MPEG4 implementation.


- Many companies complain about the fact that ASP decoding is just too CPU intensive to be put on cheap chips that they want to put in standalones.
Yep, this is the true issue. You have to realize that both DivX and chipset manufacturers are companies and as such, have to make money. While some of us idealists can whine on and on that DivX has done wrong to create their own profiles, this is certainly not the case. For them it was the only way to ensure playback on a reasonable amount of different devices. I believe still standalones are being sold which are said to be able to playback MPEG4 (what is MPEG4 anyway?), but in realtiy have no support for some features (very often these are GMC and QPEL). With a DivX device at least you know, what things will play and what will not. And if Nero will do the same thing, I'll applaud that. Certification gives clarity when a term as MPEG4 has become too ambiguous (MPEG4 SP, MPEG4 ASP, MPEG4 AVC(!?)).

Some people like to have standards... other people like to have things that work.

To come back to the original topic. A button which disables all non-certified options would certainly be useful for the XviD encoder.

yaz
20th October 2004, 10:39
motto : 'life is hard for all of us why would it be easy just for u' (heard 1st from my grandpa)

khm ... d'you know the label 'keep away from children' ... why's it occured to me? if u don't know what (a/o how) to do with sg u'd better keep away. it'd just hurt. imho!

anyway. a quick'n'dirty solution would be (until devels implement that funky 'i'm_a_hopeless_bumpkin_a/o_i'm_just_unwilling _to_learn_even_the_very_basics' button) some '.reg' files. if u know what exactly is a safe setting for a certain harware, pls, set it and drop the reg file into a sticky. this way anyone would download that setting which fits the bests to his/her standalone.
ok, i know, it's not perfect as there remain some options to be set by the '...' user but ... (see motto above :-)

the bests
y

gotaserena
20th October 2004, 11:27
Just to make myself clearer, before we go hopelessly off-topic:

My point is that HW producers had a demand to build chips that would conform to existing containers, private tracks, etc., in contrast with DVD producers which had the standards set before going into the market. In all probability if they had their way we would be talking about transcoding .mp4 to .mp4 now (or bypassing DRM). But we came to a point where instead of worrying on how to implement 5.1 HE-AAC decoding in .mp4 they are worrying about keeping A-V synch in .avi files. That this is straying resources I think it is quite clear. But in your view this is just a matter of setting different standards, so I guess I'll stop here.

stephanV
20th October 2004, 11:42
Originally posted by gotaserena
Just to make myself clearer, before we go hopelessly off-topic:

My point is that HW producers had a demand to build chips that would conform to existing containers, private tracks, etc., in contrast with DVD producers which had the standards set before going into the market.
Yes, they need to sell their product right? If we have to wait before we can finally use MP4 in a descent manner, MPEG4 ASP will probably already be outdated (perhaps it already is).


But we came to a point where instead of worrying on how to implement 5.1 HE-AAC decoding in .mp4 they are worrying about keeping A-V synch in .avi files.
Uhm, hacking VBR MP3 into AVI is probably one of the easiest things that is ever done software wise, it basically comes down to a simple round up. Writing a spec compliant 5.1 HE-AAC decoder which will work on a standalone is probably *a lot* harder. At least make comparisons that are to the point.

That this is straying resources I think it is quite clear.
I think it isnt quite clear. Theres no point in supporting stuff that isnt implemented yet; it doesnt sell very well. ("Look, here you have chipset that you might be able to use in 2 years from now. Now gimme your money")

But in your view this is just a matter of setting different standards
No, its a matter of getting something you know that works, or getting nothing at all/something that might work.

I'll stop here
Me too :)

Mug Funky
25th October 2004, 17:06
"Look, here you have chipset that you might be able to use in 2 years from now. Now gimme your money"

if a standalone manufacturer had the guts to say that, i'd gladly hand over my money. i want a standalone that will last me several years! buying a new chunk of plastic and metal every month for something as frivolous as watching teev is such a disgusting waste that it makes me want to punch people in the face.

the leak of MS's not-quite-compliant MPEG-4 encoder was both a boon and a big mistake.

it was a boon because it got the technology out there when the only other alternative at the time was indeo. remember how crap that was? remember how amazed we all were that we could fit an ENTIRE DVD movie on 1 CD, albeit in 320x240 anamorphic initially. the DVD backup revolution started at 2 points - the cracking of CSS, and the hacking of MS mpeg-4. suddenly the consumers had a power they may not have got if mpeg-4 had stayed unhacked.

but it was a big mistake from the hardware viewpoint - the standard wasn't even finalised at this point, but we saw a scramble to support a non-compliant format in a lousy container. mpeg-4 came second, because everyone was talking about divx, not about mpeg-4.

this isn't much of a problem at the moment because the standard is finalised, and the encodes floating around the internet are getting more advanced - thanks largely to Xvid. it's on the forefront of MPEG-4 ASP, and leads the field - it keeps the other codec developers on their toes, and gives the hardware manufacturers a massive incentive to start supporting mpeg-4 properly.

once a good quick way to get things into a proper mpeg-4 container gets out there, we'll be seeing some real progress. hopefully by then AVC will be the next thing to support.


what Xvid needs, i think is to escape VirtualDub's shell. while virtualdub (great though it is) is tied to the archaic VfW interface, mpeg-4 will suffer. we need a way to encode in .mp4 that is as quick and painless as encoding to an avi file. hopefully virtualdub will be the spearhead here, and lose it's reliance on VfW.