I've had trouble finding examples of how to encode with XVid. Frankly, I've found a lot of the documentation and examples around the web a bit hard to follow. I've pieced together my script from samples that I've found around the web. Many times I'll try options I find only to find they're no longer supported or that there's a new option for it. And since most of the examples on the web don't have a version number, it's hard to figure out which version they're writing for. It would be nice if things didn't change so much making it a little easier to follow. I haven't been able to reboot my linux box (apparently I need to, to do the memtest. I'll hopefully be able to in the next hour or so. Since it's also my router, I lose connectivity whenever it goes down. I'll try the options you've posted. In the meantime, I've done two successful encodings by not using the script and instead, doing each line of the script, one step at a time. The idea being that if it failed at a step, I could simply repeat the step. Now suddenly it seems to be passing at every step. Maybe it is overheating and the break between steps is causing it to cool down. I have the box in a separate room with no monitor. I need to pull it out, hook up a monitor and run some of the visual apps that will let me monitor the temperature and other parameters so I can see if that's the problem. Thanks again for your help. Pete -----Original Message----- From: mencoder-users-bounces@mplayerhq.hu [mailto:mencoder-users-bounces@mplayerhq.hu] On Behalf Of Martin Collins Sent: Sunday, June 19, 2005 3:52 PM To: MEncoder usage discussions Subject: Re: [MEncoder-users] Mencoder finishes early on DVD to Divx encoding On Sun, 19 Jun 2005 11:41:56 -0500 "Pete Davis" <pete@petedavis.net> wrote:

I'm running mencoder 1.0pre6-3.4.2

That's only six months old, but it feels like a lifetime...

mencoder -dvd-device ./ dvd://$1 -ovc frameno -o frameno.avi -oac mp3lame-lameopts cbr:br=128

This frameno thing is so deeply frowned upon it is not even in the docs anymore.

mencoder -dvd-device ./ dvd://$1 -oac copy -o movie.avi -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=900:vhq:vpass=2:vqmin=1:vqmax=31 -vop scale=512:288 -

vqmin=1 is bad, use 2. vhq is obsolete use mbd=2. -vop is obsolete use -vf.

Anyone know what could be causing the problem? Should I just upgrade to 1.0pre7? Or is the problem somewhere else?

None of the above is likely to be causing your problem. You should upgrade to pre7, but only if you can't bring yourself to build from CVS. Then if it still happens (and your RAM checks out) run with -v and post the output. Oh, and "Divx" is not a word we use in polite company:-) Martin _______________________________________________ MEncoder-users mailing list MEncoder-users@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mencoder-users

I certainly understand. The documentation does seem to be up-to-date, but I sometimes find it hard to understand how to do things and that's where the samples on the web become helpful. They lose their helpfulness when they're so out of date that they command line arguments are no longer valid. This of course, isn't your fault. It's simply the state of affairs and it makes things difficult. I did find a sample using XVid and will play with that and see how it goes. Thanks. Pete -----Original Message----- From: mencoder-users-bounces@mplayerhq.hu [mailto:mencoder-users-bounces@mplayerhq.hu] On Behalf Of Guillaume POIRIER Sent: Sunday, June 19, 2005 5:19 PM To: MEncoder usage discussions Subject: Re: [MEncoder-users] Mencoder finishes early on DVD to Divx encoding Hi, On 6/19/05, Pete Davis <pete@petedavis.net> wrote:

I've had trouble finding examples of how to encode with XVid. Frankly, I've found a lot of the documentation and examples around the web a bit hard to follow. I've pieced together my script from samples that I've found around the web. Many times I'll try options I find only to find they're no longer supported or that there's a new option for it. And since most of the examples on the web don't have a version number, it's hard to figure out which version they're writing for.

It would be nice if things didn't change so much making it a little easier to follow. [..]

Our doc should be reasonably up-to-date (either the HTML or the man page), and I'm working on an encoding guide for XviD. I unfortunately lack time, but it should be ready someday :-) Guillaume -- A woman isn't complete without a man. But where do you find a man - a real man - these days? -- Lauren Bacall My answer: Only at #mplayerdev on the freenode IRC network. _______________________________________________ MEncoder-users mailing list MEncoder-users@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mencoder-users

On Sun, 19 Jun 2005 21:43:03 -0500 "Pete Davis" <pete@petedavis.net> wrote:

When I'm am encoding a DVD (this doesn't happen when I re-encode an existing AVI file), Every 4 frames, I get a "1 duplicate frame(s)" message. What is this about? Is there anything I can do to prevent it?

The issue is that most DVDs are telecined. This is thoroughly explained in the mplayer docs here: http://mplayerhq.hu/DOCS/HTML/en/menc-feat-telecine.html

On Mon, 20 Jun 2005 17:01:27 -0500 "Pete Davis" <pete@petedavis.net> wrote:

My CDs are progressive, so I tried the -vf pullup,softskip options with the -ofps 24000/1001, but the video came out at 54 minutes instead of 44 minutes which obviously didn't match up with the 44 minutes of sound

That's typically what happens when you leave the "o" off of the "-ofps" switch (mencoder uses that value as the input fps). Try it again, and be careful that you've typed everything correctly.

On Mon, 20 Jun 2005 21:40:11 -0500 "Pete Davis" <pete@petedavis.net> wrote:

-ovc frameno

There's the important part you left out. MPlayer devs will stab you with red- hot pokers if they find out you're still using frameno... It almost always causes desyncs. In other words... don't do that!

Ah, I see, you can do video and audio at the same time now. Much better to do it in 2 passes than 3. Look, you guys keep saying, "Oh, how dare you do this?" or "I can't believe you're doing that." What am I supposed to do? Half the samples on the web are out of date (and I'm not talking the mplayer site, I'm talking about other sites with examples and how-tos). If people shouldn't be doing stuff, IT SHOULD BE CLEARLY DOCUMENTED what stuff shouldn't be used anymore. There should be a section of deprecated and "Don't do this anymore" stuff. There's no mention of frameno in the documentation. If people shouldn't be using it, TELL THEM. We don't just divine this information out of the clear blue sky. But that's just my opinion. Pete -----Original Message----- From: mencoder-users-bounces@mplayerhq.hu [mailto:mencoder-users-bounces@mplayerhq.hu] On Behalf Of RC Sent: Monday, June 20, 2005 10:11 PM To: MEncoder usage discussions Subject: Re: [MEncoder-users] Mencoder finishes early on DVD to Divx encoding On Mon, 20 Jun 2005 21:40:11 -0500 "Pete Davis" <pete@petedavis.net> wrote:

-ovc frameno

There's the important part you left out. MPlayer devs will stab you with red- hot pokers if they find out you're still using frameno... It almost always causes desyncs. In other words... don't do that! _______________________________________________ MEncoder-users mailing list MEncoder-users@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mencoder-users

On Tue, 21 Jun 2005 07:54:38 -0500 "Pete Davis" <pete@petedavis.net> wrote:

All I'm saying is if there's stuff that people SHOULDN'T be doing: Command that shouldn't be used or new commands that should be used instead, this stuff should be clearly listed in a very obvious place in the documentation because otherwise there's no way for the users to know what's unsupported, what's problematic, what's deprecated, etc.

A reasonable hope I suppose, the problem being finding someone willing to take responsibility for doing that. My view is that obsolete features should be removed or at least give a warning when running mplayer. The counter view would be that that would break existing scripts and provoke more complaints. On the other hand, this list exists and if you followed it you would over time pick up all the information you seek. Martin

Hi, On 6/21/05, Pete Davis <pete@petedavis.net> wrote:

I agree with you regarding following the list. The problem that arises there is that in that case, the same information tends to get repeated over and over again as new people come to the list.

And I can certainly understand the issue of resources to write the documentation. A project this size I'm sure could always use more resources.

One thing that might be a good idea and wouldn't be terribly time intensive, would be to put together a collection of scripts on the web site that perform various functions and act as examples. Instead of the authors having to do the work themselves, people on this list could simply contribute whatever scripts they've written. Someone could go through, decide which ones are good examples, maybe make minor edits to fix up ones that are almost good enough, and then make them available either on the web site or in the documentation, or both.

I think what's largely lacking in the documentation and what really helps people like me, who are new to mencoder out, is to see samples. Examples:

A script to turn a DVD movie into an AVI A script to turn a DVD TV Show into multiple AVIs A script to convert an existing AVI to a specific audio and video codec. A script to re-encode just audio A script to re-encode just video

Etc...

A dozen or two of these, with just a short paragraph describing what the script does, could demonstrate a pretty wide range of things that can be done and provide a good source for people to cut and paste their own.

Otherwise, people like me end up googling and finding out of date samples.

Anyway, just an idea. But again, the developers on the project could take advantage of the people on this list as a source and save themselves some work.

I think that this is a smart idea, and projects like wikipedia showed that it was really rewarding to trust people/users to document/talk about things. A wiki doc is better than no doc at all IMHO, and wiki make the update process a lot easier/flexible than our current system. But I know now everybody think like me. It would be a lot better if more people could send doc patches. A agree that wiki or blog is the fashion thingy of this time, just like was Java, Zope, or Linux at some point, but some of those proved to be more than just a trend, but filled an empty spot that other tools did not fill, so to speak. Guillaume -- A woman isn't complete without a man. But where do you find a man - a real man - these days? -- Lauren Bacall My answer: Only at #mplayerdev on the freenode IRC network.

...

A dozen or two of these, with just a short paragraph describing what the script does, could demonstrate a pretty wide range of things that can be done and provide a good source for people to cut and paste their own.

Except that I wouldn't call them scripts. Examples, yes, but not scripts. calling them scripts suggests they actually do something, while with video encoding, it all depends on the source and what you want to achieve. There is no single way to "turn a DVD movie into an AVI" or "to turn a DVD TV Show into multiple AVIs". Each case is unique and you have to know what you're doing if you are to do it right.

R.

Well, yes and no. For example, if you want to create a Divx of a TV series from DVD, it's pretty easy to come up with a single script that you can re-use for each chapter and each disc. And if your paragraph explanation describes the options and what the different flags represent, the user can then decide if maybe they want to change some of those options. They might look at another example and pick pieces from it and combine the two into what they need. Of course there's no single way to do it. Hell, there are a tons of options. But show some of the common scenarios. Show encoding a progressive DVD. Then show an interlaced. Show what options are different between the two. Show encoding to Divx. Then show encoding to XVid. Having whole examples, I think, is easier than digging through the docs and piecing together, oh, I need this flag, and this parameter, and I need that parameter. It's all scattered all over the docs. That's fine as a reference, but back it up with whole examples (and a lot of them) that show the process and describe what each example does. This example takes an existing AVI and re-codes the sound in MP3, or this example converts a DVD chapter into a 512x288 Divx with AC3 sound. Things like that. I'm not on a crusade or anything. You guys can do what you want. I simply think from a new user's point of view, it would be very helpful. Doing it in a Wiki is fine too. That actually has the advantage that people will probably be good about updating when parameters or functionality changes. Pete

-----Original Message----- From: mencoder-users-bounces@mplayerhq.hu [mailto:mencoder-users- bounces@mplayerhq.hu] On Behalf Of Rich Felker Sent: Tuesday, June 21, 2005 9:59 PM To: MEncoder usage discussions Subject: Re: [MEncoder-users] Mencoder finishes early on DVD to Divx encoding

...

...

...

A dozen or two of these, with just a short paragraph describing what

...

...

...

script does, could demonstrate a pretty wide range of things that can be done and provide a good source for people to cut and paste their own.

Except that I wouldn't call them scripts. Examples, yes, but not

On Tue, Jun 21, 2005 at 09:01:38PM -0500, Pete Davis wrote: the scripts.

...

...

calling them scripts suggests they actually do something, while with video encoding, it all depends on the source and what you want to achieve. There is no single way to "turn a DVD movie into an AVI" or "to turn a DVD TV Show into multiple AVIs". Each case is unique and you have to know what you're doing if you are to do it right.

R.

Well, yes and no. For example, if you want to create a Divx of a TV series from DVD, it's pretty easy to come up with a single script that you can re-use for each chapter and each disc. And if your paragraph explanation

For all the discs of ONE PARTICULAR SERIES, yes. Otherwise your statement is blatently false.

Nowhere did I suggest that the scripts could be used without changes. The idea is that they're examples. But yes, for all the discs in a particular series, a single script is reusable. With minor alterations, it can be used for another series.

...

describes the options and what the different flags represent, the user can then decide if maybe they want to change some of those options. They might look at another example and pick pieces from it and combine the two into what they need.

Of course there's no single way to do it. Hell, there are a tons of options. But show some of the common scenarios. Show encoding a progressive DVD. Then show an interlaced. Show what options are different between the two.

It's nowhere near that simple. You really cannot encode without understanding the content you're dealing with. Otherwise your results will come out very bad.

Where do I suggest that people do it in complete ignorance to the documentation or the format of the content. Again, the idea is to provide EXAMPLES, not something people will necessarily be able to use "out of the box". Nowhere do I suggest the documentation shouldn't be read or used. What I'm suggesting is something in addition to the existing documentation.

...

Show encoding to Divx.

No, divx is deprecated.

...

Then show encoding to XVid.

You left out the good choice, lavc...

...

Having whole examples, I think, is easier than digging through the docs and piecing together, oh, I need this flag, and this parameter, and I need that

Have you ever read the docs? They're very good.

Yes, it is good. What it's lacking, in my humble opinion, is examples. It's very descriptive and it goes into great detail, but encoding my first movie well took a lot longer than I think it had to. I think with more examples, I might have gotten up to speed faster and the documentation might have made a little more sense to me seeing things in context.

...

Doing it in a Wiki is fine too. That actually has the advantage that people will probably be good about updating when parameters or functionality changes.

The idea of wiki was already quickly shot down a long time ago. People wanting to contribute should send patches for the official documentation.

I don't care how it's done. I don't even care if it's done. All I'm offering is a suggestion. Take it, leave it. I don't really care.

Rich

_______________________________________________ MEncoder-users mailing list MEncoder-users@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mencoder-users

Rich, what we don't realize is that sending a patch to the list is not _that_ simple to Joe User: - you need to understand Nroff or XML, and know where the source is located so you may update it (not so straightforward when you only use binary packages), - then you need to know how to make a patch... (then you need to resend it because it's not a unified diff patch), - then you need to figure out where to send it... do you send it to Diego, whose is mail address is on the front page, do you sent it to the ML? - then you need to subscribe to the list, and send the patch (and resend a another mail because you forgot to attach the file)...

There are rules to do everything. Ours aren't that much restrictive. If the contributor doesn't follow them he doesn't have enough motivation, consequently the quality of his contribution will likely be low

At the end of this process, how many people are left?

Ok now, just consider what you have to do to contribute to a wiki: - create an account - log in - start to contribute on the page you just read one minute before !

... and possibily contribute unmediated bullshit. Not a great gain for the docs. Posting docs to the ML in the form of patches has the great advantage that developers who care enough will correct the parts of text that they consider wrong or incomplete, as it happened countless times.

Hi, sorry for my late reply... Guillaume POIRIER wrote:

On 6/22/05, Nico Sabbi <nsabbi@fastwebnet.it> wrote:

...

...

Rich, what we don't realize is that sending a patch to the list is not _that_ simple to Joe User: - you need to understand Nroff or XML, and know where the source is located so you may update it (not so straightforward when you only use binary packages),

no, imho you really don't have to. That is why we have ppl like diego and you in the doc team who understand it. See the last paragraph.

...

...

- then you need to know how to make a patch... (then you need to resend it because it's not a unified diff patch),

this is clearly stated in our documentation, so it is not a big problem. We just have to assume ppl can read. And if you don't send a unified diff on the 1st run, where is the problem with resending it? And again, i don't even think you always have to send patches.

...

...

- then you need to figure out where to send it... do you send it to Diego, whose is mail address is on the front page, do you sent it to the ML? - then you need to subscribe to the list, and send the patch (and resend a another mail because you forgot to attach the file)...

That might happen, but that's live.

...

There are rules to do everything. Ours aren't that much restrictive. If the contributor doesn't follow them he doesn't have enough motivation, consequently the quality of his contribution will likely be low.

Not necessarily. I think people are a lot more lazy than careless. If you ease up the process of contributing, chances are that they would be more of them, and that the errors would end-up getting fixed one day or the other.

We have to keep the high quality of our docs, because we always point users to look at them. If they grab (completely) wrong stuff from there they will start getting angry/annoyed.

...

...

At the end of this process, how many people are left?

Ok now, just consider what you have to do to contribute to a wiki: - create an account - log in - start to contribute on the page you just read one minute before !

... and possibily contribute unmediated bullshit. Not a great gain for the docs.

How about a disclaimer to state that the wiki is not officially supported then? We already do that for binary versions of MPlayer.

This would be the least thing to do, but i still don't like the idea. Again I don't like the idea of spreading wrong information, for example outdated information was the cause of this thread. IMHO We have to eliminate these sources of wrong information instead of creating new places where it can be hosted.

...

Posting docs to the ML in the form of patches has the great advantage that developers who care enough will correct the parts of text that they consider wrong or incomplete, as it happened countless times.

I do agree with that, but I still think that our process is not so simple and clear to the newcomer.

And this is exactly the point! We do have so many of the technical developers on the doc ml that we imho have to take advantage of it. So potential contributers should send their patches, experiences and corrections there and the devels with knowledge about the topic will correct mistakes if any (and often there are). Then the documentaion people can add it to the documentation _at the right place while keeping structure and consistency_. Alex (beastd)