MPC-HC (64bit) vers. 1.7.5 HEVC playback problem

[surami]

I just wanted to encode a video through AviSynth with ffmpeg 64bit + x265:
ffmpeg -i "input.avs" -c:v libx265 -x265-params input-csp=i444:bitrate=5000:aq-strength=1.5:colorprim=bt709:transfer=bt709:colormatrix=bt709
-filter:v unsharp=5:5:0.5:5:5:0.5 -strict experimental -pix_fmt yuv444p -y "output.hevc"

e:\test\>ffmpeg -i "input.avs" -c:v libx26
5 -x265-params input-csp=i444:bitrate=5000:aq-strength=1.5:co
lorprim=bt709:transfer=bt709:colormatrix=bt709 -filter:v unsharp=5:5:0.5:5:5:0.5
-strict experimental -pix_fmt yuv444p -y "output.hevc"
ffmpeg version N-63208-gbe1fbc0 Copyright (c) 2000-2014 the FFmpeg developers
built on May 17 2014 01:30:26 with gcc 4.8.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetyp
e --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-
libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libope
njpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsox
r --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab -
-enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx
--enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-
libxavs --enable-libxvid --enable-decklink --enable-zlib
libavutil 52. 83.100 / 52. 83.100
libavcodec 55. 62.100 / 55. 62.100
libavformat 55. 38.100 / 55. 38.100
libavdevice 55. 13.101 / 55. 13.101
libavfilter 4. 5.100 / 4. 5.100
libswscale 2. 6.100 / 2. 6.100
libswresample 0. 19.100 / 0. 19.100
libpostproc 52. 3.100 / 52. 3.100
Input #0, avisynth, from 'input.avs':
Duration: 00:01:04.48, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (444P / 0x50343434), yuv444p, 1920x1080, 25 fps
, 25 tbr, 25 tbn, 25 tbc
x265 [info]: HEVC encoder version 1.0+38-d0acf82a77f9
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
x265 [info]: WPP streams / pool / frames : 17 / 4 / 2
x265 [warning]: !! HEVC Range Extension specifications are not finalized !!
x265 [warning]: !! This output bitstream may not be compliant with the final spe
c !!
x265 [info]: None profile, Level-4 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-5000 kbps / 1.5 / 1
x265 [info]: tools: rd=3 lft sao-lcu signhide
Output #0, hevc, to 'output.hevc':
Metadata:
encoder : Lavf55.38.100
Stream #0:0: Video: hevc (libx265), yuv444p, 1920x1080, q=2-31, 200 kb/s, 90
k tbn, 25 tbc
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo -> libx265)
Press [q] to stop, [?] for help
the file is rendered, but I cannot play back with MPC-HC (64bit) vers. 1.7.5.134

Is this because of the experimental 444 option at x265?

Update: I put the HEVC into MP4 container and the MediaInfo shows this:

General
Complete name : E:\output.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : iso4
File size : 39.0 MiB
Duration : 1mn 4s
Overall bit rate : 5 080 Kbps
Encoded date : UTC 2014-05-29 14:55:20
Tagged date : UTC 2014-05-29 14:55:20

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : L4.0
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 1mn 4s
Bit rate : 5 077 Kbps
Maximum bit rate : 112 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.098
Stream size : 39.0 MiB (100%)
Encoded date : UTC 2014-05-29 14:55:20
Tagged date : UTC 2014-05-29 14:55:21

[benwaggoner]

How recent is the x265 lib you're using?

I've never played around with 444, which is definitely experimental! The bitstream spec isn't finalized yet. I wouldn't recommend it as a starting point in your HEVC journey :).

The Main 10 (10-bit 4:2:0) profile is about as far as most existing decoders can handle, and some are Main only (8-bit 4:2:0). I'd start with Main and make sure that works before trying anything else.

Generally, I'd prefer 10-bit 4:2:0 over 8-bit 4:4:4 for natural image content. It's really only rendered/hand drawn stuff without motion blur where 444 makes a difference. But 10-bit can help all sorts of content, and lots of source content is 10-bit now.

[surami]

I used a Zeranoe ffmpeg 64bit build, which was built on the day 17.05.2014 and as I see the HEVC encoder version is 1.0+38-d0acf82a77f9.

Well my source (it's a timelapse) comes through Premier Pro, it is 4K 4:4:4 16bit in a MOV container (look at this (http://cineform.blogspot.hu/2014/02/quicktime-16-bit.html)), every frame is from 4K 16bit 300dpi TIFF files in the MOV (the RAW sources were .CR2 files (14bit) from a DSLR camera). From Premier Pro I can't render HEVC files directly so I'm using the Advanced FrameServer (http://sourceforge.net/projects/advancedfs/) plugin, this gives me a fake AVI file (~50kb :) ), which is RGB24 so I'm at 8bit (I hadn't found any 16bit frameserver plugin yet, maybe with VapourSynth (http://www.vapoursynth.com/about/), with the vsrawsource plugin by Chikuzen (https://github.com/chikuzen/vsrawsource) it could be done somehow, see this here too (https://code.google.com/p/frame-server/wiki/BuildInstructions).) In my AviSynth script, I read in this AVI file and convert it to YV24 or YV12, if I want to resize from 4K, I'm using lanczos4.

AVISource("E:\signpost.avi", audio=false).AssumeFPS(25,1)
lanczos4resize(1920,1080)
#4:2:0 4K
#ConvertToYV12(matrix="Rec709")
#4:2:0 1080p
ConvertToYV12(matrix="Rec709", chromaresample="lanczos4")
#4:4:4 4K
#ConvertToYV24(matrix="Rec709")
#4:4:4 1080p
#ConvertToYV24(matrix="Rec709", chromaresample="lanczos4")


I see this AVS output with MPC-HC and it's nice.

So I would like to keep the quality as good as it can be and to compress it as it can be. I'm not an expert, I learnt everything on the net about videos and I saw here for example (http://en.wikipedia.org/wiki/File:Colorcomp.jpg) and read this (http://wolfcrow.com/blog/chroma-subsampling-numbers-explained/), so I decided to go with 444. This solution is a very long pipe, but it works, in 4K 10bit-16bit the same would be a bit better. :)

The x265 in 1080p 4:2:0 8bit works fine through this piping as I tested, but in 4K I got problems. Is there somewhere a description, how to do it in 4K?

[benwaggoner]

(I hadn't found any 16bit frameserver plugin yet, maybe with VapourSynth (http://www.vapoursynth.com/about/), with the vsrawsource plugin by Chikuzen (https://github.com/chikuzen/vsrawsource) it could be done somehow, see this here too (https://code.google.com/p/frame-server/wiki/BuildInstructions).)
ffmpeg can do this and pipe to x264. That's what I've been doing when I don't want to prerender a y4m.

In my AviSynth script, I read in this AVI file and convert it to YV24 or YV12, if I want to resize from 4K, I'm using lanczos4.

AVISource("E:\signpost.avi", audio=false).AssumeFPS(25,1)
lanczos4resize(1920,1080)
#4:2:0 4K
#ConvertToYV12(matrix="Rec709")
#4:2:0 1080p
ConvertToYV12(matrix="Rec709", chromaresample="lanczos4")
#4:4:4 4K
#ConvertToYV24(matrix="Rec709")
#4:4:4 1080p
#ConvertToYV24(matrix="Rec709", chromaresample="lanczos4")

Woah, since your source already went through 4:2:0, there's no point in converting it back to 4:4:4. The chroma detail was already nuked. Just use normal Main and make sure that works.

So I would like to keep the quality as good as it can be and to compress it as it can be. I'm not an expert, I learnt everything on the net about videos and I saw here for example (http://en.wikipedia.org/wiki/File:Colorcomp.jpg) and read this (http://wolfcrow.com/blog/chroma-subsampling-numbers-explained/), so I decided to go with 444. This solution is a very long pipe, but it works, in 4K 10bit-16bit the same would be a bit better. :)

Woah, those samples aren't even the same pixels. Also note that you are staring at 200% zoomed ~144x144 screen caps. With a moving image of 3840x2160, no way are you going to notice any chroma differences unless it's some very specifically created synthetic test image and you're sitting closer to the screen than its diagonal width. Remember that UHD 4:2:0 has all the chroma detail of a 1080p 4:4:4.

More to the point, there just isn't a final HEVC 444 profile yet :).

The x265 in 1080p 4:2:0 8bit works fine through this piping as I tested, but in 4K I got problems. Is there somewhere a description, how to do it in 4K?
What kind of problems? A slow decoder could well be the culprit. For HEVC 4K decode, you need a good number of fast cores. And decoders vary wildly in performance right now.

[surami]

ffmpeg can do this and pipe to x264. That's what I've been doing when I don't want to prerender a y4m.

I have a PP project file with 16bit things (as I wrote), how to pass this to ffmpeg to render with x264 or x265 with maintaining the best quality? I would like to avoid intermediate file, just do things simple. In my head that 4K 16bit 4:4:4 frame could be stored (as the 8bit frame is also stored somewhere by that frameserver) in a virtual AVI file or not? If not, why? I don't understand.

Woah, since your source already went through 4:2:0, there's no point in converting it back to 4:4:4. The chroma detail was already nuked. Just use normal Main and make sure that works.

I used that AVS file just for testing I deleted/added # for different options, I didn't converted the source from 4:2:0 to 4:4:4 AFAIK, just in that case when I wanted to feed ffmpeg with 4:2:0.

Woah, those samples aren't even the same pixels. Also note that you are staring at 200% zoomed ~144x144 screen caps. With a moving image of 3840x2160, no way are you going to notice any chroma differences unless it's some very specifically created synthetic test image and you're sitting closer to the screen than its diagonal width. Remember that UHD 4:2:0 has all the chroma detail of a 1080p 4:4:4.

More to the point, there just isn't a final HEVC 444 profile yet .


Ok, I got it.

What kind of problems? A slow decoder could well be the culprit. For HEVC 4K decode, you need a good number of fast cores. And decoders vary wildly in performance right now.

Yes, probably my computer is too slow for this. I will test more on this.

How to rename this topic? :P

[foxyshadis]

For your 1080p test, if you want to keep real 4:4:4 in your avisynth script, you have the resize in the wrong place. It should be after the ConvertToX, not before, otherwise like ben said, you're just trying to recreate what was already destroyed. (Even at 1080p 4:4:4 is nearly pointless for video. It gets more useful the smaller the frame size.) But I suspect the reason it doesn't work is because it's just not finished yet.

BTW, Main10 works in MPC-HE/BE, and you can encode in Main10 even if you have 8-bit source. It's not as good feeding it a true 16-bit source, but it's a little bit better than an 8-bit encode.

[surami]

For your 1080p test, if you want to keep real 4:4:4 in your avisynth script, you have the resize in the wrong place. It should be after the ConvertToX, not before, otherwise like ben said, you're just trying to recreate what was already destroyed. (Even at 1080p 4:4:4 is nearly pointless for video. It gets more useful the smaller the frame size.) But I suspect the reason it doesn't work is because it's just not finished yet.

BTW, Main10 works in MPC-HE/BE, and you can encode in Main10 even if you have 8-bit source. It's not as good feeding it a true 16-bit source, but it's a little bit better than an 8-bit encode.

If I put the resize line after the ConvertToX, it gives me worse guality than the line before.

Yes, the 1080p 4:2:0 8bit HEVC works very well in MPC-HC, so this topic should be renamed and moved. :) I will try that 10bit encoding too.

I did many other tests at night and the best is when I feed the ffmpeg straight with the 4K AVI source from the frameserver and I put a scale command to be done by ffmpeg if I want 1080p. The ffmpeg reads in the AVS as rawvideo RGB24 source.

This is the AVS (I'm using the latest AviSynth+):
AVISource("E:\signpost.avi", audio=false).AssumeFPS(25,1)

and this is my x265 1080p 4:2:0 ffmpeg.bat:
ffmpeg -i "signpost.avs" -s 1920x1080 -c:v libx265 -x265-params bitrate=5000:aq-strength=1.5 -filter:v unsharp=5:5:0.5:5:5:0.5 -pix_fmt yuv420p -y "output.hevc"

An interesting thing for me, everything is 4K in the following test. I opened the AVS in Virtualdub and I applied a very extreme RGB curve (similiar as seen in that blogpost) with this plugin (http://members.chello.at/nagiller/vdub/readme.html) and the gradient looks verysmooth. Could it be, that I get through the frameserver 16bit frames? It's ok, that softwares are reading as 8bit but maybe it's only metadata. I ask this because I also tested the same curve on this way: I wrapped the 16bit 4:4:4 stuff from MOV to AVI (just wrap, not encoded) and I opened this in Virtualdub, applied the curve and the quality and gradients are the same as in case of the AVS file.

Update: I just tested the same curve in PS on the 16bit TIFF frame, and it's looks the same as in case AVS or AVI. This is veryinteresting... :D
Update2: Well I have to correct myself there is big qualityloss, if the AVI goes through my AVS file, so I was wrong sorry. But now I will test AVS's High bit-depth possibilities.

[foxyshadis]

yuv420p is 8-bit; you need yuv420p10le for 10-bit. I have no idea if avisynth+ works directly with ffmpeg, last I heard you needed avs2pipemod to pipe the 16-bit output to either x265 or ffmpeg. (It outputs y4m so you don't need to set all the parameters on the command line.)

[surami]

yuv420p is 8-bit; you need yuv420p10le for 10-bit. I have no idea if avisynth+ works directly with ffmpeg, last I heard you needed avs2pipemod to pipe the 16-bit output to either x265 or ffmpeg. (It outputs y4m so you don't need to set all the parameters on the command line.)

Thanks for that info.

I think now I wil start to experiment with High bit-depth possibilities (http://avisynth.nl/index.php/High_bit-depth_Support_with_Avisynth), maybe I can read in the 4K 4:4:4 16bit AVI somehow and pass the data out to convert with x264 or x265.

Update: I just found this (http://forum.doom9.org/showpost.php?p=1616084&postcount=32) and this (http://forum.doom9.org/showthread.php?t=154830&page=4).

[kolak]

You can use LSMASHSource which does support RGB48 or sashimi.
You can also use vapoursynth which works better with 8bit+ bit depths.

You can also try this (with x265 10bit):

ffmpeg -i "16bit_input" -pix_fmt yuv444p16le -strict -2 -f yuv4mpegpipe - | x265 --input-csp i444 -o out.265 - --y4m

Keep in mind that ffmpeg RGB->YUV conversion is broken and always uses Rec.601.

[surami]

Thanks for the ffmpeg line kolak, it's very helpful, I will test that too.

There was a huge update on the AviSynth site (at the section High bit-depth possibilities) this days... it's more clear now.
Till now I can't get VapourSynth to work on my system, maybe later I can figure it out what is the right way, I think it has a big future.

Yes I know about the RGB -> YUV conversion problem at the ffmpeg, I read it on many sites and I experienced too.

In the last few days I did many tests and as far as i see on my display (it's 8bit + 2bit dithered 23" Full HD IPS panel) I figured out the right solution.
I will write about it in another topic, but at first I have to sort the information. I inspected so much that my head was full with the things.
Finaly I got a very simple solution, it gives outstanding quailty and the file size is ridiculously small. :)