Author Topic: [WONTFIX] Variable bitrate according to buffer level  (Read 24216 times)

Leon

  • Freshman
  • **
  • Posts: 73
Re: [WONTFIX] Variable bitrate according to buffer level
« Reply #25 on: August 03, 2012, 12:28:35 AM »
I just don't get why this is dismissed as a "won't fix"; it would be great for people with Class 4 cards (and slow/strange Class 6 cards like my Verbatim) to be able to use CBR 1.0x, and/or more safely.

sibero80

  • New to the forum
  • *
  • Posts: 9
Re: [WONTFIX] Variable bitrate according to buffer level
« Reply #26 on: August 06, 2012, 03:28:07 AM »
I've been reading some discussions about Qscale and Bitrate regarding image quality.
I have 2 questions that I dont know if they've been anwered indirectly, so Im asking here instead of creating a new thread.
Specially since developers are stating that increasing bitrate doesnt improve image quality.

1. What encoding factor could improve final results in darker areas and gradients? (banding/blocking) ( www.davidarango.com/H264.PNG )
2. In your experience with the image quality affecting factors.. theoretically speaking, could something be done software wise to improve the downsampling/line-skipping method to produce sharper images?

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 12564
Re: [WONTFIX] Variable bitrate according to buffer level
« Reply #27 on: August 06, 2012, 05:47:03 PM »
Quote
I just don't get why this is dismissed as a "won't fix"

Just try to use older ML versions with CBRe (not CBR). They did exactly what you requested.

To rewrite Canon's compression algorithm (the QScale adjustment part), one has to:

1) Find out when this adjustment should be done (somewhere in this state machine: http://a1ex.bitbucket.io/ML/states/550D-alt/sm33.htm )
2) Design the algorithm - how to change the QScale? based on what input data? Buffer level is not enough, you also need a mathematical model of what fluctuations you can expect; the H264 encoder operates with constant quality, and to get constant frame size, you have to look at previous frames. It's real-time operation, not a two-pass offline encoding process.
3) How to test? how can you tell it's more robust than Canon's? They already did a huge amount of testing and probably have engineering teams that do just this.

I'm not going to do this. It will be probably thousands of hours of work for a very small improvement that most people won't even notice.

Instead, try to change the parameters exposed by Canon's H.264 implementation. This is happening here: http://www.magiclantern.fm/forum/index.php?topic=1565.0

Closed.