2008-08-18, 19:01 | Link #24 |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
Real Encoders always use 16 references and set --level 5.1 explicitly on all content regardless of actual level/profile just to annoy PS3/X360 owners and DXVA users.
(I'm such a nice guy you see)
__________________
|
2008-08-18, 21:45 | Link #26 | |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
Quote:
That aside with anime 16 refs can actually be useful, the improvements are small but they do exist. Empirical observations from my own encodes indicate that refs beyond 10 are used about 1-2% of the time.
__________________
|
|
2008-08-19, 19:10 | Link #32 |
Fansubber
Fansubber
Join Date: Jun 2007
|
There have been countless times, though, that I've heard complaints from single-core users, complaining about unacceptable playback on their machines. (dropped frames, audio/video desync etc). So, as an encoder, I am really interesting in sorting out this matter with real numbers and percentages.
|
2008-08-19, 19:16 | Link #33 |
Aegisub dev
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 39
|
I'm pretty sure that more reference frames doesn't increase CPU usage at decoding, only memory usage because it needs to keep more decoded frames in memory.
Actually, on a second though it might increase CPU usage because B-frames may refer to much later frames meaning that more later frames must be decoded before a frame can be displayed.
__________________
|
2008-08-19, 23:39 | Link #34 |
Panda Herder
Join Date: Dec 2005
Location: A bombed out building in Beruit.
|
From what I understand bitrate, CABAC and resolution have the biggest impact. If you're very curious try a crf encodes with different reference frames and see what the difference in decoding speed is with timecodec.
|
2008-08-19, 23:41 | Link #35 | |
Senior Member
Join Date: Mar 2008
|
Quote:
__________________
|
|
2008-08-19, 23:44 | Link #36 | |
x264 Developer
Join Date: Feb 2008
|
Quote:
B-frames slow down decoding, but they also reduce bitrate at the same quality level, so they're a net win, since the bitrate affects decoding speed a lot too. Multiple reference frames has nearly no impact on decoding speed (basically zero). It might even help because, again, it reduces bitrate at the same quality level. |
|
2008-08-20, 01:07 | Link #37 | |
Cogito, Ergo Sum
Fansubber
Join Date: Jul 2006
Age: 43
|
Quote:
The result is that the psyRDO disabled plays everywhere smoothly, while the psyRDO enabled stutters even in a friend's 2-month Core2Duo (can't remember the model atm).
__________________
|
|
2008-08-20, 01:08 | Link #38 | |||
Fansubber
Fansubber
Join Date: Jun 2007
|
Quote:
Quote:
So, what is left is the bitrate. Surely, when the bitrate increases, so does the complexity of the content it describes. In other words, more bitrate describes a content with more details. Absolutely true. But then again, we can' t lower it too much, can we? Quote:
I haven't really studied how x264 exactly works, but as far as I know, in a traditional mpeg there are I-frames and B-frames. Now, when a b-frame is both dependent to I-frames and B-frames, I guess we have to do the extra work of decoding the depencies first. And if I am right, the concept of the "b-pyramid" refers to the fact that these dependencies can be dependent on other frames, too. References, especially mixed-references, come to make this thing even more complex. It sounds to me like we are not only dealing with the individual frames and their decoding, but we are trying to deal with every partition of every frame. Let's say that a b-frame needs another 16 b-frames to be decoded. And let's also say that each of these 16 b-frames, has 16 references for its partitions. I guess with mixed ref, the reference can be a b-frame as well, which can also have further references and dependencies. So, how can it be that more reference frames provide us with a more lightweight encoding, instead of making it a lot heavier? Last edited by Left64Vegeta; 2008-08-20 at 02:37. |
|||
2008-08-20, 08:56 | Link #40 | |||
x264 Developer
Join Date: Feb 2008
|
Quote:
Quote:
Quote:
|
|||
Tags |
best practice, common standards, encoding |
Thread Tools | |
|
|