In our previous discussion you denied that removing duplicate frames reduces significant bitrate and even tried an experiment on a short intro which saved like 5% and you claimed it was a rare case.
I did a REAL experiment on 5 720p South Park episodes. I'll let the numbers speak for themselves.
40% less frames (absolute duplicates) and 80 MB reduced. As I said, trust the master when he gives his words of wisdom.
+ Reply to Thread
Results 1 to 15 of 15
-
-
That's still quite large difference than what I'm used to seeing, still not near the 100% efficiency you claimed. But ~50% is still high (40% fewer frames, but 20% less bitrate is about 50% efficiency). More typical you see for animation with lots of duplicates is around 15-20% efficiency (still significant)
What were your encoding settings for the "normal" runs? For example if you used 3 b-frames you aren't really using "typical" animation settings, and lowering the efficiency. If you're not using b-adapt 2, also you will lower efficiency as b-frame placement won't be ideal . The difference shouldn't be that big if you used typical anime encoding settings -
It depends on the content, specifically ones that greatly benefit from more ref frames. For photographic movies, 8 and 16 refs wont make any difference, for anime/cartoons it will make a noticeable but not considerable difference, for 2D game replay footage, the efficiency increases linearly with more refs, so 8 refs gives half the quality of 16 refs, thus 100% efficiency.
Since South Park is a crudely animated paper cut-out show, motion vectors can't always recognize the proper crafted motion for more refs to be as useful as they could and thus you end up with half the efficiency.
What were your encoding settings for the "normal" runs? For example if you used 3 b-frames you aren't really using "typical" animation settings, and lowering the efficiency. If you're not using b-adapt 2, also you will lower efficiency as b-frame placement won't be ideal . The difference shouldn't be that big if you used typical anime encoding setting -
--ref ? no, not 100% efficiency with linear gains. Eitherway this statement is clearly wrong.
We use maximum settings, 16 b-frames and refs by default for animated content. Everybody should use at least 10 for animation, IMO. I'm frankly ******* tired of downloading rips by idiots who can't be bothered to spend 15 more minutes using more than just 2 refs. I personally buy all my entertainment now to get away from all this rampant inbredism of infestation of retards on the internet that either gives you garbage or makes you wait days to get high quality. My rips give high quality and you wait even less than to get garbage from others, yet mine only have a cult popularity at best. Go figure. -
Yes, the more the content benefits from more --refs, the more bitrate you will reduce when removing duplicates.
Content which does not benefit from more refs, like non-animated video, will not benefit from deldup. Get it now?
Really?? Now that is interesting, that's the largest % efficiency gains I've seen for animation VFR . These are very atypical results . Are you sure everything else was the same ? filters ? -
I know what you're trying to say about this relationship in generic terms, but you don't get 100% efficiency or linear gains with long GOP encoding. Ever.
(Only if you use CBR encoding with I-frames only, will you ever come close)
Another way of saying this is content that benefits from more b-frames and reference frames will likely have more similar content, more static scenes, or even complete duplicates (and thus with duplicates can benefit from dedup or similar functions) . But that is the also very reason why you don't get 100% efficiency. b-frames and p-frames are less expensive to encode bitrate wise (that's the whole idea behind long GOP), and similar content should (and will) be filled with "low cost" b-frames. That's why you use high numbers of consecutive b-frames in the first place for content like simple animation . This is also why the ~50% efficiency numbers look out of the ordinary - the frames that are removed are complete or near duplicates , and thus should have been low cost b-frames in the "normal" non decimated encode. And just from practical experience, I know those numbers are very high. -
You are still forgetting WHY duplicates screw with the encoder in the first place. H264 has a limit of 16 frames you can reference to, so if you have even a completely static video, doubling the frame-rate will basically be halving your refs to the efficiency it can achieve with 8. This is why deldupping is important with videos that need to take advantage of as many --refs as possible. The very best examples are 8 and 16-bit video game replays. Efficiency goes up linearly with more refs. Encoders at TASVideos wish they could go higher than just 16, but now that they discovered deldup, it's not much of a problem anymore.
-
I'm not forgetting anything.
And you are wrong about the 100% number, and you seem to be confusing reference frames with b-frames
Your incorrect assumption is that the number of reference frames used is a 1:1 relationship to bitrate .
Efficiency - defined in terms of ratio of input and output, will never be 100% for long GOP encoding when compared to the VFR duplicate decimated version. FACT.
Higher numbers of references frames will be beneficial on content that can use them, but the slope of the graph won't be 1:1 (or 100%) . So it might be a linear relationship on some types of video, but the slope will be low, not near 1:1 -
And you are wrong about the 100% number, and you seem to be confusing reference frames with b-frames
Your incorrect assumption is that the number of reference frames used is a 1:1 relationship to bitrate.
Higher numbers of references frames will be beneficial on content that can use them, but the slope of the graph won't be 1:1 (or 100%) . So it might be a linear relationship on some types of video, but the slope will be low, not near 1:1 -
Ok I misread - you're using "100%" in the theoretical sense now, nothing necessarily to do with bitrate.
e.g If you use 16 reference frames it will be theortically "100%" more efficient than if you used 8 and for a video (and the video actually used those numbers)
You pulled a switcharoo in terms. We were talking about efficiency in terms of quantitative bitrate e.g 40% reduction in frames and 20% reduction in bitrate is 50% efficiency - but you weren't even talking about bitrate savings now -
Ok I misread - you're using "100%" in the theoretical sense now, nothing necessarily to do with bitrate.
You pulled a switcharoo in terms. We were talking about efficiency in terms of quantitative bitrate e.g 40% reduction in frames and 20% reduction in bitrate is 50% efficiency - but you weren't even talking about bitrate savings now -
-
And how are you measuring "quality" ? Something like SSIM ?
So with your definition, what would "100% efficiency" indicate ?
Earlier we were talking about decimating duplicates, and efficiency in those terms is measured by
(% less bitrate compared to non decimated encode) / (% of fewer frames by decimation) -
And how are you measuring "quality" ? Something like SSIM ?
So with your definition, what would "100% efficiency" indicate ?
Earlier we were talking about decimating duplicates, and efficiency in those terms is measured by
(% less bitrate compared to non decimated encode) / (% of fewer frames by decimation)