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.

 

Go Back   Doom9's Forum > (HD) DVD, Blu-ray & (S)VCD > (HD) DVD & Blu-ray authoring

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 14th December 2004, 22:56   #61  |  Link
Guest
Guest
 
Posts: n/a
Hi folks,
Check this out - tsp coded a frames2smpte function for avisynth.
frames2smpte
Great work mpucoder!
Tin2tin
 
Old 15th December 2004, 00:24   #62  |  Link
mpucoder
Moderator
 
Join Date: Oct 2001
Posts: 3,530
The problem reported by Trahald has finally been duplicated here. So be warned, there is a bug. And a fix as soon as I nail it down.
mpucoder is offline  
Old 15th December 2004, 04:30   #63  |  Link
mrslacker
Junior Slacker
 
mrslacker's Avatar
 
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.
mrslacker is offline  
Old 15th December 2004, 04:43   #64  |  Link
mpucoder
Moderator
 
Join Date: Oct 2001
Posts: 3,530
I'd like to see the log, for now.
mpucoder is offline  
Old 15th December 2004, 04:57   #65  |  Link
mrslacker
Junior Slacker
 
mrslacker's Avatar
 
Join Date: May 2004
Location: End-World
Posts: 296
mpucoder,
I put the log and profile up as well. See your PM. Thanks.
mrslacker is offline  
Old 15th December 2004, 09:29   #66  |  Link
mpucoder
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.
mpucoder is offline  
Old 15th December 2004, 22:21   #67  |  Link
jptheripper
Registered User
 
Join Date: Aug 2003
Posts: 913
i used 0.4 with complete success

ntsc m2v stream
dd5.1
dts
3 subs
chapter list from ifo edit

0 errors, 0 xtra cells at end (perfect 20 chapters)

thank you!!
jptheripper is offline  
Old 15th December 2004, 23:28   #68  |  Link
erdoke
Custom User Title
 
erdoke's Avatar
 
Join Date: Aug 2004
Location: Lat. 47.3350 | Long. 21.3850
Posts: 226
Quote:
Originally posted by mrslacker
PgcEdit warns that the PGC playback time doesn't match the total of the cells times.
I experienced exactly the same with v. 0.3. Will try 0.5.

BTW thanks MPUCoder, I'm pretty sure that it will be a great project.
__________________
Today begins the rest of your life...
erdoke is offline  
Old 16th December 2004, 01:00   #69  |  Link
mrslacker
Junior Slacker
 
mrslacker's Avatar
 
Join Date: May 2004
Location: End-World
Posts: 296
No more extra chapters with 0.5. Groovy.
I'll try to remember that frame numbers start with 1, not zero!
mrslacker is offline  
Old 16th December 2004, 01:38   #70  |  Link
mpucoder
Moderator
 
Join Date: Oct 2001
Posts: 3,530
That's not what was meant. Frame 0 is the first frame, but there is no need to make a chapter there.
mpucoder is offline  
Old 16th December 2004, 15:35   #71  |  Link
M7S
Really? Really really!
 
M7S's Avatar
 
Join Date: Jan 2004
Location: Finland
Posts: 163
Quote:
Originally posted by mpucoder

...(whereas most code in MuxMan is written for portability, with an eye toward Linux. That means there is no MFC, AFX, DDX, or the dreaded .NET framework).
Will we see an Linux version sometimes in the near future? It would be great. After 1.0 perhaps?

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.
M7S is offline  
Old 16th December 2004, 20:33   #72  |  Link
Sir Didymus
Registered User
 
Join Date: Mar 2004
Location: Italy
Posts: 946
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
The whole title has been remuxed and it plays perfectly. So the relevance of the following is just informative (no relevant bug to report) and concern the compliancy of the generated title against some MPEG2 and DVD rules.

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.
Sir Didymus is offline  
Old 16th December 2004, 20:57   #73  |  Link
mpucoder
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.
mpucoder is offline  
Old 16th December 2004, 21:25   #74  |  Link
Sir Didymus
Registered User
 
Join Date: Mar 2004
Location: Italy
Posts: 946
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.
Sir Didymus is offline  
Old 17th December 2004, 00:04   #75  |  Link
mpucoder
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).
mpucoder is offline  
Old 17th December 2004, 11:36   #76  |  Link
Sir Didymus
Registered User
 
Join Date: Mar 2004
Location: Italy
Posts: 946
Quote:
Originally posted by mpucoder
What I meant was the exact value used by Scenarist is not 58x4096 (232KB), but slightly less.
Oh, I see. Afraid I misunderstood what you meant. I didn't know this very little margin was adopted by Scenarist, VERY INTERESTING TO REALISE... By the way, you may hear my very strong Italian accent, dont'you ? I am not a native English speaking person, so having sometimes troubles in the proper understanding of some post contents...

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
Sir Didymus is offline  
Old 17th December 2004, 13:25   #77  |  Link
M7S
Really? Really really!
 
M7S's Avatar
 
Join Date: Jan 2004
Location: Finland
Posts: 163
@mpucoder

Quote:
originally by liquid217 from this thread
If any of what I say below is incorrect, please feel free to correct me.
but, from what I understand, Ifoedit is built on some old outdated mplex code. The mplex version packaged with dvdauthorgui is fairly recent, and I believe the mjpegtools folks have fixed a great number of problems that were in mplex.
If this is true and it's not too much work could you do the comparison on your page again with a up-to-date version of mplex, please? I wish I knew how to do a comparison myself...

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.
M7S is offline  
Old 17th December 2004, 15:22   #78  |  Link
mpucoder
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.
mpucoder is offline  
Old 17th December 2004, 16:19   #79  |  Link
liquid217
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.
liquid217 is offline  
Old 17th December 2004, 17:38   #80  |  Link
mpucoder
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.
mpucoder is offline  
Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 04:38.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.