Muxman - simple DVD authoring

[mpucoder]

Two years ago (or was it three?) I set about gathering information so that I could write an authoring program. But a couple things got in the way, and all the world got was the information I had gathered.
Now things are finally back to normal. Yes, the crackhead girlfriend is finally gone (my apologies to Germany, where she decided to go next).
Anyway, the centerpiece of any authoring program is its multiplexer, so I wrote that first and designed a simple authoring program to test it. It is available at www.mpucoder.com/Muxman

My plans are to further develope this into a program rivaling Scenarist. Such a program, however, would not be free. But this program, along with bugfixes and some later improvements, will continue to be available and free. At some point there will be two, or maybe more, versions ranging from free on up.

[lark]

The product of Muxman is virtually identical to that of Scenarist, and far superior to any mplex based authoring program.

sounds too good to be true!

regards
t :)

[mpucoder]

For the sceptics I published the verification results. See the link on the page.

[Trahald]

Excellent.. great work mpucoder.

Originally posted by mpucoder
... Yes, the crackhead girlfriend is finally gone (my apologies to Germany, where she decided to go next).LOL!

[Trahald]

I demuxed one of the features from The Two Towers extended.. disk 4 appendices (the feature that goes into the premiers for TTT) powerdvd plays it fine except for right before the london premier where Billy boyd is talking (about the 2:20 minute mark) it glitches there and you cant rewind over it. Windvd and IFOEdits player both can barely play the output( the video stutters behind the audio the whole way). This is a NTSC (almost pure 29.97) video right off the dvd. Just to parallel i muxed it in scenarist and was fine.

[mpucoder]

Were there any errors reported? Look in c:\muxman.log

[Trahald]

Opened video file D:\TWO_TOWERS_EXT_D4\VIDEO_TS\VTS_01_1 - 0xE0 - Video - MPEG-2 - 720x480 (NTSC) - 16~9 - Letterboxed.M2V, 275750255 bytes.
Opened audio 1 file D:\TWO_TOWERS_EXT_D4\VIDEO_TS\VTS_01_1 - 0x80 - Audio - AC3 - 2ch - 48kHz - DRC - English - DELAY -66ms_fixed.ac3.
AC3 audio, frame size = 0x300.
10:33:29 Begin multiplex.
SeqEnd at 106F880A.
SeqEnd at 106F9D6B.
Bytes remaining in buffer = 0.
10:34:27 End multiplex.
Fields: 34046, VOBU: 1362, Sectors: 145013.

[mpucoder]

The 2 SeqEnd is probably the cause of the problem with this video. There is one part of Muxman that didn't make it for this week that deals with short VOBU's. And SeqEnd can, and usually does, create a short VOBU. Here's what happens: A SeqEnd marks the end of encoding, and also forces the multiplexer to end the current VOBU. If that VOBU is less than 0.4 seconds long it should be merged with the VOBU prior to it. But since Muxman is a single pass multiplexer it doesn't know about this until after it has happened. I'm still working on the process of backing up to join them together. The cases I ran into didn't have SeqEnd close together, so the player was able to recover.

Just bad luck, I hope, on your choice of material. But it is something I'm aware of and working on.

I also noticed a negative audio delay. This is something I'm going to be writting about on my website, as it has really gotten out of hand. The bottom line is if you need a negative audio delay something is wrong with the software you are using. I believe it all started with dvd2avi not handling closed GOPs properly, and has persisted like a bad urban legend ever since. Donald Graft (neuron2) has written a corrected version of the program, you can get it here (http://neuron2.net/fixd2v/decodefix.html)
Another source of negative delay is demuxing by VobID. This would be a great idea if implemented properly, but it isn't by any program I tried. What goes wrong? In a seamless VOB joint, like those found within a title, some audio for the first VOB is multiplexed into the second. But during demux all the programs start and stop on the VOB boundary, leaving out the tail end of the audio and grabbing extra at the beginning.

But, IF you demux and never pass the video through dvd2avi or avisynth, AND this starts with the first VobID of the title, negative audio delay is not possible, and should not be "corrected" for.

[Trahald]

OK.. I encoded video from the file and remuxed.. now plays perfect on powerdvd.. but the video still stutters on ifoeditplayer and windvd (the audio plays through w/out problems or pause)
here is the new log
Opened video file D:\TWO_TOWERS_EXT_D4\VIDEO_TS\reencode.mpv, 428434548 bytes.
Opened audio 1 file D:\TWO_TOWERS_EXT_D4\VIDEO_TS\VTS_01_1 - 0x80 - Audio - AC3 - 2ch - 48kHz - DRC - English - DELAY -66ms_fixed.ac3.
AC3 audio, frame size = 0x300.
13:04:24 Begin multiplex.
SeqEnd at 19896470.
Bytes remaining in buffer = 0.
13:06:03 End multiplex.
Fields: 34045, VOBU: 1418, Sectors: 220459.im going to totally reencode the audio and remux and see what happens

[LigH]

One of the users in the german board, who is not so good in English, asked me to report the following:

This tool does not work well with still menus with audio streams. If there is one video frame, and several "frames" of audio below an beyond, you shall stuff the video stream with NAV packs, as some kind of padding to ensure a consecutively advancing timecode.

[Matthew]

Good luck :)

Shame it doesn't have command-line support though :( Otherwise I would use it instead of DVDAuthor when doing scripted avi->DVD-Video. For the moment, if I want a GUI I'll use maestro :/

[mpucoder]

Originally posted by LigH
One of the users in the german board, who is not so good in English, asked me to report the following:

This tool does not work well with still menus with audio streams. If there is one video frame, and several "frames" of audio below an beyond, you shall stuff the video stream with NAV packs, as some kind of padding to ensure a consecutively advancing timecode.
It is not intended to work with stills and menues yet.

[mpucoder]

Originally posted by Matthew
Good luck :)

Shame it doesn't have command-line support though :( Otherwise I would use it instead of DVDAuthor when doing scripted avi->DVD-Video. For the moment, if I want a GUI I'll use maestro :/
It will have a CLI once the use of project files is working.

[lark]

i tried muxman briefly yesterday and discovered following:

- cannot select subpictures before video is seleted => crashes (perhaps the same for audio, but i didn't test)
- if destination folder doesn't exist, muxman seems to work correctly (muxes), but there's neither any output (at least i couldn't find) nor error messages

- not quite sure if 2 subs works, i tried, but at least powerdvd listed only 1

regards
t :)

[mpucoder]

Both of the first 2 are fixed in the next release.

The second subpicture is mapped wrong. Regardless of aspect ratio sub 1 is the 4:3 and sub 2 is LB, which is total nonsense. In order to really fix it more dialog is needed for 16:9 to select the wide, LB, and PS versions of a language (not to mention set the language and extension). So that will take a little time.

I hadn't planned to release every day anyway, but to fix as many problems as possible each week.

[jptheripper]

look forward to using

not sure if you are familiar with subtitle workshop. If you are, I will be loading an sst file into to do some editing and need to know what format to export the subs in.

Ifo-edit isnt a format but almost everything else is

[mean]

There is one thing i did not get
The comparison is that muxman get almost the same output as scenarist while mplex output is different.

But how does it make it better or worse ?

[mpucoder]

The problem I ran into with subs was the huge number of formats and lack of documentation for them. Using the IfoEdit format is admittedly, a hack to add the same functionality as IfoEdit (and therefore get its users to try Muxman). I also ran into many utilities to convert amongst the formats, but that, too, is not a solution.

I believe .sst is a must to support, Maestro's format an option. I just need a good document on the format, or even a good informal explanation.

[SeeMoreDigital]

Lovely tool mpucoder... many thanks!


Cheers

[Malcolm]

hi mpucoder,
great work! Thanks!

Unfortunately it seems that muxman has some problems with mp2 files. muxman always says 'audio type not recognized' and it refuses to add the mp2 file. this happens with all of my mp2 files that come from digital DVB capture (Germany, PAL). the mp2 files are demuxed from the captured DVB mpg file using ProjectX and then cut using Cuttermaran. i have no problems using these mp2 files with other programs (Winamp, BeSweet, IfoEdit, Media Player Classic, etc. pp.) if i try to use other mp2 files that i have produced myself with BeSweet by reencoding the original mp2 file from DVB, then Muxman accepts them.

i have added the first 100 kB from a mp2 file that does not work with Muxman. (DVB -> ProjectX -> Cuttermaran)
Here's the link: http://tinyurl.com/47ef6

greetings,
Malcolm

[mpucoder]

@mean - most of the differences represent non-compliance. For example the first GOP of the test clip contains 3 frames. That is too short for a VOBU and should be combined with another GOP. But mplex does not do that. Subpictures should have pointers in the SRI area back to the VOBU where the data resides if they span more than one VOBU. Again, mplex does not do that. And there are more, but I'd be giving away free help to mplex by listing them all :)

@SeeMore - thanks. It's just the start.

[mpucoder]

The file contains a CRC. There was some confusion as to whether or not this was allowed. But since Scenarist accepted it (I tried) I'll change that in the next release to allow a CRC. While I'm at it, I should give a reason for rejecting the file if possible. With mp2 files the first 2 bytes tell a lot, but Muxman just uses a few signature bytes to identify the file type rather than rely on the extension. 0xFF 0xFD is what it wants for mpeg audio. This means "mpeg-1 layer 2 no protection (CRC)"

[Guest]

Cool work!

Tested it with my DVDslideshowGUI (http://www.videohelp.com/forum/viewtopic.php?t=245071) - muxman works fine with m2v and ac3.

Just two things:
720x576(pal) doesn't seem to be supported?
If the export folder doesn't exist it won't render.

Looking forward to cli. :)

Tin2tin

[mpucoder]

All PAL resolutions are supported, but the picture rate must be 25fps.
Did you get an error message, or is there some other reason you believe PAL is not working?

[SeeMoreDigital]

Originally posted by mpucoder
All PAL resolutions are supported, but the picture rate must be 25fps.
Did you get an error message, or is there some other reason you believe PAL is not working? PAL works here!

I've only tried very, very short encodes/muxes though!


Cheers

[Guest]

Sorry my bad. Used a 1:1 m2v pal file - works fine with 4:3 pal.
Tin2tin

[jsoto]

Amazing!
Many, many, thanks!!
The GUI can be improved ;), but the important thing is the machine inside. We know the author, and sure it will become a fantastic tool.

First try:
- One video + 2audios + 2subs
I've noticed that the output files are a little bit higher than 1 GB. But they grow at the end of the process :confused: May be a second pass to mux the subs?

EDIT: Ooops, something went wrong.
I've three VOB files, the first and second are 1 GB of zeroes + some packs (seems only video and corrupted). The third VOB file (600 MB aprox) plays well in powerDVD
I'll do more tests and report back, but in the meantime here is the log

Opened video file F:\DVDSHR2\Encoded_Video_CCE_PAL.mpv, 2211711360 bytes.
Opened audio 1 file F:\DVDSHR2\Encoded_audio_1.ac3.
AC3 audio, frame size = 0x700.
Opened audio 2 file F:\DVDSHR2\Encoded_audio_2.ac3.
AC3 audio, frame size = 0x600.
Opened sub 1 file F:\DVDSHR2\DVD\TEMP\SUBS\VTS_01_1.20.sup.
Opened sub 2 file F:\DVDSHR2\DVD\TEMP\SUBS\VTS_01_1.21.sup.
16:59:13 Begin multiplex.
SeqEnd at 83D4097C.
Bytes remaining in buffer = 0.
17:05:18 End multiplex.
Fields: 265937, VOBU: 11024, Sectors: 1388237.


BTW, the same mux job took a little bit more than 10 minutes in IFOedit (6 minutes in MuxMan). Obviously in the same PC, same conditions of disk drives, etc.

mdvdauth: Starting muxing at time: 06:29:05
mdvdauth: Finished IfoEdit at time: 06:39:42

jsoto

[jsoto]

Sorry, I'm unable to get a correct VTS higher than 1 GB.
The same material (previously cutted) works fine if the resulting VTS is only one file (lower than 1 GB, of course).

jsoto

[mpucoder]

You are absolutely right, there is something wrong with >1GB titlesets. I think I found the cause, and am testing it now. This bug is big enough to warrant a new release.

[SeeMoreDigital]

Bugger!

I've just tried MuxMan to re-mux 1no 4000MB approx .m2v video stream and an 300MB approx .AC3 audio stream (ripped using DVDdecrypter in IFO mode, around 12 months ago)... and got this: -

http://img66.exs.cx/img66/9273/muxman010bz.gif

The trouble is... it won't play!

Well, to be correct... only the 563,424KB file will play :(


Cheers

[mpucoder]

Another victim of copy/paste from the samples!
OK, new version (www.mpucoder.com/Muxman) available that fixes several problems, including the >1GB mess.

04/12/08 added display options (4:3 from 16:9) radio buttons
fixed lseek bug in backfill operation
released as ver 0.2

04/12/07 fixed crash when opening .sup file prior to video
added check for destination folder, create option
accept mp2 files with CRCs
added language and extension pulldown menus for subpictures and audio

[jsoto]

Yep, it works now!. Final VOB files are just one sector below 1 GB, as they used to be.

Good work.

Err...
- More audios and subs are foreseen?.
- What about delays in audio?

jsoto

EDIT: I've found the application icon quite similar (but inverted) to PgcDemux one. Funny. Yours has more colors.

[SeeMoreDigital]

Yep... it works for me now too!

http://img61.exs.cx/img61/5748/muxman025qo.gif

Great stuff and many thanks :D

[Uruk-hai]

I tried the version 0.2 but the result was negative:(
I prepared 2 subtitles .sup by srt2sup. The output seemed normal but none of the subtitles appeared when playing back in PowerDVD.
Here is the log:

Opened video file E:\TMPGEnc\0 - moive.mpv, 3685285888 bytes.
Opened audio 1 file E:\TMPGEnc\0 - moive.mp2.
MP2 audio, frame size = 0x2A0.
Opened sub 1 file Z:\moive\moive.cht.sup.
Opened sub 2 file Z:\moive\moive.eng.sup.
22:26:25 Begin multiplex.
End of video file
Bytes remaining in buffer = 0.
22:36:28 End multiplex.
Fields: 362403, VOBU: 11942, Sectors: 1923641.

SubRemap did not detect any subtitles in the output either. What's happening?

[mrslacker]

I muxed a ~2.1Gb m2v with an ac3 and the results were good! I'm excited about a quality oriented approach, but I could use an additional element of flexibility: No authoring, just muxing. I have two large m2v files that need to be part of the same pgc. Using dvdauthor, I could list the several MuxMan vobs from the different source files in the same pgc, but I'd rather have just two files. I would be happy to test MuxMan more if it could just make a large vob or mpeg with NAV packets. Even better would be concatenation of multiple inputs! :D I'm wary about implementing the obvious solution: joining the source before using MuxMan. I suspect most programs just do a 'cat-like' operation, ignoring the headers, and fudge the integrity of the stream. In any case, I'd like to keep testing the MuxMan engine. I like the idea of an mplex alternative.

typo

[SeeMoreDigital]

Any thoughts about the possibility of being able to "manually add" chapter time points!

I quite often receive Mpeg2 DVD "Show Reels" that have been weirdly authored. Typically they don't need (or have) to contain an on screen menu. But they really should contain chapter seeking!

The total DVD content very rarely exceeds 1GB but they often contain several separate VOB's (one VOB for each clip).

What I would like to do is to, load the original DVD into say, DVDdecrypter. Rip and de-mux the streams into separate but continuous .m2v and .ac3 streams. And then use your MuxMan to re-mux the streams into one VOB... And add my own chapter points!

....Does that make sense?


Cheers

[jsoto]

@Uruk-hai
I've succesfully muxed two audios and two subs (obtained with
VobSub+subTosup).
So please check with VobEdit to see if the subs are there. May be the problem is in the colour palette

@SeeMoreDigital
Chapters:
You can do it now!. Look in "File" menu, you have the option to add a Celltimes.txt file with the chapter frame numbers (one per row)

jsoto

[SeeMoreDigital]

Originally posted by jsoto
@SeeMoreDigital
Chapters:
You can do it now!. Look in "File" menu, you have the option to add a Celltimes.txt file with the chapter frame numbers (one per row) Bugger... I missed that feature!

Can you post a typical layout style of a "Celltimes.txt" file?


Many thanks

[bourtzovlakas]

Can you post a typical layout style of a "Celltimes.txt" file?

650
5830
11870
21105
30795
31646
45530
59170
59791
64690
74611
86205
90341
103165
111230
115156
121230
130060
131865
133760
148031
151696
164035
170515
176580
179075
191281
202201
217331
222105
222192

[SeeMoreDigital]

Thanks bourtzovlakas,

May I ask... what do the figures you've posted represent. Are they "seconds"?


Cheers

[mrslacker]

Originally posted by SeeMoreDigital
May I ask... what do the figures you've posted represent. Are they "seconds"?

Frame numbers.

[SeeMoreDigital]

Originally posted by mrslacker
Frame numbers. Okay.. I understand.

In the past I've been used to creating "bookmark" files, to represent chapter points, that look like this: - <bookmarks>
<bookmark time="00:00:00"/>
<bookmark time="00:03:06"/>
<bookmark time="00:04:33"/>
<bookmark time="00:07:19"/>
<bookmark time="00:11:03"/>
<bookmark time="00:13:03"/>
<bookmark time="00:16:11"/>
<bookmark time="00:22:20"/>
<bookmark time="00:24:41"/>
<bookmark time="00:27:27"/>
<bookmark time="00:29:44"/>
<bookmark time="00:35:27"/>
<bookmark time="00:40:25"/>
<bookmark time="00:41:20"/>
<bookmark time="00:44:43"/>
<bookmark time="00:47:09"/>
<bookmark time="00:53:03"/>
<bookmark time="00:55:08"/>
<bookmark time="00:57:20"/>
<bookmark time="00:59:19"/>
<bookmark time="01:00:41"/>
</bookmarks>



Or even this: -

<bookmarks>
<bookmark time="00:00:00" name="01 Credits And Foreword"/>
<bookmark time="00:03:06" name="02 Eye On The Sky"/>
<bookmark time="00:04:33" name="03 Leons Emotional Response"/>
<bookmark time="00:07:19" name="04 Street Scene"/>
<bookmark time="00:11:03" name="05 The Old Blade Runner Magic"/>
<bookmark time="00:13:03" name="06 The Replicants In Question"/>
<bookmark time="00:16:11" name="07 Rachael: The Voigt-Kampff Test"/>
<bookmark time="00:22:20" name="08 Leon's Apartment"/>
<bookmark time="00:24:41" name="09 Chew's Visitors"/>
<bookmark time="00:27:27" name="10 If Only I could See..."/>
<bookmark time="00:29:44" name="11 A Visitor with Someone Else's Memories"/>
<bookmark time="00:35:27" name="12 Pris Meets Sebastian"/>
<bookmark time="00:40:25" name="13 Deckards Dream"/>
<bookmark time="00:41:20" name="14 Computer Photo Scan"/>
<bookmark time="00:44:43" name="15 Manufactured Skin"/>
<bookmark time="00:47:09" name="16 Miss Salome's Dressing Room"/>
<bookmark time="00:53:03" name="17 Pursuing Zhora"/>
<bookmark time="00:55:08" name="18 Retirement... Witnessed"/>
<bookmark time="00:57:20" name="19 How Many To Go"/>
<bookmark time="00:59:19" name="20 Wake Up. Time To Die"/>
<bookmark time="01:00:41" name="21 I Am The Business. I Owe You One"/>
</bookmarks>But I reckon I can get used to frame numbers instead :)


Many thanks

[Uruk-hai]

[QUOTE]Originally posted by jsoto
[B]@Uruk-hai
So please check with VobEdit to see if the subs are there. May be the problem is in the colour palette
QUOTE]

Subs are there and the color palette looks ok but still no subs when playing back:

Title Set (Movie) attributes:
Video: MPEG-2 704x480 (NTSC) (NTSC 525/60) (4:3) (not specified perm.display)
Audio 1: English (Mpeg-1 ) 2ch 48Kbps 16bps normal (ID: 0xc0)
SubPicture 1: Chinese (2-bit rle ) (ID: 0x20)
SubPicture 2: English (2-bit rle ) (ID: 0x21)
PG Playback mode = sequential
[000000a3] Still time in seconds 0 [00]
[000000a5] Color 0 Y Cr CB 40 109 240 [28 6d f0 ]
[000000a9] Color 1 Y Cr CB 81 240 90 [51 f0 5a ]
[000000ad] Color 2 Y Cr CB 16 128 128 [10 80 80 ]
[000000b1] Color 3 Y Cr CB 234 128 128 [ea 80 80 ]
[000000b5] Color 4 Y Cr CB 144 34 53 [90 22 35 ]
[000000b9] Color 5 Y Cr CB 106 221 202 [6a dd ca ]
[000000bd] Color 6 Y Cr CB 210 146 16 [d2 92 10 ]
[000000c1] Color 7 Y Cr CB 91 73 146 [5b 49 92 ]
[000000c5] Color 8 Y Cr CB 123 128 128 [7b 80 80 ]
[000000c9] Color 9 Y Cr CB 209 128 128 [d1 80 80 ]
[000000cd] Color 10 Y Cr CB 48 182 109 [30 b6 6d ]
[000000d1] Color 11 Y Cr CB 79 81 91 [4f 51 5b ]
[000000d5] Color 12 Y Cr CB 28 119 182 [1c 77 b6 ]
[000000d9] Color 13 Y Cr CB 97 207 207 [61 cf cf ]
[000000dd] Color 14 Y Cr CB 205 149 81 [cd 95 51 ]
[000000e1] Color 15 Y Cr CB 60 174 164 [3c ae a4 ]

[jsoto]

@Uruk-hai
Sorry, I'm lost. But I can confirm your palete is the same than mine. My subs play fine and I see them red in powerDVD.

@SeeMoreDigital
If you are backing up a DVD you can get the original frame numbers in a "Celltimes.txt" file using IFOedit. Just select the PGC and from Menu Tools->Save Celltimes to a file

jsoto

[mpucoder]

The colors are a default set of colors, since there is no color information in a .sup file.

I tried a Chinese and English set of subs, and on one player the Chinese played, as it was first. On another the English played, as it is my "preffered subtitle language", but I had to turn subtitles on.
Unless they are forced subpictures you may have to enable subs, Muxman adds no PGC commands to select a stream.

[Uruk-hai]

Originally posted by mpucoder
Unless they are forced subpictures you may have to enable subs, Muxman adds no PGC commands to select a stream.

I had selected the subs, both Chinese & English in PowerDVD but still nothing appeared before I posted my problem here,

The video stream came from CCE without closing the GOP. Does it matter? In the UI, I selected normal for sub1 & sub2.

[MvB]

Hi,

that's a nice tool you've written there.
Couldn't test it because it crashes all the time when muxing.
It seems to crash when loosing focus and it does not respond after the green bar has reached 100%.
After killing it some time later there where all the files i needed except video_ts.ifo and video_ts.bup.
Recreated them whith ifoedit, but the muxed video seems to have problems at the beginning of cells. My DVD-Standalone stops there for about a second and continues to play after that. Strange.

I have a dual processor machine, could that cause the problem with muxman?

Thanks
MvB

[mpucoder]

Don't stop it, it's not hung (which is what I assume you mean, rather than crash). Even though the progress bar is at 100% there is still more work to do. I'll be changing the progress bar to acknowledge that work as well. What Muxman is doing is backfilling all the NAV pointers. After that it creates the ifo files. If you interrupt it the vob files will be non-spec.

As for losing focus and then trying to regain it - Muxman doesn't periodically check for Windows messages while multiplexing, so it will not repaint its area.

[mrslacker]

Any chance of multiple inputs in MuxMan? Or at least a recommendation for a quality joining program? Can I just "copy /B file1+file2 output" because m2v has no container? I've read the forums but most solutions feel like hacks. Sorry if I am getting off topic. I like to do things the right way. Thanks for helping a rookie!

Think I'll just join the vobs with VobEdit or the like. Also, all MuxMan vobs from my CCE encodes have worked in my standalone.

[mpucoder]

New version 0.3 is available here (http://www.mpucoder.com/Muxman/)

Added another sub file and the buttons needed to assign 16:9 subs to their track and display mode.
The "short VOBU" has been fixed, although this should not have bothered very many people.

A hint for those using 16:9 subs - start with the first file. As you assign sub streams/files to tracks and display modes the streams/files below will have buttons greyed out to prevent double assignment. It is possible to assign a higher file/stream to a track/display mode combination used by a lower file, in which case the button of the lower file will be pushed but greyed. This is OK, the first file has precedence and took its place.

[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

[mpucoder]

At version 0.6 some io changes were made, and since then 3 reports of hanging during ifo creation.
So here (http://www.mpucoder.com/Muxman/muxman_0_7a.zip) is a special compile of version 0.7 that goes back to using buffered writes for ifo creation.

Trahald, Sir Didymus, Koepi, and anyone else who experienced hanging please try this version and let me know. I'm also curious which OS (I'm assuming XP)

[Koepi]

For now the result looks the same. I'll give muxman some more minutes though (it's at 99% CPU) to give it a chance to create video_ts.ifo|bup.

OS: Win2k SP4 + all security patches (german)

source drive: 7.200 rpm/2mb 80GB maxtor u-dma 133
target drive: 7.200 rpm/8mb 160GB samsung u-dma 133

athlon xp 2.800+; nforce 2 ultra chipset.

Regards
Koepi

P.S.: forgot to paste the log, maybe the underflows and/or remaining bytes in buffer are the problem here?
MuxMan version 0.7
Opened video file E:\Filme\LOTR1-SE\lotr1-se-DVD.m2v, 3033623797 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.
17:35:39 Begin multiplex.
P-STD buffer underflow by 7536 bytes at 776890892, sector 1376871.
P-STD buffer underflow by 17464 bytes at 776901692, sector 1376944.
P-STD buffer underflow by 20135 bytes at 776912492, sector 1377018.
P-STD buffer underflow by 10292 bytes at 776923292, sector 1377092.
P-STD buffer underflow by 37956 bytes at 776944892, sector 1377242.
P-STD buffer underflow by 7898 bytes at 776955692, sector 1377314.
P-STD buffer underflow by 4305 bytes at 776977292, sector 1377461.
P-STD buffer underflow by 10324 bytes at 777002492, sector 1377633.
P-STD buffer underflow by 2730 bytes at 777009692, sector 1377683.
SeqEnd at B4D16CF1.
Bytes remaining in buffer = 118640.
17:50:53 End multiplex.

EDIT2: weird. now that I forced the program closing, vts_01_0.ifo|bup get the current timestamp instead of the creation time 15 minutes ago. Maybe that helps.

[SeeMoreDigital]

Lord of the Ring's!

Those movies have run times that are measured in "parts of days" rather than in hours and minutes ;)

That said, it should provide MuxMan with "the ultimate test" :D


Cheers

[mpucoder]

Well, since it is not the io routines, the next thing would be for people having this problem to make a profile and send it to muxman@mpucoder.com so I can hopefully reproduce it.

[Koepi]

Obviously this is true, SeeMoreDigital ;)

@mpucoder:
Another thing I noticed - with mplex-based programs the vts_01_0.[ifo|bup] are 113kb in size. With muxman, they are 63kb. On my 2nd test with a lot more time not touching anything muxman still hangs in the same place.

If I can help you in any other way to track down the issue?

Regards
Koepi

[mpucoder]

@Koepi - if you could run it again with "make profile" checked and then send c:\muxman.mxl to muxman@mpucoder.com that would help. Even if Muxman hangs the profile will contain enough information to reconstruct conditions up to the hang.

[Koepi]

ok, mail is on the way (takes a little due to my max. 16kb/s uplink). My zip program refused to pack it, so it's full 1.2MB.

Cheers,
Koepi

[mpucoder]

Got it OK, thanks. This takes awhile to expand and test, so I probably won't know anything until tomorrow.

[mpucoder]

I found the problem, and man, is that one long movie. Although I don't like releasing so often, especially right after the last version made the news, this is important enough.
Version 0.8 is available here (http://www.mpucoder.com/Muxman/)

Fixes hang while building vobu_admap > 64K (movies > 2h16m)
And although it hasn't happened yet, the same thing could have happened while building the time map for movies longer than about 4H30M. So that has been recoded as well.

[Koepi]

Success! I got the "summary" messagebox at the end and muxman closed. The resulting files are playing correctly. Forgot the chapter list in the first run but repeating that now, then burn the stuff and try it on my standalone.

mpucoder,
one other suggestion though, if the input files aren't compliant and muxman won't accept them, can you spit out an according message too? I don't have my 18frames-per-(PAL)-gop file around anymore but that would be sure helping.

Regards
Koepi

[mpucoder]

MuxMan will diagnose the GOP size, and tell you when it encounters a large one. The bug was that if the first GOP is too large MuxMan attempted to calculate the average bitrate before showing the error message, resulting in division by zero.
The ironic thing is it crashed while trying to tell you. The program can easily handle 18 frame GOPs, they are used in NTSC. But a check was put in, mainly to prevent GOPs larger than 18 from crashing MuxMan (as that is the limit of one table).
All files get checked somewhat before the multiplex. Video is checked to see if the required headers are present (also needed to see if it is MPEG-1 or MPEG-2, if Pan/Scan is present, and for closed-captions). Audio files are recognized by content, not file extension, so they get scanned a little. If the files meet the first checks the multiplex can begin.
Any time MuxMan absolutely can not go on it will tell you why, but sometimes that will be very far into the multiplex as there is no pre-scan.

[stickboy]

Originally posted by mrslacker
I could use an additional element of flexibility: No authoring, just muxing. I have two large m2v files that need to be part of the same pgc. Using dvdauthor, I could list the several MuxMan vobs from the different source files in the same pgc, but I'd rather have just two files. I would be happy to test MuxMan more if it could just make a large vob or mpeg with NAV packets.I'd like to see this too. Is there any chance of entertaining this? Right now I use DVDLab to join the VOB files, but it's a real waste of time and disk.

[Trahald]

Reran 0.8 on those files that caused the hang and worked 100%! Thank you mpucoder

[RFontenot]

While muxing one of my RTV recordings of a 8mm video, I got an error message from MuxMan 0.7 about 2/3 of the way through a 2 hour recording saying it had detected a GOP with more than 18 frames. I clicked the "OK" button, and MuxMan terminated gracefully.

I eventually traced the problem to a section of the original 8mm recording that was flaky. I edited that section out, and MuxMan was then able to successfully mux the entire recording.

No problem to report, just wanted you to know that the NTSC GOP > 18 error handling is working as designed, at least in this situation.

RF

[buzzqw]

may i also ask for a command line version ?

Thanks

BHH

[PatchWorKs]

Do you know MPLEX (http://www.petercheat.host.sk/libav/mplex-howto.html) ?

I think it could be a great feature...

[Koepi]

Originally posted by PatchWorKs
Do you know MPLEX (http://www.petercheat.host.sk/libav/mplex-howto.html) ?

I think it could be a great feature...

Did you at all read the initial post? Or read on the site of mpucoder?

Please do so.

Cheers,
Koepi

[RFontenot]

I had a 4 hour recording of the Olympics still, so I ran it through MuxMan. MuxMan 0.8 successfully multiplexed the video and audio streams into 6 VOB files, but the program abended with the error: "Can't open VOB file" and did not create any .IFO or .BUP files. Clicking on the "OK" button appeared to hang the program, and clicking "Close" results in the "Program Not Responding" error to appear.

This is all that's in the log file:

MuxMan version 0.8
Opened video file M:\newdvd.m2v, 4294967295 bytes.
Opened audio 1 file M:\newdvd.mp2.
MP2 audio, frame size = 0x240.
11:58:49 Begin multiplex.
Cell map size 50.

[EpheMeroN]

I have two requests for a future MuxMan version:

1: Make the muxman.log file goto whatever dir the actual MuxMan.exe is located at, instead of defaulting to C:

2: Option to mux .m2v and .mp2 to a .mpg MPEG-2 video file instead of setting it up for authoring.

Keep up the great work :-)

[Malcolm]

hi mpucoder,
i have another 2 requests for muxman:
1. please add an option to relax some DVD compliancy-checks. that means primarily GOP-length. resolution (e.g. 480x480, 480x576) would be nice too.

i record DVB streams regularly and burn them to DVD. nearly all DVB streams have a few GOPs (<0.1%) with lengths > 18 (15). they all play fine on my dvd-player.
IMHO it's a bit far from practical use if a muxer refuses *at all* to mux such streams. (again only MHO :))

2. ability to add more than 1 video file. there are 2 types of use for this:
a) you have some mpeg files (e.g. 2 or 3 SVCDs) and you want them to play as a single film on the dvd. AFAIK playing all videos after another automatically can be done by adding some navigation commands in the .ifo file.
b) you have some mpeg files (2 individual movies) that you want to select + play individually.

greetings,
Malcolm

[SeeMoreDigital]

I've been experimenting with Mpeg2 high-def 1920x1080 (1088) and 1440x1080 (1088) files!

Would it possible for MuxMan to author such streams into VOB too?

I realise std-def stand-alone DVD players will not be able to spin and display such files but PC's and maybe even high-def stand-alone players might!


Just a thought... Cheers

[Sir Didymus]

Hey guys, :)

Respectfully speaking, but it seems here nobody takes care any longer about silly things like specifications...

About muxing more than a single video stream into a VOB file... this is simply explicitely forbidden...

But in general, lets'assume it's possible to go beyond the specification, generating some exotic super format DVD++. What happens when something goes wrong ? Which way people can judge who is right if person X say a given title plays perfectly and person Y states the same is crappy ?

Firt of all NEW specifications are necessary,... THEN it will be possible to provide some implementation compliant with this superset...

Regarding high definition, that's a feature I'd like to see... But not on my PC. I'd like it on my HD standalone, with my HD television, using my HD media... I mean, let's wait a couple of years, in the most optimistic scenario...

What I know (maybe I am wrong...) is that two consortia are actually fighting for the promotion of two candidate standards: Blue-ray and HD-DVD... All the rest is just dreaming.

Are you actually so disappointed about the DVD quality ?

Cheers,
SD

[mrslacker]

Originally posted by Sir Didymus
About muxing more than a single video stream into a VOB file... this is simply explicitely forbidden...

If you are refering to what Malcolm said, I think this would be very useful. It's not a request for creating a VOB with two video streams, just the ability to join clips. That's just my understanding of what he said.

Butterfingers: Edited spelling.

[Xesdeeni]

Isn't it a feature of DVDs to allow multiple viewing angles? Isn't that multiple video streams?

Xesdeeni

[Malcolm]

Originally posted by Sir Didymus
About muxing more than a single video stream into a VOB file... this is simply explicitely forbidden...I think there's a misunderstandig: muxing multiple videostreams *after* another in one VOB file is exactly what you can do with every DVD authoring program around. Try it with DVD Lab. Multiple .MPVs (same size, etc.) IN -> one .VOB OUT.
I think this is 100% compliant to the DVD standard. DVD Lab gives explicit warnings + errors if you try to do somethings that isn't dvd compliant!

to my request regarding GOP lengths > 15 (and video sizes like 480x576): this is no 'super format DVD++' as you say! supporting such things is of big practical use. DVB streams *HAVE* GOP lengths > 15. what prize do i get for having a super-duper 100% standard-compliant multiplexer when i can't use it because it refuses 99% of all my videos?
i'm recording & burning DVB streams for myself. and my dvd player plays them fine. so for whom should it make them standard compliant?
why *REFUSE* a stream which has 0.1% long GOPs inside?? it's o.k. to give a warning but i expect a tool to *HELP* me, not *HINDER* me!
i mean i'm just talking about a *checkbox* to switch some dvd compliancy-checks on and off! this doesn't makes muxman worse! it's beneficial IMHO!
Btw. no other multiplexer complains about GOP lengths > 15. and this is perfectly ok. otherwise i would have had a lot of trouble getting my videos on dvd!
sure i could use these muxers (as i already do). but if muxman is faster, will have more options and is more reliable, why not have it alltogether?

greetings,
Malcolm

[SeeMoreDigital]

Originally posted by Sir Didymus
About muxing more than a single video stream into a VOB file... this is simply explicitely forbidden... As far as I know, there's nothing forbidden with being able to join multiple video streams (with their corresponding audio streams) into a single VOB file (or more VOB files), if required...

Indeed, such an option would be very handy when coupled with a correctly written "import chapter" file!

I'm quite fed up receiving show-reel DVD's that contain only one "short" video file per VOB.

I got a disc before Xmas that had 24 VOB files on it, with a total run-time of approx 30mins. Which certainly does not conform to the DVD specification!


Cheers

[Sir Didymus]

@Malcom.

Regarding "more than 1 video stream", I have to apologise: just totally misunderstood what you meant. Really afraid.

Well, since the declared intentions (written in the download page) of the author are:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is only the beginning. The multiplexing engine, dubbed "MME" for MPUCoder's Multiplexing Engine, was written from the ground up to work with multiple angles as well as properly handle mpeg-2 pulldown. This means multiple angles and multiple stories (true seamless branching) are possible without altering the engine. Of course to achieve that the engine needs to be driven properly, but the capability is there.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I think you (and myself) may assume that what you are asking is already planned as an evolutionary step of this "MME"...

About the GOP lenght and the requirements of other kind people asking to "exceed" or to "relax" the DVD specs, well, there are very solid reasons in the standards for requiring the max GOP size of 15 (for PAL) and 18 (for NTSC). That's all. If it is not allowed, it is of no relevance the result play perfectly on 99% of the standalones. There are situations [Well, here I am emphasizing, a little bit, it is just an example...] where you simply must be 100% compliant, and can not tolerate that 1% of your products would be rejected (with valid reasons) by your customers...

Cheers,
SD

[stickboy]

Originally posted by Sir Didymus
There are situations [Well, here I am emphasizing, a little bit, it is just an example...] where you simply must be 100% compliant, and can not tolerate that 1% of your products would be rejected (with valid reasons) by your customers...... and there are situations where you can tolerate 1% incompatibility.

The question is about who should be deciding this: the muxer or the user? I think the user should have the final say. The tool should give a warning, yes, (and this is what muxman does for underflows) and ask the user if they really want to continue, but it shouldn't summarily reject them.

Unconditional rejection is fine if you're in a position to encode the video again to be compliant, but it sucks if you're dealing with a video stream you didn't make.

[mpucoder]

Multiple video/audio files is mentioned in the readme file as something that will come later. The development of MuxMan is going through stages, the first of which is a multiplexer which is as standard-compliant as possible. Other programs have rushed to add features, and the result is what we here call a cluster f*** of non-compliant programs. That is not what I want Muxman to become, or to even help continue.

Some changes mentioned here will come in good time. Others are just not in the path of development I envision. DVB needs to be looked at for ways to make it compliant. Possibly by splitting GOPs (needs an I-frame). HD will come in another multiplexer once the format is known to me.

One workaround for short clips is to join them prior to multiplexing. If they are compatible you can join them using something as simple as copy /b

And in case you're wondering what I'm working on currently - one computer is running compliancy tests, which are getting fixed (they are not severe) for the next release. I've finished I-frame encoding and am working on bmp import for subpictures. That will enable sst support, and together will take Muxman one step closer to making menues.

[mpucoder]

About relaxing the GOP restriction - it could be done, but I need to know by how much. The restriction is there primarily to prevent internal tables from overflowing, so I need an absolute upper limit.

[Sir Didymus]

Originally posted by SeeMoreDigital

...
I'm quite fed up receiving show-reel DVD's that contain only one "short" video file per VOB.

I got a disc before Xmas that had 24 VOB files on it, with a total run-time of approx 30mins. Which certainly does not conform to the DVD specification!


Cheers

Hi, :) Afraid if my poor English generated some confusion...
Again apologise about the point of "more than 1 video stream".

On the other hand the second point you are stating is really surprising to me...

Almost sure I am having again some poor understanding of your words...

You mean that since you receive badly authored DVD on your desktop, and they play well on your standalone, then we should ask to the MuxMan author the "freedom" of producing crappy DVD ? Mhhh...

All the best,
SD

[SeeMoreDigital]

Originally posted by Sir Didymus
You mean that since you receive badly authored DVD on your desktop, and they play well on your standalone, then we should ask to the MuxMan author the "freedom" of producing crappy DVD ? Mhhh... I'm sorry to report, I receive badly authored DVD's all the time SD :(

And although these DVD's are not "store bought" movie titles, they have been created by people in the "audio/video" industry, who should know better!

Quite often I receive disc's that contain a simple menu pointing to many individual VOB files. Or disc's with multiple clips that are in one long VOB file but with no chapter points!

I even receive disc's containing both of the above :eek:


Cheers

[mpucoder]

I can see why you'd want a program to point to and ask them to use. But just what would you like the disks to contain? A single vob with each file as a chapter?
I have thought about adding a "dailies" feature. For those of you not familiar, a daily is the raw footage shot in one day. Put on DVD they contain identification and timecode to aid in critique. If I were to do this the id and timecode would be added by forced sub.

[Xesdeeni]

Please forgive me if this is too far asunder, but putting the timecode as a subtitle is something I'd like to do with my home movies when I convert them from DV to DVD. I can't seem to find a reasonable method of doing this. Might your daily proposal be part of the process?

Xesdeeni

[mrslacker]

Originally posted by mpucoder
I can see why you'd want a program to point to and ask them to use. But just what would you like the disks to contain? A single vob with each file as a chapter?
I don't know about SeeMoreDigital, but A single VOB with arbitrary user specified chapter points would be ideal. I'm thinking along the lines of the way DVDAuthor can form a single VOB and single pgc from multiple sources. On the other hand, having an option to create separate VOBs might be useful for a disc with distinctly different footage, like episodes or daily footage. Not sure I would have any use for the subs you mentioned in regards to "dailies" however.

[mpucoder]

Xesdeeni - That is exactly what it would do. There is a program out there that does just this. Unfortunately, I can't remember its name, or if it is free.

[SeeMoreDigital]

Originally posted by mpucoder
But just what would you like the disks to contain? A single vob with each file as a chapter? If you mean "each clip as a chapter" then... yes please :D

Can one of you guys confirm the maximum quantity of VOB's allowable on a spec compliant DVD please? Because I'm sure many of the DVD's I receive contain way more than there should be!

Thankfully none of them will ever require subtitles.


Cheers

[mpucoder]

Per titleset - 9. But you can have up to 99 titlesets (vts)

[SeeMoreDigital]

Originally posted by mpucoder
Per titleset - 9. But you can have up to 99 titlesets (vts) No wonder some of the DVD's I receive don't work correctly in stand-alone players!


Cheers

[makoto916]

Xesdeeni, this may seem like an obvious solution to your timecode issue, but you can always use an AVISynth script to generate it for you.

video = AVISource("dvsource.avi")
ShowSMPTE(video,video.framerate)

These two lines will load a video file and then display the SMPTE timecode at the bottom. You can get fancier and move it around if you want it to be within TV cropping.

[Xesdeeni]

1. I don't want the timecode (which is zero-based in AVISynth), I want the date/time stamp from the camcorder.

2. I don't want it burned in, I want it controlled on playback, just like a subtitle.

The idea is to see what date each clip in my home movies occurred, to see how old my children were when each thing happened, but not have it on screen at all times. I can do this manually, but it is a huge amount of work. I'd like a way to send the edited DV (from Premiere) through a filter that would create the subtitles for me, that I could add when I author the DVD.

Xesdeeni

[RFontenot]

Perhaps this got lost in all the talk about relaxing the specs for non-compliant elementary streams, but I did run into the problem of MuxMan hanging when multiplexing a 4 hour video. MuxMan successfully created six VOB files, but no .IFO or .BUP files, and the program ended up in a non-responsive state. Since up to nine VOB files are allowed, it should have worked, or is there some limit to video length that I'm not aware of?

Video files from the same source that are less than 4 hours mux just fine.

[mpucoder]

That particular error means Muxman cannot open another vob file. There are 3 reasons that I know of that will prevent that.
1) too many open files - this can't happen because Muxman closes the last file before opening another.
2) too many files in one directory - only the root in FAT file systems has a limit. Other directories and NTFS do not have this problem
3) no disk space.
I don't know of any other reasons, but I will try a simulation with a synthetic 4.2G file to see if there is any other problem.
The error should exit more gracefully, though, and that will get fixed.

[RFontenot]

I have two 11GB NTFS partitions on separate physical drives that I use mainly for ripping/muxing/demuxing video. The target filesystem was empty except for the 6 VOB files created by MuxMan.

I ran the stress test twice, with and without chapterpoints, with the same results.

RF

[mpucoder]

I just ran Muxman out to 9 vob files with no problems. It could be specific to the structure of your video, so create a profile and send it to muxman@mpucoder.com

[Stef]

Originally posted by Xesdeeni
1. I don't want the timecode (which is zero-based in AVISynth), I want the date/time stamp from the camcorder.

2. I don't want it burned in, I want it controlled on playback, just like a subtitle.

The idea is to see what date each clip in my home movies occurred, to see how old my children were when each thing happened, but not have it on screen at all times. I can do this manually, but it is a huge amount of work. I'd like a way to send the edited DV (from Premiere) through a filter that would create the subtitles for me, that I could add when I author the DVD.

Xesdeeni

This if offtopic for Muxman, therefore short version...

Maybe this link is useful for you:
DV_DATECODE (http://www.skydiver.de/stef/datecode_en.htm)

Stefan

[Xesdeeni]

Originally posted by Stef
Maybe this link is useful for you:
DV_DATECODE (http://www.skydiver.de/stef/datecode_en.htm)That looks like just the ticket. Thanks!

Now back to our regularly scheduled topic...

Xesdeeni

[katjarella]

@mpucoder
added single-frame still with audio

Many thank you. I am very lucky, it function. The first tests look very good.

[mpucoder]

I'm glad to hear that someone has used this feature.

[nnigam]

This is a great product. It works better then IFOEdit for me, but I have just started creating dvd's and my first dvd will be created using Muxman. But a few questions.

I see messages about P_STD buffer underflow, and talk of re-encoding. I too am getting the same errors. My process is as below

1. Record 1 hr HD content 720p from my MYHD tv card.
2. Demux using dvd2avi2.
3. Convert dvd2avi project to mpeg2 using QuEnc (Takes 10-12 hrs).
4. Process quenc mpeg file and dvd2avi ac3 file with muxman (takes 10 min).

In QuENC use GOP of 12, Max B-Frames of 2, DC Precision of 10. 16:9 aspect ratio and checked scene detection and auto max bit rate with AC3 audio.

Try 1. I used bitrate of around 9048 or something like that, (max bitrate -192 for the audio). Muxman processed about 600k and then died with numerious P_STD errors.

Try 2. I reduced bitrate to 4092-192. Muxman completed, but compalained that it may not play on my dvd player. It played fine on my computer dvd player, but audio was out of synch near the end. I suspect the reason was that in the advanced options page in quenc, I put audio bitrate of 256 instead of 192.

Try 3. I corrected the audio bit rate in QuEnc and am re-encoding. I am still getting P_STD errors, but it looks like the process will complete. This takes a long time (12 hrs per try in QuENC) and will see what happens.

Some questions.

1. DVD should have AUDIO_TS and VIDEO_TS directories. Muxman only creates files in the video_TS directory. What if anything goes into the AUDIO_TS directory.

2. My Audio file has a delay of 360 ms. I cannot set this in Muxman. I read about the audio delay in this chain, but if capturing from live broadcast, I have no control on the audio delay. Is there a tool to correct this delay.

log file looks something like this. (Removed 11 P_STD error lines)

MuxMan version 0.8
Opened video file D:\DH\T.m2v, 2328158682 bytes.
Opened audio 1 file D:\DH\pdvd AC3 T01 2_0ch 192Kbps DELAY -360ms.ac3.
AC3 audio, frame size = 0x300.
18:50:06 Begin multiplex.
P-STD buffer underflow by 16138 bytes at 125412554, sector 375592.
P-STD buffer underflow by 4535 bytes at 125415557, sector 375613.
...
...
P-STD buffer underflow by 4376 bytes at 334619552, sector 964022.
End of video file
Bytes remaining in buffer = 158330.
18:57:22 End multiplex.
Bitrate - avg: 4181065, min: 450109 (lba 1142416), max: 14198921 (lba 375329).
Fields: 284188, VOBU: 11077, Sectors: 1209917.

[mpucoder]

You can set an audio delay of up to 300ms, that should get you close enough to be unnoticable.
Nothing goes into the AUDIO_TS folder, and no player should need it. Since the product of Muxman could go to any folder you like it will not create an AUDIO_TS folder. Most burning programs will add an empty AUDIO_TS folder for you, or you can create it yourself. Just remember to use all uppercase letters.

The problem is your maximum bitrate is too high. I'm not familiar with QuEnc, but it should have settings for minimum, average, and maximum bitrate. Set the max to around 9000. Right now you're maxing at over 14Mbps. This is why Muxman gives you the stats, so you will know just how high the encoder went.

[papas]

Originally posted by nnigam
2. My Audio file has a delay of 360 ms. I cannot set this in Muxman. I read about the audio delay in this chain, but if capturing from live broadcast, I have no control on the audio delay. Is there a tool to correct this delay.

Yes, you can use jsoto's delaycut - see http://www.posunplugged.com/jsoto/ .

[Trahald]

quenc is very prone to bitrate spikes (and/or vbv issues )so you have to set the bitrate lower. scenarist will outright refuse alot of quenc streams.

[nnigam]

OK. So I am going to correct the AC3 delay with the delay correct utility. In QuEnc I set the bitrate to 2048 and still got a max bitrate of 10851. Muxman processed this with no errors. The sould is still off and the delay corrector may help with that. It may be a problem with the original HD stream. I watchted the show on TV with captions on, and saw that the captions came before the actual words were spoken, sometimes as much as 2-3 seconds earlier.

Anyway to set the bitrate in the Avisynth script that QuEnc is opening? Any benefit to adding the audio in the avisynth script since QuEnc59 can handle audio, though I do not see any option for it anywhere.

[mpucoder]

The delay between captions and sound is not a good way to judge sync as captions are supposed to preceed dialog. Watch the actors lips, listen for cues such as doors closing, footsteps, etc to judge audio sync.
As for your other questions about avisynth and QuEnc - these are best asked in their respective forums.

[nnigam]

I found the problem. It was not due to any delay. I had converted a 59.94fps program down to 29.97 for dvd frame rate in the avisynth script that was processed by QuEnc. I had not done the same to the audio so the more I played the more out of synch it got. Let me look at how to reduce the audio frame rate.

Short of the audio which is my fualt, the program is perfect.

Also how about adding a check box to make vob files of around 650mb so they fit on cd for miniDVD recording instead of the default 1gig for regular dvd's.

[kheops]

hi all

i don't think my problem deserves a new thread
since i've forgotten this twice now, i wonder if muxman could add a warning, before compiling, when no chapters are added ?

thanks :)

[Trahald]

hehe.. well.. if mpucoder is inclined to do so i hope he makes it an option (i normally dont bother with chapters..) i have mostly been just testing muxman.. my dvd player can seek to a specific time also.

[stickboy]

Originally posted by kheops
i don't think my problem deserves a new thread
since i've forgotten this twice now, i wonder if muxman could add a warning, before compiling, when no chapters are added ?Maybe "Import Chapters" shouldn't be a menu item and should be displayed in the main window along with everything else.

[jsoto]

I'd like to have the version number somewhere in the GUI. May be in the about box?

jsoto

[cannew]

Will Muxman create a Menu to point to 2 or more movies copied onto a dvd? I want to copy my old b&w movies on dvd ( say 2 or more per dvd) and would like to create a menu to select the movie to watch.

[SeeMoreDigital]

You might like to know, there's a new MuxMan thread hrere: -

http://forum.doom9.org/showthread.php?s=&threadid=88493


Cheers

[mpucoder]

Originally posted by cannew
Will Muxman create a Menu to point to 2 or more movies copied onto a dvd? I want to copy my old b&w movies on dvd ( say 2 or more per dvd) and would like to create a menu to select the movie to watch.

No, that is not its purpose.

I'm going to close this thread, as SeeMoreDigital said, there is a newer one.