No support for coloured emoji with drawtext filter

[Illya]

Summary of the bug:
Using the drawtext filter and a capable emoji font, the colour is changed by whatever the fontcolor parameter is. The emoji should stay it's original colour (in this case, red), rather than being changed.

How to reproduce:

% ffmpeg -t 100 -s 640x480 -f rawvideo -pix_fmt rgb24 -r 25 -i /dev/zero -vf drawtext="emojione.ttf: text='Nice 💯 !': fontcolor=white: fontsize=24: x=(w-text_w)/2: y=(h-text_h-line_h)/2" -codec:a copy output.mp4 -y
ffmpeg version N-81321-g17eb004 Copyright (c) 2000-2016 the FFmpeg developers
  built with Apple LLVM version 7.3.0 (clang-703.0.31)
  configuration: --samples=fate --enable-libopenmpt --enable-libdc1394 --enable-libfreetype --enable-fontconfig
  libavutil      55. 28.100 / 55. 28.100
  libavcodec     57. 51.100 / 57. 51.100
  libavformat    57. 46.100 / 57. 46.100
  libavdevice    57.  0.102 / 57.  0.102
  libavfilter     6. 51.100 /  6. 51.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
Input #0, rawvideo, from '/dev/zero':
  Duration: N/A, start: 0.000000, bitrate: 184320 kb/s
    Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 640x480, 184320 kb/s, 25 tbr, 25 tbn, 25 tbc
[mp4 @ 0x7f9495800600] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
Output #0, mp4, to 'output.mp4':
  Metadata:
    encoder         : Lavf57.46.100
    Stream #0:0: Video: mpeg4 ( [0][0][0] / 0x0020), yuv420p, 640x480, q=2-31, 200 kb/s, 25 fps, 12800 tbn, 25 tbc
    Metadata:
      encoder         : Lavc57.51.100 mpeg4
    Side data:
      cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: -1
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> mpeg4 (native))
Press [q] to stop, [?] for help
frame= 2500 fps=545 q=2.0 Lsize=    1209kB time=00:01:39.96 bitrate=  99.1kbits/s speed=21.8x
video:1197kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.954954%

[Illya]

output of command

[Carl Eugen Hoyos]

Replying to Illya:

Using the drawtext filter and a capable emoji font, the colour is changed by whatever the fontcolor parameter is.

The emoji should stay it's original colour (in this case, red), rather than being changed.

Why?

[Illya]

Replying to cehoyos:

Why?

because that's how emoji is meant to be rendered

[Carl Eugen Hoyos]

How would the drawtext filter know that the font you provided contains emojis and not characters?

[Illya]

The glyph emoji characters have the suffix 0xFE0F, while the text styled ones have the suffix 0xFE0E

[Carl Eugen Hoyos]

Am I correct that this is (only) related to libfreetype and has nothing to do with FFmpeg?

[Illya]

Freetype has had support for rendering color emoji since version 2.5, so I assumed it was an FFmpeg issue (e.g. the drawtext filter not using the full capability)

[Cigaes]

Replying to cehoyos:

More or less. When Freetype implements it, FFmpeg needs to implement the corresponding glue to do the color blending of glyph.

For now, IIUC, colored emojis are implemented in various non-standard and incompatible extensions to font formats, I wound not recommend to hold one's breath.

[Illya]

Note: NotoColorEmoji (by Google) is probably a better font than emojione for testing

[justswim]

Any update on this?

[space-pope]

As pointed out above, Freetype has support (draft support, at least) for color emoji. Is integrating it as simple as adding ​the `FT_LOAD_COLOR` flag to drawtext's ft_load_flags param?