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. |
25th February 2015, 07:40 | #101 | Link |
Registered User
Join Date: Sep 2007
Posts: 41
|
use same clip having a daala test
the daala one's performance is truly good! (-v30) ......I forgot I have already had the post...... ......here it is... http://pan.baidu.com/s/1jGh5K1K x265 1.5 daala foxyshadis's latest build (dedicated) Last edited by uneedme; 25th February 2015 at 07:48. |
25th March 2015, 14:11 | #102 | Link |
Registered User
Join Date: Mar 2002
Posts: 863
|
Daala got a new block size RDO algorithm, which supposedly brings decent quality/efficiency improvements. I'm curious how it performs now, so i'd be grateful if someone could make a new build.
Last edited by Tommy Carrot; 25th March 2015 at 16:49. |
27th March 2015, 10:26 | #105 | Link |
Registered User
Join Date: Aug 2009
Posts: 201
|
The IETF decided to formed a working group to develop a royalty-free video codec for internet usage, after their success with Opus in the audio space.
http://www.ietf.org/mail-archive/web.../msg00235.html This might be Daala or some future variant, as the Daala team are heavily involved, but it could well follow the Opus path where tech from rival companies was combined into something new. Rubber stamping VP9 (or 10?) isn't entirely out of the question either though it seems like beyond VP9/H265 is seen as the target space. |
27th March 2015, 16:43 | #106 | Link |
Registered User
Join Date: Jan 2007
Posts: 729
|
Hopefully the "internet" target doesn't impact its compression strength in other less constrained settings. I'd like more changes in the high fidelity, high bitrate space too. Currently, that usage is ruled by x264 and since circa 2011, little has changed :/
Last edited by mandarinka; 27th March 2015 at 16:46. |
28th March 2015, 02:20 | #107 | Link |
Registered User
Join Date: Mar 2002
Posts: 863
|
Thanks for the new build.
Yeah, the ringing is still pretty bad, in fact in many cases it has gotten worse, perhaps due to the tendency to prefer larger blocks (so the ringing spreads further). Also, the motion artifacts are still very noticable. On the other hand, the level of detail and the overally efficiency has definitely improved a lot since the previous build. |
8th April 2015, 09:08 | #108 | Link |
Registered User
Join Date: Jul 2003
Location: somewhere north
Posts: 260
|
wut am stuck at 1 core on my 8 core cpu encoding daala
__________________
Woah! Ninja?! http://nwgat.ninja/ (AV1 Overview) "Not available in your region" has now been redefined as "Go Pirate, you filthy scum" Nwgat |
9th April 2015, 14:19 | #109 | Link |
Registered User
Join Date: Jan 2007
Posts: 729
|
You have read on some FLOSSy blog that "Xiph is finishing Daala and it already looks very good" or something like that, didn't you
Well, the reality is that they don't even know yet how will they go about finishing the bitstream format (last time I checked, the intra prediction was still unsolved problem and they have other issues). So multithreading in the *example/reference* encoder is something that hasn't even been touched on. It is simply not time for bothering with such stuff when you are still in a format-design phase. Since it is in no way suitable or usable for actual use, it doesn't matter if it only uses 1 thread. |
9th April 2015, 15:16 | #110 | Link | |
Registered User
Join Date: Jul 2003
Location: somewhere north
Posts: 260
|
Quote:
__________________
Woah! Ninja?! http://nwgat.ninja/ (AV1 Overview) "Not available in your region" has now been redefined as "Go Pirate, you filthy scum" Nwgat |
|
9th April 2015, 16:14 | #111 | Link |
Registered User
Join Date: Jan 2007
Posts: 729
|
Everything improves. Theora was making those "huge strides" all the time. If you start with no rate control and untuned stuff, it is natural that you improve. It still doesn't mean that the format will end up good or usable.
IMHO it is better to not put too much hope into these things for now and wait till it is more finished. Once everything is done and implemented in a realistic production encoder (which tend to have speedup optimizations that sacrifice quality), it might turn up that it has more artifacts, worse compression and is harder to decode than HEVC... Not that I would want that, but to be honest I think it will be very hard to beat HEVC and I'm not really sure Xiph&Co.'s resources and design approach can deliver that. The royalty-free requirement is an obvious burden too. </scepticism> |
9th April 2015, 18:14 | #112 | Link | |
Registered User
Join Date: Oct 2009
Posts: 930
|
Quote:
|
|
9th April 2015, 20:33 | #113 | Link | |
Registered User
Join Date: Jan 2007
Posts: 729
|
Quote:
AFAIK Daala is designed for YUV, with techniques like luma-to-chroma prediction especially. |
|
9th April 2015, 21:02 | #114 | Link | |
Registered User
Join Date: Oct 2009
Posts: 930
|
Quote:
|
|
9th April 2015, 21:07 | #115 | Link |
Registered User
Join Date: Jan 2007
Posts: 729
|
But that would be silly - why move the RGB conversion into the decoder when it can be completely standalone. If they were changing the storage format to get more compression, they would instead use something even more complex than YUV and even more different from RGB.
|
9th April 2015, 21:35 | #116 | Link | ||
Registered User
Join Date: Oct 2009
Posts: 930
|
Quote:
Quote:
|
||
10th April 2015, 15:58 | #118 | Link | |
Registered User
Join Date: Oct 2009
Posts: 930
|
Quote:
Or bringing a consistent video quality, by not relying on inconsistent hardware/software environment for scaling is too vague? |
|
10th April 2015, 16:01 | #119 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,348
|
A decoder should always decode to its native storage format, anything else just eats massive performance. A conversion to RGB can be done much much more efficient on the GPU.
If you are afraid of bad conversions, just use a software converter that you control yourself.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
10th April 2015, 16:15 | #120 | Link | |
Guest
Posts: n/a
|
Quote:
Only if you sacrifice all the performance benefits of hardware-accelerated colorspace conversion and scaling that the renderer can take advantage of. If you do, though, make the decoder use the GPU for doing the colorspace conversion then you run into the exact same inconsistent hardware/software issue. So I don't see a single benefit to your idea over simply outputing the native pixel format and using madVR to convert to RGB and scale when rendering the video. Last edited by captainadamo; 10th April 2015 at 16:18. |
|
|
|