[FFmpeg-devel] [FFmpeg-devel-irc] IRC log for 2010-09-17
Sat Sep 25 20:12:19 CEST 2010
On Fri, Sep 24, 2010 at 11:35 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Fri, Sep 24, 2010 at 02:11:02AM -0700, Jason Garrett-Glaser wrote:
>> On Thu, Sep 23, 2010 at 8:37 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > On Thu, Sep 23, 2010 at 08:20:54PM -0700, Jason Garrett-Glaser wrote:
>> >> >> [19:48:17] <Dark_Shikari> we're going to have to write a downsampling/dither module since swscale doesn't have one
>> >> >
>> >> > swscale has that since eternity
>> >> Since when can swscale output to 10-bit or 9-bit, given 16-bit input?
>> > 16bit formats are amongth the supported input and output formats
>> > converting to 10 or 9 bit should then just be a matter of changing scaling
>> > and cliping which doesnt seem hard.
>> > if you say precissely what you need i could try to look into where the problem
>> > is but i cant promisse that ill have the time to look into it soon
>> We need 16-bit -> 8, 9, and 10 bit conversion with dithering. ?It's
>> not hard, but the issue is primarily an API one, unless we already
>> have a way of telling swscale how many bits to output to.
> ok, would a
> ?* Allocates and returns a SwsContext. You need it to perform
> ?* scaling/conversion operations using sws_scale().
> ?* @return a pointer to an allocated context, or NULL in case of error
> struct SwsContext *sws_getContext(SwsParams *params);
> solve this ?
> if yes i can add this together with AVOptions access to it, this also should
> squish a few issues stefano had with AVOptions in relation to sws
I think it's a great idea to update libswscale's api. What about
dropping the camelCase from the names while we're at it? (like
More information about the ffmpeg-devel