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. |
24th July 2013, 11:05 | #181 | Link | |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Quote:
/edit: I stand corrected (see below). Last edited by sneaker_ger; 24th July 2013 at 11:28. |
|
24th July 2013, 11:08 | #182 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
There are a bunch of commits from the "chinese guy" in the MCW x265 repository, so either they are working together, or they recycled some of his changes while keeping attribution.
However, it looks like they started with the HM encoder as a base, not the gcode x265
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
24th July 2013, 12:48 | #184 | Link | |
4:2:0 hater
Join Date: Apr 2008
Posts: 1,302
|
Quote:
|
|
24th July 2013, 13:28 | #185 | Link |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
It's kind of unclear at the moment; from what I recall they intend to add a few external committers and use a more x264-esque development model now that the code is released, but really, I suppose we'll basically wait and see what happens. Hence the tentative endorsement!
|
25th July 2013, 00:01 | #187 | Link |
Registered User
Join Date: May 2008
Posts: 1,840
|
It's nice to see the 3 parties trying to work together instead of fighting over the name 'x265'. It looks like Multicoreware has projects focused on opencl/cuda which brings some hope to achieving high quality, higher speed encoders in the future.
__________________
PC: FX-8320 GTS250 HTPC: G1610 GTX650 PotPlayer/MPC-BE LAVFilters MadVR-Bicubic75AR/Lanczos4AR/Lanczos4AR LumaSharpen -Strength0.9-Pattern3-Clamp0.1-OffsetBias2.0 |
25th July 2013, 01:58 | #188 | Link |
Guest
Posts: n/a
|
Hello everyone! I'm sorry for showing up late to the discussion, but I just created this account on Friday, and there is a 5 day waiting period before you can post messages.
As sborho (our lead developer) posted in the News section, MulticoreWare is excited to lead this project. It is quite challenging to balance the needs and demands of our commercial customers (who are funding the development work) with the needs and desires of the open source community, but we are hopeful that we can manage the project in a way where everyone can benefit. We will do our best to listen and learn, and answer questions to the extent possible. Tom Vaughan MulticoreWare |
25th July 2013, 03:35 | #190 | Link | |
Registered User
Join Date: Jun 2013
Posts: 98
|
Quote:
Thanks and good luck with the project, I will certainly enjoy following it. |
|
25th July 2013, 04:20 | #191 | Link |
Guest
Posts: n/a
|
Thank you for the warm welcome!
We are committed to offering x265 under both commercial and GPL 2 licenses, following the successful business model of x264. We will manage the open source side of the project in a way that is as fair and open as is reasonably possible. MulticoreWare and developers have contributed to and managed a number of open source projects, and we are confident that the rest of the open source development community will appreciate the way that we manage this project. We welcome talented developers to join the project, and we will support them fully. Tom MulticoreWare |
4th August 2013, 05:31 | #192 | Link |
Registered User
Join Date: Dec 2012
Posts: 197
|
I got some time to test x265 on an old Windows Core 2 Duo using the ref pdf's settings (and bframes) and using a couple 1080p JCTVC test clips. There hasn't been any qualitative comments on x265, so I'll offer a few cursory ones.
Quality via MS-SSIM is roughly mid-teens percentage worse than anchor HM11 (parkscene, cactus). MS-SSIM quality versus VP9-cpu-0 on same clips (w/ 1 sec keyints) is strictly better. Subjective quality versus VP9-cpu-0 is distinctly better at QP32, mainly through temporal stability. Speed on 2-thread x265 is comparable to single-threaded VP9-cpu-1, which is then comparable to multithreaded x264 placebo on this system. All in all, I'm quite impressed by initial results. Edit: Ignoring the reference pdf's speed-focused switches will bring x265 almost right on top of anchor HM11 quality. On dual core, speed is now ~halfway between VP9-cpu-0 and cpu-1. Oh, and these were built with latest 8/2/13 commits. Last edited by xooyoozoo; 4th August 2013 at 08:49. |
4th August 2013, 20:09 | #193 | Link |
Testeur de codecs
Join Date: May 2003
Location: France
Posts: 2,484
|
x265 is pre-alpha build. You can't use multithread encoding because quality will be very lower in this case. With best quality profil, x265 must have higher quality than HM11 ...
PS: Which decoder are you using? which muxer are you using? thank's
__________________
Le Sagittaire ... ;-) 1- Ateme AVC or x264 2- VP7 or RV10 only for anime 3- XviD, DivX or WMV9 Last edited by Sagittaire; 4th August 2013 at 20:14. |
4th August 2013, 22:25 | #194 | Link |
Registered User
Join Date: Dec 2012
Posts: 197
|
Well, I was purposefully vague because everything here is still quite transient. My fluffy definition of "almost right on top" quality-wise was low single-digit percents. According to the docs, that should more than account for WPP's slight quality cost (<1% for 1080p).
I've had a good experience with GPAC for muxing/playing, but for the above, I've been using reference HM decoder, which also seems to match x265's internal yuv dump. |
5th August 2013, 17:20 | #195 | Link |
Nooooooooooooooob
Join Date: Jul 2011
Location: China
Posts: 11
|
I've just got MultiCoreWare's x265 source code and built a 8bit version successfully using i686-pc-mingw32 and x86_64-w64-mingw32 on win 7. However there is no "install" instuctions in the makefile generated by cmake. So what execuatables, libraries and headers should I copy in order to "install" it, I mean, to use the x265 library just like how x265.cpp use it? Or x265 just isn't planning to offer a library for other developers to use right now?
BTW: Why the file size of the x265 executable generated by mingw/gcc and MSVC differ so much? The former is about 4-5MB file size and the latter is only about 1.5MB file size...
__________________
vapoursynth auto deint script |
5th August 2013, 18:08 | #197 | Link | |
Nooooooooooooooob
Join Date: Jul 2011
Location: China
Posts: 11
|
Quote:
And the executable is just 1.5MB file size.
__________________
vapoursynth auto deint script Last edited by gnaggnoyil; 5th August 2013 at 18:56. Reason: did what #203 said. |
|
5th August 2013, 18:51 | #199 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
He just created a vanilla build with a special flag on the build command line, how does that require sources? o.O
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
5th August 2013, 18:57 | #200 | Link |
Nooooooooooooooob
Join Date: Jul 2011
Location: China
Posts: 11
|
sorry i didn't thought that it is a kind of "redistribution". i've uploaded a screenshot instead.
__________________
vapoursynth auto deint script Last edited by gnaggnoyil; 5th August 2013 at 19:00. |
Thread Tools | Search this Thread |
Display Modes | |
|
|