Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 30th October 2013, 10:59   #61  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
Quote:
Originally Posted by Kurtnoise View Post
btw, what is the status of high bits depth ? It looks like it's clamped to 8bits in the current code...but I'm just wondering.
Main10 profile is listed in the "Upcoming improvements" section...
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 30th October 2013, 11:07   #62  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
Ups, yeah, I missed that...thanks.
Kurtnoise is offline   Reply With Quote
Old 31st October 2013, 13:49   #63  |  Link
BadFrame
Registered User
 
Join Date: Jun 2013
Posts: 98
Quote:
Originally Posted by x265_Project View Post
x265 reaches 0.5 milestone

New stable version tag 0.5:
That's some very impressive progress, seems x265 is on a the same excellent path as x264 before it, great work!
BadFrame is offline   Reply With Quote
Old 2nd November 2013, 15:42   #64  |  Link
professor_desty_nova
Registered User
 
professor_desty_nova's Avatar
 
Join Date: Nov 2006
Posts: 55
It seems that with the new --preset switch, the default values are not the ones shown in --h (help) anymore.

Before the presets, they are the same:
Code:
G:\x265_0.5+72-e842b2a4aeeb>x265 --frames 1 G:\x264\TestClipsYUV\ducks_take_off_420_720p50.y4m -o test.hevc
y4m  [info]: 1280x720 50Hz, frames 0 - 0 of 500
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast LZCNT
x265 [info]: performance primitives: intrinsic assembly
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: WPP streams / pool / frames  : 12 / 4 / 1
x265 [info]: CU size                      : 64
x265 [info]: Max RQT depth inter / intra  : 3 / 3
x265 [info]: ME / range / subpel / merge  : star / 60 / 5 / 5
x265 [info]: Keyframe min / max           : 250 / 250
x265 [info]: Rate Control                 : CQP-32
x265 [info]: Lookahead / bframes / badapt : 10 / 3 / 1
x265 [info]: tools: rect amp rd=2 ref=1 lft sao-lcu sign-hide tskip(fast+rdo)
x265 [info]: frame I:1      kb/s: 36872.80 PSNR Mean: Y:36.404 U:36.833 V:39.259

x265 [info]: global:        kb/s: 36872.80 PSNR Mean: Y:36.404 U:36.833 V:39.259

encoded 1 frames in 4.71s (0.21 fps), 36872.80 kb/s, Global PSNR: 36.814
After presets commit, not anymore:
Code:
G:\x265_0.5+90-f81af999ef6c>x265 --frames 1 G:\x264\TestClipsYUV\ducks_take_off_420_720p50.y4m -o test.hevc
y4m  [info]: 1280x720 50Hz, frames 0 - 0 of 500
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast LZCNT
x265 [info]: performance primitives: intrinsic assembly
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: WPP streams / pool / frames  : 12 / 4 / 1
x265 [info]: CU size                      : 64
x265 [info]: Max RQT depth inter / intra  : 1 / 1
x265 [info]: ME / range / subpel / merge  : star / 60 / 5 / 3
x265 [info]: Keyframe min / max           : 250 / 250
x265 [info]: Rate Control                 : CQP-32
x265 [info]: Lookahead / bframes / badapt : 10 / 3 / 1
x265 [info]: tools: rect amp rd=0 ref=1 lft sao-lcu sign-hide
x265 [info]: frame I:1      kb/s: 38479.60 PSNR Mean: Y:36.366 U:36.744 V:39.278

x265 [info]: global:        kb/s: 38479.60 PSNR Mean: Y:36.366 U:36.744 V:39.278

encoded 1 frames in 2.53s (0.40 fps), 38479.60 kb/s, Global PSNR: 36.778
PS: It seems to me that "--preset medium" is used by default, and overrides the (older?) default values that appear in --h (help).
professor_desty_nova is offline   Reply With Quote
Old 2nd November 2013, 18:10   #65  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
anyone manged to compile x265 on Mac OS X?
Tried it myself, but I'm really not good with using a mac.

I checked out the source using SourceTree, opened a terminal, called the x265/build/linux/make-Makefiles.bash (there I set x86_64 as architecture, called configure and generate), then I called make and got:
Code:
 1%] Building CXX object encoder/CMakeFiles/encoder.dir/__/Lib/TLibEncoder/NALwrite.cpp
/Users/selur/x265/source/Lib/TLibEncoder/NALwrite.cpp:1: error: -mstackrealign not supported in the 64bit mode
make[2]: *** [encoder/CMakeFiles/encoder.dir/__/Lib/TLibEncoder/NALwrite.cpp] Error 1
make[1]: *** [encoder/CMakeFiles/encoder.dir/all] Error 2
make: *** [all] Error 2
so I removed -mstackrealign from x265\source\CMakeLists.txt and ran make-Makefiles.bash again (configure and generate), now calling make I ended up with:
Code:
[  1%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComBitStream.cpp.o
[  2%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComDataCU.cpp.o
[  4%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComLoopFilter.cpp.o
[  5%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComMotionInfo.cpp.o
[  7%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPattern.cpp.o
[  8%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPic.cpp.o
[ 10%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPicSym.cpp.o
[ 11%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPicYuv.cpp.o
[ 12%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPicYuvMD5.cpp.o
[ 14%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPrediction.cpp.o
[ 15%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComRom.cpp.o
[ 17%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComSampleAdaptiveOffset.cpp.o
[ 18%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComSlice.cpp.o
[ 20%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComTrQuant.cpp.o
[ 21%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComWeightPrediction.cpp.o
[ 22%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComYuv.cpp.o
[ 24%] Building CXX object common/CMakeFiles/common.dir/x86/asm-primitives.cpp.o
[ 25%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/pixel-a.asm.o
[ 27%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/const-a.asm.o
[ 28%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/cpu-a.asm.o
[ 30%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/sad-a.asm.o
[ 31%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/mc-a.asm.o
[ 32%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/mc-a2.asm.o
[ 34%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/ipfilter8.asm.o
[ 35%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/pixel-util.asm.o
[ 37%] Building CXX object common/CMakeFiles/common.dir/vec/vec-primitives.cpp.o
/Users/selur/x265/source/common/vec/vec-primitives.cpp:121: warning: unused parameter ‘p’
/Users/selur/x265/source/common/vec/vec-primitives.cpp:121: warning: unused parameter ‘cpuMask’
[ 38%] Building CXX object common/CMakeFiles/common.dir/primitives.cpp.o
[ 40%] Building CXX object common/CMakeFiles/common.dir/pixel.cpp.o
[ 41%] Building CXX object common/CMakeFiles/common.dir/dct.cpp.o
[ 42%] Building CXX object common/CMakeFiles/common.dir/ipfilter.cpp.o
[ 44%] Building CXX object common/CMakeFiles/common.dir/intrapred.cpp.o
[ 45%] Building CXX object common/CMakeFiles/common.dir/cpu.cpp.o
cc1plus: error: unrecognized command line option "-Wno-narrowing"
make[2]: *** [common/CMakeFiles/common.dir/cpu.cpp.o] Error 1
make[1]: *** [common/CMakeFiles/common.dir/all] Error 2
make: *** [all] Error 2
Cu Selur
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 2nd November 2013, 19:41   #66  |  Link
MoSal
Registered User
 
Join Date: Jun 2013
Posts: 95
Code:
cc1plus: error: unrecognized command line option "-Wno-narrowing"
Are you building with clang?
Maybe "-Wnarrowing" is GCC-specific.
MoSal is offline   Reply With Quote
Old 2nd November 2013, 22:18   #67  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by professor_desty_nova View Post
It seems that with the new --preset switch, the default values are not the ones shown in --h (help) anymore.
...
PS: It seems to me that "--preset medium" is used by default, and overrides the (older?) default values that appear in --h (help).
Yes, we have started to implement x264 style presets. As part of this work the values for the "medium" performance preset have become the new default values. I apologize that our documentation efforts haven't kept pace with our development efforts. We'll get a new Evaluator's Guide posted ASAP.

The presets are as follows (default values are used wherever a setting is not specified).

ultrafast=-s 32 --b-adapt 0 -b 4 --tu-inter-depth=1 --tu-intra-depth=1 --rd 0 --subme=0 --max-merge=1 --me=0 --no-amp --no-rect --no-tskip --early-skip --fast-cbf --no-lft --no-sao --no-signhide --no-weightp
superfast=-s 32 --b-adapt 0 -b 4 --tu-inter-depth=1 --tu-intra-depth=1 --rd 0 --subme=1 --max-merge=1 --me=1 --no-amp --no-rect --no-tskip --early-skip --fast-cbf --no-signhide --no-weightp
veryfast=--b-adapt 0 -b 4 --tu-inter-depth=1 --tu-intra-depth=1 --rd 0 --subme=1 --me=1 --max-merge=2 --no-amp --no-rect --no-tskip --early-skip --fast-cbf
faster=--b-adapt 0 -b 4 --tu-inter-depth=1 --tu-intra-depth=1 --rd 0 --subme=1 --me=1 --max-merge=2 --no-amp --no-rect --no-tskip --early-skip
fast=--tu-inter-depth=1 --tu-intra-depth=1 --rd 0 --subme=1 --me=1 --max-merge=2 --no-amp --no-rect --no-tskip
medium=--tu-inter-depth=1 --tu-intra-depth=1 --rd 2 --max-merge=3 --no-amp --no-rect --no-tskip
slow=--b-adapt 2 -b 4 --tu-inter-depth=1 --tu-intra-depth=1 --rd 2 --max-merge=3 --no-tskip
slower=--b-adapt 2 --rc-lookahead 20 -b 5 --tu-inter-depth=2 --tu-intra-depth=2 --rd 2 --max-merge=4 --no-tskip --ref 3
veryslow=--b-adapt 2 --rc-lookahead 30 -b 9 --max-merge=5 --ref 5
placebo=--b-adapt 2 -b 16 --max-merge=5 --ref 16 --merange 124 --rc-lookahead 60

These are a fairly quick first take at the right settings to use for these presets. We're not satisfied that these are optimal at this point. For example, placebo mode should produce HM reference quality compression efficiency under any circumstance, and in our early tests it doesn't yet. As you select slower presets we want to see a clear improvement in compression efficiency (quality@ any bit rate), and as you select faster presets we want to see the minimum possible tradeoff in compression efficiency for the maximum improvement in encoding speed.

Keep in mind that for faster performance you will need to set the number of frames to be encoded in parallel (-F), and that you should also use --no-progress.

As this is an open source project, we welcome your testing of these presets and your suggestions for improvement. I'll monitor this thread for your feedback. We have our own tests underway also.

Tom
MulticoreWare
  Reply With Quote
Old 2nd November 2013, 23:36   #68  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Quote:
Originally Posted by Selur View Post
anyone manged to compile x265 on Mac OS X?
Tried it myself, but I'm really not good with using a mac.

I checked out the source using SourceTree, opened a terminal, called the x265/build/linux/make-Makefiles.bash (there I set x86_64 as architecture, called configure and generate), then I called make and got:

[snip]
Cu Selur
IMO, the build/ directory should just be ignored.

It builds just fine under OSX if you just use cmake directly.

Code:
hg clone https://bitbucket.org/multicoreware/x265
cd x265/source
cmake .
make
sudo make install
If you want a 16bpp build, then tack -DHIGH_BIT_DEPTH:bool=on onto the cmake command. If 16bpp fails to build, it doesn't necessarily mean the default 8bpp build has the same problem.

Last edited by qyot27; 2nd November 2013 at 23:39.
qyot27 is offline   Reply With Quote
Old 3rd November 2013, 00:03   #69  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
What does "16bpp" mean? I thought even 12 Bit encoding is still nothing but a draft?
sneaker_ger is offline   Reply With Quote
Old 3rd November 2013, 00:23   #70  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Quote:
Originally Posted by sneaker_ger View Post
What does "16bpp" mean? I thought even 12 Bit encoding is still nothing but a draft?
16 bits per pixel (or maybe plane).

The internal precision of the encoder doesn't necessarily have anything to do with the output depth. No one answered my previous question on the relevance of the 16bpp build so anything I'd say is pure conjecture.
qyot27 is offline   Reply With Quote
Old 3rd November 2013, 05:39   #71  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
@qyot27: did a clean checkout and 'cmake .' ends with:
Quote:
Building CXX object encoder/CMakeFiles/encoder.dir/__/Lib/TLibEncoder/NALwrite.cpp
/Users/selur/x265/source/Lib/TLibEncoder/NALwrite.cpp:1: error: -mstackrealign not supported in the 64bit mode
make[2]: *** [encoder/CMakeFiles/encoder.dir/__/Lib/TLibEncoder/NALwrite.cpp] Error 1
make[1]: *** [encoder/CMakeFiles/encoder.dir/all] Error 2
make: *** [all] Error 2
(got a clean Snow Leopard install with Xcode 4 installed)

Quote:
Are you building with clang?
Maybe "-Wnarrowing" is GCC-specific.
I guess, only installed Xcode 4 and it's command line tools,..
__________________
Hybrid here in the forum, homepage

Last edited by Selur; 3rd November 2013 at 05:42.
Selur is offline   Reply With Quote
Old 3rd November 2013, 05:41   #72  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by qyot27 View Post
16 bits per pixel (or maybe plane).
I don't know what terminology conventions HEVC uses, but traditionally BPP is different than BPC

BPC is bits per channel . e.g. 8bits R, 8bits B, 8bits G for "8bit RGB" , or 8bit Y, 8bit U, 8bit V for "8bit YUV". It's usually expressed as per channel as in each channel . 8bit values would allow for 2^8 or (0 to 255) = 256 values per channel . It's also referred to as "bit depth"

BPP is bits per pixel . It's usually expressed as the sum of the bits in all the channels . However, because of chroma subsampling , the amount of bits is reduced

YV12 4:2:0 is "12bpp" because U , V ,are reduced in dimension 1/2 for width and height . e.g. 1920x1080 is only 960x540 in each U, V plane or 1/4 of the bits. So 8 + 2 + 2 = 12

YUY2 4:2:2 is "16bpp" because U, V planes are 1/2 of the bits, or 8+4+4 = 16
poisondeathray is offline   Reply With Quote
Old 3rd November 2013, 14:22   #73  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Quote:
Originally Posted by poisondeathray View Post
I don't know what terminology conventions HEVC uses, but traditionally BPP is different than BPC

BPC is bits per channel . e.g. 8bits R, 8bits B, 8bits G for "8bit RGB" , or 8bit Y, 8bit U, 8bit V for "8bit YUV". It's usually expressed as per channel as in each channel . 8bit values would allow for 2^8 or (0 to 255) = 256 values per channel . It's also referred to as "bit depth"

BPP is bits per pixel . It's usually expressed as the sum of the bits in all the channels . However, because of chroma subsampling , the amount of bits is reduced

YV12 4:2:0 is "12bpp" because U , V ,are reduced in dimension 1/2 for width and height . e.g. 1920x1080 is only 960x540 in each U, V plane or 1/4 of the bits. So 8 + 2 + 2 = 12

YUY2 4:2:2 is "16bpp" because U, V planes are 1/2 of the bits, or 8+4+4 = 16
Well, obviously there is some confusion on that. For what it's worth, ImageMagick uses 'bits per pixel' to mean the 'bits per channel/component' case, so I just went with their description.
qyot27 is offline   Reply With Quote
Old 3rd November 2013, 16:00   #74  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Quote:
Originally Posted by Selur View Post
@qyot27: did a clean checkout and 'cmake .' ends with:

(got a clean Snow Leopard install with Xcode 4 installed)


I guess, only installed Xcode 4 and it's command line tools,..
It would appear that the -mstackalign issue is a common problem for 64-bit Snow Leopard. At the very least, Homebrew requires Lion for the x265 formula:
https://github.com/mxcl/homebrew/commit/fe806e9adb03f7f3fe87b8b6153e864f19bfa1d8

And they make mention of the -mstackalign issue in the formula.

It *might* be possible to get around it for Snow Leopard if you build your compilation toolchain from scratch and make sure it's updated enough, but that's only a guess (and beyond what the average user is willing to do).
qyot27 is offline   Reply With Quote
Old 3rd November 2013, 20:56   #75  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by poisondeathray View Post
I don't know what terminology conventions HEVC uses, but traditionally BPP is different than BPC

BPC is bits per channel . e.g. 8bits R, 8bits B, 8bits G for "8bit RGB" , or 8bit Y, 8bit U, 8bit V for "8bit YUV". It's usually expressed as per channel as in each channel . 8bit values would allow for 2^8 or (0 to 255) = 256 values per channel . It's also referred to as "bit depth"

BPP is bits per pixel . It's usually expressed as the sum of the bits in all the channels . However, because of chroma subsampling , the amount of bits is reduced

YV12 4:2:0 is "12bpp" because U , V ,are reduced in dimension 1/2 for width and height . e.g. 1920x1080 is only 960x540 in each U, V plane or 1/4 of the bits. So 8 + 2 + 2 = 12

YUY2 4:2:2 is "16bpp" because U, V planes are 1/2 of the bits, or 8+4+4 = 16
In video coding, bits per pixel is generally understood to mean the # of bits per sample (per pixel per color), not the sum of all bits in all channels for each pixel. For example, note how Imagination uses a row labeled "bit/pixel" in their chart when defining their HEVC decoding capability - http://withimagination.imgtec.com/in...colour-formats. It is not as technically accurate as bits/color or bits/sample, but it is fairly prevalent, even among video professionals. It's understood by the context that we're not talking about 8, 10 or 12 bits for the whole RGB or YUV pixel.

Obviously, you can't use 8 bit internal precision when working with decoded video that was encoded with 10 or 12 bits per sample. So, the encoder must switch over to using 16 bit values internally (even though the least 6 or 4 significant bits will be zero). For obvious reasons, this will impact performance.

x265 can be built to use 8 bit internal precision, or (with the HIGH_BIT_DEPTH build option) 16 bit internal precision. The HIGH_BIT_DEPTH version of x265 has not been an area of focus in the initial months of the project, but are fully committed to supporting high bit depths, and we are starting to devote more time and attention to this now.

Tom
MulticoreWare
  Reply With Quote
Old 3rd November 2013, 21:32   #76  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 729
I don't know any details, but it seems that some sort of CRF rate-control has landed in x265 code tree: https://bitbucket.org/multicoreware/x265/commits/c51c35880df53def63953e95d81ad90b56ea67b9
mandarinka is offline   Reply With Quote
Old 3rd November 2013, 23:19   #77  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by x265_Project View Post
In video coding, bits per pixel is generally understood to mean the # of bits per sample (per pixel per color), not the sum of all bits in all channels for each pixel. For example, note how Imagination uses a row labeled "bit/pixel" in their chart when defining their HEVC decoding capability - http://withimagination.imgtec.com/in...colour-formats. It is not as technically accurate as bits/color or bits/sample, but it is fairly prevalent, even among video professionals. It's understood by the context that we're not talking about 8, 10 or 12 bits for the whole RGB or YUV pixel.

Obviously, you can't use 8 bit internal precision when working with decoded video that was encoded with 10 or 12 bits per sample. So, the encoder must switch over to using 16 bit values internally (even though the least 6 or 4 significant bits will be zero). For obvious reasons, this will impact performance.

x265 can be built to use 8 bit internal precision, or (with the HIGH_BIT_DEPTH build option) 16 bit internal precision. The HIGH_BIT_DEPTH version of x265 has not been an area of focus in the initial months of the project, but are fully committed to supporting high bit depths, and we are starting to devote more time and attention to this now.

Tom
MulticoreWare

Thanks, It's good that you clarify that

There is some confusion, it almost feels like a "switcharoo" , sort of like how "PAR" or pixel aspect ratio was used in MPEG2 terminology but "SAR" or sample aspect ratio is used in MPEG4-AVC terminology

I'm not sure of the historical orgins, but I think the the term "bpp" was derived from old computer graphics displays . For example, Microsoft uses the old terminology for video rendering.

http://msdn.microsoft.com/en-us/library/windows/desktop/dd206750%28v=vs.85%29.aspx#YUV420formats12bitsperpixel
poisondeathray is offline   Reply With Quote
Old 4th November 2013, 08:10   #78  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Can someone please compile this video with HEVC while retaining maximum bitrate.

"Ducks take off" 1080p 108Mbps MKV.
https://docs.google.com/file/d/0B-Xd...=sharing&pli=1

Last edited by James Freeman; 4th November 2013 at 08:15.
James Freeman is offline   Reply With Quote
Old 4th November 2013, 09:22   #79  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Compile? Encode, probably.

Recoding from a quite lossy source may not make much sense. A best possible source is always preferable. The file name (including "CRF25") suggests a rather low quality.

And furthermore, the rate control of x265 is probably not yet implemented up to the ability of ensuring a specific maximum bitrate, this would certainly require a VBV or similar implementation.

BTW, you ask for a maximum of 108 Mbps, this looks like a double 802.11g WLAN rate?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 4th November 2013, 10:53   #80  |  Link
Brazil2
Registered User
 
Join Date: Jul 2008
Posts: 532
Quote:
Originally Posted by James Freeman View Post
Can someone please compile this video with HEVC while retaining maximum bitrate.
"Ducks take off" 1080p 108Mbps MKV.
https://docs.google.com/file/d/0B-Xd...=sharing&pli=1
Check this one :
http://forum.doom9.org/showthread.ph...83#post1651083
Brazil2 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 01:42.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.