This is an hevc file I created myself, ffprobe identifies it as:Code:andrew@ilium~/shared/youtube$ muxer -i hero.h265 -o test.mp4 MP4 muxing mode [HEVC: Info]: IDR: 1, I: 168, P: 2444, B: 3782, Unknown: 0 Error: there is no media that can be stored in output movie. Error: failed to open input files.
Could be I have missed something here, so my apologies in advance...Code:Input #0, hevc, from 'hero.h265': Duration: N/A, bitrate: N/A Stream #0:0: Video: hevc (Main), yuv420p(tv), 320x240, 25 fps, 25 tbr, 1200k tbn, 25 tbc
You think that's air you're breathing now?
Yeah, the HEVC support in L-SMASH got disabled a couple weeks after that post in October, since the official specs for putting it in MP4 hadn't come out (I still don't know if they've been published). So it's sort of a case where work is being done on it, but the users are kept away from it for the time being.
Muxing it with mp4box is currently the only method I know of at the moment to put HEVC into MP4. So long as it's built from SVN, anyway.
OIC! Thanks for guiding me to my first muxed h.265 file:
It is very exciting to see the whole hevc experience growing...Code:andrew@ilium~/shared/youtube$ muxer -i hero.h265 -o hero.mp4 MP4 muxing mode [HEVC: Info]: IDR: 1, I: 103, P: 2281, B: 4010, Unknown: 0 Track 1: H.265 High Efficiency Video Coding (for testing purposes only) Muxing completed! andrew@ilium~/shared/youtube$
You think that's air you're breathing now?
Slow work on a big file, even with my newish build:
A little over 2 hours for this effort.Code:andrew@ilium~/media/lossless$ x265 --preset veryslow --crf 30 --threads 8 elephants_dream_480p24.y4m -o elephant.hevc y4m [info]: 704x480 24Hz C420, frames 0 - 15690 of 15691 x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 LZCNT BMI1 x265 [info]: HEVC encoder version 0.6+324-237bf6667405 x265 [info]: build info [Linux][GCC 4.8.2][64 bit] 8bpp x265 [info]: Main profile, Level-3 (Main tier) x265 [info]: WPP streams / pool / frames : 8 / 8 / 3 x265 [info]: CU size : 64 x265 [info]: Max RQT depth inter / intra : 3 / 3 x265 [info]: ME / range / subpel / merge : star / 60 / 4 / 4 x265 [info]: Keyframe min / max : 250 / 250 x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-30.0 / 1.0 / 1 x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2 x265 [info]: b-pyramid / weightp / refs : 1 / 1 / 5 x265 [info]: tools: rect amp rd=6 lft sao-lcu sign-hide x265 [info]: frame I: 144 kb/s: 1633.08 x265 [info]: frame P: 15532 kb/s: 174.87 x265 [info]: frame B: 15 kb/s: 35.85 x265 [info]: global : 15691 kb/s: 188.11 x265 [info]: 3329 of 15532 (21.43%) P frames weighted encoded 15691 frames in 8045.54s (1.95 fps), 188.11 kb/s
@qyot27 I read your question on Doom 9 about the 16bit internal depth setting, have you experimented with this? I will recompile and compare over the next few days but my eye is not sharp for what will probably be fine detail
You think that's air you're breathing now?
If memory serves, I never got an actual answer. But that was also before 10bit encoding was actually added to the HIGH_BIT_DEPTH build. Now that it has the ability to output in 10bit, the question of the internal processing is not really relevant.
Unless they've rejiggered the crf scale like x264 did so that the crf values are the same across bit depths, the difference in crf values between 8bit and 10bit is something like 12 points. So if you use --crf 30 for 8bit, you'd have to use --crf 18 for a comparable encode in 10bit (or in my case, since I'd normally use --crf 18 or --crf 14, it'd be --crf 6 or --crf 2 for 10bit). Yes, this means that 10bit would take negative crf values for some quality levels, and I'm sure the weirdness of that is what prompted x264 to adjust the crf scaling for 10bit so that you can use the same values you would for 8bit. I wonder if/when x265 will do the same.
Also, there are more caveats involved with high bit depth content. Notably, x265 still hasn't added support for FFmpeg's extended y4m format from what I can see from my RSS feeds, so the only way to input >8bit content is to pipe it in raw or use a raw .yuv stream, and then specify the resolution, bit depth, and framerate parameters manually.
I expect that, as with x264, inputting 8bit and outputting with 10bit will still provide a benefit in filesize reduction@same quality or quality increase@same bitrate. But no, I haven't done any real testing with x265's high bit depth stuff; it's probably still not comparable to x264's 10bit abilities right now because there are things like the psy optimizations and AQ that may not be totally up to speed yet. The encode time will also be slower than on 8bit due to less assembly optimizations for high bit depths.
The biggest benefit (aside from being able to save bits) is the effect on banding artifacts - the higher the bit depth, the less obvious/severe the banding will be, or can even possibly be avoided. The problem, though, is that the average user doesn't have access to real high bit depth content - Xiph's media archives for Sintel and Tears of Steel (or the SVT samples) are notable exceptions as they provide 16bit TIFF or 16bit SGI files, but understandably, the filesizes are monstrous.
For normal consumer content that's only available in 8bit, you'd have to dither and upsample it first to try and eliminate any banding that might be present in the source, and then give the dithered upsampled file to x265 (or x264) for encoding in 10bit. This does have the benefit of not needing to download a huge amount of data since you can accomplish the dithering/upsampling with either AviSynth under Wine or VapourSynth (AvxSynth isn't an option here since the dithering filters were never ported for it). The AviSynth method actually requires the use of a patched x264 to take the result of the upsampled script and encode it to lossless H.264 @ 10bit first, and then you can give that file to ffmpeg to pipe to x265 as a high bit depth input. VapourSynth can just output right to the extended y4m format, so you'd still need to pipe over to ffmpeg and then pipe it raw to x265, but it can be done that way I guess.
The dithering/upsampling isn't actually necessary to output in 10bit. Giving it 8bit and telling it to output in 10bit is fine; giving it 10bit and telling it to output in 10bit is simply a nice flourish and can have some additional benefit because you did pre-processing to try and eliminate banding.
Last edited by qyot27; January 27th, 2014 at 01:16 PM.
I'm guessing it was this commit. There's also multiple threads that bring up the subject on Doom9, like this one.
Although, maybe I'm remembering the exact details (RE: negative crf) incorrectly for x264. But the quant scale is different between them (8bit is 0-51, 10bit is 0-63), and --crf 0 ceased to be equivalent to --qp 0. The more I try to think about it, the more confused I end up getting; all I know is that on some recent encodes that I did (back in July), crf14 in 10bit looked roughly equal or better than crf14 in 8bit while hitting just about the same filesize, so that's part of what I was considering.
Last edited by qyot27; January 28th, 2014 at 09:11 AM.
...And now FFmpeg officially has the ability to use libx265. Use the --enable-libx265 option to tell FFmpeg to link it in.
The big caveat is that if you build the high bit depth version and link that in, you can't encode 8-bit content with it - it actually stops you and tells you so. This is something carried over from x265 itself, as you can't output 8-bit encodes with a 16bpp build (and because x265 doesn't do internal upsampling, it requires high bit depth input into such a build anyway). Of course, this all just means that if you need to input 8-bit and output 10-bit, use -pix_fmt to upsample it.Code:hg clone https://bitbucket.org/multicoreware/x265 cd x265/source cmake . -DENABLE_SHARED:bool=off make sudo checkinstall --pkgname=x265 --pkgversion="$(grep \ X265_VERSION common/CMakeFiles/common.dir/flags.make | \ cut -f3 -d =)" --backup=no --deldoc=yes --delspec=yes --deldesc=yes \ --strip=yes --stripso=yes --addso=yes --fstrans=no --default # Use -DHIGH_BIT_DEPTH:bool=on to enable builds that can output 10-bit and (in the future) 12-bit.
So the issue of not having AviSynth input or support for FFmpeg's extended Y4M format are partially resolved now - you just have to use FFmpeg with libx265 support enabled. It would still be nice to have it in the x265 CLI too, but at least this is something.
-crf hasn't been mapped (yet) as a private option for libx265, but it is still possible via -x265-params: