[FFmpeg-devel] [PATCH] swscale/utils: Remove bpc==8 gating init_range_convert

[Neil Birkbeck]

On Sat, Dec 2, 2017 at 5:25 PM, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:

> 2017-12-01 20:08 GMT+01:00 Neil Birkbeck <neil.birkbeck at gmail.com>:
> > On Thu, Nov 30, 2017 at 9:52 AM, Michael Niedermayer wrote:
>
> >> > For that sample, I feel like it may be incorrectly tagged as pc/full.
> >>
> >> is it stored in the file or taken from:
> >> ff_generate_avci_extradata()
> >> maybe theres a bug in the AVCIntra handling
> >
> > It seems avci100_1080i_extradata may be the one that is signalling full
> > range for the AVCI100.mov sample. I tested changing the range flag:
> > -        0x3c, 0x60, 0x20, 0x20, 0x28, 0x00, 0x00, 0x03,
> > +        0x3c, 0x20, 0x20, 0x20, 0x28, 0x00, 0x00, 0x03,
>
> If you believe it is safe (or a bug), please change it.
>

I've looked at a few avci-100 files that I could find, and the ones I came
across had data that appeared to be tv range. Unless there is some spec
that says it should be pc/full, I'd say tv (or unspecified) may be a better
default. Let me look into the other avci modes to confirm.

I also attached an updated patch with fate tests. In it, for each
configuration {8-bit/10-bit, scaled/unscaled}, the checksum should be the
same when in_range is set explicitly (or implicitly). And output explicit
to tv or unset is is the same. There is still the issue of whether having
out_range be "unspecified" should give "tv" range (that is what happens for
8-bit at the moment).

Samples are here:
https://github.com/nbirkbeck/ffmpeg-test-samples/tree/master/color-range/data

In the patch, I'd put them in ffmpeg-synthetic/color.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-swscale-utils-Remove-bpc-8-gating-init_range_convert.patch
Type: text/x-patch
Size: 22408 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171207/c9176839/attachment.bin>