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.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 18th November 2008, 01:01   #1  |  Link
ACoolie
Registered User
 
Join Date: Mar 2008
Posts: 30
x264 Pre scenecut Error

It's not a very significant bug, but with pre-scenecut on (or x264 is threaded), I get 38 of 51 frames as i-frames, and the others as p-frames. With pre-scenecut off I get only 3 i-frames. I observed the same 38/13 frame decision with threads=1 and pre-scenecut on.

The source is House Season 4 Episode 1 DVD. The clip is a dust cloud caused by a building collapsing.

This is the stats file and the x264 output:
http://pastebin.ca/1259842
Here is the source in y4m. I don't know how to frame-accurately cut a VOB (9MB): http://rapidshare.com/files/164818388/out.y4m.zip
ACoolie is offline   Reply With Quote
Old 18th November 2008, 01:05   #2  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Pre-scenecut tends to be more aggressive than scenecut, especially in the case of psy-RD, as psy-RD tends to bias against intra-blocks but is only taken into account in non-pre-scenecut.

It chose scenecuts there because those frames were basically completely uncorrelated: they were completely smoke-filled, leading to be basically nothing but grain, so this resulted in the entire sequence being encoded as I-frames.

Generally, I think pre-scenecut tends to be more accurate. It might be an interesting project, sometime, however, to make pre-scenecut more adaptive to the effects and properties of psy-RD.

Edit: Just tested, and even with psy-RD, there's no point in making them P-frames. The frames are over 80% i8x8 blocks at CRF18. It does get a bit less optimal at higher CRFs though.

Last edited by Dark Shikari; 18th November 2008 at 01:13.
Dark Shikari is offline   Reply With Quote
Old 20th November 2008, 02:58   #3  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,174
Quote:
Originally Posted by Dark Shikari View Post
It chose scenecuts there because those frames were basically completely uncorrelated: they were completely smoke-filled, leading to be basically nothing but grain, so this resulted in the entire sequence being encoded as I-frames.
This brings up a question I forgot to ask some time ago: When you have a run of uncorrelated frames like this, and you don't want to shovel a lot of extra bitrate into them, but don't want them to get all blurry, what can you do? I was thinking, encoder side, reduce deblocking so that it doesn't get too blurry on high quantizer, while selectively keeping high frequency bands for the illusion of a noisy source? (Blurring & blocking are far more noticeable than ringing at times like that, after all.) Without changing the encoder, I don't really know what to do even if I singled the frames out in a zone.
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. ~ Ed Howdershelt
foxyshadis is offline   Reply With Quote
Old 20th November 2008, 04:03   #4  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by foxyshadis View Post
This brings up a question I forgot to ask some time ago: When you have a run of uncorrelated frames like this, and you don't want to shovel a lot of extra bitrate into them, but don't want them to get all blurry, what can you do? I was thinking, encoder side, reduce deblocking so that it doesn't get too blurry on high quantizer, while selectively keeping high frequency bands for the illusion of a noisy source? (Blurring & blocking are far more noticeable than ringing at times like that, after all.) Without changing the encoder, I don't really know what to do even if I singled the frames out in a zone.
qcomp will already generally lower the bitrate of complex grainy sections like that.
Dark Shikari is offline   Reply With Quote
Old 18th November 2008, 01:08   #5  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,756
Isn't it expected to get a different result with pre-scenecut, compared to pre-scenecut disabled ???

Also: Why do you think it is a bug? 38 of 51 frames as I-Frames sound like very much, but does it actually look worse with that specific sample?
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 18th November 2008, 01:22   #6  |  Link
ACoolie
Registered User
 
Join Date: Mar 2008
Posts: 30
Thanks DarkShikari, I'll never doubt x264's pre-scenecut decision again!

@Lord_Mulder: I thought it was a bug because so many consecutive i-frames seemed suboptimal and the final bitrate of the pre-scenecut encode was over 2000kb/s greater than the scenecut encode.
ACoolie is offline   Reply With Quote
Old 18th November 2008, 01:27   #7  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,756
Quote:
Originally Posted by ACoolie View Post
@Lord_Mulder: I thought it was a bug because so many consecutive i-frames seemed suboptimal and the final bitrate of the pre-scenecut encode was over 2000kb/s greater than the scenecut encode.
You must do 2-Pass encodes and compare two encodes of the same size/bitrate. Then decide which one looks better.
Looking at the size of an encode alone doesn't help anything. It's the "quality to bitrate" ratio that matters. And 2-Pass is the only feasible way to compare that.

A great number of consecutive I-Frames would only be sub-optimal for your source, if it looks worse at same bitrate/size.
If pre-scenecut produces a bigger file in CRF mode, then it's almost impossible to decide whether the increase in quality is worth the increase in size or not...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 18th November 2008 at 01:30.
LoRd_MuldeR is offline   Reply With Quote
Old 18th November 2008, 01:37   #8  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by ACoolie View Post
Thanks DarkShikari, I'll never doubt x264's pre-scenecut decision again!
Probably a bad idea as well, it isn't perfect
Dark Shikari is offline   Reply With Quote
Old 21st November 2008, 08:35   #9  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,174
But doesn't that generally just make it blurry, with default matrix and sane AQ/RDO values?
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. ~ Ed Howdershelt
foxyshadis is offline   Reply With Quote
Old 21st November 2008, 08:36   #10  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by foxyshadis View Post
But doesn't that generally just make it blurry, with default matrix and sane AQ/RDO values?
Not really. As long as psy-RD has grain to grab from previous frames, things generally turn out fine as long as the quantizer doesn't go ridiculously high.
Dark Shikari is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 22:34.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.