would you consider varying the libvpx configure ?

[hydra3333]

Just enables a few more things.
#'configure_options': '--target={bit_name2}-{bit_name_win}-gcc --prefix={target_prefix} --disable-shared --enable-static --enable-webm-io --enable-vp9 --enable-vp8 --enable-runtime-cpu-detect --disable-install-docs --disable-unit-tests --as=yasm', # examples,tools crash with x86_64-w64-mingw32-ld: unrecognised emulation mode: 64',

'configure_options': '--target={bit_name2}-{bit_name_win}-gcc --prefix={target_prefix} --disable-shared --enable-static --enable-webm-io --enable-tools --enable-examples --enable-vp9 --enable-vp9-highbitdepth --enable-vp9-postproc --enable-coefficient-range-checking --enable-error-concealment --enable-better-hw-compatibility --enable-multi-res-encoding --enable-vp9-temporal-denoising --enable-vp8 --enable-runtime-cpu-detect --disable-install-docs --disable-unit-tests --as=nasm',

[DeadSix27]

@hydra3333 --enable-vp9-highbitdepth does that only produce 10bit vp9? Or is it select-able.

[hydra3333]

I thought the lot. This https://ffmpeg.org/pipermail/ffmpeg-cvslog/2015-April/088915.html seems to imply it

ffmpeg | branch: master | Deb Mukherjee | Wed Mar 25 17:10:16 2015 -0700| [26a0bcb15b83c926eb2688b145900a94ca851a26] | committer: James Zern

Support for VP9 high-color/high-bit-depth encoding

Patch to support VP9 encoding with new profiles 1-3.
Profile 1 (8-bit 422/444) should work with default libvpx
configuration.
However you will need to configure libvpx with
--enable-vp9-highbitdepth before building and linking
with ffmpeg for profile 2 (10-/12-bit 420) and profile 3
(10-/12-bit 422/444) encoding.

You may use the appropriate profile option on the
command line:
-profile:v 1 for 422/444 8-bit encoding
-profile:v 2 for 420 10-/12- bit encoding
-profile:v 3 for 422/444 10-/12-bit encoding
If you do not use the -profile:v option, it will be deduced
from the source format.

Signed-off-by: James Zern

http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=26a0bcb15b83c926eb2688b145900a94ca851a26

[hydra3333]

It was said to be applied, here
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-April/172075.html

more info here
https://developers.google.com/media/vp9/hdr-encoding/

[DeadSix27]

@hydra3333 Seems to be fine, ill compile it with these options later and test it.

[hydra3333]

This also looked very interesting (only indirectly related).
https://developers.google.com/media/vp9/hdr-encoding/

Convert SDR to HDR with a look-up table (LUT)

Converting HDR to SDR requires the transcoder to understand how to map brightness levels and colors to the smaller BT.709 color space and non-HDR range of brightness. For best results, an LUT describing how to perform that mapping -- usually specific to the content -- can be used. Examples C and D show how to use a LUT. We used bt2020_to_bt709_example.cube

Note: The LUT above is provided as an example of how to use an LUT with FFMpeg and is not optimized for the content in the example. LUTs are nearly always optimized for specific content.

Example C: 18Mbps 4k SDR to HDR with LUT
ffmpeg -i strobe_scientist.mkv -y -b:v 18000000 -speed 4 -pass 1 \
  -pix_fmt yuv420p \
  -color_primaries 1 -color_trc 1 -colorspace 1 -color_range 1 \
  -maxrate 26800000 -minrate 8040000 -profile:v 0 \
  -vf scale=-1:-1:in_color_matrix=bt2020,format=rgb48,lut3d=bt2020_to_bt709_example.cube,scale=-1:-1:out_color_matrix=bt709 \
  -vcodec libvpx-vp9 -f webm /dev/null && \
  ffmpeg -i strobe_scientist.mkv -y -b:v 18000000 -pass 2 \
  -pix_fmt yuv420p \
  -color_primaries 1 -color_trc 1 -colorspace 1 -color_range 1 \
  -maxrate 26800000 -minrate 8040000 -profile:v 0 \
  -vf scale=-1:-1:in_color_matrix=bt2020,format=rgb48,lut3d=bt2020_to_bt709_example.cube,scale=-1:-1:out_color_matrix=bt709 \
  -vcodec libvpx-vp9 -f webm SDR_strobe_scientist_18Mbps-static.webm

Note: -profile has been set to 0 (4:2:0) and -pix_fmt changed to yuv420p.

Output file: SDR_strobe_scientist_18Mbps-static.webm
Encode time: 124m23s
File size on disc: 165MB

[DeadSix27]

@hydra3333 totally forgot about this... ill check it out this weekend

[hydra3333]

OK.

I also saw this over at Zeranoe's.
https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=5&p=13527#p13527
Not sure if it's applicable to your build scheme (in my fork I build nasm locally and make the relevant changes from YASM to NASM, but can't comment about CMAKE_SYSTEM_PROCESSOR).

[DeadSix27]

I added that a while ago to fix issues with libjpeg-turbo -> 6320e66#diff-e223906984ace16458e9ef6f3437aeeeR440

Also why nasm, yasm is preffered by aom:
For x86 targets, yasm, which is preferred, or a recent version of nasm.

[hydra3333]

OK, iirc another product preferred nasm, can't recall which atm, I'll ponder it. was it maybe x264 ?

[DeadSix27]

@hydra3333 yup, but you generally have both installed anyway, no? So not a big deal to make each use the preferred one

[hydra3333]

your view makes a lot of sense.

[DeadSix27]

@hydra3333 Is 9791eb1 what you wanted?

[hydra3333]

Yes, thank you.
I wonder if mp4box configure options should also have --target-os=mingw64 ?