| Message ID | 201704041233.32226.cehoyos@ag.or.at |
|---|---|
| State | Accepted |
| Commit | c1616b454dc0c1fd391140e5dec1da0c3228b1e1 |
| Headers | show |
Hi, On Tue, Apr 4, 2017 at 6:33 AM, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote: > Hi! > > I believe attached patch makes FFmpeg a little more consistent with itself. Looks like it, yes. This patch does expose a bug we've discussed before though. Since the return value of handle_jpeg() is or()'ed into src_range and dst_range, it overwrites an explicit zero range requested by the user. So If my input is a h264 grayscale file with color_range in VUI explicitly set to MPEG-range, I believe swscale does the wrong thing and the output color will be distorted. (This is orthogonal to your patch, but may be worth of a trac ticket.) Ronald
2017-04-04 14:01 GMT+02:00 Ronald S. Bultje <rsbultje@gmail.com>: > Hi, > > On Tue, Apr 4, 2017 at 6:33 AM, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote: > >> Hi! >> >> I believe attached patch makes FFmpeg a little more consistent with itself. > > > Looks like it, yes. Patch applied. Thank you for the analysis, Carl Eugen
Hi, On Tue, Apr 4, 2017 at 8:01 AM, Ronald S. Bultje <rsbultje@gmail.com> wrote: > On Tue, Apr 4, 2017 at 6:33 AM, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote: > >> I believe attached patch makes FFmpeg a little more consistent with >> itself. > > > Looks like it, yes. > > This patch does expose a bug we've discussed before though. Since the > return value of handle_jpeg() is or()'ed into src_range and dst_range, it > overwrites an explicit zero range requested by the user. So If my input is > a h264 grayscale file with color_range in VUI explicitly set to MPEG-range, > I believe swscale does the wrong thing and the output color will be > distorted. > > (This is orthogonal to your patch, but may be worth of a trac ticket.) > Was the ticket created? This is a fairly important bug. Ronald
2017-04-13 0:09 GMT+02:00 Ronald S. Bultje <rsbultje@gmail.com>: > Hi, > > On Tue, Apr 4, 2017 at 8:01 AM, Ronald S. Bultje <rsbultje@gmail.com> wrote: > >> On Tue, Apr 4, 2017 at 6:33 AM, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote: >> >>> I believe attached patch makes FFmpeg a little more consistent with >>> itself. >> >> >> Looks like it, yes. >> >> This patch does expose a bug we've discussed before though. Since the >> return value of handle_jpeg() is or()'ed into src_range and dst_range, it >> overwrites an explicit zero range requested by the user. So If my input is >> a h264 grayscale file with color_range in VUI explicitly set to MPEG-range, >> I believe swscale does the wrong thing and the output color will be >> distorted. >> >> (This is orthogonal to your patch, but may be worth of a trac ticket.) > > Was the ticket created? This is a fairly important bug. Not by me (I don't even know how to reproduce). Carl Eugen
On 4/12/2017 6:01 PM, Carl Eugen Hoyos wrote: > 2017-04-04 14:01 GMT+02:00 Ronald S. Bultje <rsbultje@gmail.com>: >> Hi, >> >> On Tue, Apr 4, 2017 at 6:33 AM, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote: >> >>> Hi! >>> >>> I believe attached patch makes FFmpeg a little more consistent with itself. >> >> >> Looks like it, yes. > > Patch applied. > > Thank you for the analysis, Carl Eugen This broke gray10/12 on every filter-pixdesc and filter-pixfmts test. You should update the refs, assuming the changes are intended. Also, please make sure to run fate before pushing changes like this.
2017-04-13 3:53 GMT+02:00 James Almer <jamrial@gmail.com>: > On 4/12/2017 6:01 PM, Carl Eugen Hoyos wrote: >> 2017-04-04 14:01 GMT+02:00 Ronald S. Bultje <rsbultje@gmail.com>: >>> Hi, >>> >>> On Tue, Apr 4, 2017 at 6:33 AM, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote: >>> >>>> Hi! >>>> >>>> I believe attached patch makes FFmpeg a little more consistent with itself. >>> >>> >>> Looks like it, yes. >> >> Patch applied. >> >> Thank you for the analysis, Carl Eugen > > This broke gray10/12 on every filter-pixdesc and filter-pixfmts test. > You should update the refs, assuming the changes are intended. Done, they are. Thank you, Carl Eugen
diff --git a/libswscale/utils.c b/libswscale/utils.c index 4c9b53b..17c9967 100644 --- a/libswscale/utils.c +++ b/libswscale/utils.c @@ -1016,6 +1016,10 @@ static int handle_jpeg(enum AVPixelFormat *format) return 1; case AV_PIX_FMT_GRAY8: case AV_PIX_FMT_YA8: + case AV_PIX_FMT_GRAY10LE: + case AV_PIX_FMT_GRAY10BE: + case AV_PIX_FMT_GRAY12LE: + case AV_PIX_FMT_GRAY12BE: case AV_PIX_FMT_GRAY16LE: case AV_PIX_FMT_GRAY16BE: case AV_PIX_FMT_YA16BE: diff --git a/libswscale/version.h b/libswscale/version.h index 259ae7a..dcdc85b 100644 --- a/libswscale/version.h +++ b/libswscale/version.h @@ -28,7 +28,7 @@ #define LIBSWSCALE_VERSION_MAJOR 4 #define LIBSWSCALE_VERSION_MINOR 7 -#define LIBSWSCALE_VERSION_MICRO 100 +#define LIBSWSCALE_VERSION_MICRO 101 #define LIBSWSCALE_VERSION_INT AV_VERSION_INT(LIBSWSCALE_VERSION_MAJOR, \ LIBSWSCALE_VERSION_MINOR, \
Hi! I believe attached patch makes FFmpeg a little more consistent with itself. Please comment, Carl Eugen From 5e1239a6bf3d97b360a447bd88da2e0477ffc0c9 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos <cehoyos@ag.or.at> Date: Tue, 4 Apr 2017 12:24:41 +0200 Subject: [PATCH] lsws/utils: Make gray10 and gray12 full-scale like gray8 and gray16. --- libswscale/utils.c | 4 ++++ libswscale/version.h | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-)