Hi,

2011/5/26 Måns Rullgård <[email protected]>:
> "Ronald S. Bultje" <[email protected]> writes:
>> 2011/5/26 Måns Rullgård <[email protected]>:
>>> Kostya <[email protected]> writes:
>>>> On Thu, May 26, 2011 at 12:17:33PM +0100, Måns Rullgård wrote:
>>>>> "Ronald S. Bultje" <[email protected]> writes:
>>>>> > On Thu, May 26, 2011 at 7:10 AM, Kostya <[email protected]> 
>>>>> > wrote:
>>>>> >> On Thu, May 26, 2011 at 07:07:35AM -0400, Ronald S. Bultje wrote:
>>>>> >>> 2011/5/26 Måns Rullgård <[email protected]>:
>>>>> >>> > Kostya <[email protected]> writes:
>>>>> >>> >> On Wed, May 25, 2011 at 02:38:15PM -0400, Ronald S. Bultje wrote:
>>>>> >>> >>> ---
>>>>> >>> >>>  libswscale/swscale_internal.h |    8 --------
>>>>> >>> >>>  libswscale/utils.c            |   15 +++++++--------
>>>>> >>> >>>  2 files changed, 7 insertions(+), 16 deletions(-)
>>>>> >>> >>
>>>>> >>> >> ok, though I'd prefer giving a new variable more meaningful name
>>>>> >>> >
>>>>> >>> > +1
>>>>> >>>
>>>>> >>> Is "dst_buffer_width_bytes" (and dst_buffer_width_pixels) OK?
>>>>> >>
>>>>> >> dst_width should be enough IMO
>>>>> >
>>>>> > dstW exists already, let's name it "dst_width_aligned" or "dst_w_align".
>>>>>
>>>>> How about dst_stride or whatever we call this elsewhere?
>>>>
>>>> It's called VOFW elsewhere :) Really, it seems to be used for single 
>>>> purpose -
>>>> indicate the start of the second component in the single buffer for chroma.
>>>
>>> Why not use two chroma pointers (even if using a single buffer) like
>>> everywhere else?
>>
>> That's what most of the patch does. However, in some cases (the MMX
>> code, in particular), there's not enough registers for that, so I need
>> to untangle that in the future before this variable can do completely.
>
> Would there be enough registers if it were written in yasm instead of
> inline?  Just curious...

It's as if you can read my mind. Yes, there are, because yasm makes
spilling much easier.

Ronald
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to