P-STD buffer underflow: how to calculate correct bitrate?

[fvisagie]

Hi All,

This overflow problem manifested in MuxMan.

From other posts containing text like

P-STD buffer underflow by 19582 bytes at 49132892, sector 234862

it's clear that the combined bitrate at that point was illegal.

Firstly, how do I relate those values to a point in time in the video, to get some idea of what kind of material is causing the problem?

Secondly, how do I calculate a safe bitrate?

Is it possible to use the above "by ... bytes" value to calculate by how much the current bitrate needs to be reduced?

And/or, can the safe bitrate be calculated from the specifications? https://www.videohelp.com/dvd says (for PAL video):

Total bitrate including video, audio and subs can be max 10.08 Mbps (10080 kbps)

I now what my audio bitrate is, I know the current video bitrate, but how does one determine a subtitle stream's bitrate? This particular DVD title has 3 subtitle streams.

<edit>
Sorry, let me just explain why I need to calculate a suitable bitrate. Obviously I want to use the maximum possible, but I don't want to keep retrying until I get it right - this video takes about 8 hours to encode on my computer! If I could locate the offending footage by the values given in this underflow message I could maybe make a short test clip for experimenting. Otherwise I must be able to calculate the correct bitrate value.
</edit>

Thanks in advance,
Francois

[borax]

Not that easy...
What kind of subtitle format are we talking about? If it is SUP, you can calculate an average bitrate just with dividing the size (in bit) by the length (in seconds). But there can be parts with a much higher bitrate as the average...

Is it possible to use the above "by ... bytes" value to calculate by how much the current bitrate needs to be reduced?

In theory yes, but I don't know how to calculate it either. The "by ... bytes" value is referring to the actual video buffer, and therefore not simply convertible to something like bps.

Firstly, how do I relate those values to a point in time in the video, to get some idea of what kind of material is causing the problem?

I would use the max. number of possible chapters (99) spread over the video and check in which chapter the overflow arises...

[fvisagie]

Hello borax,

Regarding locating the offending point in the video:

Towards the end of the log file MuxMan prints (this is not from the same footage as in the original posting):

Bitrate - avg: 6959069, min: 655360 (lba 30627), max: 11141120 (lba 23884).
Shortest GOP has 2 fields, longest GOP has 30 fields.
Fields: 5950, VOBU: 208, Sectors: 50545.

Assuming that sectors progress linearly, from the Sectors value I calculated average sectors/s over the video and then converted the sector values in the error messages to seconds. These time values were accurate enough when compared to encoder results (see below) as well as the results of Bitrate Viewer.

Judging by their values, the "lba" values probably also refer to sectors.

Regarding calculating a safe birate:

I am still unable to use the values MuxMan printed to calculate a safe bitrate, but an additional dimension to the problem just emerged. MEncoder sometimes violates its maximum bitrate setting, probably causing this MuxMan behaviour.

When preparing the encode that leads to this muxer failure, MEncoder reports e.g.
BUFFER UNDEFLOW at stream 0, raising muxrate to 11088 kb/s

That whilst vrc_maxrate=9800 on the command line.

I've asked the MEncoder-users mailing list for advice and will see what happens.

Hopefully if I can disappear that problem it will disappear MuxMan's P-STD buffer underflow problem .

Failing a fix via MEncoder, what excellent, rock-solid and free alternative to MEncoder would you recommend?

Kind regards,
Francois

[borax]

Hank's encoder: HCenc

[fvisagie]

Because I'd invested so much effort timing subtitles etc. I wasn't keen to edit out the problem footage and re-encode and re-time subtitles. Similarly I wasn't keen to get to grips with a new encoder and run lots of test encodes to get to its best settings for particular footage etc.

So luckily I found an older encode which isn't quite ultimate quality but which doesn't cause the problem .

I'll keep HcEnc (and ffmpeg) in my back pocket in case .

Email me your postal address - my first DVD is now completed, and beautiful!