| Message ID | 20190127234707.27689-8-sw@jkqxz.net |
|---|---|
| State | New |
| Headers | show |
2019-01-28 0:47 GMT+01:00, Mark Thompson <sw@jkqxz.net>: > + if (avctx->color_range == AVCOL_RANGE_MPEG) { > + av_log(avctx, AV_LOG_WARNING, "Input video does not appear " > + "to use full-range: output colours may be incorrect.\n"); The wording seems not ideal to me: Are you not sure if the encoder will produce correct output for mpeg-range jpeg? That's how it sounds to me... Carl Eugen
On 05/02/2019 13:27, Carl Eugen Hoyos wrote: > 2019-01-28 0:47 GMT+01:00, Mark Thompson <sw@jkqxz.net>: > >> + if (avctx->color_range == AVCOL_RANGE_MPEG) { >> + av_log(avctx, AV_LOG_WARNING, "Input video does not appear " >> + "to use full-range: output colours may be incorrect.\n"); > > The wording seems not ideal to me: > Are you not sure if the encoder will produce correct output for > mpeg-range jpeg? > That's how it sounds to me... The problem is that, unlike H.264 and other codecs, JPEG has no way to signal that the data are actually limited-range. The encode will preserve the values, but those values will not have the right interpretation at a remote end which only looks at the JPEG data. On the other hand, if signalled by some out-of-band method (perhaps the container, or you control both ends) everything is perfectly usable. I agree the message isn't particularly clear; do you have any thoughts about how it should be phrased? - Mark
2019-02-10 19:21 GMT+01:00, Mark Thompson <sw@jkqxz.net>: > On 05/02/2019 13:27, Carl Eugen Hoyos wrote: >> 2019-01-28 0:47 GMT+01:00, Mark Thompson <sw@jkqxz.net>: >> >>> + if (avctx->color_range == AVCOL_RANGE_MPEG) { >>> + av_log(avctx, AV_LOG_WARNING, "Input video does not appear " >>> + "to use full-range: output colours may be incorrect.\n"); >> >> The wording seems not ideal to me: >> Are you not sure if the encoder will produce correct output for >> mpeg-range jpeg? >> That's how it sounds to me... > > The problem is that, unlike H.264 and other codecs, JPEG has no way to > signal that the data are actually limited-range. The encode will preserve > the values, but those values will not have the right interpretation at a > remote end which only looks at the JPEG data. On the other hand, if > signalled by some out-of-band method (perhaps the container, or you control > both ends) everything is perfectly usable. > > I agree the message isn't particularly clear; do you have any thoughts about > how it should be phrased? Can't you add the same COM tag as mjpegenc_common.c does? If not it could be something like "mpeg-range jpeg will be undetectable". Carl Eugen
On 10/02/2019 18:49, Carl Eugen Hoyos wrote: > 2019-02-10 19:21 GMT+01:00, Mark Thompson <sw@jkqxz.net>: >> On 05/02/2019 13:27, Carl Eugen Hoyos wrote: >>> 2019-01-28 0:47 GMT+01:00, Mark Thompson <sw@jkqxz.net>: >>> >>>> + if (avctx->color_range == AVCOL_RANGE_MPEG) { >>>> + av_log(avctx, AV_LOG_WARNING, "Input video does not appear " >>>> + "to use full-range: output colours may be incorrect.\n"); >>> >>> The wording seems not ideal to me: >>> Are you not sure if the encoder will produce correct output for >>> mpeg-range jpeg? >>> That's how it sounds to me... >> >> The problem is that, unlike H.264 and other codecs, JPEG has no way to >> signal that the data are actually limited-range. The encode will preserve >> the values, but those values will not have the right interpretation at a >> remote end which only looks at the JPEG data. On the other hand, if >> signalled by some out-of-band method (perhaps the container, or you control >> both ends) everything is perfectly usable. >> >> I agree the message isn't particularly clear; do you have any thoughts about >> how it should be phrased? > > Can't you add the same COM tag as mjpegenc_common.c does? Hmm, I had not really thought about that. Do you know any reference for where this feature comes from and what might support it? It was added as dd4f8a04 in 2005, but the motivation for the change isn't recorded. Searching reveals little beyond references to the FFmpeg source code. Thanks, - Mark
On Sun, Feb 10, 2019 at 06:21:42PM +0000, Mark Thompson wrote: > On 05/02/2019 13:27, Carl Eugen Hoyos wrote: > > 2019-01-28 0:47 GMT+01:00, Mark Thompson <sw@jkqxz.net>: > > > >> + if (avctx->color_range == AVCOL_RANGE_MPEG) { > >> + av_log(avctx, AV_LOG_WARNING, "Input video does not appear " > >> + "to use full-range: output colours may be incorrect.\n"); > > > > The wording seems not ideal to me: > > Are you not sure if the encoder will produce correct output for > > mpeg-range jpeg? > > That's how it sounds to me... > > The problem is that, unlike H.264 and other codecs, JPEG has no way to signal that the data are actually limited-range. The encode will preserve the values, but those values will not have the right interpretation at a remote end which only looks at the JPEG data. On the other hand, if signalled by some out-of-band method (perhaps the container, or you control both ends) everything is perfectly usable. > > I agree the message isn't particularly clear; do you have any thoughts about how it should be phrased? It might be worse than that. assuming this code is used for mjpeg not just jpeg images then IIRC some mjpeg variants in avi use the mpeg style not full range. But i might misremember this is very long ago thx [...]
diff --git a/libavcodec/vaapi_encode_mjpeg.c b/libavcodec/vaapi_encode_mjpeg.c index 350800697f..e52f8b9820 100644 --- a/libavcodec/vaapi_encode_mjpeg.c +++ b/libavcodec/vaapi_encode_mjpeg.c @@ -460,6 +460,11 @@ static av_cold int vaapi_encode_mjpeg_configure(AVCodecContext *avctx) if (err < 0) return err; + if (avctx->color_range == AVCOL_RANGE_MPEG) { + av_log(avctx, AV_LOG_WARNING, "Input video does not appear " + "to use full-range: output colours may be incorrect.\n"); + } + return 0; }