MuxMan 0.11 released

[mpucoder]

The maximum number of subpicture lines for PAL is 573, you lose two at the top, and one at the bottom. This means the biggest display area is 0 2 719 574
It's alright to use bmp's that are larger, you just have to determine which line(s) to lose.
In your case, since the bmp's have 574 lines, I would recommend:
Pixel_Area (1 573)
Display_Area (0 2 719 574)
And Muxman will accept them, cropping off the top line.

Muxman complies with the specs, so if this is what subresync produces, it should change.

Auto pan/scan and auto letterbox are methods of displaying 16:9 video on 4:3 displays. Scenarist and Muxman both require either:
a) 16:9 video and a Picture_Display_Extension header (specifies the horizontal offset)
b) Sequence_Display_Extension indicating display horizontal size of 540

[Matthew]

Thanks for the subtitle tip, I'll try it later. I knew it was probably SubResync's fault, but it along with vsconv.exe (dunno if it has same problem) are major sst saving apps.

Re pan and scan, if video is encoded as 16:9 + panscan checked in CCE then Scenarist takes it as 16:9.

However, if it's flagged as 4:3 + panscan is checked then Scenarist detects it as "4:3 (Pan-scan)".

Now, MuxMan will accept stream 1 as pan-scan but not stream 2.

Some time back it took me bloddy ages to figure out why Scenarist wasn't detecting the panscan info, so I remember it very clearly.

Plus I just tried it as well.

[Trahald]

I modified pulldown.exe source to add a -ps flag (pan and scan) it modifies (or adds *which was a pita since pulldown wasnt coded to add stuff) the sequence_display_extension with width 540. i force AR to 2 (4:3) since my intent for the option was compliance with scenarist. scenarist likes the output and it works great.. just wondering is it really part of the spec to have 4:3 flagged or is it scenarist. ive heard there are p&s streams on pro dvds that are 16:9 flagged with p&s width. i would make it optional for the app

[mpucoder]

The DAR and headers are used as clues. In Muxman auto P/S can be set even without the headers present (or cleared if they are present). The only problem is multi-file wants the files to match in regard to the headers. This perhaps should be changed, along with requiring all files to match in regards to closed captioning.

I know it may sound rigid, but in order to produce spec compliant output Muxman will be strict in the early stages of any feature. Later on I can find ways to correct minor problems, such as subpicture height. I also know that this is a widespread problem, but the spec (as quoted in the Philips Video Verifier User Manual) is clear.

X-co-ordinate values shall be in the range 0 to 719 inclusive.
Y-co-ordinate values shall be in the range 2 to 479 inclusive for TV system 525/60.
Y-co-ordinate values shall be in the range 2 to 574 inclusive for TV system 625/50.


btw, anyone can download the User Manual from Philips (http://www.licensing.philips.com/services/lover/h/documents1051.html)

[mpucoder]

I just found a section in the User manual about the sequence_display_extension. What it says is typically hard to understand. It's a chart, so I'll paraphrase it:

When aspect ratio is 16:9
horizontal size display horizontal size aspect ratio information
720 or 704 720 16:9
720 or 704 540 4:3

When aspect ratio is 4:3
720 or 704 720 4:3
352 360 4:3


Confused as to which aspect ratio they're talking about? So was I - I guess by "When aspect ratio..." means the VTS video attributes, and "aspect ratio information" means the sequence header value.

Muxman will accept video coded this way, the presence of either a sequence_display_extension or a picture_display_extension will flag the VTS as 16:9 with auto P/S. If neither extension is present Muxman then relies on the sequence header DAR.

[Sir Didymus]

Originally posted by mpucoder
... it is only the GUI that is limited. The problem is what you're seeing now will become the demo for the full featured product, and I have promised never to take anything away from it. So I have to restrict it in some places. 3 seemed like a good number as it is the minimum you might need for a 16:9 movie.


Cough, cough...
Well, I don't know if you may be open to a little tricky negotiation...

Cough, cough...
But it seems to me that in order to support three subpictures for a 16:9 movie, including wide screen and letterbox variants, we poor users, cough, cough, we need at least SIX entries for the subs in the GUI...

:cool:

Edit: adding three more subpicture entries while keeping just three radiobuttons for the additional tracks may do the job...

Edit2: of course if you inadvertitely add some more than three radiobuttons, me think nobody would object...

[mpucoder]

Well, there's no more room for track select radio buttons, so it would have to change to a pulldown. Either that or remove the track selection altogether and do as Scenarist does - automatically assign streams to tracks. The same logic as Muxman already has for determining possible tracks (which is based on language and extension match plus display modes not assigned) would set the track number to the lowest available. You lose some flexibility, but it gets simpler looking.

I'm leaning toward automatic track asignment since that means no extension to the Scenarist-like script syntax for project files coming in the next release.

[Matthew]

@Trahald, unless I'm mistaken DVDAuthor (or mplex) expects 16:9 for PS, while DVDMaestro will take either 16:9 or 4:3 (in fact I think it might not even check for the PS info).

Anyway, suppose I'll just have to live with the 16:9 only thing, when CLI comes along. It just would have been nice for the same output to be usable in both MuxMan and Scenarist.

[mpucoder]

I'm not clear on what Matthew means. As long as the headers for PS are in the first GOP Muxman doesn't care what the DAR is. Either 16:9+PS or 4:3+PS will set the video attributes to 16:9 auto-LB auto PS (aka "both"). You should be able to intermix videos of both encodings in a multi-file list. What you won't be able to add to the list is 4:3 without the headers.

[Matthew]

Mea culpa.

I had a 4:3 (no pan-scan) m2v in the same directory as well so I probably added that by mistake :o

I had also tried an earlier release of MuxMan and thought that 4:3+pan-scan wasn't detected properly then either.

Fortunately I'm wrong :) It's really odd how one can do multiple tests, come back later and do it once, and realise they've been an idiot :P

[LordCrew]

I'm not sure if it has been fully implemented yet for SST....

Importing a sst and multiplexing works but if I choose 2 sst subtitles I get an error message when starting the multiplexing: "Sub stream 1 sst tv_type disagrees with video"
The video is PAL 16/9 and both WideScreen and Letterbox was selected for the subtitles.

Track 1 sst:

st_format 2
Display_Start non_forced
TV_Type PAL
Tape_Type NON_DROP
Pixel_Area (0 576)
Display_Area (0 2 719 576)
E2 (255 0 0 ===)
E1 (0 0 0 ===)
PA (0 0 255 ===)
BG (255 255 255 ===)
Directory D:\dvdproj\en


Track 2 sst

st_format 2
Display_Start non_forced
TV_Type PAL
Tape_Type NON_DROP
Pixel_Area (0 576)
Display_Area (0 2 719 576)
E2 (255 0 0 ===)
E1 (0 0 0 ===)
PA (0 0 255 ===)
BG (255 255 255 ===)
Directory D:\dvdproj\fr


and the muxman.log:

MuxMan version 0.11
Accepted video D:\dvdproj\spid.m2v size = 3747474934
Accepted audio D:\dvdproj\spid-en.ac3
Accepted audio D:\dvdproj\spid-fr.ac3
Opened sub 1 file D:\dvdproj\en\en.sst.
Pixel_Area values 0 576 are incorrect, using default of 2 574.
Display_Area Y values 2 576 are incorrect, using default of 2 574.
Opened sub 2 file D:\dvdproj\fr\fr.sst.
23:02:10 Begin multiplex.
Maximum audio duration 366748 fields.
Sub stream 1 sst tv_type disagrees with video

[mpucoder]

That was an interesting bug. The fixed version is available at the Muxman homepage (http://www.mpucoder.com/Muxman/)

[lordyu]

I know it is still in early stage but I would love to see easier way of specifying destination folder than browsing through directory tree. Perhaps in the final version.

1. current way, 2. better way, 3. another better way
(Pics should appear soon ;))

I should think it's easy to add the edit box. Thank you for the tool by the way.

[TheJez]

Hi MPUCoder,

I just started working with this great tool, and noticed a tiny bug:
After multiplexing, a messagebox is showing the following info:

Multiplex completed with no video decoder buffer underflow
Average bitrate 0.
Minumum bitrate 339943 (lba 0)
Maximum bitrate 11293666 (lba 258172)

Of course, the average bitrate amazed me !

Muxman.log shows the correct result, so I guess it's just an optical glitch:

MuxMan version 0.11
Accepted video F:\The_Village\VIDEO_TS\VTS_01_1.m2v size = 1994638092
Accepted audio F:\The_Village\VIDEO_TS\VTS_01_1.80.ac3
Opened sub 1 file F:\The_Village\The Village.sup.
14:02:48 Begin multiplex.
Maximum audio duration 387774 fields.
14:02:48 starting video file number 1.
End of video file
Bytes remaining in buffer = 0.
14:06:06 End multiplex.
Bitrate - avg: 2742554, min: 339943 (lba 0), max: 11293666 (lba 258172).
Fields: 387780, VOBU: 12841, Sectors: 1082938.

Thanks a lot for this great tool !

TheJez

[mpucoder]

Oops. Fixed for the next release.

[Trahald]

seeing a weird thing with the filename for sst import.. here is part of the log

MuxMan version 0.11a
Opened sub 1 file D:\doit8\VTS02\subs\VTS_02_VSUB_P1A1-00-W\VTS_02_VSUB_P1A1-00-W-English.sst.
unable to open d:\doit8\VTS02\subs\VTS_02_VSUB_
\VTS_02_VSUB_P1A1-00-W-English_0001_v001_c001.bmp, file skipped.
unable to open d:\doit8\VTS02\subs\VTS_02_VSUB_
\VTS_02_VSUB_P1A1-00-W-English_0002_v001_c001.bmp, file skipped.
unable to open d:\doit8\VTS02\subs\VTS_02_VSUB_
\VTS_02_VSUB_P1A1-00-W-English_0003_v001_c001.bmp, file skipped.
unable to open d:\doit8\VTS02\subs\VTS_02_VSUB_
\VTS_02_VSUB_P1A1-00-W-English_0004_v001_c001.bmp, file skipped.
unable to open d:\doit8\VTS02\subs\VTS_02_VSUB_
\VTS_02_VSUB_P1A1-00-W-English_0005_v001_c001.bmp, file skipped.
unable to open d:\doit8\VTS02\subs\VTS_02_VSUB_
\VTS_02_VSUB_P1A1-00-W-English_0006_v001_c001.bmp, file skipped.

its truncating the vts_02_vsub_p1a1-00-w from the path when its looking for the file. i played with it a bit and oddly if i made 'subs' into 'sub' (by editing the sst not moving the file) the pathname appeared correctly in the log .. also if i named it subssssss it worked ok to.. although subss didnt work..

[mpucoder]

Almost anything could have happened - the string for the directory name wasn't long enough.
New version at Muxman homepage (http://www.mpucoder.com/Muxman/) fixes this and the average bitrate display.

[bourtzovlakas]

Sorry to bring it up again,but i 've got no answer and thought i should try again,just in case it was overlooked....

Is it possible to implement IFO colors copy from the/an original IFO?
Thanks....

[Trahald]

Originally posted by mpucoder
Almost anything could have happened - the string for the directory name wasn't long enough.
New version at Muxman homepage (http://www.mpucoder.com/Muxman/) fixes this and the average bitrate display.
Worked like a charm. thanx!

<EDIT>
For NTSCers used to scenarist. scenarist ignores the Tape_Type parameter of the .sst.. but muxman does not. so if you find your subs out of sync. make sure it reads Tape_Type DROP.. then you should have perfect sync

[Tnebreux]

Hi, there!
I am new to this forum, although not quite a newbie in DVD re-authoring, and I'd like to add my thanks to MPUCoder for making Muxman available at this stage. The multiplexing part is very impressive, and it processes without glitch some material that had mplex cough up a furball.

I'd like to raise a couple of points about subtitles though:

- I have to concur with Sir Didymus earlier about the number of subtitles. Not only is 3 a bit light for some users, but it also makes it difficult to test thoroughly the use of all colors from the IFO file, since most subtitles streams (even home-made ones) use the same 4 colors for all the subtitles in the stream. This means the result of the muxing uses at most 12 colors...

- I have also noticed a problem, systematic as far as I can make out, when you mux several subtitles streams in different languages. In the resulting DVD structure, only the first subtitle stream is accessible. When you look at the IFO file, the 3 languages are listed, but they all seem to point to the same stream.
However, the bitmaps for the 3 streams are present in the .VOBs, as you can see when you generate new IFOs with IFOedit (the structure with the new IFO files works fine).

[mpucoder]

I wisk I'd known about that earlier. It's fixed in the latest (0.11c) available on the Muxman homepage (http://www.mpucoder.com/Muxman/)

As for the other matter, version 0.12, which will be released in another week possibly, has an entirely new subpicture dialog that allows up to 8 streams - and is no larger than the old dialog.

[bourtzovlakas]

The .zip file of Muxman 0.11c contains an .exe file named 0.11b....
Forgot to rename it, possibly?

[Ebobtron]

from the web page

Currently Muxman produces a working single title DVD from DVD compliant elementary streams. Input may be:

Video: Any DVD compliant mpeg-1 or mpeg-2 or bmp.

--------------------

Mpeg-1 video on DVD? Really, can that be done.

[The Geek]

Mpeg-1 video on DVD? Really, can that be done.

Sure. MPEG-1 352x288 (or x240 for NTSC) is included in the DVD standard.
Therefore putting VCD on DVD is rather easy, as you only need to resample the audio from 44,1 to 48 kHz, and the video goes as is.

The Geek

[mpucoder]

Originally posted by bourtzovlakas
The .zip file of Muxman 0.11c contains an .exe file named 0.11b....
Forgot to rename it, possibly?
Looks like I was in such a hurry to get the bugfix online that I did forget to change the revision - I'll fix that, but there are no new fixes.

[SeeMoreDigital]

I know this is probably not the correct place to ask this, but is there a standard for muxing high-def Mpeg2 MP@HL (720p/1080i) audio and video streams onto DVD... and if so, can MuxMan incorporate such a feature?

I accept that ordinary std-def/resolution players would not be able to spin such discs and that you can only store around an hour of HD content onto an dual-layered DVD~R/RW, but I'm hoping to test a high-def/resolution player very soon and wondered if the creation of such DVD's might be possible or even playable!


Cheers

[The Geek]

is there a standard for muxing high-def Mpeg2 MP@HL (720p/1080i) audio and video streams onto DVD

Nope, there isn't. DVD Video is MP@ML only.

The Geek

[SeeMoreDigital]

Originally posted by The Geek
Nope, there isn't. DVD Video is MP@ML only. Oh well... never mind then!

What about still images, can only 720x480 or 720x576 be used?


Cheers

[mpucoder]

For now, yes (same reason as the aspect ratio - the dialog for tweaking is not ready). Any resizing has to be done with your favorite graphics program before authoring.

[SeeMoreDigital]

Originally posted by mpucoder
For now, yes (same reason as the aspect ratio - the dialog for tweaking is not ready). Any resizing has to be done with your favorite graphics program before authoring. Thanks!

I've come across something else which I'm hoping you can provide an answer to.

I've been experimenting with the following applications to de-mux .VOB files into their separate elementary streams: - TMPGEnc (v2.524.63.181-Free)
VOBedit (v0.6)
DGIndex (v1.1.0)Anyway, for some reason, MuxMan will not accept audio streams de-muxed using TMPGEnc or VOBedit!

Is there any particular reason why?


Cheers

[Sir Didymus]

@SeeMoreDigital:
Yes. These applications (may) demux audio by cell-id. This way some audio header info is missed and MuxMan (correctly) complain about. A proper way to demux audio is following the PGC; give a try to PgcDemux (by Jsoto):
http://forum.doom9.org/showthread.php?s=&threadid=84778

An alternative solution is to manually add one (or more) "silence frames", having the right header info set, to the demuxed audio, but then you have to take into account of the added audio delay. The "silence" tool is available at the Jsoto Home Page.

A third solution (maybe it is the primary workaround...) has been reported to adopt some audio manipulation suite (do not remind which one specifically), to import the file and to export it to a new (or to the same) format, with the heading info properly set...

Cheers,
SD

Edit: Got it! ;)

I finally remind where a similar discussion started:
http://forum.doom9.org/showthread.php?s=&threadid=87298&highlight=silence

[Malcolm]

@mpucoder
in case you remember: we talked about optionally supporting nonstandard GOP lengths. (relaxed check of GOP lengths). You asked what GOP lengths i usually encounter with DVB recordings. My results so far are that i have not encountered GOP lengths > 20.
So imho it would be great if muxman accepts video files with GOP lengths greater than the standard DVD length of 15 (18).
maybe a checkbox for enabling the relaxed check will do. or muxman simply outputs a warning afterwards if GOP lengths are > 15 (18) instead of refusing the video.

Greetings,
Malcolm

[SeeMoreDigital]

Thanks very much Sir Didymus :D

By-the-way, has anybody had any luck muxing PAL Mpeg1 video with MuxMan... Can it do this?


Cheers

[mpucoder]

@Malcolm - the next version, which is in alpha testing now and available from my forum, has quite a few changes in this regard. In order to support field_pictures the GOP tables were expanded to 36 entries (max for NTSC) and the limit set to 36 regardless of tv standard or picture_structure (field or frame). Muxman is only concerned about table overflow now.
btw I think (but have no samples) the longer gop's in DVB are the result of field encoding during high motion. But whatever the cause, version 12 should handle it.

[mpucoder]

I haven't tried PAL mpeg1, but NTSC mpeg1 works OK. The only thing to watch for is the PAR - Muxman will accept 3 or 8 for PAL, 6 or 12 for NTSC. It will not accept square pixels (1).

[Malcolm]

@mpucoder

o.k.! Thank you very much! :)

[The Geek]

I tried it with PAL MPEG-1 and it works fine.
But I had to select the option "All files", as with "usable video files" the m1v file did not appear.

The Geek

[mpucoder]

I'll add that extension to the list.

[Trahald]

is it possible to have muxman align audios.. right now it puts one audio after each other (as well as each video) but if you have an audio that does not match the duration of the video it goes with, the next video/audio sequence will be out of sync. an option to have a non-seamless connection between the pairs so audio always matches would be cool. obviously this means having a way to determine 'pairs'. anyways.. food for thought

[SeeMoreDigital]

Originally posted by mpucoder
I'll add that extension to the list. That would be most useful thanks!

When I mux PAL Mpeg1 I get this: -

http://img94.exs.cx/img94/4348/muxmanpalmpeg17eq.gif


Cheers

[The Geek]

@SeeMoreDigital

That has nothing to do with the MPEG-1 format itself. Your file simply has GOPs that are too long. The DVD Video Standard limits a GOP length to 15 frames (for PAL).

That is very common with DVB, for example. What you need to do is to re-encode the oversized GOPs (so you replace an oversized GOP with two smaller GOPs, so that the DVD Video specification are met).
I use Cuttermaran + TMPGEnc to do that with DVB Streams.

The Geek

[SeeMoreDigital]

Originally posted by The Geek
That has nothing to do with the MPEG-1 format itself. Your file simply has GOPs that are too long. The DVD Video Standard limits a GOP length to 15 frames (for PAL).

That is very common with DVB, for example. What you need to do is to re-encode the oversized GOPs (so you replace an oversized GOP with two smaller GOPs, so that the DVD Video specification are met).
I use Cuttermaran + TMPGEnc to do that with DVB Streams. Thanks Geek,

So does this mean I'm going to have to re-encode the entire Mpeg1 stream then. Meaning another bounce down in quality :(

I guess when the DVD Video Standard was being created for PAL content, making the GOP length 25 frames instead of 15 would have been "too easy" and obvious....

But I have to admit I'm somewhat of a newbie when it comes to DVD structures.


Cheers

[The Geek]

So does this mean I'm going to have to re-encode the entire Mpeg1 stream then.

It means exactly what I said, nothing more, nothing less. You have to re-encode the oversized GOPs.
I never said anything about re-encoding the DVD compliant GOPs, too. Obviously, they don't have to be re-encoded, as they are already DVD compliant ;)

Now it depends on how many oversized GOPs you have in your MPEG-1 Stream. If every GOP is too long, well, then yes, you have to re-encode the whole thing.
DVB recordings only have a few of them. I've done that with 4 King of Queens Seasons from DVB-S, that are about 90 episodes (a few are still missing). I think 15 oversized GOPs in one episode was the maximum I've seen so far, all other episodes had around 10.
Using a high bitrate (6500 kbps), I don't see a quality loss. A GOP is short, and DVB-S ain't block-free anyway. With a low bitrate I was able to see the difference, but with 6500 I am not.

The Geek

[mpucoder]

Or you could use version 0.12, either when it comes out or the alpha version from my forum. This version addresses two problems related to DVB - GOP size and field pictures. Actually I think they are the same problem, that is the large GOPs are the result of field (vs frame) encoding for high motion, but I have no examples. The next Muxman doubles the table size to accomodate field encoding to 36 and removes the tv standard based limit.

As for the DVD standards, they do not discriminate. The number of frames is based on time, 0.6 seconds to be exact (25x0.6 = 15, 30x0.6 = 18, the NTSC limit)

[The Geek]

Actually I think they are the same problem, that is the large GOPs are the result of field (vs frame) encoding for high motion, but I have no examples.

I can't confirm that. Oversized GOPs occur also at low motion and even still scenes. And they do not always occur in the same scenes.
In my example, with 80 king of queens episodes, sometimes the intro has no oversized gops at all, and sometimes it has one or two. And the intro is always the same.

On the other hand, you can encode field based MPEG streams with max. 30 fields in a GOP.

The Geek

[mpucoder]

This is why I thought occasional field encoding might be the culprit. The actual limit is 30 (or 36 for NTSC) fields, regardless of picture_structure. And a GOP can contain a mixture of field and frame encoded pictures. But until version 0.12 there was no code to recognize and properly multiplex field encoded pictures, so the internal table limit was set to 18 pictures (regardless of type).
In version 0.12 it does not matter what the tv standard limit is, so long as there are no more than 36 pictures per GOP - it still has to protect against table over-indexing.

[Wojciech]

Originally posted by mpucoder
Available here (http://www.mpucoder.com/Muxman/)

New features:
Supports multiple video files
Able to import and encode bmp images as mpeg-2
Can make slideshows using any combination of motion video, pre-encoded stills/slides, and bmp images.

As always, compliance tested.

It would be very useful, if MuxMan could result as a simple "name.mpg" file and NOT ONLY a full strcture DVD folder(with VOB files etc.)

[sweetness]

MuxMan keeps rejecting BMP files.(0 file accepted, 1 files rejected)using version 0.11c

does the BMP have to be 720x480?or does it resize it?
i'm i doing something wrong?

thanks

[mpucoder]

From readme.txt:
"Image files (bmp) must be 720x480 or 720x576 and get encoded as mpeg-2."

[sweetness]

yes, thank you
i thought i did that but the preset in photoshop was NTSC D1 720x486. didn't see that. should have selected NTSC DV preset.