[FFmpeg-devel] [PATCH] Remove swscale_internal.h:fmt_depth()

Måns Rullgård mans
Mon Jan 18 00:27:09 CET 2010


Ramiro Polla <ramiro.polla at gmail.com> writes:

> 2010/1/17 M?ns Rullg?rd <mans at mansr.com>:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>>
>>> On Sun, Jan 17, 2010 at 11:36:26PM +0100, Stefano Sabatini wrote:
>>>> On date Sunday 2010-01-17 22:04:47 +0100, Michael Niedermayer encoded:
>>>> > On Sun, Jan 17, 2010 at 06:46:40PM +0100, Stefano Sabatini wrote:
>>>> > > On date Saturday 2010-01-16 17:08:48 -0200, Ramiro Polla encoded:
>>>> > > > Hi,
>>>> > > >
>>>> > > > On Sat, Jan 16, 2010 at 4:59 PM, Stefano Sabatini
>>>> > > > <stefano.sabatini-lala at poste.it> wrote:
>>>> > > > > Hi, I'm aware this patch introduces a slow-down, an idea would be to
>>>> > > > > initialize a ff_bits_per_pixel array during the init phase, and then
>>>> > > > > use a function of the kind:
>>>> > > > >
>>>> > > > > static inline int fmt_depth(int fmt)
>>>> > > > > {
>>>> > > > > ? ?return ff_bits_per_pixel[fmt];
>>>> > > > > }
>>>> > > > >
>>>> > > > > Would be that acceptable?
>>>> > > > > In this case can you suggest where to initialize stuff?
>>>> > > >
>>>> > > > I think all code that uses fmt_depth currently should eventually be
>>>> > > > moved to some init code that's only run once, and so a small slow-down
>>>> > > > wouldn't be a problem.
>>>> > >
>>>> > > Check the attached: smaller, more extensible, faster, the price is a
>>>> > > little more bloat in the context.
>>>> > >
>>>> >
>>>> > > Regression test passed.
>>>> >
>>>> > if(regression == swscale_example) patch ok
>>>> > else not ok
>>>>
>>>> I had to hack swscale-example since the recent change in pixfmt.h
>>>> broke it (BTW does it ever worked with big-endian system?), anyway
>>>
>>> i suspect yes
>>> but people are always eager to fix bugs at the wrong place and its so
>>> easy to flip a rgb<->bgr that i cannot test
>>>
>>>> what should I test with swscale-example?
>>>
>>> everything you plan to commit to swscale:)
>>
>> We should hook it up in make test somehow. ?Can't be hard.
>
> Last time I checked the output from swscale-example was about 6Mb. If
> we remove the useless info it can be stripped down to some 2Mb or so,
> but it's still a lot. Removing more than that removes useful
> information from the output.

We could hash it and at least detect that it broke.

-- 
M?ns Rullg?rd
mans at mansr.com



More information about the ffmpeg-devel mailing list