I got the new Opus Arte BD and was glancing at the bit-rate info and saw the video AVC spiked at 40.00Mbps peak now and again. Together with two PCM tracks (2.0 at 2.30Mbps and 5.1 at 6.91Mbps) the maximum multiplex rate of 48Mbps for BDAV MPEG-2 transport stream is exceeded. So it is out of spec. I don't know how accurate the Pioneer 51FD bit-rate meter is but it surely played fine.:)

I vaguely remember someone saying occasional spikes are allowed but can't find the thread. So does anyone know how much excess over 48Mbps is allowed or tolerated? I suppose it depends on the chip inside. If some players are less tolerant then would it be better to cap the video bitrate to not to exceed the multiplex rate of 48Mbps?

As for the production and PA/AQ (there is a problem with the 5.1 mix) if there's interest I'll say more about them.

It's fine.. Some discs spike way over the limit. This is from Earth: The Biography.

http://img120.imageshack.us/img120/4204/img0354fq1.jpg (http://img120.imageshack.us/my.php?image=img0354fq1.jpg)

I don't think it is possible to exceed 48 Mbps with Blu-ray.

If you fill every possible 'time slot' in the m2ts stream with a valid packet, you are running at 48Mbps.

To exceed that, you would have to be sending packets at abnormal time stamp intervals.

That said, there are buffers in the system, so while the flow can't exceed 48 Mbps, the packets could potentially be consumed at faster than 48 Mbps, which would drain the buffer faster than it could possibly fill.

Obviously that can only be maintained for a short period of time...

If the Wiki chart is correct BD can read 54MBps of data. I always thought that was for M2TS overhead but maybe you can out actual data in there.

I don't think it is possible to exceed 48 Mbps with Blu-ray.

If you fill every possible 'time slot' in the m2ts stream with a valid packet, you are running at 48Mbps.

To exceed that, you would have to be sending packets at abnormal time stamp intervals.

That said, there are buffers in the system, so while the flow can't exceed 48 Mbps, the packets could potentially be consumed at faster than 48 Mbps, which would drain the buffer faster than it could possibly fill.

Obviously that can only be maintained for a short period of time...

Bitrate isn't constant. So so codecs fold excessive (clipped bitrate) bits back and fill in previously unused bandwidth in lower bitrate scenes. On playback these "clipped" bits are read and stored in the buffer until the scene that uses them comes along.Two pass encodes can do this. That's how higher than spec peak bitrates can be accomplished.

It's fine.. Some discs spike way over the limit. This is from Earth: The Biography.

http://img120.imageshack.us/img120/4204/img0354fq1.jpg (http://img120.imageshack.us/my.php?image=img0354fq1.jpg)

DTS-HD HR? What is that? I thought that was the 1.5Mbit I got on my old receiver through optical -- which I thought was the max bitrate you could get through optical. Yours says 2Mbit? And it says HD HR, mine just said DTS-MA 1.5Mbit from what I remember.

I'm confused. :-P

DTS-HD HR? What is that? I thought that was the 1.5Mbit I got on my old receiver through optical -- which I thought was the max bitrate you could get through optical. Yours says 2Mbit? And it says HD HR, mine just said DTS-MA 1.5Mbit from what I remember.

I'm confused. :-P

It's the equivalent of DD+ really, DTS-HD MA is a notch above, like TrueHD.

Players that don't support DTS-HD HR will pull the core DTS track out, which is 1.5mbps and ignore the HR extension. Same with MA (core and extension).

Bitrate isn't constant. So so codecs fold excessive (clipped bitrate) bits back and fill in previously unused bandwidth in lower bitrate scenes. On playback these "clipped" bits are read and stored in the buffer until the scene that uses them comes along.Two pass encodes can do this. That's how higher than spec peak bitrates can be accomplished.

My understanding of the buffers is that they are FIFO - first in first out.

So what you say can be true over a very small period of time.

I don't believe that there is the capacity to 'store' high bitrate stuff over a long period to be used later.

But I could be wrong... if you have technical documentation on this I would love to see it.

My understanding of the buffers is that they are FIFO - first in first out.

So what you say can be true over a very small period of time.

I don't believe that there is the capacity to 'store' high bitrate stuff over a long period to be used later.

But I could be wrong... if you have technical documentation on this I would love to see it.

Amir explained it a while ago. Its like a bucket of water were you fill water in from the top, and drain it from the bottom. While BD is limited on 48 at filling (video+audio) but the draining can be something else.

It also makes it harder to judge how much "filling" you need for a certain scene.

I got the new Opus Arte BD and was glancing at the bit-rate info and saw the video AVC spiked at 40.00Mbps peak now and again. Together with two PCM tracks (2.0 at 2.30Mbps and 5.1 at 6.91Mbps) the maximum multiplex rate of 48Mbps for BDAV MPEG-2 transport stream is exceeded. So it is out of spec. I don't know how accurate the Pioneer 51FD bit-rate meter is but it surely played fine.:)


As for the production and PA/AQ (there is a problem with the 5.1 mix) if there's interest I'll say more about them.

Your player meter is not accurate (in the way how you think about it) and doesn't show actual transport stream rate. There are spikes in video stream reaching even 80Mbit and it's fully complaint with BD spec.
There is something called buffer fill and the whole playback proccess is not as simple as you think. There is nothing wrong with seeing 60Mbit peaks on your player and you will see them time to time.

Did you have playback issues?? I can bet you not :)

Also I can tell you that actual maximum rate is 36Mbit, which gives about 45Mbit with audio for the safety. None of the existing authoring software would let you mux stream if there would be "real" spikes above 48Mbit. There is also Sony's verification tool, which checks it again.


Andrew

My understanding of the buffers is that they are FIFO - first in first out.

So what you say can be true over a very small period of time.

I don't believe that there is the capacity to 'store' high bitrate stuff over a long period to be used later.

But I could be wrong... if you have technical documentation on this I would love to see it.

Of course I can't find it now. I remember reading it and thinking, "Wow... ingenious!"

There are spikes in video stream reaching even 80Mbit and it's fully complaint with BD spec.

...

Also I can tell you that actual maximum rate is 36Mbit, which gives about 45Mbit with audio for the safety.

In this case, video transport stream was limited to 36Mbps during encoding but actual playback rate reached 40Mbps: did you know at the time of encoding 40Mbps would be reached? Can this be controlled? In general, how much beyond 80Mbps is possible? How far ahead can the excess bits be transported?


Did you have playback issues?? I can bet you not :)

I won't take your bet on something I already said at the outset.;)

In this case, video transport stream was limited to 36Mbps during encoding but actual playback rate reached 40Mbps: did you know at the time of encoding 40Mbps would be reached? Can this be controlled? In general, how much beyond 80Mbps is possible? How far ahead can the excess bits be transported?

I won't take your bet on something I already said at the outset.;)

During playback data is read form the disc and constantly fills the buffer- the speed of buffer filling it's not the same as transport stream rate- can be higher (should be).Your player is showing how fast the data is read from the disc and stored in the buffer. I'm not 100% sure about it- but maybe someone will correct me.


Andrew

During playback data is read form the disc and constantly fills the buffer- the speed of buffer filling it's not the same as transport stream rate- can be higher (should be).Your player is showing how fast the data is read from the disc and stored in the buffer. I'm not 100% sure about it- but maybe someone will correct me.


Andrew

Actually, I think the player is indicating how fast data is being fed to the decoder (and hence fetched from the buffer). That's why the indicated bitrate peak exceeded the physical transport peak bitrate spec.

Unless I misunderstood what you are saying.

Actually, I think the player is indicating how fast data is being fed to the decoder (and hence fetched from the buffer). That's why the indicated bitrate peak exceeded the physical transport peak bitrate spec.

Unless I misunderstood what you are saying.

Hmmm...maybe- or how fast it's read from the disc into the buffer. It's not the same, but I don't knwo which is correct:)
There are many buffers (not only video one) in BD playback model.


Andrew

Actually, I think the player is indicating how fast data is being fed to the decoder (and hence fetched from the buffer). That's why the indicated bitrate peak exceeded the physical transport peak bitrate spec.
Like Andrew_HD just said, there is more than one way to bake that cake that could be considered "correct".

In BDInfo, peak measurements are taken over sliding time windows of 1-, 5- and 10-seconds using the video frame timestamps as the markers and making a measurement at each video frame. So, for example, a 1-sec peak bitrate is derived by counting the number of bytes in all the encoded frames that fall within the timestamp of the first frame in the window plus one second, and then dividing this byte count by one second.

Right off the bat with this technique, you can see a few recurring circumstances that can lead to "spec-busting" measurements. A given measurement window can sometimes have more frames in it than another due to the non-integral nature of certain frame rates. Also, depending on whether or not the calculation routine attempts to account for out-of-order video frames, you might get some extra frames in a particular measurement. Finally, each measurement will be pulling in different parts of the GOP and frame types depending where you are in the frame sequence, so some measurements will naturally be "fatter" than others.

Generally speaking, with time-window measurements there is going to be more variance (higher peaks and lower valleys) the smaller the time-window gets, so this can also lead to differences in reported peaks depending on how the calculations are made. Since the technique described above might be unnecessarily computationally intensive for a Blu-ray playback device, I can imagine a simpler approach which would involve polling the frame buffer size periodically and dividing this result by the difference between the highest and lowest frame timestamp currently in the buffer. In this case, the length of the time window used for measurement would vary which does not seem as consistent to me compared to keeping the time window fixed, but certainly is not "wrong".

An interesting insight would be to know if there is a recommended peak measurement technique defined in the Blu-ray spec itself. Without this, there is not much to indicate what a limit like X Mbps actually means without the reference points of "no more than Y bytes in Z seconds". At the very least, it is clear that Z != 1.

Hmm... I don't think the optical transport spec can ever be exceeded. So it's limited to 40, or 48 Mbps whichever it is (I'm too lazy to look it up ATM...), and that is a hard-limited spec. It's the lowest-common-denominator physical limitation of the transport (that is, all discs must be authored to playback even on first-generation 1X drives... just like DVD must).

However.. the buffer-to-decoder spec is not limited to that speed, hence thats what is likely being indicated on displayes where we see 50Mbps spikes.

Incidentally, that's also why encoders need to know about buffer size... so they can make decisions about how to allocate bits on "quieter" scenes so that excess bandwidth can be used to stuff the buffer for upcoming "busy" scenes that may benefit fomr a bitrate burst that exceeds the physical bandwidth of the optical transfer rate.

Incidentally, that's also why encoders need to know about buffer size... so they can make decisions about how to allocate bits on "quieter" scenes so that excess bandwidth can be used to stuff the buffer for upcoming "busy" scenes that may benefit fomr a bitrate burst that exceeds the physical bandwidth of the optical transfer rate.

This is what I said back in post #5 and Phloyd asked me for some technical documentation on it. I couldn't find it. Do you have an easy link? I'm curious about this.

Kilian, outside of all the technical issuues surrounding this post, I'm wondering how you got this Opus Arte Don Giovanni here in Canada so quickly. Naxos.ca the distributer, has a release date set for May 26. Did you import from The UK?

nc

This is what I said back in post #5 and Phloyd asked me for some technical documentation on it. I couldn't find it. Do you have an easy link? I'm curious about this.

Hey... Actually I don't have any one place that I've found that explains this handily. I've gleaned it from the Insider discussion here over the years, sites that have come and gone, etc...

If you google some of the pertinent keywords (vbv, maxbuffsize, vbv-maxrate, etc...) there seem to be some interesting discussions on doom9, somve stuff from encoder app vendor websites, etc... maybe those have what you are looking for?

This is what I said back in post #5 and Phloyd asked me for some technical documentation on it. I couldn't find it. Do you have an easy link? I'm curious about this.

My only point was that the bit bucket is only so big, so the 'storage' available may not last over a long period of time...

It would all depend on how much high bitrate video is needed and whether it is all grouped together or more evenly spread throughout the program.

Certainly the buffers allow for 'short term' peaks exceeding the 'spec', which clever bit allocation can take advantage of - it is just not an 'infinite resource'...

It would be interesting to know if there is a maximum amount of data that can be processed to create a frame (a decoder based limit), though that is probably dependent on the way the frame is made up also...

For example, I recall that someone made a VC-1 encode of Elephant Dreams (or similar open source content) that had a huge spike that would play through on BD players but not HD DVD players even though the average bitrate spec was not violated...

It is no doubt possible to kill a BD decoder if the bitrate got high enough...

Lastly, the two specs I recall are that 1x BD is 36 Mbps and that the Transport Stream is limited to 48 Mbps, which implies that all Blu-ray drives need to be able to run 33% over 1x...

We have certainly seen discs with a higher mux rate than 36 Mbps - occasionally even higher average video bitrate than 36....

Kilian, outside of all the technical issuues surrounding this post, I'm wondering how you got this Opus Arte Don Giovanni here in Canada so quickly. Naxos.ca the distributer, has a release date set for May 26. Did you import from The UK?

nc

You can order it directly from OA. Not sure about Canadian currency, but with the current US-UK exchange rate, and OA's reasonable shipping rates, it's not a bad deal at all. I just did it with their BD Giselle, and had the disk within a week for slightly more than what I would have paid Amazon, whenever they would have gotten the disk --- US$42 delivered at current exchange rates.

--Andre

My only point was that the bit bucket is only so big, so the 'storage' available may not last over a long period of time...

It would all depend on how much high bitrate video is needed and whether it is all grouped together or more evenly spread throughout the program.

Certainly the buffers allow for 'short term' peaks exceeding the 'spec', which clever bit allocation can take advantage of - it is just not an 'infinite resource'...

It would be interesting to know if there is a maximum amount of data that can be processed to create a frame (a decoder based limit), though that is probably dependent on the way the frame is made up also...

For example, I recall that someone made a VC-1 encode of Elephant Dreams (or similar open source content) that had a huge spike that would play through on BD players but not HD DVD players even though the average bitrate spec was not violated...

It is no doubt possible to kill a BD decoder if the bitrate got high enough...

Lastly, the two specs I recall are that 1x BD is 36 Mbps and that the Transport Stream is limited to 48 Mbps, which implies that all Blu-ray drives need to be able to run 33% over 1x...

We have certainly seen discs with a higher mux rate than 36 Mbps - occasionally even higher average video bitrate than 36....


BD 1x read disc speed is 54Mbs (not 36Mbs) and BD max muxing rate is 48Mbs. They left a room to make sure that playback will be smooth.

VC-1 encode of Elephant Dreams as far as I remeber didn't respect VBV buffer size, which is very important. If you don't stay with spec limitation hardware palyers may not playback video smoothly. VBV buffer size and its fillnes is the most important thing for smooth playback- it's related to max bitrate, but it's not the same thing.


Andrew

Kilian, outside of all the technical issuues surrounding this post, I'm wondering how you got this Opus Arte Don Giovanni here in Canada so quickly. Naxos.ca the distributer, has a release date set for May 26. Did you import from The UK?


Yes, £15.63 plus S/H from Amazon.co.uk. Very good price and tax free.:)



It is no doubt possible to kill a BD decoder if the bitrate got high enough...

Lastly, the two specs I recall are that 1x BD is 36 Mbps and that the Transport Stream is limited to 48 Mbps, which implies that all Blu-ray drives need to be able to run 33% over 1x...



From the BDA Spec papers, BD-ROM read speed x1 is 36Mbps. I see the 1.5x (54Mbps) quoted elsewhere but can't find it specifically mentioned in the papers. 1.5x would cover the 48Mbps max. multiplex rate.

The BDA papers also mention buffers in the diagrams and there are quite a few. The high spikes seem to me could be the rate from buffer to decoder or from decoder to output.

From the BDA Spec papers, BD-ROM read speed x1 is 36Mbps. I see the 1.5x (54Mbps) quoted elsewhere but can't find it specifically mentioned in the papers. 1.5x would cover the 48Mbps max. multiplex rate.

The BDA papers also mention buffers in the diagrams and there are quite a few. The high spikes seem to me could be the rate from buffer to decoder or from decoder to output.

Yes- it's again more complicated :)
I've checked it in the AV specfication book (for BD read only disc) and it says 54Mbit data read from the drive for BD read only disc, but it doesn't say 1x :)


Andrew