View Full Version : MuxMan 0.11 released


mpucoder
17th January 2005, 17:34
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.

Arky
17th January 2005, 20:47
Keep up the good work, mpucoder :)


Arky ;o)

Matthew
17th January 2005, 23:13
I can't wait until project file and cli support is implemented. Don't want to nag but is that in the pipeline for the near future, or is it some way off?

mpucoder
17th January 2005, 23:41
It's not that far off. First I need to finish up what didn't make this release (multiple audio and sub files, expand pre-encoded slideshows into individual frames, import bmp to subs, import sst, and, believe it or not, code was developed that didn't get added to recognize mpeg multichannel audio) and then define the file. It will mostly look like Scenarist, as I want to be able to import Scenarist scripts, but more relaxed with respect to the data section (there is mostly redundant information in there).
What holds it back is two things:
1) Text file processing/parsing - there is none to mention, and project files as well as subpicture scripts need it.
2) Design not exceeding the ability - I don't want to continually change the project file design as the program gains abilities. On the other hand, I don't want to release the full design spec with lots of unimplemented features.

But it is getting close to the right time to introduce it, as the complexity grows, so does the need to save and restore a project.

Matthew
18th January 2005, 00:12
Cool, sst support will be fantastic too. But I hope that the project file will be able to link just to ssts (like the GUI presumably will) and not require specification of every individual subpicture as in Scenarist's scripts. They look nightmarishingly complex.

And good luck with creating a commercial release, but I it will be great if you always maintain a decent stripped down free version for us cheapskates that would like an alternative to mplex/spumux/DVDAuthor :)

D3s7
18th January 2005, 02:32
Scenarist scripts aren't really that bad.. .just mind numbing repeating lines :)

MPUCoder, always glad to help out w/ the scripting aspect - I'm sure others who have a full knowledge of scenarist and the bitch she is will be willing to help that way too :)

Keep up the good work

katjarella
18th January 2005, 18:28
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.
Hello mpucoder.
I am pleased much, which you continue working with Stillframes. Here my first results:
Source Frames Time@25FPS
Motion01.m2v 25 00:00:01.00
Still01.bmp 1 00:00:00.01
Audio.mp2 750 00:00:30.00

A: Still01(audio end) + Audio = OK (00:00:30.0, 750Frames) Fields: 1500, Still fields: 1498, VOBU: 61, Sectors: 567
B: Motion01(actual) + Audio = OK, Audio Cut (00:00:01.0, 25Frames) Fields: 50, VOBU: 2, Sectors: 392
C: Motion01(audio end) + Audio = OK (00:00:30.0, 750Frames) Fields: 1500, Still fields: 1450, VOBU: 61, Sectors: 910

D: Motion01(actual) + Still01(audio end) + Audio = OK (00:00:30.0, 750Frames) Fields: 1500, Still fields: 1448
E: Still01(auto:12) + Motion01(actual) + Audio = Error and crash
F: Still01(auto:12) + Motion01(audio end) + Audio = Error and crash
G: Still01(725) + Motion01(actual) + Audio = OK (00:00:30.0, 750Frames) Fields: 1500, Still fields: 1448, VOBU: 61, Sectors: 940
H: Still01(25) + Motion01(actual) + Audio = OK, Audio Cut (00:00:02.0, 50Frames) Fields: 100, Still fields: 48, VOBU: 4, Sectors: 440
I: Motion01(actual) + Still01(25) + Audio = OK, Audio Cut (00:00:02.0, 50Frames) Fields: 100, Still fields: 48, VOBU: 4, Sectors: 440
J: Motion01(actual) + Still01(725) + Audio = OK (00:00:30.0, 750Frames) Fields: 1500, Still fields: 1448, VOBU: 61, Sectors: 940

K: Still01(25) = Error and crash
L: Motion01(actual) = OK (00:00:01.0, 25Frames) Fields: 50, VOBU: 2, Sectors: 375
M: Motion01(actual) + Still01(audio end) = OK (00:00:01.01, 26Frames) Fields: 52, VOBU: 3, Sectors: 406
N: Motion01(actual) + Still01(50) = Error and crash

Is it possible, a picture list to importing?
sourcenlist.lst:
imagefile1,750
imagefile2,750
videofile,-1
...

many thank you for your work.

mpucoder
18th January 2005, 23:06
Were these crashes during multiplexing, or in the multi-file dialog box? I found a bug in the dialog box where after setting a duration the spinners and set button were left enabled, but the file was no longer selected. Pressing set again would cause a crash. I've fixed that two ways - never allow set to operate if there is no selection (there was a bug in the code to detect this condition) and to re-select the last file after setting it.

I was wondering how you did test C since you can not set the duration of motion video, but then I saw that "reset" is left active, which will change motion video from "actual" to "default". Default is "audio ends" for the last file, and half a second for other positions. Extending motion video is possible, but shortening it is not (at the moment - edl functions are for later), which is why setting duration times is disabled. So use that with caution.

The blue results - this is normal. Video duration determines the multiplex duration. If you want the full audio then the last video must be set to "audio end".

jsoto
19th January 2005, 00:05
Grr, I didnīt see this thread yesterday....

First of all, a BIG THANK YOU.

And...., this is what I get muxing a 2 channel LPCM 24 bit 96KHz.
Do you see the number of channels? . Seems you are setting bit 3 (so channels number changes from 2 to 10) instead of bit 4 when trying to set the frequency. The same value (0x89) is stored in the IFO.


[0029] (L)PCM stream info: 137 [0089]
details of stream info:
Audio emphasis flag: 0
Audio mute flag: 0
Audio frame number: 0
Quantization word length: 24 bps
Audio sample frequency (0=48kHz): 0
Audio channels: 10
[002b] Dynamic range 128 [80]


jsoto

katjarella
19th January 2005, 00:06
Originally posted by mpucoder
Were these crashes during multiplexing, or in the multi-file dialog box?
the crash occured while multiplexing.

I was wondering how you did test C since you can not set the duration of motion video
Yes, I test much ( I like to twiddle ) :)

The blue results - this is normal.
Yes. I do understand it and it shouldn't be wrong.

----------------------------------------
There are still some minor Problems with the subtitles.
But I have to do some further tests.

mpucoder
19th January 2005, 00:40
@jsoto - yes, you're right, the wrong bit got set for 96K

@katjarella - tests K, L, M, and N are without audio?
If so K is a special case (the last frame can be extended without audio by up to one second, but the logic assumes there is audio) and N can not be done at all.
I'll test all of the failures and either make them work or fail gracefully.
There is a similar condition when you deliberately extend the video beyond the audio duration.

@all - I usually put the latest alpha executable and its changelog at http://www.mpucoder.com/Muxman/alpha/
Remember, this is an alpha, not fully tested by me yet, and not a release.

katjarella
19th January 2005, 01:24
Originally posted by mpucoder
@katjarella - tests K, L, M, and N are without audio?
Yes,without audio. K & N is for my special Menu. (DVDAuthor)

mpucoder
19th January 2005, 02:01
OK, the alpha should fix K.
There are two ways to make N work:
1) repeat the frame (use add) and set the duration to 1 second for both.
2) by cell still, not vobu still. ie multiplex it as normal, then set cell still time to 2.

mrslacker
19th January 2005, 02:02
katjarella,

So are you just taking the VTS_01_1.VOB as the still image input for DVDAuthor? Just wondering how people are using the still image output from MuxMan.

katjarella
19th January 2005, 04:55
@mpucoder
K: Still01(25) = OK (00:00:01.0, 25Frames) Fields: 50, Still fields: 48, VOBU: 1, Sectors: 31

K: & Variants...
Still01(50) = Error Multiplex operation failed. Probable causes: Excessive bitrate Still or slideshow video duration longer than audio.
Still01(750) = Error (00:00:00.12, 12Frames) Fields: 24, Still fields: 22, VOBU: 1, Sectors: 31
Still01(1500) = Error (00:00:00.12, 12Frames) Fields: 24, Still fields: 22, VOBU: 1, Sectors: 31

& N: In DVDMaestro it functions. Motion + Still(*Frames)

@mrslacker
Yes, I create *AudioFiles+Images to AudioSlide and Working perfect. With sub-titles it does not go unfortunately yet correctly. (DVDSubTools=OK, DVDAuthor:spumux=OK, all Other *2SUP = Error)

wondering : Why? , 1FrameVideo and *FrameAudio with mplex, does not function on all Playern correctly.

Sorry for my very bad English.

mpucoder
19th January 2005, 19:22
@katjarella - I did a long still without audio on Scenarist and it produced what I thought was not allowed - empty VOBUs (NAV pack only). Philips verifier calls them "oddities", but not errors. So I have removed the length restrictions for stills without audio.

The alpha contains the changes - all your tests now pass?

Sir Didymus
19th January 2005, 21:04
Wow... Impressive improvements...

So, first of all, thanks a lot for your hard work on MuxMan. :)

Want to report the following situation (not sure it is really a little bug):

1. Muxed a m2v + 1 Audio + 2 Subtitles.

2. MuxMan log is as follow:

MuxMan version 0.9
Accepted video D:\Temp\VIDEO_TS\VTS01\VideoFile.m2v size = 3663195936
Opened audio 1 file D:\Temp\VIDEO_TS\VTS01\AudioFile_80.ac3.
AC3 audio, frame size = 0x700.
Opened sub 1 file D:\Temp\VIDEO_TS\VTS01\Subpictures_20.sup.
Opened sub 2 file D:\Temp\VIDEO_TS\VTS01\Subpictures_22.sup.
20:07:32 Begin multiplex.
Maximum audio duration 304314 fields.
20:07:32 starting video file number 1.
End of video file
SeqEnd at DA57EF20.
P-STD buffer underflow by 460 bytes at 547790492, sector 2000917.
Bytes remaining in buffer = 0.
20:20:55 End multiplex.
Bitrate - avg: 5386345, min: 580266 (lba 0), max: 9045333 (lba 62103).
Fields: 304316, VOBU: 12598, Sectors: 2000917.

3. Mux log is reporting a single buffer underflow event (just at the end of the title) but MuxMan completed its task, so I decided to accept the risk of a little freezing in the picture, at the end of the movie.

4. The following VobEdit picture is showing Subtitles #20 & #21 are present in the VOB files...

http://img93.exs.cx/img93/6264/image18wd.gif

5. The following IfoEdit picture is just pointing to Subtitle #20 for both of the Subtitles...

http://img136.exs.cx/img136/9213/image22qz.gif

6. The playback (on a sw player) did not allow me to select the second subtitle...

All the best,
SD

katjarella
19th January 2005, 21:50
Originally posted by mpucoder
The alpha contains the changes - all your tests now pass? [/B]

My *Speed.Test.Results*: A:, B:, C:, D:, E:, F:, G:, H:, I:, J:, K*:, L:, M:, N: *& Variants

Perfect, NO Error or Crash.

You are the best one. Thank You.

mpucoder
19th January 2005, 22:14
SD - I noticed the same message on a run that is longer than the one I use for testing. As far as I can tell it is false, and caused by the changes made for stills upsetting the model. I've been running tests for 2 hours now, and hope to figure it out soon.

Are you sure you assigned all the subpictures to tracks and display modes? Muxman will multiplex them even if you did not. It will also show a warning under the last subpicture area as you work.

LigH
19th January 2005, 22:24
I'm not sure if this is related to karjarella's problem, but:

A few years ago, when we produced image galleries with Sonic DVD Creator in a DVD studio, this tool always arranged consecutive still frames with a distance of 10 frames in the timeline.

mpucoder
19th January 2005, 23:22
@Sir Didymus - alpha 10c (http://www.mpucoder.com/Muxman/alpha/) fixes the false underrun report.
For compliance Muxman inserts an end_of_sequence header if eof is reached without detecting it. Unfortunately both the eof and eos added the last frame to the decode list.

influenza
20th January 2005, 10:34
Wow, the support for scenarist scripts would be very neat. Especially if it's a bit faster than scenarist (can it be slower I wonder ;)).

Nice work Mpucoder :)

Sir Didymus
20th January 2005, 11:27
Originally posted by mpucoder
Are you sure you assigned all the subpictures to tracks and display modes? Muxman will multiplex them even if you did not. It will also show a warning under the last subpicture area as you work.

You are definitely right. Checked and working. I assigned SP to tracks [it was done by default to track 1 & 2] but I did not define any display mode. My fault... Wrongly assumed that all default assignements were sufficient...

What do you mean with "It will also show a warning..." ? Are you stating something about some future releases of MuxMan ?

mpucoder
20th January 2005, 15:47
No, this is something it has done since 0.3
At the bottom right of the subpicture area, under the assignment buttons, is a line of text that tells you what is missing.

Sir Didymus
20th January 2005, 16:41
Thanks mpucoder!!!
Missed this info, which is very useful (and new to me...).

Next time I will use MuxMan, I'd better looking at the monitor, not at the keyboard...

:D

mpucoder
20th January 2005, 17:25
LOL - first time with 16:9?

mpucoder
24th January 2005, 15:57
Version 0.10 is now ready here (http://www.mpucoder.com/Muxman/)

New features:
added code to detect mpeg audio multi-channel extension
added 2 more audio tracks for total of 4
audio is now multi-file
modified progress bar to work with multiple video files and stills

bugs fixed:
multi-file dialog crash fixed
PAL still crash fixed
fixed audio attributes for LPCM 96K
false buffer underflow report fixed
P-STD model corrupted by adjacent motion video files

E-Male
24th January 2005, 16:18
i got a feature request, no idea how hard to add it would be

i often put vcds on dvd, keeping the video untouched, just re-encoding the audio to 48k

i think it would work faster if the re-encoding would be done while muxing

so would it be possible to integrate samplerate-conversion and mp2-encoding into muxman?

thx

stickboy
24th January 2005, 20:04
Originally posted by mpucoder
bugs fixed:
multi-file dialog crash fixed
Here's another one:
Click the "..." button for Video or Audio, then click "Cancel". You get the "Import File List" dialog anyway.

If you press the "Up" button, Muxman crashes.

This also happens with a non-empty list if no list items are selected.
Originally posted by E-Male
so would it be possible to integrate samplerate-conversion and mp2-encoding into muxman?Muxman's a muxer... IMO it shouldn't be doing this sort of thing. Surely there are command-line tools to demux, resample, and encode to MP2 that would work better anyway?

E-Male
24th January 2005, 20:25
seperating the steps makes things slower and more complicated
working with images and joining multiple videos or audios could also be done seperately, but it is not, which is good

mpucoder
24th January 2005, 21:35
Originally posted by stickboy
Here's another one:
Click the "..." button for Video or Audio, then click "Cancel". You get the "Import File List" dialog anyway.
That's supposed to happen


If you press the "Up" button, Muxman crashes.
This also happens with a non-empty list if no list items are selected.
That isn't :eek:

Muxman's a muxer... IMO it shouldn't be doing this sort of thing.
Exactly. Yes, it can encode a single I-frame, but that's as far as it goes. Muxman has no need for audio processing such as decoding (which format? they all require licensing) upsampling and encoding.

E-Male
24th January 2005, 22:28
ok, i'll make me a batchfile for preprocessing

SeeMoreDigital
24th January 2005, 23:52
Cool.... you can now mux 4No audio streams.... cool!

When importing "image" files (which I've tried to do), it might be handy if you could make it so your application states which type of image files are supported please (ie: .BMP)?


Thanks mpucoder

SeeMoreDigital
25th January 2005, 12:13
Another thing about "image" file importing!

It seems 720x480/576 images are automatically assigned a DAR of 4:3. Is there any way this can be selectable between 4:3 and 16:9 DAR?

And could it be made possible to import images files that contain higher resolutions than 720x480/576 pixels?

There's always something more ;)


Cheers

mrslacker
26th January 2005, 02:27
Originally posted by mpucoder
Version 0.10 is now ready here (http://www.mpucoder.com/Muxman/)
...
audio is now multi-file
...
I never got a chance to say thanks for this an multi-file video.... THANKS! This has become a very useful tool for me. I'll be testing multi-file input.

mpucoder
26th January 2005, 03:19
De nada - or You're welcome.

@SeeMoreDigital. I was wondering when someone would notice that. There is another dialog in the planning to set DAR, but since it involves mpeg decoding isn't ready yet. What you can do as a workaround is include a 16:9 video file (still or motion) and then remove it from the list. Just the act of accepting a video file will establish the DAR.

SeeMoreDigital
26th January 2005, 13:54
Originally posted by mpucoder
... What you can do as a workaround is include a 16:9 video file (still or motion) and then remove it from the list. Just the act of accepting a video file will establish the DAR. Thanks... that works well :)

Being able to import images and merge video streams is a great addition to the application.

But, is there any particular reason why, when multiple images or video streams added (and then "Set", via the "Import File List"), that a chapter point is not automatically created?

http://img178.exs.cx/img178/4315/muxmanimportfilelist2mu.gif

Could a button be added to the GUI to "mark" a chapter point?


Cheers

nnigam
26th January 2005, 15:51
Thanks mpucoder for a great tool. I am now able to burn dvd's that work perfectly. I still have to try the subtitles, and chapters. I will now free up some disk space by getting rid of the other dvd authoring programs on my pc.

A suggestion : How about a selection to create mini dvd's so we can burn to cd for testing output.

erdoke
27th January 2005, 22:32
Multiplexed an NTSC movie (rare exception for me) with v. 0.10 of Muxman. When I opened it in PGCEdit (0.4.8) I got this warning message again:
http://erdoke.uw.hu/Pix/PGCEditErrorOnMuxman.png

Only one audio and one subtitle stream.
BTW when can we expect handling more than 3 subtitle streams to be added?
THX

mrslacker
27th January 2005, 22:37
Originally posted by erdoke
Multiplexed an NTSC movie (rare exception for me) with v. 0.10 of Muxman. When I opened it in PGCEdit (0.4.8) I got this warning message again:
http://erdoke.uw.hu/Pix/PGCEditErrorOnMuxman.png

Only one audio and one subtitle stream.

I get that error routinely with MuxMan discs. It was happening with multi-file inputs. When using pre-joined files, I don't think I got the error. I will double check.

mrslacker
27th January 2005, 22:40
Small request: Could the "Input file list" dialog be made resizable or at least have a horizontal scroll for long file names? Thanks.

mpucoder
27th January 2005, 22:56
The cell times should add up in the next release (you can check its alpha version at http://www.mpucoder.com/Muxman/alpha/ use 11e or later)

This only happens with NTSC, and only with cells that have an odd number of fields. The PGC total is correct, the individual cell times can be short one frame.

@mrslacker - I never thought anyone would have a filename not fit, but I will enable horizontal scroll.

erdoke
27th January 2005, 23:00
THX mpucoder, it seemed to be an administrative issue anyway for I had no problems with the playback.

Any plans on increasing the number of multiplexable subtitle number soon?
And subtitle color table support? At least to be able to copy colors?

mpucoder
27th January 2005, 23:02
What's really strange is I was testing subpicture pointers to make sure they were not spanning cells when the verifier spat out an error concerning cell elapsed time. So the problem got fixed before I read the post.

btw alpha 11e now processes sst files.

erdoke
27th January 2005, 23:04
Originally posted by mpucoder
btw alpha 11e now processes sst files.

Good news indeed. ;)

Sorry, I edited my previous post while you were answering. Support of Muxman is really quick here. :)

mpucoder
27th January 2005, 23:10
Those are a couple good requests. Muxman internally can process all 32 subpicture streams, 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.

The color tables is another story. Eventually the project file will carry it, and I'd like to avoid a whole bunch of little text files to import for each aspect of the project.

mpucoder
27th January 2005, 23:17
This is kinda pre-release info, but. I added a line to the sst file to allow Muxman to correct for the errors in SubRip 1.17.1 (and I have told Zuggy about them in this thread (http://forum.doom9.org/showthread.php?s=&threadid=87912) , but so far no fix)
the line looks like this:

Generator SubRip1.17.1 25257

the number (25257 in this example) is the initial vobu_s_ptm value (SubRip does not account for this when computing times) which you can get from VobEdit, first NAV pack.
Other corrections made for SubRip are to get the pixel mapping correct.

bourtzovlakas
28th January 2005, 10:12
Hello,
Is it possible to add an option,to copy the color palette from the original IFO to the new IFO,created by Muxman?

Thanks

mpucoder
31st January 2005, 18:58
Version 0.11 is now available here (http://www.mpucoder.com/Muxman/)

New features:
added sst (Scenarist subpicture script)
added ini file, saves window position, log file name, and destination folder

other changes:
internal changes to prepare for CLI ability

bug fixes:
fixed problem accepting multiple video with Closed Captions

Matthew
1st February 2005, 00:20
Good stuff.

But I just tried sst (PAL), saved from a sub/idx using subresync, and the subs did not appear. The entry is there in the IFO, but vobsub cannot find any subs. While this may be the fault of subresync, perhaps some sort of relaxation would be desirable :) I included the muxman log and the start of the sst.

Also, unless I'm mistaken, to use automatic pan and scan Scenarist requires the video to have an aspect ratio of 4:3. This is inconsistent with MuxMan.


----
MuxMan version 0.11
Accepted video H:\minoritychap1\minoritychap1.mpv size = 290610004
Accepted audio H:\minoritychap1\MINORITYCHAP1 AC3 T01 3_2ch 448Kbps DELAY 0ms.ac3
Opened sub 1 file D:\hjhj\minoritychap1.sst.
Pixel_Area values 0 573 are incorrect, using default of 2 574.
Display_Area Y values 2 575 are incorrect, using default of 2 574.
.\minoritychap1_0001.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0002.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0003.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0004.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0005.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0006.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0007.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0008.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0009.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0010.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0011.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0012.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0013.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0014.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0015.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0016.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0017.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0018.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0019.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0020.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0021.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0022.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0023.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0024.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0025.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0026.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0027.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0028.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0029.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0030.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0031.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0032.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0033.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0034.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0035.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0036.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0037.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0038.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0039.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0040.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0041.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0042.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0043.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0044.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0045.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0046.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0047.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0048.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0049.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0050.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0051.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0052.bmp height of 574 is less than the required height of 575. file skipped.
.\minoritychap1_0053.bmp height of 574 is less than the required height of 575. file skipped.
10:01:38 Begin multiplex.
Maximum audio duration 19360 fields.
10:01:38 starting video file number 1.
SeqEnd at 11525B50.
Bytes remaining in buffer = 0.
10:02:14 End multiplex.
Bitrate - avg: 6568652, min: 3969969 (lba 8649), max: 9011200 (lba 8385).
Fields: 19374, VOBU: 648, Sectors: 155348.
----
st_format 2
Display_Start non_forced
TV_Type PAL
Tape_Type NON_DROP
Pixel_Area (0 573)
Directory .
Subtitle minoritychap1
Display_Area (0 2 719 575)
Contrast (15 15 15 0)

PA (0 0 255 - - - )
E1 (255 0 0 - - - )
E2 (0 0 0 - - - )
BG (255 255 255 - - - )

SP_NUMBER START END FILE_NAME
Color (3 4 14 3)
Contrast (13 15 0 15)
0001 00:01:18:16 00:01:19:20 minoritychap1_0001.bmp
0002 00:01:27:05 00:01:29:12 minoritychap1_0002.bmp
0003 00:01:29:17 00:01:31:13 minoritychap1_0003.bmp
0004 00:01:51:18 00:01:54:13 minoritychap1_0004.bmp
0005 00:02:25:23 00:02:28:02 minoritychap1_0005.bmp
0006 00:02:28:08 00:02:29:23 minoritychap1_0006.bmp
0007 00:02:44:05 00:02:46:21 minoritychap1_0007.bmp
0008 00:02:47:01 00:02:50:02 minoritychap1_0008.bmp
0009 00:02:50:07 00:02:54:22 minoritychap1_0009.bmp
0010 00:02:55:02 00:02:58:12 minoritychap1_0010.bmp
0011 00:02:58:17 00:03:01:07 minoritychap1_0011.bmp
0012 00:03:05:10 00:03:07:05 minoritychap1_0012.bmp
0013 00:03:08:09 00:03:11:10 minoritychap1_0013.bmp
0014 00:03:11:15 00:03:13:10 minoritychap1_0014.bmp
0015 00:03:13:16 00:03:17:24 minoritychap1_0015.bmp
0016 00:03:18:04 00:03:19:03 minoritychap1_0016.bmp

mpucoder
1st February 2005, 06:10
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
1st February 2005, 08:00
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
1st February 2005, 13:47
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
1st February 2005, 15:09
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
1st February 2005, 15:26
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
1st February 2005, 20:54
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
1st February 2005, 21:59
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
2nd February 2005, 00:56
@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
2nd February 2005, 02:19
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
2nd February 2005, 03:37
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
2nd February 2005, 23:21
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
3rd February 2005, 01:13
That was an interesting bug. The fixed version is available at the Muxman homepage (http://www.mpucoder.com/Muxman/)

lordyu
3rd February 2005, 16:16
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
4th February 2005, 14:35
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
4th February 2005, 15:40
Oops. Fixed for the next release.

Trahald
4th February 2005, 20:11
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
4th February 2005, 21:39
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
4th February 2005, 22:43
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
5th February 2005, 17:34
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
6th February 2005, 02:02
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
6th February 2005, 04:13
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
8th February 2005, 09:52
The .zip file of Muxman 0.11c contains an .exe file named 0.11b....
Forgot to rename it, possibly?

Ebobtron
8th February 2005, 14:20
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
8th February 2005, 15:05
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
8th February 2005, 15:39
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
8th February 2005, 21:05
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
8th February 2005, 23:29
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
9th February 2005, 11:40
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
9th February 2005, 16:02
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
9th February 2005, 16:57
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
9th February 2005, 17:11
@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
10th February 2005, 22:04
@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
10th February 2005, 22:12
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
10th February 2005, 22:20
@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
10th February 2005, 22:21
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
10th February 2005, 22:24
@mpucoder

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

The Geek
10th February 2005, 22:45
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
10th February 2005, 22:47
I'll add that extension to the list.

Trahald
10th February 2005, 22:59
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
10th February 2005, 23:09
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
11th February 2005, 00:20
@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
11th February 2005, 11:02
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
11th February 2005, 11:46
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
11th February 2005, 15:36
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
11th February 2005, 15:44
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
11th February 2005, 15:56
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
11th February 2005, 17:08
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
11th February 2005, 19:39
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
11th February 2005, 19:51
From readme.txt:
"Image files (bmp) must be 720x480 or 720x576 and get encoded as mpeg-2."

sweetness
11th February 2005, 21:03
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.

john3voltas
13th February 2005, 02:03
Hello :)
Great tool you got here MPUCoder ;-)
Sorry to bump in on the good conversation but I have 2 doubts.
The 1st is related to SUP subtitles.
After muxing my m2v + ac3 + sup, do I need to edit the generated IFO file to patch the subs colors like with Ifoedit?
I'm raising this because I did some test runs and I got weird color in my subs that were extracted with Vobedit.
The 2nd doubt is related to underflows.
I used Peter Cheat's NuEnc to encode my m2v and I used the original ac3 file extracted with DGMPGDec. The subs I already explained above.
Here is my log:
MuxMan version 0.11
Accepted video D:\POAZKABAN.m2v size = 1874953676
Accepted audio D:\POAZKABAN\D2V\POAZKABAN AC3 T01 3_2ch 384Kbps DELAY 0ms.ac3
Opened sub 1 file D:\POAZKABAN\VOBS\VTS_01_1.21.sup.
22:31:18 Begin multiplex.
Maximum audio duration 407560 fields.
22:31:18 starting video file number 1.
SubPicture stream 0 backwards move in time.
P-STD buffer underflow by 468 bytes at 391788092, sector 653136.
P-STD buffer underflow by 1091 bytes at 391791692, sector 653161.
P-STD buffer underflow by 2298 bytes at 391795292, sector 653186.
P-STD buffer underflow by 1201 bytes at 391798892, sector 653210.
P-STD buffer underflow by 1178 bytes at 391802492, sector 653235.
P-STD buffer underflow by 2993 bytes at 391806092, sector 653259.
P-STD buffer underflow by 1180 bytes at 391809692, sector 653284.
P-STD buffer underflow by 1284 bytes at 391813292, sector 653309.
P-STD buffer underflow by 1854 bytes at 391816892, sector 653333.
P-STD buffer underflow by 1155 bytes at 391820492, sector 653358.
P-STD buffer underflow by 1375 bytes at 391824092, sector 653382.
P-STD buffer underflow by 3335 bytes at 391827692, sector 653407.
P-STD buffer underflow by 1217 bytes at 391831292, sector 653432.
P-STD buffer underflow by 1365 bytes at 391834892, sector 653456.
P-STD buffer underflow by 4177 bytes at 391838492, sector 653755.
P-STD buffer underflow by 1185 bytes at 391842092, sector 653755.
P-STD buffer underflow by 1074 bytes at 391845692, sector 653755.
P-STD buffer underflow by 2546 bytes at 391849292, sector 653755.
P-STD buffer underflow by 1313 bytes at 391852892, sector 653755.
P-STD buffer underflow by 1145 bytes at 391856492, sector 653755.
P-STD buffer underflow by 2887 bytes at 391860092, sector 653755.
P-STD buffer underflow by 1601 bytes at 391863692, sector 653755.
P-STD buffer underflow by 1162 bytes at 391867292, sector 653755.
P-STD buffer underflow by 3016 bytes at 391870892, sector 653755.
P-STD buffer underflow by 1603 bytes at 391874492, sector 653755.
P-STD buffer underflow by 1261 bytes at 391878092, sector 653755.
Cell map size 50.
SeqEnd at 6FC185C8.
Bytes remaining in buffer = 44964.
22:42:43 End multiplex.
Bitrate - avg: 2296042, min: 535630 (lba 0), max: 21599573 (lba 652963).
Fields: 407562, VOBU: 13585, Sectors: 1142309.
Video decoder buffer underflowed 26 times.
Check c:\muxman.log for details.
Resulting DVD will probably not play smoothly.
Can you tell me if this is happening at the begining or at the end of the movie?
Could it have something to do with an m2v encoding underflow?
NuEnc reported 0 underflows when it finished encoding :rolleyes:
TIA for any help you can give me.

mpucoder
13th February 2005, 03:03
yes, you currently have to copy the colors.
max: 21599573 (lba 652963)
Your maximum bitrate is over 2 times the allowable rate (10080000). These peaks must be short, as Muxman almost managed to multiplex it (the total bytes that could not be delivered on time is what is left in the buffer), just not short enough, or low enough. I'm not familiar with NuEnc, but there must be some control for maximum bitrate.

You also have a problem with your sup file - backwards time movement. VobEdit does this when crossing vob boundaries, use PGCDeMux instead.

mpucoder
13th February 2005, 03:16
This is a very short section of your movie that has the high bitrate, from frame 108823 to 108848, or 1:12:32.23 to 1:12:33.23 Just 26 frames

To get the frame number (PAL) use the number after "bytes at" - it is the internal clock, as follows:
(clock - 25292) / 3600

john3voltas
13th February 2005, 12:31
@mpucoder,
Thank you so much for the precious information you have given me.
NuEnc is a frontend for ffmpeg's libavcodec.
Peter Cheat is trying to fix libavcodec because it has a lot of bugs in the underflows business.
Also the GUI that he's using is based on Nic's QuEnc.
In fact NuEnc has a field where you can set the Maxbitrate and another one for the minbitrate.
But it seems that sometimes the encoder doesn't respect the Maxbitrate...
I'll talk to Peter and see if he can do something about it.
Regarding Muxman I'd like to pose just 2 more questions:
1-Do you plan on implementing a feature in Muxman that will possibly allow us to get the right subtitle colors from the source and patch the destination with it? Or are you going to leave that for Ifoedit&Cia?
2-Would it be possible to have a 'settings button' with a window where you would choose where to put the muxman.log and the muxman.xml along with some other preferences? But I'm sure you were already planning on doing something similar, weren't you?
Thanks for sharing your work with us.
Bye

Trahald
13th February 2005, 16:36
yeah. nuenc tends to do better than quenc in that regaurd. peters mission was to avoid the underflows through proper vbv control more than bitrate restriction. (which would seem to be the same thing but is only partially so) but apparently there is some more work to do.

Paazabel
13th February 2005, 22:11
I've been trying to convert NTSC footage to DVD for about a week, now. I've been using commercial tools, such that I've had at my disposal, and have had zero luck. All but one wanted to re-encode all the video, which was already good quality, compliant MPEG-2. One actually field-reversed the thing, which probably made it dangerous to watch for people with epilepsy ...

Finally, I came across MuxMan.

I'm using Canopus ProCoder, and MuxMan takes all the pieces and makes a nice whole out of them. I wish I knew why PAY software I was using didn't do as good of a job, but I guess that's another story.

Thanks, mpucoder. Keep up the good work. This is a great tool and I look forward to seeing where it goes.

richarddd
15th February 2005, 04:39
What would you recommend using to demux a DVD into DVD compliant elementary streams (video, audio, sub) and chapter index that muxman can then mux back together?

erdoke
15th February 2005, 12:53
Originally posted by richarddd
What would you recommend using to demux a DVD into DVD compliant elementary streams (video, audio, sub) and chapter index that muxman can then mux back together?

PGCDemux now seems to be working fine. You can find it in the IFO/VOB Editors section.

E-Male
15th February 2005, 16:23
it seems that the combination SubtitleCreator and MuxMan produces wrong colors

mpucoder
15th February 2005, 17:35
The colors for subtitles are contained in the ifo, not the subtitle itself. For the time being these have to be set with and editor such as PgcEdit or IfoEdit, otherwise you get Muxman's default colors.

thastarter
19th February 2005, 13:56
i have a dvd ripped on my hard disk, and when i try to load all the 4 vob's, the program only accepts the first one, saying that the others are not the same resolution or bitrate. how can it be, when all the files ale from the same dvd? will you fix that??

mpucoder
19th February 2005, 15:46
Muxman doesn't accept vob files at all, so I don't know what you are actually trying to use as input. And it does not check bitrate.
If the files are actually elementary video streams (m2v) it is still possible that they do not match unless they are from the same title.

john3voltas
19th February 2005, 19:49
Originally posted by mpucoder
...otherwise you get Muxman's default colors.

Hmmmm :)
Anyway I can change those defaults colors to my own set of colors?
That is, instead of using Ifoedit or something similar?
I'd like to be able to change the default colors from within Muxman ;)
If that's not asking too much :D
Regards

thastarter
20th February 2005, 13:49
my mistake.... i forgot that i demuxed the vobs using the mpeg tools in tmpgencoder, and then i loaded the m2v files in muxman, and it didn't accept it

mpucoder
20th February 2005, 17:09
Most probably they were not demuxed properly. You cannot demux each vob seperately or you end up with files that do not start with a sequence header. Instead you must demux the files as a set. PgcDemux or VobEdit can do this.

This happens because the vob files from one titleset are all large chunks of the data split at arbitrary points - by size, not content - so only the first vob file is guaranteed to start with the proper headers.

David007
2nd November 2005, 19:47
Hello!

I'm new here and I have just started to use the program MuxMan. It's a very good program, but I have some problems. I'd like to now, if it is possible to combine letterbox and wide versions of subtitles into one stream.

I have found this explanation:

If you want to keep the original subtitles, load them in the correct order (you can tell the order by the filename: Subpictures_20.sup is the first, Subpictures_21.sup is the second, and so on). If you created 2 streams for a subtitle, add the wide version first and click on wide button. Then for the next stream, add the letterbox
version and click on LB button. Make sure that the languages of both streams are the same.

If I follow the explanation and do as it says, it doesnt work. I have upload the image, which shows, how I did this.

Please, help me.

SeeMoreDigital
2nd November 2005, 19:51
Hi David... welcome to the forum.

Are you using MuxMan 0.11 or the newer MuxMan 0.14 (http://forum.doom9.org/showthread.php?t=93553)?


Cheers

David007
2nd November 2005, 20:26
MuxMan 0.14g

SeeMoreDigital
2nd November 2005, 20:32
MuxMan 0.14gBest to make your posts/suggestions/requests in the newer version thread ;)

vigi_lante
27th March 2006, 23:48
It is possible to use non-standard resolutions ? (480x480 and 544x480)

Anime
4th November 2007, 12:32
(i cannot find another newer muxman thread... so have to bumbp this....) sorry

hello everyone (a feedback from a poor user)
actually i had never ever seen muxman fullbody before on my monitor due to i use my actual TV, RGB input for PC
it only supports 640x480, due to my room is so small with full of DVD and stuff, i actually have no space for a new monitor unless i buy a NEW TV with higher resolution RGB input but it isn't cheap.... below image is all i can see but not touching any muxman button.....

http://i66.photobucket.com/albums/h245/vaxva/misc/MUXMAN_015R.gif

all along my usage of muxman is CLI by subtitle creator....
thats the only way i could get it running....
because {tab} to change selection is also not working in muxman

will there be a day that...muxman have capabitly to resize for smaller resolution or making {TAB on keyboard} work (so i can tab to destination button? because i wanted to use .sst because of subtitle flickering issue but too bad subtitlecreator doesn't support it or will never.....?
http://radkongo.wordpress.com/2007/10/08/overlapping-and-consecutive-subtitles-without-flicker/

lastly i also like to mention if above process can be done by muxman
> "-" for same {END_TIME} -> {START_TIME} that will save alot people alot of time

thanks for making muxman.
any sugestion is welcome......

kumi
4th November 2007, 18:41
In the meantime you can press Alt-Space + Move, and use your arrow keys to move the window past the edges of your viewable area.

Politiken
20th January 2008, 12:15
MuxMan ver. 0.15R defaults to "NTSC 720x480 MPEG-2 4:3" if using a bitmap as the videopart !

How do I change this to "PAL 720x576 MPEG-2 4:3" or "PAL 720x576 MPEG-2 16:9" ?

regards Pol