[PATCH] more detailed description of brd_scale
I'll commit this tomorrow if there are no objections/corrections. -Corey Index: DOCS/man/en/mplayer.1 =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/man/en/mplayer.1,v retrieving revision 1.1214 diff -u -r1.1214 mplayer.1 --- DOCS/man/en/mplayer.1 24 Jan 2006 22:44:34 -0000 1.1214 +++ DOCS/man/en/mplayer.1 27 Jan 2006 22:40:01 -0000 @@ -6897,8 +6897,11 @@ .TP .B brd_scale=<0\-10> Downscales frames for dynamic B-frame decision (default: 0). -Speed should increase by a factor of 4 every time brd_scale is increased -by 1. +Each time brd_scale is increased by one, the frame dimensions are +divided by two, which improves speed by a factor of four. +A given brd_scale value will work only if both dimensions can be evenly +divided by two that many times. +In other words, the dimensions must both be a multiple of 2^brd_scale. . .TP .B bidir_refine=<0\-4>
Corey Hickey wrote:
I'll commit this tomorrow if there are no objections/corrections.
-Corey
------------------------------------------------------------------------
Index: DOCS/man/en/mplayer.1 =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/man/en/mplayer.1,v retrieving revision 1.1214 diff -u -r1.1214 mplayer.1 --- DOCS/man/en/mplayer.1 24 Jan 2006 22:44:34 -0000 1.1214 +++ DOCS/man/en/mplayer.1 27 Jan 2006 22:40:01 -0000 @@ -6897,8 +6897,11 @@ .TP .B brd_scale=<0\-10> Downscales frames for dynamic B-frame decision (default: 0). -Speed should increase by a factor of 4 every time brd_scale is increased -by 1. +Each time brd_scale is increased by one, the frame dimensions are +divided by two, which improves speed by a factor of four. +A given brd_scale value will work only if both dimensions can be evenly +divided by two that many times. +In other words, the dimensions must both be a multiple of 2^brd_scale.
It is not possible for two dimensions to be *a* multiple of X, unless the dimensions are equal. The least ugly way to fix that (very minor) problem would be to say "multiples" instead, and possiby drop the "both". Other than that, looks good to me. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
The Wanderer wrote:
+In other words, the dimensions must both be a multiple of 2^brd_scale.
It is not possible for two dimensions to be *a* multiple of X, unless the dimensions are equal. The least ugly way to fix that (very minor) problem would be to say "multiples" instead, and possiby drop the "both".
Right, good catch.
Other than that, looks good to me.
I might have misunderstood an email from Michael, so I'm going to postpone applying this until I know for sure I have it right. -Corey
Hi On Sat, Jan 28, 2006 at 12:33:16AM -0800, Corey Hickey wrote:
The Wanderer wrote:
+In other words, the dimensions must both be a multiple of 2^brd_scale.
It is not possible for two dimensions to be *a* multiple of X, unless the dimensions are equal. The least ugly way to fix that (very minor) problem would be to say "multiples" instead, and possiby drop the "both".
Right, good catch.
Other than that, looks good to me.
I might have misunderstood an email from Michael, so I'm going to postpone applying this until I know for sure I have it right.
odd dimendions _might_ work but are not recommanded in YV12 do 3x3 luma samples have 1x1 chroma or 2x2 chroma? the correct awnser is 2x2 but width>>1 and height>>1 would end up with 1x1 now if we try to convert some luma x,y to chroma by x>>1,y>>1 we would again need 2x2 chroma ... odd dimensions and YV12 works but its not a good idea, for decoding you have no choice, but for encoding you do, so if someone volunteers to maintain this / fix all related bugs fine, but i wont be that one [...] -- Michael
Michael Niedermayer wrote:
odd dimendions _might_ work but are not recommanded in YV12 do 3x3 luma samples have 1x1 chroma or 2x2 chroma? the correct awnser is 2x2 but width>>1 and height>>1 would end up with 1x1 now if we try to convert some luma x,y to chroma by x>>1,y>>1 we would again need 2x2 chroma ... odd dimensions and YV12 works but its not a good idea, for decoding you have no choice, but for encoding you do, so if someone volunteers to maintain this / fix all related bugs fine, but i wont be that one
Ok, I get it now. Here's a new patch with the correct explanation. -Corey Index: DOCS/man/en/mplayer.1 =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/man/en/mplayer.1,v retrieving revision 1.1214 diff -u -r1.1214 mplayer.1 --- DOCS/man/en/mplayer.1 24 Jan 2006 22:44:34 -0000 1.1214 +++ DOCS/man/en/mplayer.1 28 Jan 2006 22:50:50 -0000 @@ -6897,8 +6897,13 @@ .TP .B brd_scale=<0\-10> Downscales frames for dynamic B-frame decision (default: 0). -Speed should increase by a factor of 4 every time brd_scale is increased -by 1. +Each time brd_scale is increased by one, the frame dimensions are +divided by two, which improves speed by a factor of four. +Both dimensions of the fully downscaled frame must be even numbers, so +brd_scale=1 requires the original dimensions to be multiples of four, +brd_scale=2 requires multiples of eight, etc. +In other words, the dimensions of the original frame must both be +divisible by 2^(brd_scale+1) with no remainder. . .TP .B bidir_refine=<0\-4>
Corey Hickey wrote:
Michael Niedermayer wrote:
odd dimendions _might_ work but are not recommanded in YV12 do 3x3 luma samples have 1x1 chroma or 2x2 chroma? the correct awnser is 2x2 but width>>1 and height>>1 would end up with 1x1 now if we try to convert some luma x,y to chroma by x>>1,y>>1 we would again need 2x2 chroma ... odd dimensions and YV12 works but its not a good idea, for decoding you have no choice, but for encoding you do, so if someone volunteers to maintain this / fix all related bugs fine, but i wont be that one
Ok, I get it now.
Here's a new patch with the correct explanation.
I see no problems; I'd say go for it. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
The Wanderer wrote:
odd dimendions _might_ work but are not recommanded in YV12 do 3x3 luma samples have 1x1 chroma or 2x2 chroma? the correct awnser is 2x2 but width>>1 and height>>1 would end up with 1x1 now if we try to convert some luma x,y to chroma by x>>1,y>>1 we would again need 2x2 chroma ... odd dimensions and YV12 works but its not a good idea, for decoding you have no choice, but for encoding you do, so if someone volunteers to maintain this / fix all related bugs fine, but i wont be that one
Ok, I get it now.
Here's a new patch with the correct explanation.
I see no problems; I'd say go for it.
Applied. -Corey
participants (3)
-
Corey Hickey -
Michael Niedermayer -
The Wanderer