Did you try it? What's your expreiences with the new codec? It is compatible with FFMPEG....
It works only in 32bit systems, and it has real GPU support.
"Simple and powerful HEVC/H.265 implement.
Optimize for embedded, FPGA, GPU, MultiCores system."
Homepage and dowloands of the new codec: http://code.google.com/p/x265/
What's your opinions?
Describe your opinions and views!
Thank you for your reply!
+ Reply to Thread
Results 1 to 30 of 42
It is still early in development (even the official JM reference version is still in development) - right now it doesn' t look to be optimized (very slow, not GPU support added yet - about 75x slower than x264 on "placebo") . It will probably be at least a year before it's suitable for general use
Some early testing results here
I think HEVC looks promising, here my little test on foreman_cif.yuv clip
- HM9.1 (build commit a0da0c21f34b05bda60e406f991a76b599876a68 ):
TAppEncoder.exe -c encoder_randomaccess_main.cfg -q 26 -fr 30 -wdt 352 -hgt 288 -f 300 -i foreman_cif.yuv -b hevc.bin
hevc.bin : 369 ko
- X264 (2216)
X264 --tune psnr --crf 26.7 --preset placebo
X264.mkv : 370 ko
psnr with MSU Video Quality Measurement Tool :
HEVC : AVG: 37.57242
X264 : AVG: 36.87016
Not bad for HEVC but not 50% better and X264 encode need ~10 sec and HM9.1 746 sec
And with x264 --tune psnr --preset medium --crf 28.1 : x264.mkv 366 ko
Did you try it?
Over at doom9 JEEP posted a link to TAppEncoder and TAppDecoder if you want to test. (it uses the reference encoder HM9.1, seems like x265 is based on HM6.3)
Also note that x265 is a one-man-project and none of the active x264 developers is involved, so the name choice seems more like a publicity stunt than anything else)
What's your expreiences with the new codec?
The developers of x264 project were angry, because they wanted the name "x265" for their future HEVC project. The compromise between the developer boy of x.265 and the developer team of x.264 would be better! Wouldn't it? They could produce a better codec together.
LOL - I asked the same question almost a year ago
Last I heard, the x264 dev's were more interested working on daala, not a HEVC implementation
yes, but it certainly sounds like they have a working version:
Rovi will have a production ready version of its HEVC codec following official ratification of the standard, in early 2013. The product will include a new encoder, decoder, and transport multiplexer for various platforms including Windows, Mac OS, Linux, iOS and Android. Rovi will be demonstrating the new HEVC SDK encoder in its booth (Hall 5, Stand 5.A31) at IBC 2012.
I have added in "encmain" programme print command,but when i run the program added print command dose not apply,why????
As of now, h.265 video tools are totally vaporware. And considering the state of open source h.264 video tools, after all this time, I'm not holding my breath.
64bit x264 is roughly 10%+ faster, but other than that and it's limited to a maximum of 4GB RAM for it's lookaheads&co (which should not really matter at all)
I know 10%+ faster encoding is nice, but not really reason to not encode with it.
I did most of the steps available on the above web site to test run the HEVC but i am stuck in point no.3 ---The encoder tool is called TAppEncoder.exe which should be located in trunk/bin/vc9/win32/release.
this is the 3rd step and i can not locate bin folder in trunk. if some body knows something about that please help me out.waiting for reply
There's a download link for TAppEncoder over at doom9, link was posted before,..
We searched for that link but unable to find.Could you please share it again.
i am trying with teh same stream.lets hope that it runs
hi there thanks for all the help.
it is running now.i am just changing the configuration file to get some different results.
one thing more which is still not resolved.The YUV player which i got from web site--- http://codesequoia.wordpress.com/2012/11/04/make-your-first-hevc-stream/#comment-251------
does not support more than 20 frames.if someone knows about that issue plz let me know.
I would want to configure a GOP of size 16 for HEVC, but I have plenty of errors. Can someone please help me with this, I am really stuck at this point.
It's -g in the reference encoder, it might not be implemented yet properly in the x265 variants (they are very alpha right now and missing many things)
I am sorry I didn't gave enough details. Actually I am using HM 9.0 and I have a config file, with the GOP table as specified in the user manual. I tested HEVC with GOP size 4 and 8 but the GOP of size 16 I don't know to make it.
Here is what I've tried to make:
#======== Coding Structure =============
IntraPeriod : 64 # Period of I-Frame ( -1 = only first)
DecodingRefreshType : 0 # Random Accesss 0:none, 1:CDR, 2:IDR
GOPSize : 16 # GOP Size (number of B slice = GOPSize-1)
# Type POC QPoffset QPfactor tcOffsetDiv2 betaOffsetDiv2 temporal_id #ref_pics_active #ref_pics reference pictures predict deltaRPS #ref_idcs reference idcs
Frame1: B 16 1 0.442 0 0 0 4 4 -16 -18 -20 -32 0
Frame2: B 8 2 0.3536 0 0 0 3 3 -8 -10 8 2 0
Frame3: B 4 3 0.3536 0 0 0 4 4 -4 -6 4 12 2 2
Frame4: B 2 4 0.68 0 0 0 4 4 -2 -4 2 6 2 1
Frame5: B 1 4 0.68 0 0 0 4 4 -1 1 3 7 2 -2
Frame6: B 3 3 0.3536 0 0 0 4 4 -1 -3 1 5 2 -3
Frame7: B 6 4 0.68 0 0 0 4 4 -2 -4 -6 2 2 1
Frame8: B 7 4 0.68 0 0 0 4 4 -1 -3 -5 1 2 -2
Frame9: B 5 1 0.353 0 0 0 4 4 -1 -5 1 3 2 -2
Frame10: B 9 2 0.3536 0 0 0 4 4 -1 -5 -9 7 2 0
Frame11: B 12 3 0.3536 0 0 0 4 4 -3 -4 -8 -4 2 0
Frame12: B 10 4 0.68 0 0 0 4 4 -1 -2 -6 2 2 1
Frame13: B 11 4 0.68 0 0 0 4 4 -3 -7 1 5 2 -2
Frame14: B 14 3 0.3536 0 0 0 4 4 -2 -5 -6 2 2 0
Frame15: B 13 4 0.68 0 0 0 4 4 -1 -3 1 3 2 0
Frame16: B 15 4 0.68 0 0 0 4 4 -1 -3 -7 1 2 1
ListCombination : 1 # Use combined list for uni-prediction in B-slices
Last edited by roa; 7th Aug 2013 at 09:17.
They actually define "GOP size" as the number of b slices, "IntraPeriod" as I-frame interval.
But traditionally, "GOP size" would actually refer to "IntraPeriod", is that what you want ? Or did you really want to specify 16 b slices ?
What error are you getting ?
So far, I tried to specify 16 B slices.
The first error is:
Error: ref pic -5 is not available for GOP frame 9
Error: Invalid GOP structure given
After I change all the reference pictures in order to be accepted by the encoder (even if it is not according to my initial planned structure) and to have a valid Gop structure, I receive a segmentation fault.
So, regarding what you said, it should be enough to use a GOP of 8 B slices and with I-frame period of 16? Is this the equivalent of Gop size 16?
I need this because I am trying to compare HEVC with H.264 and I want to see the influence of Gop structure in both cases.
Yes, if you set intraperiod to 16, and gopsize to 8 , the GOP structure I->I will be 16 comparable to if you set h.264 to 16.
The "gopsize" in HEVC means that pattern repeats, so 2 sets of 8 b-slices in that example. If you use something like the random access template, it will be IBBBBBBBBBBBBBBI for a what h.264 would call a GOP size of 16.
But you have "decodingrefresh" set to 0 in your cfg file ; so that' s not really an access delimiter in the sense of an "IDR" frame equivalent in h.264. Set it to 2 if you want equivalent to "IDR" frame, or set it to 1 if you want to allow "open GOP's"
Thank you for your explanation, you made my day. I wasn't aware of the influence of DecodingRefreshType. So, I will set it to 2 for having the same parameters as in h.264. Does H.264 allows open gop's?
h264 spec allows for open GOP's , so it depends on which flavor of h264 implementation you are using . The majority have it set to closed by default , so DecodingRefreshType should usually be set to 2
But for example, with x264 you can use --open-gop , in which DecodingRefreshType should be set to 1 if you want "apples to apples" comparison
the switch for open gop in ffmpeg libx264 is -x264opts open-gop , -g is the gop size (max I->I interval, during which which a non IDR frame might be placed if open gop is used)
But I'm not sure if it's working properly in ffmpeg libx264, it had problems a while back. It works correctly in x264.exe
Let me do some quick tests....