On Mon, Aug 18, 2014 at 01:22:37PM -0400, Ronald S. Bultje wrote: > Hi, > > > On Mon, Aug 18, 2014 at 9:58 AM, Kieran Kunhya <kier...@obe.tv> wrote: > > > > How is it different? If you're interlacing-aware and call > > swscale_convert() > > > twice (once for each field, double stride each, alternate offset for > > second > > > call), isn't that the same? > > > > That would be true in the 422 domain, yes. In 420, the chroma planes > > are offset and this has to be taken into account with weighted > > averages as ilpack does. > > > You mean the centerpoint chroma location (top-left, top-middle, > middle-middle, etc.) respective to the set of luma pixels? If that's all, > that's a mere few seconds to implement in swscale, correctly for all cases > (you just offset the start of the filter). You don't need special filters > just for that. > > I bet Michael or me could do this in 15 minutes.
i had almost forgotten it but there is:
{ "src_v_chr_pos", "source vertical chroma position in luma grid/256" ,
OFFSET(src_v_chr_pos), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 512,
VE },
{ "src_h_chr_pos", "source horizontal chroma position in luma grid/256",
OFFSET(src_h_chr_pos), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 512,
VE },
{ "dst_v_chr_pos", "destination vertical chroma position in luma
grid/256" , OFFSET(dst_v_chr_pos), AV_OPT_TYPE_INT, { .i64 = -1 },
-1, 512, VE },
{ "dst_h_chr_pos", "destination horizontal chroma position in luma
grid/256", OFFSET(dst_h_chr_pos), AV_OPT_TYPE_INT, { .i64 = -1 },
-1, 512, VE },
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
