Muxman and buffer underflow problem

[vlada]

Hi, a friend of mine was convertind an AVI to DVD-Video. According to my advice he used HC, BeLight and Muxman. But Muxman is reporting a problem while creating DVD. This is the error message:
http://www.ukazto.com/img/untitled-wcp1.jpg
and here is the important part of Muxman log:
18:55:19 Begin multiplex.
Maximum audio duration 454628 fields.
Starting scene Segment_1_scn1 at 00:00:00:00
SubPicture stream 0 backwards move in time.
P-STD buffer underflow by 6670 bytes at 798231692, sector 2220528.
P-STD buffer underflow by 36760 bytes at 798235292, sector 2221267.
P-STD buffer underflow by 3963 bytes at 798238892, sector 2221268.
P-STD buffer underflow by 5171 bytes at 798242492, sector 2221269.
P-STD buffer underflow by 14403 bytes at 798246092, sector 2221270.
P-STD buffer underflow by 3055 bytes at 798249692, sector 2221271.
P-STD buffer underflow by 5160 bytes at 798253292, sector 2221272.
P-STD buffer underflow by 9194 bytes at 798256892, sector 2221273.
P-STD buffer underflow by 4523 bytes at 798260492, sector 2221274.
P-STD buffer underflow by 5899 bytes at 798264092, sector 2221275.
P-STD buffer underflow by 9505 bytes at 798267692, sector 2221276.
P-STD buffer underflow by 4815 bytes at 798271292, sector 2221277.
P-STD buffer underflow by 7299 bytes at 798274892, sector 2221278.
P-STD buffer underflow by 14738 bytes at 798278492, sector 2221279.
P-STD buffer underflow by 7115 bytes at 798282092, sector 2221280.
P-STD buffer underflow by 7745 bytes at 798285692, sector 2221281.
SeqEnd at 10CAE35.
Bytes remaining in buffer = 146015.
19:26:37 End multiplex.
Bitrate - avg: 4146714, min: 382293 (lba 0), max: 33614506 (lba 2220035).
Shortest GOP has 2 fields, longest GOP has 30 fields.
Fields: 454634, VOBU: 15392, Sectors: 2301315.

I thought that the max. video bitrate would be to high, but according to BitrateViewer it was O.K. (not higher then 9000 kbps, as set in HC).

Btw. he tried 2 Muxman versions - 0.15R and 0.14G nad both report the same problem.

What could be the problem? Thank you.

[kumi]

Bitrate - avg: 4146714, min: 382293 (lba 0), max: 33614506 (lba 2220035).

That's a maximum bitrate of 33.6 Mbit/s. If I'm not mistaken, occasional spiking above 11.08 Mbit/s is OK... but 33.6 Mbit/s just sounds way too high. My guess is your friend encoded the stream without the VBV check enabled. There's a very handy "make DVD compliant" button in the HC gui that will take care of this (and other) critical settings.

Also, he still has to manually ensure that the maximum bitrate is within reason, taking into account the audio stream(s) it will be multiplexed with. If "a maximum of 9800 kb/s can be split amongst audio and video" (source (http://en.wikipedia.org/wiki/DVD-Video)), and his audio stream is 448 kb/s, his maximum video bitrate would be 9800 - 448 = 9352 kb/s.

However, a lot of smart Doom9 users recommend working with a lower maximum bitrate. Why? Because not all DVD players are perfect, and some will inevitably choke when you're stressing the limits.

[vlada]

I usually use 8500 or 9500 kbps for maximum bitrate.

The strange thing is, that BitRate Viewer reports the video to be O.K. - please check this image:

http://www.ukazto.com/img/untitled3-26r1.jpg

The peak bitrate reported by Muxman is extremely high. So I'm wondering which program should I believe.

[Sir Didymus]

You did not reply to the (very proper) question given by Kumi about the settings (DVD compliance) adopded in HC...

Also I would use a more recent release of MuxMan (the free version is now 0.15R)...

Finally - if possible - I would also make a test, encoding the source asset using a different encoder to see if it makes any difference...

Cheers,
SD

[vlada]

The results are the same if "Make DVD compliant" is used. AFAIK the "VBV check" is on by default and I doubt anyone would disable it without knowing what he's doing. Also as I already mentioned my friend tried the newest version (0.15R) first, after my suggestion he also tried this older one with the same result.

Of course it is possible to use another program, but I would like to know, what went wrong and why.

[bigotti5]

SubPicture stream 0 backwards move in time.
It is possible, with incorrect timing information, for MuxMan to attempt to mux all the subpictures at the same point. This can set off a chain reaction of underflows.

Try to mux without Subpictures...or another (correct timing) sup file