http://www.eoshd.com/content/11534/new-h-265-codec-test-prores-4444-quality-1-file-size
There are a few H.265 projects and encoders/decoders popping up online plus source code for devs: https://bitbucket.org/multicoreware/x265/wiki/Home (https://bitbucket.org/multicoreware/x265/wiki/Home)
The Cinec encoder with HERC/H.265 (v2.7) doesn't appear to be available yet. Still showing v2.5
Divx has a working 1080p HERC encoder http://www.divx.com/en/software/hevc-plugin (http://www.divx.com/en/software/hevc-plugin)
Here come... this kind of questions
-It's possible to implement this codec in ours machines and have better compress video?
-The problem is how to access the h.264 chip? The dedicated chip don't have enough power.
-Will be illegal?
-Impossible, but why? The dedicated chip don't have enough power.
-How i can start to make reverse engeniere for the chip that contain the h.264 codec of our beloved cameras? ::)
Quote from: arrinkiiii on November 18, 2013, 03:23:09 PM
-Will be illegal?
I think it's illegal, copyright, such as MP3 codec, we can not use it for audio playback or record. We need to use WAV files.
Quote from: Greg on November 18, 2013, 05:35:34 PM
I think it's illegal, copyright, such as MP3 codec, we can not use it for audio playback or record. We need to use WAV files.
Did't know that mp3 is copyright... it's allover the internet. God to know this =))
http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds
Here are binarys of x.265 and a GUI
But I can't get it work. I think I use the wrong cmd.
how i wish to know a lite bit of code...
"SYSTEM REQUIREMENTS
Hardware: AVX capable CPU recommended
At least 8GB of RAM
Software: Win7/8 x86_64
Microsoft Visual C++ Redistributable Update 3 "
Not even this i got in my pc...
It's amazing the sample that you can see with this codec, damnnn :D
I tried the DivX HERC convertor on a 2.8gb DNxHD 10bit 1080p (1m 48s) and it took about 10 mins to convert. It's visually losses to my eyes and file size is down to 80mb. Very promising but needs to get much faster and it eats CPU/GPU.
I can't see this being an 'in-camera' codec for some time yet and 3rd party recorders will have to become much more powerful to record to H.265 externally. When that day comes 4k and 8k will become totally viable IMO.
Yes, indeed. The big camera manufacteres don't want to spend money in new power processors... they prefer to (how i going to say this in english) they prefere to lik/drop2 drop until sometihng new come and they think... "ok, they busted us, we need to upgrade..." and with this "frenessim" of evolution in video world if they not, they will stay behind.... i remeber wend im a kid that grundig (german) and sony are the main leader of TV's... and look now. Remember, dslr are for photo... or was to be?
Quote from: Andy600 on November 19, 2013, 12:03:21 AM
I tried the DivX HERC convertor on a 2.8gb DNxHD 10bit 1080p (1m 48s) and it took about 10 mins to convert.
This means 0.5 fps.
I think at this speed it is not usable even not for uploads on slow internet connections.
With the DIVX h.265 I get 2.6fps on a Xeon E3 1230v3 @3.7GHz
The x.264 is 10 times faster on a slow preset.
Quote from: spider on November 19, 2013, 12:13:04 PM
With the DIVX h.265 I get 2.6fps on a Xeon E3 1230v3 @3.7GHz
The x.264 is 10 times faster on a slow preset.
http://forum.doom9.org/showthread.php?t=141352
QuoteConclusion: Very nice. The last few years have brought an extra 10 fps each year with an increase in quality regarding metrics.
12 fps in one year would be nice.
21.11.2014 should be marked in my calendar 8)
Quote from: spider on November 21, 2013, 12:56:43 PM
21.11.2014 should be marked in my calendar 8)
lololol ;D
MP3 isn't copyrighted, it's patented.
It's only illegal in the countries where mp3 is patented.
Also, the xiph project (ogg, opus, etc) are coming out with their own open source version also of a HEVC.
Also, the h265 is less crisp than the prores.
That's either because h265 uses smoothing to compress OR
because h265 is 4:2:0 for most part. Depends what they converted to.
It's probably a little early to make quality comparisons that are meaningful at this stage, no offence intended.
H.265 is only in it's initial development cycle. If memory serves me correctly, xvid beat x264 in a number of situations early in it's dev cycle. Of course, most people probably didn't use all of the encoder optimisations in x264 when it first arrived since on the then current hardware, it was painfully slow.
I haven't had a chance to test a H.265 encoder yet, so the above is merely speculation based on past experience.
Quote from: Audionut on November 22, 2013, 09:29:20 PM
It's probably a little early to make quality comparisons that are meaningful at this stage, no offence intended.
None taken at all. All the HEVC are in early development and there probably will be improvements again.
Plus on top of that h265, among the other HEVC's, all have 10bit options and 4:4:4.
On top of that, I'm sure there will be a lossless version as well, much like there was for h264.
But still, in that example, there was some blurring going on, which is one way to decrease size, getting rid of grain and such.
Well if they're just going to blur detail away, we should get much better then the 30% or so improvements they claim :P
Development progress of multicoreware looks very healthy. There's been lots of assembly added just in the last 3 days.
Lol yeah.
Webm compared to H264 is more blurred, probably a disadvantage, but it seems to have better quality in other areas.
Here is Xiphs HEVC https://xiph.org/daala/
Edit: My comment on webm was for when they were using VP8, they have since switched to VP9.
(and also switched the audio from ogg to opus)
Any thoughts on the timeframe for useable implementations?
During this years perhaps?
After finally learning to achieve a higher quality of my grades I continue to get frustrated when I convert to web delivery ..:)
Will be like that for a while...
I tried x265 and its terrible slow.
Getting 0.7fps on the "very slow" preset (x264 about 7-9fps) and I can save only about 35-40% bitrate.
I think we have to wait at least 1.5 years.
Isn't very slow much the same as placebo.
I wonder how VP9 compares at the moment.
Also how Xiphs new HEVC compares.
Interesting the VP9 !
Quote from: ItsMeLenny on March 07, 2014, 08:16:43 AM
Isn't very slow much the same as placebo.
The Placebo preset is much slower.
Quote from: spider on March 28, 2014, 11:28:05 AM
The Placebo preset is much slower.
That was in terms of video quality.
There is unnoticeable difference.
http://forum.doom9.org/showthread.php?p=1677487#post1677487
QuoteWe were at the NAB show in Las Vegas last week, giving demonstrations to many of the companies attending, showing x265 encodes of popular video sequences side by side with x264 encodes (the gold standard for quality today). Attendees were blown away by the quality of x265. We demonstrated 2 streams played back in sync, showing the middle 50% of two 4K clips on a 4K monitor. Here is a photo of our demo...
Samsung Galaxy S5 has just came out and it is equipped with an arm based quad core CPU running at 2.5Ghz frequency. If such powerful processors in very little power envelope can be implemented in small devices such as cell phones and tablets then our DSLR cameras can surely can benefit from them.
I don't think computing power of H.265 encoding will be much of an issue after this point. We hear incredible powerful processors coming out rapidly as well as GPUs. NVIDIA Tegra K1 for instance. It has 192 CUDA cores, supports DX11 and the latest technology yet consumes very little power.
Quote from: Nautilus on April 14, 2014, 11:54:04 AM
I don't think computing power of H.265 encoding will be much of an issue after this point.
H.265 is extremely processor intensive. This is one aspect of the spec that helps it to reduce bitrate. It's simply a case of running more and more motion estimations, until the least bit hungry one is found.
Intel is currently delivering around 10%/year (give or take) performance increase with each tik or tok, of it's production cycle. Serious (H.265) performance based development, which likely won't happen until all the main features are implemented, and killer bugs are fixed, is likely to produce 20-50%/year. (http://forum.doom9.org/showthread.php?t=141352)
Considering --preset veryslow encodes at sub 1fps here (OC'd i2700k), it's likely to still be a few years, before even top of the line desktop systems, can encode in real time. And there isn't going to be significant amounts of encodes produced by x265, until after, people can encode movies in less then a day.
GPUs are not suitable for high quality video encoding. There's a reason why HQ GPU based encoders, do not exist. ;)
The dinky little ARM cpu in your phone, probably only produces around 50% of the processing power of a desktop CPU, for each clock cycle. It's good for doing lots of simple things at low power, it's useless for video encoding (or anything else processor intensive).
It won't be until dedicated chips are designed and manufactured (specifically for H.265 decoding/encoding), that you will see encoders in consumer based devices such as phones and cameras. Of course, there are good encoders, and bad encoders (http://x264dev.multimedia.cx/archives/164).
Quote from: Nautilus on April 14, 2014, 11:54:04 AM
If such powerful processors in very little power envelope can be implemented in small devices such as cell phones and tablets then our DSLR cameras can surely can benefit from them.
I am just doing some tests with x265 (very slow preset) and its encoding at 0.4 fps while the CPU consumes 72 W
What do you think?
Which is which?
//edit by Audionut. Images scaled per forum rules. Click for full size images.
I am the original
(https://dl.dropboxusercontent.com/s/6wtykai13j7lm2q/cgi%20testfile2.mov_snapshot_00.02_%5B2014.05.10_21.04.28%5D.jpg?dl=1&token_hash=AAFh4cPBF6o2aIMP9Eego4MAbx2_G5cPqpHKR3l-VAAEAg&expiry=1399763119)
I am encoded with x26x @ 2565 kb/s
(https://dl.dropboxusercontent.com/s/fvxx06qw0v12ic8/cgi%20testfile2%20x2xx%20crf32%202565kbs.jpg?dl=1&token_hash=AAFwCdYSrSLXMd81ymtF9clw5x5KpE1YmrP2Vp18KKZQMQ&expiry=1399763298)
I am encoded with x26x @ 2455 kb/s
(https://dl.dropboxusercontent.com/s/m4e7snof7pldm2n/cgi%20testfile%20x26x%20crf34%202455kbs.jpg?dl=1&token_hash=AAF7v_GpX9eLBf2yHSrsWD1XF-mqjWjc_46uHMfjZUdSQw&expiry=1399763465)
Care to share the x264 command line?
Did you use this psy-rd patch (https://mailman.videolan.org/pipermail/x265-devel/2014-May/004371.html) with x265?
Based on images alone, I would say the bottom one is x264.
--crf34 --preset veryslow was the x264 command line
psy-rd 1.0 was used in x265 also preset veryslow
bit of a pointless test as they're encoded at different bit-rates.
on top of that there are general standards of bit-rate to resolution ratios,
and for fullHD it's quite a bit bigger than 2.5 mbps
Quote from: ItsMeLenny on May 11, 2014, 11:26:38 AM
bit of a pointless test as they're encoded at different bit-rates.
There is nearly no difference
Quoteon top of that there are general standards of bit-rate to resolution ratios,
and for fullHD it's quite a bit bigger than 2.5 mbps
Never heard about general standards of bit-rate to resolution ratios.
But nevertheless YouTube uses around 5mbit/s for 1080p encoded with x264 and x265 goal is saving 50% bitrate.
Quote from: spider on May 11, 2014, 12:30:38 AM
What do you think?
i think that is north of the north eastern airfield in DayZ.
That's absolutely right
And the first one is encoded with x265 and the second one with x264
Quote from: spider on May 11, 2014, 12:40:24 PM
There is nearly no difference
There's a pretty big difference between all 3 photos, the 2 encoded get incredibly smeary and soft.
Quote from: ItsMeLenny on May 11, 2014, 01:58:36 PM
There's a pretty big difference between all 3 photos, the 2 encoded get incredibly smeary and soft.
:o
You talked about bitrate I answered about bitrate and now you reply about visual.
Quote from: spider on May 11, 2014, 12:55:05 PM
And the first one is encoded with x265 and the second one with x264
:)
x264 tries really hard to keep sharp detail (at the cost of some blocking), because it looks better in the temporal domain.
x265, just blurs everything. Of course, x265 is still in its development infancy. x264 was no better than Xvid, or MPEG2, in its early development cycle.
From what I have seen of the psy-rd patch for x265, it currently isn't doing much at default settings.
To be perfectly honest, considering where x264 started, and where it is now, and where x265 is now, I'm excited to see what x265 will be doing in 1-2 years.
Quote from: spider on May 11, 2014, 02:15:54 PM
:o
You talked about bitrate I answered about bitrate and now you reply about visual.
My bad. But then on the note of bitrate, 100kb is a quite a bit when youve only got 2.5mb to spread around.
4.5% bitrate difference :D
For the sake of comparisons, it would be better to be a little closer. x264 accepts decimal places for CRF. --crf 34.3 :)
x265 got tagged as release 1.1 the other day. There have been some good improvements since the last time I tested it.
Is psy-rd still producing artifacts?
It's better now. You may want to try smaller settings (0.2-0.4).
From what I understand, all of the CPU expensive stuff has been translated to ASM, so I imagine we should start to see rate control and quality improvements.
I am using the Divx edition to code and playing on the Divx player. There is not much difference to the visible eye and file sizes are way much smaller.
QuoteI can't see this being an 'in-camera' codec for some time yet and 3rd party recorders will have to become much more powerful to record to H.265 externally.
Not only has it arrived (1 year later), it has arrived at a consumer level price.
http://www.dpreview.com/previews/samsung-nx1
28.2 megapixel APS-C BSI-CMOS sensor
Hybrid AF system with 205 phase-detect points covering 90% of the frame
15 fps burst shooting with continuous autofocus
4K (DCI 4K & UHD) video recording using H.265 codec
Can output 4:2:0 8-bit 4K video over HDMI
Stripe pattern AF illuminator with 15m range
Weather-resistant magnesium alloy body
Context-sensitive adaptive noise reduction
3" tilting Super AMOLED touchscreen display
2.36M dot OLED EVF with 5ms lag
LCD info display on top of camera
Built-in 802.11ac Wi-Fi and Bluetooth
USB 3.0 interface
Optional battery grip
The only thing I don't like about this camera (for the price), is the retarded lens mount that no one cares about. Dear God I wished they had used micro four thirds (since there are a tonne of active adapters for it).
I'm a wedding photographer. I would totally shoot a wedding with this (in favor of my 5DII) for stills. For video, it's a no-brainer.
If those samsung lenses prove to be sharp, it may well be my next camera(s).
With the hybrid AF system, a 28MP crop sensor, it may be the world's best sports camera.
Of course, pro photographers take a long time to get with the program. Mostly because they are wedded to lenses. Samsung may have shot themselves in the foot with their STUPID STUPID STUPID decision to make their own proprietary lenses, and not allow the customer to choose. This could have been a GH4 killer.
By some freak miracle, metabones might decide to come to the party, but I doubt it. They have to justify their choices based on market share.
Looks like marketing to me.
What is better a simple h264 encoder or an even more simple h265 encoder? :o
I've just learned that h.265 AND h.264 can support 10bit color. Pretty annoying camera dev's aren't utilising it.
Please read a little bit more.
1. Had been discussed here more than once
2. There is nothing dev's could do because they have to deal with the technology Canon implemented.
I may be wrong, but I don't think he's talking about Magic Lantern not using it. I think he's just commenting on how lame it is that camera developers such as Canon and Sony are not using 10 bit colour in their codecs. It really is a shame.
^what he said :)
The last time I used x265 was about 8 months ago, and the quality was to be expected given the development infancy. Just tried again with the latest build by LigH, things have improved immensely, both speed and quality. :)
ducks_take_off_1080p50.y4m
x265_Win64_64bpp.exe -o output.hevc input.y4m
x264_Win64_10bit.exe --crf 31.6 input.y4m output.mkv
https://dl.dropboxusercontent.com/u/34113196/x265.hevc (https://dl.dropboxusercontent.com/u/34113196/x265.hevc)
https://dl.dropboxusercontent.com/u/34113196/x264.mkv (https://dl.dropboxusercontent.com/u/34113196/x264.mkv)
y4m [info]: 1920x1080p 1:1 @ 50/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: profile High 10, level 4.2, 4:2:0 10-bit
x264 [info]: frame I:2 Avg QP:50.35 size: 81802
x264 [info]: frame P:251 Avg QP:52.02 size: 37366
x264 [info]: frame B:247 Avg QP:53.78 size: 6177
x264 [info]: consecutive B-frames: 1.2% 98.8% 0.0% 0.0%
x264 [info]: mb I I16..4: 6.1% 71.8% 22.1%
x264 [info]: mb P I16..4: 0.6% 1.6% 0.1% P16..4: 50.2% 19.2% 10.9% 0.0% 0.0% skip:17.3%
x264 [info]: mb B I16..4: 0.0% 0.1% 0.0% B16..8: 41.3% 0.6% 0.2% direct: 0.6% skip:57.2% L0:15.6% L1:82.5% BI: 1.8%
x264 [info]: 8x8 transform intra:70.7% inter:74.1%
x264 [info]: coded y,uvDC,uvAC intra: 58.4% 64.7% 35.6% inter: 25.3% 17.1% 0.8%
x264 [info]: i16 v,h,dc,p: 4% 83% 3% 9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 3% 39% 14% 3% 6% 3% 19% 2% 12%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 4% 52% 12% 3% 5% 2% 12% 1% 8%
x264 [info]: i8c dc,h,v,p: 62% 32% 4% 2%
x264 [info]: Weighted P-Frames: Y:4.8% UV:2.0%
x264 [info]: ref P L0: 90.5% 5.8% 3.6% 0.1%
x264 [info]: ref B L0: 98.0% 2.0%
x264 [info]: kb/s:8854.55
encoded 500 frames, 22.69 fps, 8855.13 kb/s
y4m [info]: 1920x1080 fps 50/1 i420p8 sar 1:1 frames 0 - 499 of 500
x265 [info]: HEVC encoder version 1.4+527-d26268f9dc19
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 10 profile, Level-4.1 (Main tier)
x265 [info]: WPP streams / frame threads / pool : 17 / 3 / 8
x265 [info]: Internal bit depth : 10
x265 [info]: CTU size / RQT depth inter / intra : 64 / 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 : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rd=3 psy-rd=0.30 deblock sao signhide tmvp
x265 [info]: frame I: 3, Avg QP:36.35 kb/s: 34836.93
x265 [info]: frame P: 124, Avg QP:36.74 kb/s: 25119.47
x265 [info]: frame B: 373, Avg QP:39.85 kb/s: 3166.34
x265 [info]: global : 500, Avg QP:39.06 kb/s: 8800.74
x265 [info]: Weighted P-Frames: Y:21.0% UV:13.7%
x265 [info]: consecutive B-frames: 1.6% 0.8% 0.0% 97.6% 0.0%
encoded 500 frames in 82.58s (6.06 fps), 8800.74 kb/s
Quote from: TequilaKez on December 10, 2014, 03:09:16 AM
I've just learned that h.265 AND h.264 can support 10bit color. Pretty annoying camera dev's aren't utilising it.
This! I still don't understand why none of them (Canon, Sony, Panasonic... not so sure about Panasonic, Samsung, etc) don't have a DSLR or mirrorless with 4:2:2 10bit video? I've heard that its done intentionally to not kill off camcorders and other higher end products, in which case, this roughly translates to screwing with the consumer.