[PATCH] document a couple more x264 options in mencoder.xml
Added entries for the me (motion estimation search algorithm) and 4x4mv options. For a future patch: the subq discussion needs to be moved down to the next section.
Hi, On 5/30/05, Jeff Clagg <snacky@ikaruga.co.uk> wrote:
Added entries for the me (motion estimation search algorithm) and 4x4mv options.
Looks good to me, except that I think it would be a good idea to explain what each me option means: (1=diamond search, radius 1, 2=hexagon search, radius 2, 3=uneven multi-hexagon search) Other than that, I'll wait until someone with more English knowledge comments on it to apply it. -- Jazz music and Open Source development looks like chaos to an untrained eye, but end-up producing masterpieces like "Kind of Blue" and "MPlayer". That's why I love them both... -- John Coltrane
On Mon, May 30, 2005 at 11:16:33PM +0200, Guillaume POIRIER wrote:
On 5/30/05, Jeff Clagg <snacky@ikaruga.co.uk> wrote:
Added entries for the me (motion estimation search algorithm) and 4x4mv options.
Looks good to me, except that I think it would be a good idea to explain what each me option means: (1=diamond search, radius 1, 2=hexagon search, radius 2, 3=uneven multi-hexagon search)
Other than that, I'll wait until someone with more English knowledge comments on it to apply it.
Jeff's English composition skills are completely above reproach. Commit whenever you feel like it. Diego
Diego Biurrun wrote:
On Mon, May 30, 2005 at 11:16:33PM +0200, Guillaume POIRIER wrote:
On 5/30/05, Jeff Clagg <snacky@ikaruga.co.uk> wrote:
Added entries for the me (motion estimation search algorithm) and 4x4mv options.
Looks good to me, except that I think it would be a good idea to explain what each me option means: (1=diamond search, radius 1, 2=hexagon search, radius 2, 3=uneven multi-hexagon search)
Other than that, I'll wait until someone with more English knowledge comments on it to apply it.
Jeff's English composition skills are completely above reproach. Commit whenever you feel like it.
Other than a couple of nitpicks which are mostly "yes, it's good English, but I'm not sure it's sufficiently idiot-proof clear", and which could well be just a product of lack of sleep on my part, I pretty much agree. I have no objections to committing this as it stands. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. A government exists to serve its citizens, not to control them.
On Mon, May 30, 2005 at 11:16:33PM +0200, Guillaume POIRIER wrote:
Looks good to me, except that I think it would be a good idea to explain what each me option means: (1=diamond search, radius 1, 2=hexagon search, radius 2, 3=uneven multi-hexagon search)
I don't think I mind seeing this explained in the xml docs, but one of the reasons I didn't bother is because I can't improve on the explanation in the manpage, and readers are explicitly encouraged to go look at it. There's a related issue here, which is separating the function of the man page and the function of the xml docs. With lavc, it's now pretty much an accomplished fact that the manpage is an exhaustive list of all options, with terse (but well-worded) technical explanations of what each option actually does. The xml docs pick out the few that are of highest interest to most end-users, and discuss their impacts on speed and quality, and how this impact differs depending on the source, and so on. Anyway, my intention was to get straight to the point: results are the first thing the user cares about. This is why I'm trying to establish a pattern of listing example speed and PSNR changes for each option, but I don't bother so much with technical details. Notice I also never explained what subq, frameref, or b_pyramid really do, either. If users want to know, there are excellent explanations in the man page.
Hi, On 5/31/05, Jeff Clagg <snacky@ikaruga.co.uk> wrote:
On Mon, May 30, 2005 at 11:16:33PM +0200, Guillaume POIRIER wrote:
Looks good to me, except that I think it would be a good idea to explain what each me option means: (1=diamond search, radius 1, 2=hexagon search, radius 2, 3=uneven multi-hexagon search)
I don't think I mind seeing this explained in the xml docs, but one of the reasons I didn't bother is because I can't improve on the explanation in the manpage, and readers are explicitly encouraged to go look at it.
There's a related issue here, which is separating the function of the man page and the function of the xml docs. With lavc, it's now pretty much an accomplished fact that the manpage is an exhaustive list of all options, with terse (but well-worded) technical explanations of what each option actually does.
BTW, if you can come up with better descriptions for lavc options, you're welcome to do so. (yeah, I know I'm the one who was told to do so, but I guess it doesn't hurt to unify our workforce)
The xml docs pick out the few that are of highest interest to most end-users, and discuss their impacts on speed and quality, and how this impact differs depending on the source, and so on.
Yeah, I guess you're right. All the more since the me options may still evolve, which means that both the xml doc and the man page would have to be kept in sync, which means more work...
Anyway, my intention was to get straight to the point: results are the first thing the user cares about. This is why I'm trying to establish a pattern of listing example speed and PSNR changes for each option, but I don't bother so much with technical details. Notice I also never explained what subq, frameref, or b_pyramid really do, either. If users want to know, there are excellent explanations in the man page.
I agree. Regards, Guillaume -- Jazz music and Open Source development looks like chaos to an untrained eye, but end-up producing masterpieces like "Kind of Blue" and "MPlayer". That's why I love them both... -- John Coltrane
On Tue, May 31, 2005 at 09:38:14AM +0200, Guillaume POIRIER wrote:
On 5/31/05, Jeff Clagg <snacky@ikaruga.co.uk> wrote:
There's a related issue here, which is separating the function of the man page and the function of the xml docs. With lavc, it's now pretty much an accomplished fact that the manpage is an exhaustive list of all options, with terse (but well-worded) technical explanations of what each option actually does.
BTW, if you can come up with better descriptions for lavc options, you're welcome to do so. (yeah, I know I'm the one who was told to do so, but I guess it doesn't hurt to unify our workforce)
Yes. The man page is exhaustive, but it is far from well-worded. I'd call the lavc option descriptions very terse but probably correct. Just compare with the xvid and x264 option descriptions, they're much better. And yes, any help improving them is much appreciated :-) Diego
Hi, On 5/31/05, Diego Biurrun <diego@biurrun.de> wrote:
On Tue, May 31, 2005 at 09:38:14AM +0200, Guillaume POIRIER wrote:
On 5/31/05, Jeff Clagg <snacky@ikaruga.co.uk> wrote:
There's a related issue here, which is separating the function of the man page and the function of the xml docs. With lavc, it's now pretty much an accomplished fact that the manpage is an exhaustive list of all options, with terse (but well-worded) technical explanations of what each option actually does.
BTW, if you can come up with better descriptions for lavc options, you're welcome to do so. (yeah, I know I'm the one who was told to do so, but I guess it doesn't hurt to unify our workforce)
Yes. The man page is exhaustive, but it is far from well-worded. I'd call the lavc option descriptions very terse but probably correct. Just compare with the xvid and x264 option descriptions, they're much better. And yes, any help improving them is much appreciated :-)
BTW, I followed your advice and subscribed to MEncoder-user ML, which allowed me to hear about lavc's "nr" (noise reduction) encoding option, and its sane range, thanks to the tests made by RC. Given that it have a great impact PSNR-wise, and doesn't cost much, I guess it's one of those options that we should advise to use. I'll update the man page ASAP, and the XML docs when I have more time. Regards, Guillaume -- Jazz music and Open Source development looks like chaos to an untrained eye, but end-up producing masterpieces like "Kind of Blue" and "MPlayer". That's why I love them both... -- John Coltrane
Sorry, the last patch has a typo (s/ony/only/)
Hi, On 5/31/05, Jeff Clagg <snacky@ikaruga.co.uk> wrote:
Sorry, the last patch has a typo (s/ony/only/)
Applied, thanks. Guillaume -- Jazz music and Open Source development looks like chaos to an untrained eye, but end-up producing masterpieces like "Kind of Blue" and "MPlayer". That's why I love them both... -- John Coltrane
participants (4)
-
Diego Biurrun -
Guillaume POIRIER -
Jeff Clagg -
The Wanderer