Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: ABR 'run in' expression (Read 2277 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

ABR 'run in' expression

Quote
At first, we believed that the bitrate-boost is caused by a very high run-in time,
but then Ivan Dimkovic said that at an average of 128 kbps, the ABR buffer size
should be 300 kilobits, which is 2.34375 seconds. At this point, I would like to
quote the relevant lines from my ICQ conversation with him:

  Ivan Dimkovic: ABR buffer size = 300 kbits
  Ivan Dimkovic: 2.34375
  Ivan Dimkovic: seconds of run-in  if the average rate is 128 kbps


This estimation of run in period for Neros test encodes seems flawed.
I would expect run in to reflect ~normalised' time it should take, for the ABR buffer /Bit reservoir (?) to get within an insignificant range of  'design normal runtime level' - something like 50% perhaps depending on the codecs internal thresholds.

The buffer size may correspond to 2.3 seconds of playtime, but thats stated as though the buffer is to be used to store all the data. The buffer increases and decreases by fraction of the runtime allocated bitrate (no?) The buffer allows the bitstream to deviate from the average allocatable bitrate. A buffer below its design level will encourage extra bits to be allocated until it has reached its 'normal design' level. eg starting with an empty buffer ,an extra 10 kbs could be allocated for 15s seconds until the 300 kbs buffer is half full. More likely encoding logic will press harder to fill a very empty buffer than a 1/4 full buffer, but that pressure will itself be  opposed by psychoacoustic discernments showing that extra bit allocation brings diminishing returns in quality...

I estimate run in time as being an expression of these things:

. the buffer/reservoir size,
. the 'design ideal' buffer level,
. the ideal psychoacoustic bit response to the material
. minus, the target Average BitRate

....if you see what i mean - somethings to think about...


'best regards and great respect to everyone who participated in the test, which had it not been so thorough wouldnt even have noticed this issue.
no conscience > no custom