Opened 2 years ago

Closed 3 months ago

Last modified 3 months ago

#8404 closed defect (fixed)

“ffmpeg -i input -c:v libx264rgb output”: ffmpeg sets the color range to “tv” instead of “pc”

Reported by: Kdmeizk Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


ffmpeg -h encoder=libx264rgb
Encoder libx264rgb [libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 RGB]:
    General capabilities: delay threads 
    Threading capabilities: auto
    Supported pixel formats: bgr0 bgr24 rgb24
cat libavcodec/libx264.c
    x4->params.vui.b_fullrange = avctx->pix_fmt == AV_PIX_FMT_YUVJ420P ||
                                 avctx->pix_fmt == AV_PIX_FMT_YUVJ422P ||
                                 avctx->pix_fmt == AV_PIX_FMT_YUVJ444P ||
                                 avctx->color_range == AVCOL_RANGE_JPEG;

Change History (4)

comment:1 by Jun Zhao, 2 years ago

in reply to:  1 comment:2 by Jun Zhao, 2 years ago

Replying to mypopy:

Pls try the patch:

ignore the patch, you can change the color range like the command:

ffmpeg -i input -c:v libx264rgb -color_range pc output

comment:3 by gdgsdg123, 2 years ago

What's the practical impact of this issue?..

I've tested some input sources with PNG and libx264rgb (without setting -color_range), all compare groups yielded a SSIM of 1.

comment:4 by Balling, 3 months ago

Resolution: fixed
Status: newclosed

And so what? FFmpeg does not support limited rgb, it is prohibited to use it. BTW, dumb. That is #1851

all compare groups yielded a SSIM of 1.

That is again just because see above. And BTW that does not happen anymore when input is gdigrub, for example. Fixed by Jan here and for x265 here

Last edited 3 months ago by Balling (previous) (diff)
Note: See TracTickets for help on using tickets.