Log in

View Full Version : What is Buffer man@gement?


Afrinux
14th January 2006, 18:49
First, I apologize for posting this in the Gener@l Discussion.
I keep having this following error when I tried to verify my DVD disc.
Buffer m@nagement is 'rong
occup@ncy = 239227 : STC = 234293642 : stream_id = 0xe0
And also
no fr@me gap shall exist in countinual VOBs
I understand that the problem is related to the video stream bec@use stream_id = 0xe0. But I dont have a clue about buffer man@gement, occup@ncy and fr@me gap. Some1 plz help
Thanks in adv@nce.

arch_angel16
14th January 2006, 19:01
fluffer management is taking care of your fluffers and keeping them happy so the stars of the show are always hard & wet...oooh you mean buffer management. *shrugs*

Afrinux
16th January 2006, 05:36
fluffer management is taking care of your fluffers and keeping them happy so the stars of the show are always hard & wet...oooh you mean buffer management. *shrugs*
wasnt a helpful @nswer, but th@nks for taking ur time to re@d it.
Even a slight idea would be helpful, please some1 help!!

unmei
16th January 2006, 07:43
well, the video DVD specifications give an upper bound on how much/few data can represent a certain time period - ie to make sure a limited capability decoder is not suddenly confronted with a huge amount of data it has to process in the -let's say- next 20 milliseconds. You disc seems to violate that somehow - maybe your mpeg video was not encoded with "DVD" presets in the encoder, or you have cut/appended it in some unlucky way that screws up the timestamps or the average bitrate at the cut point.

ps: it would help to read your post if you wouldn't replace some of the A's with @'s ...

Koepi
16th January 2006, 07:43
0|-|, 31337!

B|_|ff325 4R3 3\/i1. I|\| Y0|_|R C@53 I7 |\/|3@|\|5 7|-|@7 7|-|3 \/id30 B|_|ff325 @R3 r|_||\||\|i|\|g 0\/3r 0r |_||\|d3r.

Afrinux
16th January 2006, 08:20
well, the video DVD specifications give an upper bound on how much/few data can represent a certain time period - ie to make sure a limited capability decoder is not suddenly confronted with a huge amount of data it has to process in the -let's say- next 20 milliseconds. You disc seems to violate that somehow - maybe your mpeg video was not encoded with "DVD" presets in the encoder, or you have cut/appended it in some unlucky way that screws up the timestamps or the average bitrate at the cut point.

ps: it would help to read your post if you wouldn't replace some of the A's with @'s ...
I am sorry for the @'s. I wont be using them in purpose, again.
From your answer, I think you have understood my prolem. Here how I made the dvd. The original VOBs had sequence end code in each of them. So I replaced the sequence end code {0x00 0x00 0x01 0xB7} by {0x00 0x00 0x00 0x00}, to set a seamless playback.
If I have changed the sequence end code, what other parameters do I have to change?
Thanks for your help.
Afrinux

mpucoder
16th January 2006, 08:52
There is a lot more to making a seamless joint than just removing the sequence end header. SCR and ptm/pts values have to change to reflect the STC discontinuity - this is a running reset not a restart of the clock. Some audio gets shifted into the next vob, but without any audio frames spanning the joint. Without the proper adjustments you will either overflow or underflow many buffers.
Use a authoring program like MuxMan 0.17 or Scenarist to make examples of seamless and non-seamless to study.
The specific complaint is an overflow of the P-STD video buffer, which is 232K (237568 bytes) - the data was delivered (SCR value) too soon.
You have also created a frame gap, which is a period of time beyond the last frame of one vobu and the first of the next without video. Possible causes are vobu_se_ptm left non-zero (it must be zero if there is no sequence_end) and improper pts/ptm values.

edit: corrected MuxMan version number

Afrinux
16th January 2006, 10:25
Hi mpucoder! That was a very helpful tip. Thank you. Like you have already mentionned, I have to learn the difference between two vobs joint seamlessly and non-seamlessly.
SCR and ptm/pts values have to change to reflect the STC discontinuity
Suppose that the movie has two vobs linked seamlessly, VOB#1 and VOB#2; and LastSCR1 is the SCR of the last pack of VOB#1 and FRSTSCR2 is the SCR of the first pack of VOB#2. Is it illegal having FRSTSCR2 smaller than LastSCR1 (FRSTSCR2 < LastSCR1 )?
Possible causes are vobu_se_ptm left non-zero (it must be zero if there is no sequence_end) and improper pts/ptm values. I had set vobu_se_ptm to zero. How clearing the sequence end header affects the values of pts/ptm? What are their relations?
Thanks for helping,
Afrinu

DeathTheSheep
17th January 2006, 23:12
0|-|, 31337!

B|_|ff325 4R3 3\/i1. I|\| Y0|_|R C@53 I7 |\/|3@|\|5 7|-|@7 7|-|3 \/id30 B|_|ff325 @R3 r|_||\||\|i|\|g 0\/3r 0r |_||\|d3r.

or

"Oh, sisst!
Buffers are evil. In your case it means that the video buffers are running over or under."
That's what my sister told me you said, Koepi; I had no idea. That is an unbelievably clever style of... what, can it be called "writing?" Did you learn this elsewhere or make it up? Cuz I've never seen writing...or should I say..."numbering"... or "coding" :D like that before...

PS: Hope you don't mind if I steal your idea :D

foxyshadis
17th January 2006, 23:47
"oh, eleet!" but otherwise yes. =D

For a quick crash course, you can check out:
http://www.albinoblacksheep.com/text/leet.php

For advanced course studies you'll have to dig into usenet, counterstrike, and megatokyo.

ph33r m4|-| b33R $k1||z!!!1

Afrinux
18th January 2006, 02:50
0|-|, 31337!

B|_|ff325 4R3 3\/i1. I|\| Y0|_|R C@53 I7 |\/|3@|\|5 7|-|@7 7|-|3 \/id30 B|_|ff325 @R3 r|_||\||\|i|\|g 0\/3r 0r |_||\|d3r.
Oh, this really had a meaning !! :confused:
I thought he was making fun of me, which I thought was not suitable for a DOOM9's team member in a DOOM9's forum.
DeathTheSheep, thanks for the translation.

Koepi
18th January 2006, 07:36
That's what my sister told me you said, Koepi; I had no idea. That is an unbelievably clever style of... what, can it be called "writing?" Did you learn this elsewhere or make it up? Cuz I've never seen writing...or should I say..."numbering"... or "coding" :D like that before...

PS: Hope you don't mind if I steal your idea :D

That is not at all my idea! Some years back i wrote a tiny program which translated usual writing into 31337 (eleet). This is "cool script kiddy talk" -- which I don't like at all...

Nice, the thread is still available: http://forum.doom9.org/showthread.php?t=31500&highlight=eleet

I don't have the code for the program anymore, but it'll produce somewhat similar results. Just if anyone really wants to know :)

@Afrinux:
Well, it was not exactly making fun of you. It was a fast reaction on those weird a->@ substitutions of yours. If you want to be taken serious you might wanna write "classic style" :)

Cheers
Koepi

Afrinux
18th January 2006, 11:41
@Afrinux:
Well, it was not exactly making fun of you. It was a fast reaction on those weird a->@ substitutions of yours. If you want to be taken serious you might wanna write "classic style" :)

Cheers
Koepi
Ok, I see. It was an old bad habit of mine, replacing 'a' by '@', 'i' by '!', 'u' by 'v' and 'g' by '9'. But since I got some warnings, I had given it up. Sorry!

Anyway, after days of trying, I have realized that , what I wanted to do is almost impossible. Easiest way to do it is probably re-encoding.
mpucoder and unmei have given me very good tips but I cant figure out how I can resolve it.
Thank you, mpucode, unmei and everyone.
Afrinux