View Full Version : 3D CMF master issue - Transport stream recording rate exceed
localhero666
16th October 2013, 09:56
Hey there!
I need some help regarding 3D CMF masters. I had lots of DVD and BD authoring works so far, altough this is my first 3D project ever.
Cutting this short, the unencrypted version of my project runs flawlessly on a PS3. But I was only able to make a successful muxing, if I was editing the TSRecordingRate of the dependent view's stream to 1. All other numbers here caused a buffer underflow error and a unsuccessful mux. So after I've managed this, I made an encrypted CMF master also, and sent it to replication.
After couple of weeks, I got back some error reports from the mastering facility - it about the dependent view of the feature:
'Transport stream recording rate exceeded'
and also, some comments, what it should mean from their side:
'It is unknown if this condition will cause playability problems. However, it is a violation of the Blu-ray specification an it is, therefore, condsidered an ERROR'
What do you think of this one?
Some data of my project:
Base target: 24,000,000bps
Dep target: 13,999,872bps
2 DTS HD MA streams
1 subtitle stream
1 pop-up menu
1 top menu
3 extra features
BD25
Anyone had experience in this? I have no clue what to do at this point. Any help is appreciated!
perquin
16th October 2013, 11:58
Hi,
Maybe you have a peak, what are your max bit rate for each video and DTS ?
regards,
localhero666
16th October 2013, 12:59
Hi,
Maybe you have a peak, what are your max bit rate for each video and DTS ?
regards,
Thank you for your fast respond!
Sorry, I was not very adequate with the bit rate before:
Base target: 19 Mbps / max: 24 Mbps
Dep. target: 12 Mbps / max: 14 Mbps
DTS HD MA #1: PeakBitrate=3402.00
DTS HD MA #2: PeakBitrate=3495.00
I was trying to keep the bit rates as low as I could, because the goal was to fit on a BD25.
perquin
16th October 2013, 13:36
you are under the 64/48 Mbps of mux.
Or you can have a peak that is not reported by the encoder or the muxer.
HWK
16th October 2013, 19:23
Or you can have a peak that is not reported by the encoder or the muxer.
This might be issue to look at. I do several MVC encode and in some cases though it says max is 24mbps but it has gone up to 44 mbps for base.
I would see if there is way to check bitrate of elementary stream.
@ localhero666
Is you encoder capable of doing in two pass, also what kind of sequence is it.
Finally is there sudden transition change from plain black background to very bright picture or lot of action. I ask because I have two films which I observed this and I ran into same problem as you are describing.
localhero666
17th October 2013, 20:33
This might be issue to look at. I do several MVC encode and in some cases though it says max is 24mbps but it has gone up to 44 mbps for base.
I would see if there is way to check bitrate of elementary stream.
@ localhero666
Is you encoder capable of doing in two pass, also what kind of sequence is it.
Finally is there sudden transition change from plain black background to very bright picture or lot of action. I ask because I have two films which I observed this and I ran into same problem as you are describing.
Thank you for your reply!
It was encoded in 2 pass VBR, and the feature is a cartoon, so indeed there's a lots of action, often using fade in/out effects between the scenes.
Here's the error message I've got from the mastering side - they are using 'EclipseSuite':
http://imageshack.us/f/716/pijg.jpg/
mp3dom
17th October 2013, 21:14
Which software muxed the project? Blu-Print and Scenarist (they use the same engine) are generally quite restrictive. Also, do you have some stats from the encoder? Do you have the ability to look at the bitrate curve and select points where you can do (if needed) segment encoding at a lower bitrate?
HWK
17th October 2013, 22:35
Since you are dealing with cartoon, I am assuming there is little or no grain present in source.
I would say try different setting, I used "MADAGASCAR_3_3D" template which I am posting here to see if it helps in your case by setting bitrate in this range.
Base
16 mbps and max 24 mbps.
Dependent View only need half so I will try
8 mbps and max 24 mbps.
Encoder will increase rate when needed. Let me know if it works for you.
Also there is tool created neuron2 which allow you to check max bitrate and buffer size for avc elementary stream. Though it will cost 15 dollars.
localhero666
29th October 2013, 13:52
Thank you all for your feedbacks!
In the mean time I was checking my archives, previous encodes, and also did a new one - not to waste your time unnecessarily.
@mp3dom
I'm working with Scenarist, and the encode was made with Cinevision, so - theoretically, because I've never used this method so far - I can do segment re-encoding. After my experience I guessed, if an asset was accepted by Scenarist, I mean importing and finally muxing was successful, that asset is after the spec's, at all. But it looks like Scenarist is never out of teaching new lessons, however I thought there'd be no surprises anymore. I was wrong.
Indeed, you all are right, after checking the bitrate curves, there are some high peaks, exceeding my max bitrate.
Here's a screen shot:
http://imageshack.us/photo/my-images/690/ypo1.jpg/
@HWK
I did a new encode after your rates/template. At this time again, there are some too high peaks.
Screen shot of this one:
http://imageshack.us/photo/my-images/197/uqw2.jpg/
Also, in this case the output is around 3GB less, then the original encode - which was ideal for me, because my disc was on 97%.
So I guess, I'd need some segment re-encodes to see, if this peaks dissappear.
What about that TSRecordingRate? Still, how is that possible, zeroing this rate and I'm able to do a working disc on a PS3? Still don't get this...
localhero666
4th November 2013, 11:43
This project is gonna kill me...
Segment re-encode was done, all peaks were pushed down.
MUI generator then gives this error message for my d.mvc file:
ERROR: Invalid num_level_values_signalled_minus1_value = 19
Again a never seen before error message :(
Any ideas?
Emulgator
12th November 2013, 09:58
http://imageshack.us/photo/my-images/197/uqw2.jpg/
This screenshot suggests that you specified max bitrates of 24Mbps base view + 24mbps dependent view,
The encoder excesses these 24Mbps joyfully (28Mbps ?)
thus allowing 48Mbps totalled for video alone, but in fact maybe reaching peaks of 56 Mps.
Now the muxing of two DTS-MA HD streams (3.5Mbps each) brings video and audio up to maybe over 63 Mbps.
Now Subs, M2TS container overhead...
I would suggest to cap the max bitrate for base view down to 22 Mbps, dependent view down to 18 Mbps.
Maybe it is still ok for a cartoon, if there is not that much grain involved.
localhero666
12th November 2013, 17:39
http://imageshack.us/photo/my-images/197/uqw2.jpg/
This screenshot suggests that you specified max bitrates of 24Mbps base view + 24mbps dependent view,
The encoder excesses these 24Mbps joyfully (28Mbps ?)
thus allowing 48Mbps totalled for video alone, but in fact maybe reaching peaks of 56 Mps.
Now the muxing of two DTS-MA HD streams (3.5Mbps each) brings video and audio up to maybe over 63 Mbps.
Now Subs, M2TS container overhead...
I would suggest to cap the max bitrate for base view down to 22 Mbps, dependent view down to 18 Mbps.
Maybe it is still ok for a cartoon, if there is not that much grain involved.
Thx for your suggestion, I thought this thread was down already!
I gave it a try following HWK's templates with the max of 24 Mbps for both views, but I'll try out yours as well.
After bothering with segment re-encoding to get this damn thing done, I'm getting never seen error messages all the time. Last time it was Scenarist, telling me my base and dependent MVC's are having different lenghts, just right after I did the segment re-encodes, and finalised the MVC's with Cinevision. On the other hand, if this would be correct, then I couldn't process the video with Cinevision in the first place...
Emulgator
12th November 2013, 18:43
Given that the segment reencode feature might be buggy I would try to reencode the whole thing in one go.
localhero666
13th November 2013, 12:29
Given that the segment reencode feature might be buggy I would try to reencode the whole thing in one go.
It's done and there're some peaks again. I guess I can't avoid them without segment re-encoding...
https://www.dropbox.com/sh/o0uwuokjy939x0k/JDw2Qw_jNT#lh:null-CNVSN_max22mbps_screen.jpg
Emulgator
16th November 2013, 17:48
If this encode still follows VBV model, it may be fine for muxing.
Donald Graft's VBV Checker may be handy there.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.