Sir Didymus
21st October 2004, 17:36
First of all sorry for the total lack of synthesis. Simply close this window when you are tired of reading... :)
You will lose nothing really relevant, believe me...
Ok. The reason for posting is to share some preliminar findings on the matter, or better, on subjects that may have some relationship with the matter, with people that could be interested on it.
I am asking Jdobbs not to bother with it just because nothing new is included, at least for the moment, on my side, on the subject.
Since the only material available to me which is by sure affected by the problem has been kindly provided by Fritzdis, I'd better stating clearly that the the rest of this post is biased by the fact that the origin of this material is synthetic, and that some tuning (using RB-OPT) has been applied in order to "simulate" the behaviour of DVD-RB on original titles.
I have a copy of "Paycheck", PAL, R2, which is one of the titles reported (by DvdManiac) as suffering from dropouts, but my release is Italian, so I can not say by sure it actually have drops or not. If DvdManiac or somebody else will find the way of making downloadable a cell (original and rebuilt) of some movie which is having BY SURE dropouts in it, I will be happy of doing the same simulation on this material...
I have also to say that the included pictures are showing systematic overflow conditions; in normal titles (including the release I have of "Paycheck") these conditions are still present, even though they are much less frequent...
The first figure (http://img96.exs.cx/img96/7972/Original.gif) is showing the STD buffer occupancy of the video stream contained in the original material. The graphics has been produced with Excel, and the data have been acquired using the Philips DVD-Video Verifier. The X axis is the time scale (in microseconds, so 45.000.000 means the first 45 seconds of the video stream...). The material has been produced using Scenarist, and the video stram is encoded at constant bitrate. See this thread for further information about the Fritzdis tests and the generation of the original:
http://forum.doom9.org/showthread.php?s=&threadid=82485&perpage=20&highlight=fritzdis%20test&pagenumber=1
The size of buffer is 237568 bytes. As it is possible to see, in no parts the real time simulation the buffer underflows or overflows.
The second picture (http://img96.exs.cx/img96/8012/DVD-RB065Reduct085.gif) has been obtained using DVD-RB 065, all standard options, three click mode, using RB-OPT for applying the 85% of reduction to the size of the original (which is already smaller than a DVD5). Let's call this material "DVD-RB-85%". As it could be seen, since the encoding has been carried out with a variable bitrate, when the original video contains black parts [0...5s.], [30...35s.], [40...50s.] the buffer occupancy is very low, but in any case no underflow conditions are present. Overflows are present in all the rest of the video, which is basically composed by different framed patterns of white noise...
The third picture (http://img96.exs.cx/img96/3131/DVD-RB065MaxBR5000.gif) is showing the result of using DVD-RB 065, all standard options, three click mode, using RB-OPT for encoding the cell with an average bitrate of 4200 Kbit/s and a maximum bitrate of only 5000 Kbit/s. The reason for doing the test is to show that a low bitrate, in itself, is not guaranteeing to solve the problem (I mean to solve the problem of the STD buffer overflows). It is possible to see that the situation is improved a lot (no more overflows exceeding 300.000 bytes), but are still present sistematic conditions of overflows exceeding 250.000 bytes.
The fourth picture (http://img96.exs.cx/img96/6087/IfoEdit.gif) is related to a test based on extracting the m2v video file and the ac2 audio from "DVD-RB-85%" and using Ifoedit fo re-authoring a new title. It's possible to see that some "special" care should be present into the code of Ifoedit for preventing underflows and overflows. Despite of this, frequent overflow situations are present, a little bit over 250.000 bytes...
The fifth picture (http://img91.exs.cx/img91/9996/Mplex.gif) is obtained using mplex for remuxing the m2v and the ac3 streams. The result is very similar to the one of Ifoedit, even though Ifoedit is a little bit better, since the overflow speaks are less deep...
The sixt picture (http://img96.exs.cx/img96/1597/DVDLab13.gif) is obtained using DVD-Lab 1.3 for re-authoring the m2v and the ac3 streams. Here the situation is "quite" good: just four overflow have been detected...
The seventh picture (http://img27.exs.cx/img27/1084/DVDLabProB16.gif) has been produced with DVD-Lab Pro (beta 16 release). Finally the authored stream is fully compliant. No overflows, no underflows. Only drawback is that the average usage of the STD buffer is below 150.000. Nothing to worry about, but keeping this value higher, helps in preventing underflows...
The eight picture (http://img96.exs.cx/img96/911/Scenarist30.gif) has been produced using Scenarist 3.0 for re-authoring the video and audio assets. Other than being fully compliant, the usage of the STD buffer is very very good...
Ok. That's all. Hope not being censored due to the very long post...
And sorry if you feel exausted after reading all this stuff...
Maybe you may understand how I feel after doing so much testings...
:scared:
Cheers,
SD
You will lose nothing really relevant, believe me...
Ok. The reason for posting is to share some preliminar findings on the matter, or better, on subjects that may have some relationship with the matter, with people that could be interested on it.
I am asking Jdobbs not to bother with it just because nothing new is included, at least for the moment, on my side, on the subject.
Since the only material available to me which is by sure affected by the problem has been kindly provided by Fritzdis, I'd better stating clearly that the the rest of this post is biased by the fact that the origin of this material is synthetic, and that some tuning (using RB-OPT) has been applied in order to "simulate" the behaviour of DVD-RB on original titles.
I have a copy of "Paycheck", PAL, R2, which is one of the titles reported (by DvdManiac) as suffering from dropouts, but my release is Italian, so I can not say by sure it actually have drops or not. If DvdManiac or somebody else will find the way of making downloadable a cell (original and rebuilt) of some movie which is having BY SURE dropouts in it, I will be happy of doing the same simulation on this material...
I have also to say that the included pictures are showing systematic overflow conditions; in normal titles (including the release I have of "Paycheck") these conditions are still present, even though they are much less frequent...
The first figure (http://img96.exs.cx/img96/7972/Original.gif) is showing the STD buffer occupancy of the video stream contained in the original material. The graphics has been produced with Excel, and the data have been acquired using the Philips DVD-Video Verifier. The X axis is the time scale (in microseconds, so 45.000.000 means the first 45 seconds of the video stream...). The material has been produced using Scenarist, and the video stram is encoded at constant bitrate. See this thread for further information about the Fritzdis tests and the generation of the original:
http://forum.doom9.org/showthread.php?s=&threadid=82485&perpage=20&highlight=fritzdis%20test&pagenumber=1
The size of buffer is 237568 bytes. As it is possible to see, in no parts the real time simulation the buffer underflows or overflows.
The second picture (http://img96.exs.cx/img96/8012/DVD-RB065Reduct085.gif) has been obtained using DVD-RB 065, all standard options, three click mode, using RB-OPT for applying the 85% of reduction to the size of the original (which is already smaller than a DVD5). Let's call this material "DVD-RB-85%". As it could be seen, since the encoding has been carried out with a variable bitrate, when the original video contains black parts [0...5s.], [30...35s.], [40...50s.] the buffer occupancy is very low, but in any case no underflow conditions are present. Overflows are present in all the rest of the video, which is basically composed by different framed patterns of white noise...
The third picture (http://img96.exs.cx/img96/3131/DVD-RB065MaxBR5000.gif) is showing the result of using DVD-RB 065, all standard options, three click mode, using RB-OPT for encoding the cell with an average bitrate of 4200 Kbit/s and a maximum bitrate of only 5000 Kbit/s. The reason for doing the test is to show that a low bitrate, in itself, is not guaranteeing to solve the problem (I mean to solve the problem of the STD buffer overflows). It is possible to see that the situation is improved a lot (no more overflows exceeding 300.000 bytes), but are still present sistematic conditions of overflows exceeding 250.000 bytes.
The fourth picture (http://img96.exs.cx/img96/6087/IfoEdit.gif) is related to a test based on extracting the m2v video file and the ac2 audio from "DVD-RB-85%" and using Ifoedit fo re-authoring a new title. It's possible to see that some "special" care should be present into the code of Ifoedit for preventing underflows and overflows. Despite of this, frequent overflow situations are present, a little bit over 250.000 bytes...
The fifth picture (http://img91.exs.cx/img91/9996/Mplex.gif) is obtained using mplex for remuxing the m2v and the ac3 streams. The result is very similar to the one of Ifoedit, even though Ifoedit is a little bit better, since the overflow speaks are less deep...
The sixt picture (http://img96.exs.cx/img96/1597/DVDLab13.gif) is obtained using DVD-Lab 1.3 for re-authoring the m2v and the ac3 streams. Here the situation is "quite" good: just four overflow have been detected...
The seventh picture (http://img27.exs.cx/img27/1084/DVDLabProB16.gif) has been produced with DVD-Lab Pro (beta 16 release). Finally the authored stream is fully compliant. No overflows, no underflows. Only drawback is that the average usage of the STD buffer is below 150.000. Nothing to worry about, but keeping this value higher, helps in preventing underflows...
The eight picture (http://img96.exs.cx/img96/911/Scenarist30.gif) has been produced using Scenarist 3.0 for re-authoring the video and audio assets. Other than being fully compliant, the usage of the STD buffer is very very good...
Ok. That's all. Hope not being censored due to the very long post...
And sorry if you feel exausted after reading all this stuff...
Maybe you may understand how I feel after doing so much testings...
:scared:
Cheers,
SD