Support writing the mastering display and CLL SEI messages

Adds --mastering-display and --cll to x264cli.

as much as i dislike it, would it be possible to use the same formatting of x265 (and rav1e)? G(x,y)B(x,y)R(x,y)WP(x,y)L(max,min) instead of the custom ordering?

added 1 commit

• 72b026ef - Support writing the mastering display color volume SEI message

Compare with previous version

changed the description

Sure. Updated. I didn't know rav1e had the same syntax too.

Are we sure repeating every IDR is enough? x265 seems to do every keyframe.

We need to use HDR metadata. Any progress for this merge request?

added 64 commits

• 72b026ef...0d754ec3 - 63 commits from branch videolan:master
• e6613d64 - Support writing the mastering display color volume SEI message

Compare with previous version

added 1 commit

• d18e0847 - Support writing the mastering display color volume SEI message

Compare with previous version

Do you support changing metadata? It must be supported. See hevc sample

https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/uploads/16c628c535865d7282a48317064345a2/out.mp4

Use ffprobe -show_frames -select_streams v out.mp4

Also you can remove primaries checks, see

https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200812213213.429536-1-sw@jkqxz.net/

Also,

x264_log( h, X264_LOG_ERROR, "mastering display max brightness must be greater than its minimum\n" );

is wrong. Greater or equal just as you did in the code (correct code, both can be 0 for unknown).

added 1 commit

• 62d10a9d - Support writing the mastering display color volume SEI message

Compare with previous version

Updated with the 2019/06 spec changes.

The SEI message is written every keyframe, so you should be able to make changes.

@ValZapod Your sample actually has the CLL SEI changing. CLL wasn't even in the 2017/04 revision, but I can add it to this patchset.

added 2 commits

• 2ced5ac3 - Support writing the mastering display color volume SEI message
• 28e5fe7f - Support writing the content light level information SEI message

Compare with previous version

changed title from Support writing the mastering display color volume SEI message to Support writing the mastering display and CLL SEI messages

changed the description

added 1 commit

• 51db1df2 - Support writing the content light level information SEI message

Compare with previous version

added 65 commits

• 51db1df2...0d754ec3 - 63 commits from branch videolan:master
• 7107de83 - Support writing the mastering display color volume SEI message
• 220dc99e - Support writing the content light level information SEI message

Compare with previous version

added 18 commits

• 220dc99e...55d517bc - 16 commits from branch videolan:master
• 4cc1cc63 - Support writing the mastering display color volume SEI message
• c2fcd7b6 - Support writing the content light level information SEI message

Compare with previous version

added 2 commits

• faa3416e - Support writing the mastering display color volume SEI message
• 5472943d - Support writing the content light level information SEI message

Compare with previous version

added 6 commits

• 5472943d...c347e7a0 - 4 commits from branch videolan:master
• 4a3195c6 - Support writing the mastering display color volume SEI message
• b9e0b587 - Support writing the content light level information SEI message

Compare with previous version

added 1 commit

• 77f3c231 - Support writing the content light level information SEI message

Compare with previous version

• Looks like G(x,y)B(x,y)R(x,y)WP(x,y)L(max,min) format for --mastering-display was reverted around version 5. Was it intentional?
• I would prefer not to use unsigned int for this values in x264.h. Because of signed vs unsigned comparisons and because sscanf doesn't error out for negative values if you use %u (for example: --mastering-display 8500,-4294900000,6550,2300,35400,14600,15635,16450,-10000000,1). I would prefer to use simple int for coordinates and int64_t for i_display_max/i_display_min. Otherwise most of comparisons like i_green_x < 0 or i_display_max > UINT32_MAX don't make sense.
• in x264_encoder_encode: x264_sei_mastering_display_write and x264_sei_alternative_transfer_write should not be in else-branch of h->fenc->i_type != X264_TYPE_IDR. They should be written for every b_keyframe non matter if it is IDR or not. Otherwise if you encode open-gop or PIR stream and then cut few GOPs from start than stream will start without this metadata.