Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
14th December 2004, 22:56 | #61 | Link |
Guest
Posts: n/a
|
Hi folks,
Check this out - tsp coded a frames2smpte function for avisynth. frames2smpte Great work mpucoder! Tin2tin |
15th December 2004, 04:30 | #63 | Link |
Junior Slacker
Join Date: May 2004
Location: End-World
Posts: 296
|
I ran into a problem where MuxMan creates too many chapters and cells. In the one mux where this happened, there are several very short extra cells following the last specified chapter. Normally, I get the number of chapters that I specify in the text file + 1 at the end. Here is an IfoEdit screenshot showing the extra chapters and the chapter list used. The chapters occur basically where I want (every five minutes at 29.97fps) and none exceed the duration of the clip.
PgcEdit warns that the PGC playback time doesn't match the total of the cells times. I checked another disc authored with MuxMan and received the same warning, although the chapter count was consistent for the disc. I can provide the log (no errors) and the profile if necessary. The material is film pulldown. |
15th December 2004, 09:29 | #66 | Link |
Moderator
Join Date: Oct 2001
Posts: 3,530
|
Version 0.5 is available here
Fixes 2 bugs: 1) Mux failure due to video stream parsing error (Trahald discovered) 2) Chapter import was repeating the last line of the file causing many short chapters. Chapter import will also ignore frame numbers <= previous frame number or zero. This means that if the file begins with "0" the first chapter will not be a short chapter. If you actually want a minimum length chapter use the next higher frame number. |
15th December 2004, 23:28 | #68 | Link | |
Custom User Title
Join Date: Aug 2004
Location: Lat. 47.3350 ° | Long. 21.3850 °
Posts: 226
|
Quote:
BTW thanks MPUCoder, I'm pretty sure that it will be a great project.
__________________
Today begins the rest of your life... |
|
16th December 2004, 15:35 | #71 | Link | |
Really? Really really!
Join Date: Jan 2004
Location: Finland
Posts: 163
|
Quote:
And thank you for this nice program.
__________________
How many Microsoft employees does it take to screw in a light bulb? None, they declare darkness a new standard. |
|
16th December 2004, 20:33 | #72 | Link |
Registered User
Join Date: Mar 2004
Location: Italy
Posts: 953
|
compliancy checks...
Well, I spent some time for some little test (still preliminar, but at least I remuxed and analised a whole movie...). Well, the movie is Solaris, PAL, R2. It was re-encoded using CCE. Used assets have been one m2v video file (3.238.840 KB), one ac3 audio file (265.793 KB) and one Celltimes file with the following chapter points:
Code:
5275 9586 13008 16749 21680 24795 29106 33710 41575 46320 51060 58223 60160 71359 75085 77928 85287 89014 96966 102474 112435 114760 118336 122828 131414 141756 I noted some (many) glitches concerning the VOBU_SRI tables (they are tables used for handling the fwd and bwd playback...), but this is a minor problem..., so let me report better about this in a future moment... The real issue I see, is that I can not confirm what I reported on point 3 of my previous post: it seems it happened something in the remuxing that lead to the overflow of the STD buffer. This is surprising since it seems to me it is present into the Muxman algorithm a specific control to prevent this condition. In order to explain better what I noticed, it seems that on a specific part of the movie (in chapter 9) it happened an event that lead the payload of the PES_packet added to the STD buffer contents to cause an STD buffer contents larger than the allowed STD buffer size (which is 237.568 bytes). Normally (in all of the cells up to the ninth) the buffer figure is similar to this one: Where the x axis represents the SCR time, in units of 100 us., and the y axis is the buffer size, in bytes. In chapter 9 this situation happened: and this is the zoom of the anomalie: I really have no cue or suggestions on the matter; just wanted to report the event... Cheers, SD Edit: moment, moment; it seems to me (or better I am sure) cell 9 is across the border among VTS01_1.VOB and VTS01_2.VOB... Maybe this is useful to know... Last edited by Sir Didymus; 16th December 2004 at 20:57. |
16th December 2004, 20:57 | #73 | Link |
Moderator
Join Date: Oct 2001
Posts: 3,530
|
Thanks again for running these tests. The images look really nice, is this your own software?
And, yes, the P-STD buffer model is the controlling factor for video and audio streams. The actual value MuxMan uses is no more than 237557 bytes. This was determined by experiment to be the value used by Scenarist. It could be higher, and the actual payload, rather than the maximum payload, could be used for the model as well. But this led to differences with my comparison program. Which version of MuxMan did you test? This is important because the graph looks very much like what the last bug, fixed in 0.5, produced. First a dip, then going over. This was caused by a parsing error that would occasionally miss a picture header. To the model this looked like one large frame instead of two, and from then on the model lagged behind the real decoder. edit: I forgot to add that somewhere else in this thread (I think) I mentioned that the SRI calculations are not by time, but by VOBU offset. This will be changing as that does not work with menus or slide shows. Last edited by mpucoder; 16th December 2004 at 21:10. |
16th December 2004, 21:25 | #74 | Link |
Registered User
Join Date: Mar 2004
Location: Italy
Posts: 953
|
Hi,
Well, the images are produced by Excel... The tool(s) I am using are the Philips DVD-Video Verifier (it is a professional DVD compliancy check system) and StdBufLog. This last one is a little console application I wrote (it is public, so tomorrow I will post a link for downloading). Of course before posting I checked the issue with both... And they match... You determined the limit experimentally based on Scenarist ? hats off... Anyway (not for you, since it seems you know more than enough on the subject...) IEEE 138182 Annex C - VIDEO BUFFERING VERIFIER is the reference document on the topic... Well, in my previous post I was not joking saying that the Muxman authoring quality is at the same level of Scenarist... I posted some similar figures (in another thread of doom9), and really the ones of Muxman are adopting a very similar STD buffer usage (that is almost the perfection...). I used Muxman 0.5. I am sure about. Please consider the infringement happens exactely at the file split between VTS01_1.VOB and VTS01_2.VOB... Thanks for the explaination about the parsing error. I know the buffer handling should be very, very delicate, and it needs just a very little glitch to make things going wrong... Anyway, I say again, the title playback is ok... Edit: just added the url of the other thread... Last edited by Sir Didymus; 17th December 2004 at 14:33. |
17th December 2004, 00:04 | #75 | Link |
Moderator
Join Date: Oct 2001
Posts: 3,530
|
I'll look into whether the file split could be affecting the model (possibly using variables it should not).
Yes, I have that document, and that is the basis of the model. What I meant was the exact value used by Scenarist is not 58x4096 (232KB), but slightly less. I suspected you might be using Philips verifier - I have no license (yet). |
17th December 2004, 11:36 | #76 | Link | |
Registered User
Join Date: Mar 2004
Location: Italy
Posts: 953
|
Quote:
As anticipated yesterday here is the link for the StdBufLog application. Again this is not intended to give any type of contribution to the MuxMan author (he have by sure much stronger and proper resources on the matter) but to other kind beta testers, who may find nice to generate graphics like the one posted before... It is basically a very little (and limited) STD buffer profiler... I wrote it from scratch, since I was bored to wait for the 6 hours and more of average time necessary for producing some equivalent log using the Philips Verifier. http://webmail.libero.it/r.php?d=lib...NJIVc05kN18391 Please consider the link deadline is of five days (it is valid until 22.12.2004 10:56:41 AM CET). It is included a very little readme file, describing the usage and the limitations of this little program. Cheers, SD |
|
17th December 2004, 13:25 | #77 | Link | |
Really? Really really!
Join Date: Jan 2004
Location: Finland
Posts: 163
|
@mpucoder
Quote:
Regards, M7S
__________________
How many Microsoft employees does it take to screw in a light bulb? None, they declare darkness a new standard. Last edited by M7S; 17th December 2004 at 17:09. |
|
17th December 2004, 15:22 | #78 | Link |
Moderator
Join Date: Oct 2001
Posts: 3,530
|
@SD Thanks for the program, I'll check it out later today. And your English is better than my Italian.
@M7S A new comparison will be done soon, as the next release of MuxMan is even more compliant. The SRI mentioned by SD has been changed, and the test now compares those values as well (they were excluded). What program would you recommend as being most representative of mplex? DVDAuthor or another? Last edited by mpucoder; 17th December 2004 at 15:28. |
17th December 2004, 16:19 | #79 | Link |
Registered User
Join Date: Feb 2003
Location: USA
Posts: 56
|
The mplex build packaged with dvdauthorgui is from 2/19/2004, which is somewhat recent. Looking at the mplex cvs, there has been some changes, but I do not know if they are significant. Maybe someone with VC++ can download the cvs and build a fresh one?
http://cvs.sourceforge.net/viewcvs.p...eg_play/mplex/ looking forward to the tests. |
17th December 2004, 17:38 | #80 | Link |
Moderator
Join Date: Oct 2001
Posts: 3,530
|
@Sir Didymus - I know how difficult it is for people in PAL land to get samples and work with pulldown. The program looks interesting, but it is handling rff incorrectly. The effect of the flag on timing, specifically when to remove a frame's data, needs to be delayed by one frame. Data is sent to the decoder after presenting the current frame. At the time frame 0 presents frame 1 will start to decode. If the rff flag is set on frame 1 it does not affect when frame 2 decoding begins, that depends on the duration of frame 0. But your program shows that after removing data for a frame with rff set that the next frame is delayed. It should be the second frame following.
|
Thread Tools | Search this Thread |
Display Modes | |
|
|