xvidenc questions

[weaver4]

What XviD video preset should I use to ensure the resulting XviD file will work on Stand-Alone-DivX-Players?

I also noticed when I used avinaptic that the Aspect Ratio was a Custom Pixel Shape of (183:188 = 0.973404) where movies I encoded with autogk are square. Do I need to worry about this? What do I need to do to make the Pixel square?

Thanks,

[microchip8]

Originally Posted by weaver4

What XviD video preset should I use to ensure the resulting XviD file will work on Stand-Alone-DivX-Players?

I also noticed when I used avinaptic that the Aspect Ratio was a Custom Pixel Shape of (183:188 = 0.973404) where movies I encoded with autogk are square. Do I need to worry about this? What do I need to do to make the Pixel square?

Thanks,

At the moment I haven't implemented HW compatible presets, though the EHQ one comes very close to it. Just stay away from the UHQ preset as it uses qpel and not all devices support it

you don't need to worry about square pixels... here's a patched xvidenc with one HW preset, it's basically identical to EHQ but sets the ffourcc to DX50. I haven't tested it though

http://www.mediafire.com/?eicxztzgzl1

[weaver4]

I will test it on my Pioneer and Philips DivX players; and my popcornhour A-100 and let you know.

Thanks,

[microchip8]

Originally Posted by weaver4

I will test it on my Pioneer and Philips DivX players; and my popcornhour A-100 and let you know.

Thanks,

ok, this patched xvidenc adds 4 different HW compatible profiles which force the 'ffourcc' and 'profile' option of XviD. I hope they work like it should as I don't have a DivX player here

http://www.mediafire.com/?yzg1myxo1gb

[weaver4]

will the profiles show up if I run xvidenc --help?

[microchip8]

Originally Posted by weaver4

will the profiles show up if I run xvidenc --help?

yes, of course

[weaver4]

I tried the hwsdntsc profile and it worked on my Philip and Pioneer Divx DVD players and it also played on my popcornhour A-100.

Great Work!

[mousemurder]

hi, is there a way to determine the video bitrate for any of the profile ?

it may not be applicable encoding in this way. but i would like to know if using vbitrate option if it will make the encoding better.

?

[kinematic]

I ran xvidenc just to see what it does and I noticed some things concerning a 2 pass encoding. On the first pass me_quality can be set to 5, bvhq can be disabled as well as chroma_me and you don't have to encode audio on the first pass. Should speed things up significantly. I also don't get why you set it to create a log file in a hidden directory by default seeing how mencoder already creates a divx2pass.log file in the directory from wich mencoder is started if you don't specify anything.

[microchip8]

Originally Posted by kinematic

On the first pass me_quality can be set to 5, bvhq can be disabled as well as chroma_me

Actually you can do whatever you want, but from experience and a lot of testing, it is better to use the exact same options for both passes. Besides, turbo is already enabled on the first pass and it disables CPU hungry options by default so no real need to lower stuff.

and you don't have to encode audio on the first pass.

not really true. with mencoder you can get A/V sync issues if you omit audio encoding during the first pass, especially if you're doing some frame dropping/duplication like during ivtc. There was a time when xvidenc didn't do any audio processing during the first pass but this resulted in A/V sync issues in my case so I enabled back audio processing for the first pass

I also don't get why you set it to create a log file in a hidden directory by default seeing how mencoder already creates a divx2pass.log file in the directory from wich mencoder is started if you don't specify anything.

Because I don't want the user to see any log files during the encoding. Reason enough for you?

[kinematic]

My experience tells me the exact same setting don't have to used on both passes and I've done countless encodings with mencoder and have never had any A/V sync issues with audio not enabled on the first pass.

Soooooooooooo.......lets just agree to disagree

[microchip8]

Originally Posted by kinematic

My experience tells me the exact same setting don't have to used on both passes and I've done countless encodings with mencoder and have never had any A/V sync issues with audio not enabled on the first pass.

Soooooooooooo.......lets just agree to disagree

Just because you never had any A/V sync problems with mencoder doesn't mean that at some point you can't get them. Your reasoning is a bit flawed. I have three soft-telecined NTSC DVDs here that every time I encode them without audio for the first pass, the final encode ends out of sync. With audio encoding for both passes, these three DVDs are perfectly encodable. This is reason enough for me to enable audio processing during the first pass, and also because I don't know what content the user of xvidenc is trying to encode, it is even more reason for me to enable audio processing for the first pass. Trust me, those cases do exist, even if you never have had A/V sync problems with mencoder so far.

[kinematic]

Just as you have based your script on personal experience my comments are also based on personal experience wich means that if my reasoning is flawed yours is also flawed ;-)

[fbgd]

Originally Posted by kinematic

Just as you have based your script on personal experience my comments are also based on personal experience wich means that if my reasoning is flawed yours is also flawed ;-)

It's stated in the mplayer documentation that you should enable audio processing to ensure sync.

[microchip8]

Originally Posted by kinematic

Just as you have based your script on personal experience my comments are also based on personal experience wich means that if my reasoning is flawed yours is also flawed ;-)

Actually my reasoning is not flawed, it overthrows yours. You said that you never had A/V sync problems when encoding without audio in the first pass. I said that I have three DVDs that get A/V sync problems when encoding without audio during the first pass. Conclusion? My experience overthrows yours. Why? Because I have encountered these problems and I'm not a special case. This could happen to anyone out there, not just me - there have been various reports over the years on the mplayer mailing list of people having problems when encoding the first pass without audio. This could happen to you too, even if you never had any problems so far. The fact is that the problem is real (as I have experienced it) and it exists. Just because it didn't happen to you so far, it doesn't mean it won't happen to someone else at a given point in the future. As there are millions and millions of DVDs out there, and even more video files, there's no way you or me or someone else could tell that at a given time and the right content, the problem won't occur again.

If I had to apply your reasoning on a specific disease it will result in a flawed conclusion. Based on your reasoning, the specific disease doesn't exist because you never had experienced the effects of it. But what if others have experienced the effects of the specific disease? Does it mean that it doesn't exist because YOU never experienced it? No. It means that YOU and only YOU so far has never experienced it. This does not prove that the specific disease doesn't exist, it only proves that so far you were "lucky" and did not catch it. Based on the collective experience of others, the specific disease DOES exist as someone has experienced its effects.

Your reasoning is local (meaning it is based only on your own experience so far without taking into account the experiences of others). My reasoning is global, based not only on my own experience but also on others too, like the people on the mplayer mailing list that have reported such problems.

[kinematic]

Originally Posted by froggy1

but this resulted in A/V sync issues in my case so I enabled back audio processing for the first pass

The only thing that overthrows my reasoning is the fact of A/V sync issues with audio disabled on the first pass according to various reports on the mplayer mailinglist wich you omitted to mention the first time. I did not know about this because I have never encountered the problem and therefore there wasn't any reason for me to investigate the matter. saying you encountering a problem overthrows my reasoning is just silly because it could just as easily have meant your just unlucky. Simply encountering a problem due to whatever reason does not overthrow anything.

Having said this I'm not going into this any further because this is not a debating forum.

[microchip8]

Originally Posted by kinematic

The only thing that overthrows my reasoning is the fact of A/V sync issues with audio disabled on the first pass according to various reports on the mplayer mailinglist wich you omitted to mention the first time.

whether I omitted the mplayer mailing list reports or not, that's not the main issue here. The issue here is that YOU claim that just because YOU never had any problems, no one else should have them (which is obviously incorrect) and that's why you never use audio processing during the first pass, hence I too shouldn't use it so that I can speed up things. That's what you were trying to say in your very first post when this discussion started, and I quote:

and you don't have to encode audio on the first pass

which clearly implies that I too should disable audio for the first pass to speed things up, because based on your own experience, and that's the experience of just one person, nothing could go wrong because so far YOU never had any problems. This further implies that

a) you base your reasoning on your own personal experience, instead of taking into account the experiences of other people, which you must do if you develop something and there are experiences/reports of something not working correctly.

b) it is clear that your knowledge of mencoder's A/V sync algo is not very high. Users AND developers both acknowledge that in certain cases, the A/V sync can fail if you don't process audio during the first pass. This comes from the fact that mencoder NEEDS to see every single frame for both video and audio so that its sync algo can work correctly. mencoder drops or duplicates frames during the encoding so that it can obtain a correct A/V sync. if audio is omitted during the first pass, and then processed during the second pass, the amount of dropped/duplicated frames during the first pass will be different than that of the second pass, where mencoder has to take the audio frames into account to maintain the sync. This could lead to more or less frames being dropped during the second pass, which can result in A/V sync problems because of the difference of dropped/duplicated frames between the first pass and the second pass. As the amount of dropping/duplication CAN and in certain cases WILL differ between a first pass without audio and a second pass with audio, it can result in sync problems. The problem can get worse if the user is using filters that explicitly drop or duplicate frames, like during ivtc, which xvidenc supports and must also be taken into account.

Just because the problem doesn't apply to you yet, doesn't mean it won't apply to others too or to you in the future. I already told you that the problem DOES exist (my three DVDs) but you chose to ignore it and instead went on further to "prove" your case that so far everything is working on your side, which indirectly implies that it should work for everyone else, no matter with what content the user is dealing with. Then I mentioned the mplayer mailing list reports to further strengthen the case that the problem DOES exist, whether is has happened to you or not, but again you just ignore it.

I did not know about this because I have never encountered the problem and therefore there wasn't any reason for me to investigate the matter.

Of course not, because you are thinking locally, as I said before. When you develop an application, whether it's a simple script or something more complex, you have to investigate every possible known problem that could happen, whether it has happened to you or not, it doesn't matter. If I didn't had these three DVDs that always fail when audio processing is disabled during the first pass, I still would have enabled audio processing during the first pass. Like I said before, there was a time, a long time ago when I just got into encoding, that xvidenc didn't use audio for the first pass, but as developer I am constantly testing and investigating to see if there's a problem that could arise when using something in a certain way. I take not only my own experience into account, but also the experience of people like those on the mailing list and the experience of users of xvidenc which send me reports if something is not working for them or they know a better way how to tackle a certain problem that could happen.

saying you encountering a problem overthrows my reasoning is just silly because it could just as easily have meant your just unlucky.

If I have been unlucky and had a sync problem like I did (and others too), then this implies that something went wrong and obviously the thing that you are defending (no audio during first pass) is not bullet-proof and can fail in certain cases. This strengthens the case that there's a possibility of a problem arising when a specific combination of parameters and content is used. Saying I was just unlucky further implies that mencoder's sync algo CAN fail. If the algo was 100% perfect, then this should never have happened in the first place, thus I will never be unlucky, which is obviously not the case. This is not to say that if you always use audio for the first pass, you will never get sync problems. I have encountered numerous video clips from youtube that ALWAYS get sync problems when you encode them with mencoder, no matter what options and combinations you try, which in the end means that the sync of mencoder is not 100% bullet-proof and CAN fail. Even adjusting your system's clock during the encoding process can screw up your sync because mencoder uses the RTC (real time clock) to keep the sync. What CAN be done is minimize the possibility of the said problem arising in certain cases by following the design of mencoder's sync implementation, which clearly implies that audio should be processed during all passes. It is said in the doc of mencoder/mplayer and by the developers themselves on the mailing list, and who would know better than those who have developed it?

Simply encountering a problem due to whatever reason does not overthrow anything.

Simply saying that one never had a specific problem and at the same time dismissing the possibility of the said problem occurring to someone else when clear evidence is provided, is called ignorance.

Having said this I'm not going into this any further because this is not a debating forum.

I agree