[MPlayer-dev-eng] optimized color space implementation?

[Marc Hoffman]

On Mar 7, 2004, at 5:01 PM, D Richard Felker III wrote:

> On Sun, Mar 07, 2004 at 04:28:34PM -0500, Marc Hoffman wrote:
>>
>> On Mar 7, 2004, at 12:32 PM, Michael Niedermayer wrote:
>>
>>> Hi
>>>
>>> On Sunday 07 March 2004 15:38, Marc Hoffman wrote:
>>>> Is it acceptable to truncate the number of pixels in a horizontal 
>>>> scan
>>>> to a multiple of 32 to simplify the vector coding loops?
>>>>
>>>> e.g. 720 becomes 704.
>>> no, either write loops which dont have such a limitation or round up,
>>> and use
>>> the c converter for the last line
>>
>> Ok can I assume that I always get a multiple of 16 pixels, or is that
>> just a bad assumption as well.
>
> You should just process as much of the image as you can under the
> assumptions you want to make, and then make sure the C code handles
> the remainder of the image!
>
>> And can i assume an even number of scanlines as well?
>
> IMO you should be able to assume this since 4:2:0 with an odd number
> of scanlines makes absolutely no sense.....but I dunno if it's
> acceptable for ffmpeg. But if you take the approach I suggested above
> it shouldn't matter.
>
> Rich
>
>
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

Yes I agree 420 would never have an odd number of lines, actually I 
don't think we would see very much video which is not some multiple of 
16x16, accept for that DV jpeg stuff which I believe things are still 
16 horizontal but vertical can be 8.

I guess I need to become curious as to where the software scalar sits 
in the video pipe, if the RGB converter is done post scaling then this 
might need to done anyways.  It looks like the MMX scalar is combined 
with the RGB converter I guess I need to dig into that code set.

Any direction would be appreciated.