Muxman - simple DVD authoring

[SeeMoreDigital]

Nice one... It's getting bedderer and bedderer!

Any thoughts about adding a third audio stream?


Also, when you select "About" to obtain the "About MuxMan" information window, the "White/Red X" close button does not function :(


Cheers

[Trahald]

I did a mux with some low bitrate stuff (4 60 min episodes on 1 dvd-5) i muxed with scenarist. since i still had the files on the hd i had muxman take a shot with the original unprocessed file for episode 4. windvd played it smoothly but audio went out of sync slowly. muxman warned of underruns during mux. i'll try the encoded file later.
Opened video file D:\doit4\VTS01\VTS__01_P04.I-TFF.4~3_1.M2V, 1483355002 bytes.
Opened audio 1 file D:\doit4\VTS01\VTS__01_P04-80-384K-[-66]ms(fixed)-ch6English.AC3.
AC3 audio, frame size = 0x600.
Opened audio 2 file D:\doit4\VTS01\VTS__01_P04-81-96K-[-66]ms(fixed)-ch1Español.AC3.
AC3 audio, frame size = 0x180.
18:06:27 Begin multiplex.
P-STD buffer underflow by 1726 bytes at 133939572, sector 411340.
P-STD buffer underflow by 30577 bytes at 149495112, sector 459771.
P-STD buffer underflow by 11476 bytes at 180468054, sector 547935.
P-STD buffer underflow by 2722 bytes at 180513099, sector 548115.
P-STD buffer underflow by 1903 bytes at 180558144, sector 548285.
P-STD buffer underflow by 772 bytes at 180603189, sector 548458.
P-STD buffer underflow by 10029 bytes at 206558118, sector 623229.
P-STD buffer underflow by 8952 bytes at 263498001, sector 799777.
P-STD buffer underflow by 4415 bytes at 265969470, sector 806467.
SeqEnd at 586A1E15.
SeqEnd at 586A3376.
Bytes remaining in buffer = 72572.
18:17:10 End multiplex.
Fields: 182806, VOBU: 6148, Sectors: 832576.<Edit> Ok.. muxed the encoded version with muxman. The encoded version (about 800mb video) results in 0 underflow warnings and plays in sync the whole length of the video. Just to be sure i remuxed the source video again with muxman and same issue.. wether playing it straight through or scanning, by the end of the show its about 3/4 second out of sync. scenarist muxes either source fine with 0 underflows and sync the whole way.

[mpucoder]

Well, since it's not practical to send 1.4GB files, I came up with a way to convey the factors that influence the multiplex. MuxMan can now create a "profile" that conveys just the essential information so that I can analyze the failure. The total file size of this profile, called muxman.mxl, is 4*frames bytes, plus a little more for the audio factors. A more detailed explanation of the file created is here (http://www.mpucoder.com/Muxman/profile.html)

To generate it you need the newest, ver 0.4, available here (http://www.mpucoder.com/Muxman/)

Other changes since 0.3 are:
added bitrate stats to log (these also show in the success dialog box)
fixed potential crash (logging scoreboard)
fixed about dialog to close on "X" and alt-f4
added audio delay

@Trahald - if you don't mind, could you run that again with "make profile?" checked and send the file to muxman@mpucoder.com

@others - please don't flood me with profiles :) I'm not looking to collect them. But if you have underruns and you are very sure there should not be any, then go ahead and make a profile. Send it along with the log to muxman@mpucoder.com so that I can find out why the multiplex failed.

[Trahald]

done

[mpucoder]

Thanks, now comes the fun part. I can see one thing right off, even though the average bitrate is low, the peak was 10.55Mbps. Even so, it obviously is short enough to handle. I just have to find out why MuxMan didn't.

In case anyone is wondering, the bitrates shown are not the multiplex stream, but from the player's buffers to the decoders. They reflect the data delivered in one VOBU divided by the total presentation time of the VOBU.

[jptheripper]

Just a few thoughts

i have remuxed a number of times now and about half i forget to add the chapter list

anyway to get that moved to the main page?

other than that great program.. perfect output

[Sir Didymus]

Excellent work mpucoder... really excellent.

I just performed some (very little and preliminar) compliancy checks against the following:

1. Verify that SCR timings are sufficiently apart (relative differences among contiguous packets > 146.xx 90 KHz ticks).

2. Verify that Vob Unit lenghts less than 0.4 seconds are absent.

3. Verify that STD buffer overflow events are not present (this is especially tricky, since the big majority of muxing and authoring tools I know are very strongly concerned about STD buffer underflows, but the same care about overflows is rarely present...).

I am very glad to report that all checks passed. I was especially surprised and impressed by the passing of the third check...

In the next days I will do some more (severe and complete...) compliancy checks. Your work deserves appreciation, and (on what I see) the authoring quality of the results of your program is already at a level comparable to the one of Scenarist...

Cheers,
SD

[SeeMoreDigital]

Jeez... I wish I understood what Sir Didymus was talking about... but it sounds very important... so thank God it works :)

I've used v0.4, half a dozen times and it's worked perfectly even with importing chapters.

With regard to importing chapters, I would really find it helpful if you had choice of importing either by, "frame number" or by, "hh:mm:ss".

With regard to future releases. How difficult would it be to add an "audio/video window", so we could check the A/V and subtitle streams. And set our own chapter points?


Many thanks

[mpucoder]

Well, I understood what Sir Didymus said, and am very pleased that someone has taken the time to make these checks and post them. And even if MuxMan fails the more stringent tests, I'd like to know.

Chapters, and other points along the timeline, will be getting much more detailed control. But for now, we have the humble chapter list. Allowing time/frame entries shouldn't be too difficult, so that should be in the next release. As for putting the file on the "main" (asset) page, it would only have to come off again once the timeline gets its own page.

A/V preview is a bit tricky, all I see is huge difficulties with other programs. Library mismatches, codecs missing, etc. And it's all very Windows specific (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). Eventually something will have to be there, but for now I concentrating on some different, hopefully more useful, things like bmp->mpeg I frame for menus.

And releases will slow down now that the engine appears to be stable.

[bourtzovlakas]

And set our own chapter points?

That is possible right now,just by altering the celltimes.txt....
You can set the chapter points by setting the corresponding frame number...
You can even import new chapter points or you can delete some of the existing ones.
Of course,i am not 100% sure that this action won't affect in any way the muxing,so if anyone disagrees,feel free to correct me....

[Guest]

Hi folks,
Check this out - tsp coded a frames2smpte function for avisynth.
frames2smpte (http://forum.doom9.org/showthread.php?threadid=83115&highlight=smpte+tin2tin)
Great work mpucoder!
Tin2tin

[mpucoder]

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.

[mrslacker]

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 (http://home.comcast.net/~chappjc/too_many_chapters.jpg) is an IfoEdit screenshot showing the extra chapters and the chapter list (http://home.comcast.net/~chappjc/chapter_frames2.txt) used. The chapters occur basically where I want (every five minutes at 29.97fps) and none exceed the duration of the clip.

PgcEdit warns (http://home.comcast.net/~chappjc/pgc_playback_mismatch_pgcedit.jpg) 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.

[mpucoder]

I'd like to see the log, for now.

[mrslacker]

mpucoder,
I put the log and profile up as well. See your PM. Thanks.

[mpucoder]

Version 0.5 is available here (http://www.mpucoder.com/Muxman/)

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.

[jptheripper]

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!!

[erdoke]

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. ;)

[mrslacker]

No more extra chapters with 0.5. Groovy.
I'll try to remember that frame numbers start with 1, not zero!

[mpucoder]

That's not what was meant. Frame 0 is the first frame, but there is no need to make a chapter there.

[M7S]

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.

[Sir Didymus]

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:

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:

http://img145.exs.cx/img145/1803/solarisv1c17zy.th.gif (http://img145.exs.cx/my.php?loc=img145&image=solarisv1c17zy.gif)

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:

http://img145.exs.cx/img145/7373/solarisv1c98fc.th.gif (http://img145.exs.cx/my.php?loc=img145&image=solarisv1c98fc.gif)

and this is the zoom of the anomalie:

http://img145.exs.cx/img145/7282/solariszoomv1c99jl.th.gif (http://img145.exs.cx/my.php?loc=img145&image=solariszoomv1c99jl.gif)

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...

[mpucoder]

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.

[Sir Didymus]

Hi,

Well, the images are produced by Excel... :cool:
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 ? :eek: 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) (http://forum.doom9.org/showthread.php?s=&threadid=84221), 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...

[mpucoder]

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).

[Sir Didymus]

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 ? :rolleyes: 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=libero.it&wr=3zqcxucf&ws=3zqcxucf&e=libero.it&c=1w5kUuVh6AWAPWIbem9jsN2NJIVc05kN18391

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

[M7S]

@mpucoder

originally by liquid217 from this thread (http://forum.doom9.org/showthread.php?s=&threadid=86616)
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

[mpucoder]

@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?

[liquid217]

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.py/mjpeg/mjpeg_play/mplex/

looking forward to the tests.

[mpucoder]

@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.

[Sir Didymus]

Hi mpucoder! :)

Thanks for the feedback -- I'll try to use it for future releases of StdBufLog... That's clearily depending on the very limited availability of NTSC material to myself, so what you say is not surprising me at all...

Anyway it was my fault to mix up the roles: you're the programmer, me the beta tester... :scared:

I mean, the bugs of StdBudLog aren't changing what I reported about Muxman: please just consider I double checked any thing with the Philips Verifier before posting...

Just sorry StdBufLog is not useful for NTSC contents... Future tests will be carried out (if you feel some contribution on compliancy checks is still useful for improving your application) based on the professional profiler alone...

Also -- tell me without any problem if you feel this type of support from my side is, let me say, a little bit out of track or too early respect your development road map... I don't want to make any trouble to your work, which is really awesome !!!

Cheers,
SD

[bourtzovlakas]

Opened audio 1 file C:\Documents and Settings\MANOS34\ÅðéöÜíåéá åñãáóßáò\Demuxed DVD\VTS_01_0.80.ac3.
AC3 audio, frame size = 0x600.
Opened audio 2 file C:\Documents and Settings\MANOS34\ÅðéöÜíåéá åñãáóßáò\Demuxed DVD\VTS_01_0.81.ac3.
AC3 audio, frame size = 0x600.
Opened sub 1 file C:\Documents and Settings\MANOS34\ÅðéöÜíåéá åñãáóßáò\Demuxed DVD\VTS_01_0.20.sup.
Opened sub 2 file C:\Documents and Settings\MANOS34\ÅðéöÜíåéá åñãáóßáò\Demuxed DVD\HARRY POTTER 3.sup.
Opened video file C:\Documents and Settings\MANOS34\ÅðéöÜíåéá åñãáóßáò\Demuxed DVD\VTS_01_0.m2v, 3596035983 bytes.
15:00:34 Begin multiplex.
SubPicture stream 0 backwards move in time.
P-STD buffer underflow by 6062 bytes at 391788092, sector 1127270.
P-STD buffer underflow by 6787 bytes at 391791692, sector 1127294.
P-STD buffer underflow by 11134 bytes at 391795292, sector 1127319.
P-STD buffer underflow by 6835 bytes at 391798892, sector 1127344.
P-STD buffer underflow by 6421 bytes at 391802492, sector 1127368.
P-STD buffer underflow by 5831 bytes at 391813292, sector 1127790.
P-STD buffer underflow by 952 bytes at 391842092, sector 1127825.
P-STD buffer underflow by 4777 bytes at 391845692, sector 1127826.
P-STD buffer underflow by 10940 bytes at 391849292, sector 1127827.
P-STD buffer underflow by 6406 bytes at 391852892, sector 1127828.
P-STD buffer underflow by 4053 bytes at 391856492, sector 1127829.
Cell map size 50.
End of video file
Bytes remaining in buffer = 70198.
15:19:49 End multiplex.
Bitrate - avg: 4200038, min: 245760 (lba 2113492), max: 24958293 (lba 1126875).
Fields: 426795, VOBU: 14224, Sectors: 2188178.


Hello,
A friend of mine,has problems muxing with Muxman...
The log file is above....
It is obvious that something is wrong with the .sup file....
Is that the only cause for the buffer underflows?
Is there anything else suspicious?
Thanks in advance....
(btw this is a great program)

[mpucoder]

A backwards move in time means that the subpictures came from two vobs (aka VobID's). The .sup format uses time relative to the start of the last vob, so it goes backward when starting a new vob. Unfortunately none of the other streams give any hint as to where that happens. This can cause underflow, as all the subpictures up to the current point in time (relative to the start of the video) will be multiplexed rapidly, robbing the video stream of bandwidth.

The other cause of underflow is excessive bitrate. Muxman does not check combined bitrates prior to multiplexing. Often times the bitrate reported in the video stream is wrong, and this causes programs which do check to needlessly refuse to run. You have 2 384Kbps audio streams, if fixing or removing the subs doesn't correct the problem, try removing one of the audio streams.

[jsoto]

The .sup format uses time relative to the start of the last vob, so it goes backward when starting a new vob I believe this is true if you used VobEdit to demux, but if you use vobSub+SubToSup or pgcDemux :) you will not have these problems. In this case timestamps are relative to the initial video start, independent of the VobID.

jsoto

[bourtzovlakas]

Thanks jsoto and mpucoder....

[mpucoder]

jsoto, quite right. I should have mentioned that. It's not the format, but the way IfoEdit creates it.

[Trahald]

i have a humble request. can you add '*.mpv ' to the default choice for video asset selection (ie make it part of the default instead of separate in the drop down. alot of my assets are *.mpv mpeg2 files.. thank you

[mpucoder]

That seems only fair, since .mpa is allowed for audio. It will be in 0.6, due out Wednesday.

[RFontenot]

I've been converting 8mm videotapes to DVD using my ReplayTV and DVArchive. I had been using rtvedit, rtvconvert, and IfoEdit to author the RTV's *.MPG files, but occasionally I would have problems with IfoEdit crashing after multiplexing the output files from rtvconvert.

I haven't had a single problem with MuxMan since I started using it instead of IfoEdit. In fact, MuxMan would multiplex files that would cause IfoEdit to crash. Most of my videotapes are between 1 to 2 hours in length, and I've not detected any problems with audio sync on any of the tapes I've converted.

I would like to see a CLI interface to MuxMan so I could have the whole process automated via batch files. I would like to be able to specify the drive:/dir/filename.ext for the source files, the celltimes.txt file, and the drive:/dir for the target files. I use isolated partitions on two different physical disks for editing and muxing MPEG files. The process goes a lot faster when one disk reads while the other writes.

[mpucoder]

It's nice to hear from the people with no problems! And there will be a cli interface as soon as I can define the project file.

[mpucoder]

Version 0.6 is available in the usual place (http://www.mpucoder.com/Muxman/)

The major improvements this time are:
All valid LPCM combinations of sampling rate, quantization, and channels are now supported.
SRI and subpicture sync pointers are now fully compliant

Here are the valid LPCM combinations

samp_rate quantization channels
48K 16-bit 1 to 8
48K 20-bit 1 to 6
48K 24-bit 1 to 5
96K 16-bit 1 to 4
96K 20-bit 1 to 3
96K 24-bit 1 or 2

[Trahald]

I multiplexed some video.. it seems to create the vts_01_0.ifo fine and all the vobs are fine.. but halts before creating the vmg ifo/bup. it muxed the vobs in about 10 mins.. i left for work, came back and it still was sitting there (at 98% cpu) and the hd light was not going. i tried 3 different times (didnt change the settings any between tries.. ) and same thing. here is the last log. i terminated the process at about 15:00:00

Opened video file D:\doit4\VTS01\VTS__01_P01.P.16~9_1.M2V, 4294967295 bytes.
Opened video file D:\doit4\VTS01\VTS__01_P01.P.16~9_1.mpv.m2v, 3073651020 bytes.
Opened audio 1 file D:\doit4\VTS01\VTS__01_P01-80-448K-[0ms]-ch6English.AC3.
AC3 audio, frame size = 0x700.
Opened audio 2 file D:\doit4\VTS01\VTS__01_P01-81-192K-[0ms]-ch2English.AC3.
AC3 audio, frame size = 0x300.
12:51:33 Begin multiplex.
SeqEnd at B7343148.
Bytes remaining in buffer = 0.
13:13:23 End multiplex.
in vts_01_0.ifo the vts_tmapti is populated correctly
and the vts_c_adt seems fine.. the vts_vobu_admap is filled with 0's

[Malcolm]

@mpucoder

Hi mpucoder, i have some questions regarding muxman respectively muxing in general:
Muxman (like ifoedit) seems to do the multiplexing in 2 steps:
1) generate the vob files with the video, audio and substreams.
2) iterate over the generated vob files and correct/generate missing informations (i suppose something like indexes, etc.)
- what exactly is done in this second step?
- i'm curious why the multiplexing can't be done in one step. (i'm sure there's a reason.) can you please explain why?

i guess you know bbMPEG. bbMPEG is able to multiplex mpeg1/2 video + audio too (VCD, SVCD, DVD). although the result is just an MPG file.
the point is: bbMPEG is *FAST*!! it seems to omit the second step at all. is the second step only necessary for generating VOB files / when a 'true' DVD structure is created?
can you offer this 'fast' multiplexing mode too? (omitting the second step).

thanks and greetings,
Malcolm

[mpucoder]

Vob files contain both forward and backward pointers in the NAV packs. The second pass backfills the forward pointers.

The multiplexer in MuxMan was written specifically for DVD, destined to become part of an authoring program. So it will never support generalized multiplexing.

Currently I am concentrating on compliance. Once that is finished the code can be optimized somewhat. But on my computer it takes only 10 minutes to do a 90 minute DVD.

[Koepi]

I think I found a bug. I encoded my video with a GOP size of 18 frames, but muxman expects only 15, which even leads to a memory access violation (hm, now in the third test this didn't happen, but the GUI stalls forever).

The log:

Opened video file E:\Filme\LOTR1-SE\lotr1-se-DVD.m2v, 2890715136 bytes.
Opened audio 1 file E:\Filme\LOTR1-SE\deutsch.ac3.
AC3 audio, frame size = 0x700.
Opened audio 2 file E:\Filme\LOTR1-SE\english.ac3.
AC3 audio, frame size = 0x700.
09:33:10 Begin multiplex.
Frame 0 6497 bytes, rff = 0.
Frame 1 342 bytes, rff = 0.
Frame 2 1422 bytes, rff = 0.
Frame 3 1422 bytes, rff = 0.
Frame 4 342 bytes, rff = 0.
Frame 5 1422 bytes, rff = 0.
Frame 6 1422 bytes, rff = 0.
Frame 7 342 bytes, rff = 0.
Frame 8 1422 bytes, rff = 0.
Frame 9 1422 bytes, rff = 0.
Frame 10 342 bytes, rff = 0.
Frame 11 1422 bytes, rff = 0.
Frame 12 1422 bytes, rff = 0.
Frame 13 342 bytes, rff = 0.
Frame 14 1422 bytes, rff = 0.
Bytes remaining in buffer = 0.
09:33:10 End multiplex.

Cheers,
Koepi

[mpucoder]

Even though MuxMan detects this error it tries to do some arithmetic it should not (stats, backfill pointers, produce ifo files). This will be fixed in the next release to bypass these operations if an error has been detected.
MuxMan will still not accept more than 15 frames/GOP for PAL, though (18 for NTSC).

[papas]

Hello mpucoder!

I was trying to add a subtitle stream to LOTR Fellowship of the Ring SEE. I always use IfoEdit, but it crashed at 80% with this disc. I've tried muxman, and it worked flawlessly! Thank you for this great program! I have one question. Is it possible to add a setting, which allow to change the default audio stream IDs?

Greetings,
papas

[mpucoder]

The audio stream IDs are determined by the audio track number ("audio 1" or "audio 2"). The DVD itself does not specify defaults. Players choose a track to play based on the language specified for the tracks and your audio language preferrence programmed into the player. If there is no language match the player should use the first track.

So - if you are not specifying a language, try it, it helps. If both tracks are the same language use the extension to distinguish them. Otherwise put the preferred audio first.

[mpucoder]

Version 0.7 is now available here (http://www.mpucoder.com/Muxman/)

This fixes what I hope is the last compliance issue. Many thanks go to Sir Didymus for running compliance tests on PAL material.
Also fixed is the crash when using a GOP with more frames than allowed as the first GOP.

Added feature is the ability to create a still with audio. To do this you need an m2v file that contains just one frame followed by end_of_sequence. The result is the frame is held for the duration of the longest audio. Subpictures can be used with this.

I wanted to include slideshow, which is just a slight variation of still with audio, but the compliance issues and celebrating took up most of the week. Also nearing completion is encoding of I frames. When finished it will allow importing bmp files for still/slideshow.

[Koepi]

Now with muxman 0.7, properly encoded 15-frames-per-gop mpeg2, muxman (nearly) works alright. I have the same problem as Trahald. GUI stalls forever and doesn't create the "main" ifo/bup file (VTS_01_0.[ifo|bup] are there).

The muxing log looks the same as trahalds.

Regards
Koepi