Muxman 0.13 released

[mpucoder]

A great deal of work has gone into changing Muxman ifo generation from a simple "canned" set of tables to being compiled from a database. Unfortunately, the work isn't complete enough to allow the Navigation section to be user defined.

But this release does have 3 improvements:
Definable subpicture palette
Improved I-Frame encoder
Frame-accurate chapters (provided the chapter begins on an I frame)

Available from the Muxman homepage (http://www.mpucoder.com/Muxman/)

Please consult the mxp documentation (http://www.mpucoder.com/Muxman/mxp/index.html) especially the new Settings Section (http://www.mpucoder.com/Muxman/mxp/settings.html)

[D3s7]

Excellent advancements.... It won't be long before Scenarist is obsolete for what we need it for :)

Question: Will there be support to specify channels for audio/subtitles that's out of order.. IE: audio 1 = 84.

Scenarist requires you dummy 80-83 in order to do that.

Thanks

- D3s7

[mpucoder]

Scenarist is just enforcing the specs, audio and subpicture stream numbers should be consecutive. Right now, and for the foreseeable future, Muxman will not allow manual stream assignments. When it does the specs will still be enforced by some mechanism.
At present, with only one title, the audio and subpicture stream numbers follow the value in the scp or mxp file. But once Muxman starts working with multiple titles per titleset the script file stream numbers will be relative to each segment, but not necessarily the same as the titleset. This will happen if two titles have different requirements, e.g. title 1 has one audio stream of 5.1 DD, while title 2 has one audio stream of 2.0 DD.

But - it should not be necessary to skip stream numbers. There are 2 places where absolute numbers, rather than symbolic names, are used in scripts. One is line numbers for the "goto" command. Muxman changes the way commands are defined into what resembles assembler source, complete with labels.
The other place where numbers are used is to specify a "stream" in the SetSTN command. I prefer to call this a track, as it is the number used to index a table in the PGC which then supplies the actual stream number. This number remains the same even if stream numbers are reassigned.

[D3s7]

Understood... and I'm not sure the attraction to it for authoring houses

The problem we run into in Scenarist is when a particular PGC/VOBID uses different stream assignments from the rest of the Title. Scenarist won't except those for mux (as can be understood) forcing us to dummy the appropriate streams. Not really a problem for PGC demuxes but for VOBID demuxes it can be an issue for Seamless cells


Seems more and more the DVD "Specs" are more "Recommended guidelines but feel free to break if you wish" :)

[mpucoder]

Are you saying that there are titles which have one or more Vobs with different stream numbers than the rest of the title? This makes little sense - how does the player access a stream that suddenly appears in the middle of a title. As far as I know, and this is how I planned to implement in Muxman, all the segments (or "tracks" in Scenarist) must have the same video attributes, and have the same number and type of audio/sub streams.

I can understand a segment using different streams than others in the same titleset, this is commonl. Not in the same title, though, but a seperate title.

[D3s7]

unfortunatly, yes...

a few have "additional" audio tracks in one PGC -vs- another (same VOBID) - Finding Nemo for example, 80,81,82
PGC 1 uses 80,82 - PGC 2 uses 81 (example - not sure if that's the correct mapping) - demuxing this by vobid isn't an issue but 81 must be dummied on other assets in that PGC.

that's just one example but I've run across 4 or 5 movies like that. The problem is in order to dummy 81 across the other vobid's causes the cells to have to be linked non-seamless... Currently one of the solutions is to flip 82 and 81 so you have 80,81 on the main and the "extra" pgc uses 82

[mpucoder]

Is this the R1 version? I'm not into buying animated movies (or G ratings - btw, why won't my V chip block the teletubbies, I want ONLY R!), but in this case I could make an exception if it demonstrates a DVD oddity.

[D3s7]

I've got 3 still files that I use for Scenarist that when trying to import them into Muxman 13 (tried 12 as well) it locks the interface hard... have to kill the process to get out of it.

Want me to email them to you?

[mpucoder]

sure - muxman (at) mpucoder (dot) com (have to type it this way or I get a flood of email in Korean - have no idea what they're selling)

[sweetness]

when i mux only a bmp or a m2v file(no audio no subs) muxman crashes(encountered an error message). ifoedit reports that there is no titleset tables when i do a get vts sectors(no video_ts.ifo is created)

in version 11c it muxed everything and the operation compete window pops up but muxman close once ok is pressed. ifoedit does not complain.

[mpucoder]

What is the error message? What version of Windows? What does the Muxman log say?

[sweetness]

the microsoft "MunxMan.exe has encountered a problem and needs to close. We are sorry for the inconvenience."

win xp sp2

it crashes once the progress bar is done.

tried v.12c and it does the same thing as v.11 it closes once ok is pressed.
v.13 crash all the time now with audio or not.:(

[D3s7]

Originally posted by sweetness
when i mux only a bmp or a m2v file(no audio no subs) muxman crashes(encountered an error message). ifoedit reports that there is no titleset tables when i do a get vts sectors(no video_ts.ifo is created)

in version 11c it muxed everything and the operation compete window pops up but muxman close once ok is pressed. ifoedit does not complain.

I noted this issue myself and partially tracked it down to the installed version of comdlg32.dll....

version 6.0.2900.xxx seems to work fine where as 6.0.2800.xxx doesn't.
I was only able to test this theory on one machine but upgrading the dll seemed to resolve the issue - i assumed the newer dll was from xp sp2 but it may be from the .net 2003 extensions as well....

[mpucoder]

I'm fairly certain this bug has been squashed by version 0.13c

@sweetness - Muxman is supposed to close when you click OK. That will probably change in the future when I'm certain that the program can run project after project without problems.

[sweetness]

thanks tried out .13c and seems to work good.
also notice some dummy menus.:)

BTW creating 16:9 stills Display Mode=Only Pan Scan doesn't work, muxman displays 4:3. but P/S and LB or Only Letterbox works.

[Sir Didymus]

Just to confirm 0.13c have solved the issue: no need to upgrade comdlg32.dll...

All the best,
SD

[Zeul]

@SD
Are you working from a mxp project file? I have noticed that 0.13 has changed the scripting for pan. It was Display Mode=Only Pan Scan -> it is now Display Mode=Only Panscan.

[sweetness]

@Zeul
yes thank you. i even check the site too, but missed that the space was gone.
oh ya wrong guy.:) that's ok i get that all the time.

[mpucoder]

That's true, I changed some keywords to be the same as Scenarist.

video display mode Only Pan Scan changed to Only Panscan (as noted above)

subpicture display mode PS changed to Pan in all combinations (Pan, Letter/Pan, Wide/Pan, Wide/Letter/Pan

Sorry for not drawing more attention to that. Also Uop can be specified in scenes (but not put into the vob - oops)

[mpucoder]

btw, if you want a sneak peek at some stuff. Here's a sample of the vm commands (http://www.mpucoder.com/Muxman/alpha/cmd_sample_mxp.txt) syntax that will be used.
And here is the auto generated navigation (http://www.mpucoder.com/Muxman/alpha/autogen_mxp.txt) currently built for you.

[Sir Didymus]

Originally posted by mpucoder
btw, if you want a sneak peek at some stuff. Here's a sample of the vm commands (http://www.mpucoder.com/Muxman/alpha/cmd_sample_mxp.txt) syntax that will be used.
And here is the auto generated navigation (http://www.mpucoder.com/Muxman/alpha/autogen_mxp.txt) currently built for you.

Wow!!! :)

very happy about this info, even though the matter is quickly approaching [or better, it is already beyond...] the limits of my poor knowledge... hope it will be useful to extend it and to learn from your huge work...

For the moment, let me report a little discrepancy [not sure it is a glitch...] between 0.12d and 0.13c.

The project structure is very simple (one m2v, one ac3, 32 chapter points), as follow:


...[skip]...
Section=Content
{
Item=Segment
{
Name=Segment_1
Display Mode=Only Letterbox
Item=Video Stream
{
Coding Mode=Mpeg-2
Standard=PAL
CC Field 1=No
CC Field 2=No
Item=Video Play
{
File=E:\JONNY_ENGLISH\demux\VTS01\PGC1\VideoFile.m2v
Size=3534447192
Duration=Actual
}
}
Item=Audio Stream
{
Stream Number=1
Language=it
Language Extension=1
Delay=0
Type=04c5
Frame Size=1536
Item=Audio Play
{
File=E:\JONNY_ENGLISH\demux\VTS01\PGC1\AudioFile_81.ac3
Size=241439232
}
}
Item=Scene List
{
Item=Scene
{
Name=Segment_1_scn1
Scene Time=00:00:00:00
Uop=00000000
}

...[skip]...

Item=Scene
{
Name=Segment_1_scn31
Scene Time=01:19:31:20
Uop=00000000
}
Item=Scene
{
Name=Segment_1_scn32
Scene Time=01:23:50:00
Uop=00000000
}
}
}
}


the chapter list is:

5628
11784
20268
25671
32391
37984
38368
38488
41308
41860
46755
47127
48267
56391
63925
67165
67993
68293
70621
77911
82891
83611
84019
89668
93472
99136
105203
112287
116991
119295
125750

Muxman 0.12d builds up the title without any error.
Muxman 0.13c stops with the following error:
Reference to non-existant scene Segment_1_scn32

I double checked, in the m2v file, the frame nr. 125750 exist (it is the last picture in the stream, a black ending I frame)...

[mpucoder]

A single frame is too short to make a chapter. The vobu planner will not allow the last vobu to be split so the frame can be referenced, even if the duration extends it as a still (something I should add), therefore no cell is created.

Look in the log file, there should be no mention of the cell. You could also look at the result from 0.12d with IfoEdit to see how many chapters it created - should be the same. The difference between 0.12 and 0.13 is that 0.12 could ignore scenes (cells) that were not created when building the title PGC because the PGC was built after the multiplex from data produced by the multiplexer (VTS_C_ADT). 0.13 now builds a navigation section in the database that refers to each scene by name before the multiplex.

[mpucoder]

@SD - I wanted to try this before posting. A workaround is to get that single frame into another file, add it to the end of the list of files and set its duration to at least 10 frames (PAL, 12 if NTSC). Muxman will then make a cell for the still. You could optionally remove the frame from the original m2v, but that may be more work than it's worth just to prevent seeing the frame twice.

[Sir Didymus]

:)
dammit!
You are right, of course... :scared:

What a silly question I made!!!
Everybody knows a VOBU can not be shorter than 0.4 s...

I was scratching my head, trying to figure out why the behaviour of Muxman was different from Scenarist...

Taking the opportunity, once more, to thank you for your clarifications. No words are sufficient for the proper appreciation of your big work...

Edit: good idea, to add a still frame at the end, I'll try and report... In my situation it's very easy, being this last frame a black one... CHEERS, SD

[Sir Didymus]

@Mpucoder
Your suggestion is working perfectly:


MuxMan version 0.13c
Accepted video E:\JONNY_ENGLISH\demux\VTS01\PGC1\VideoFile.m2v size = 3534447192
Accepted still E:\JONNY_ENGLISH\demux\VTS01\PGC1\blank.m2v size = 6529
Accepted audio E:\JONNY_ENGLISH\demux\VTS01\PGC1\AudioFile_81.ac3
Opened sub 1 file E:\JONNY_ENGLISH\demux\VTS01\PGC1\Subpictures_20.sup.
Opened sub 2 file E:\JONNY_ENGLISH\demux\VTS01\PGC1\Subpictures_21.sup.
Opened sub 3 file E:\JONNY_ENGLISH\demux\VTS01\PGC1\Subpictures_22.sup.
Opened sub 4 file E:\JONNY_ENGLISH\demux\VTS01\PGC1\Subpictures_23.sup.
Opened sub 5 file E:\JONNY_ENGLISH\demux\VTS01\PGC1\Subpictures_24.sup.
expanded database to 116 entries.
expanded database to 132 entries.
expanded database to 148 entries.
expanded database to 164 entries.
expanded database to 180 entries.
expanded database to 196 entries.
expanded database to 212 entries.
18:35:28 Begin multiplex.
Maximum audio duration 251498 fields.
Starting scene Segment_1_scn1 at 00:00:00:00
...skip...
Starting scene Segment_1_scn23 at 00:55:44:11
Starting scene Segment_1_scn24 at 00:56:01:06, requested for 00:56:00:19
Starting scene Segment_1_scn25 at 00:59:46:18
Starting scene Segment_1_scn26 at 01:02:19:09, requested for 01:02:18:22
Starting scene Segment_1_scn27 at 01:06:05:11
Starting scene Segment_1_scn28 at 01:10:08:03
Starting scene Segment_1_scn29 at 01:14:51:12
Starting scene Segment_1_scn30 at 01:17:59:16
Starting scene Segment_1_scn31 at 01:19:31:20
SeqEnd at D2AB6254.
Starting scene Segment_1_scn32 at 01:23:50:01, requested for 01:23:50:00
SeqEnd at 197D.
Bytes remaining in buffer = 0.
18:43:54 End multiplex.
Bitrate - avg: 6146279, min: 368640 (lba 1887106), max: 9284266 (lba 714261).
Shortest GOP has 2 fields, longest GOP has 24 fields.
Fields: 251522, Still fields: 18, VOBU: 10169, Sectors: 1887115.


By the way, looking at the Muxman log, I see sometimes it still happen that the user request for a given chapter point is disregarded [delayed by one GOP]. One of the bad consequences is that the presence of subpictures starting at the beginning of a given chapter tends to produce a "flickering" of the subtitles: normally subtitles are 3 seconds or more, so in the condition of a delayed chapter start, the subpicture start at the very end of the previous chapter and quickly disappear (after one GOP) at the start of the actual chapter point. I hope it is clear what I mean: for this specific situation, in case it's impossible to respect the requested chapter starts, it may be better to try to "anticipate" the chapters, instead than delay them...

Do you have any hint in order to cope with this type of problems ?

All the best,
SD

[mpucoder]

I think for now it would be better to determine the reason the chapter point requests were not honored. I know this is some work, but I need to know the lengths of the 4 gops preceeding the missed chapter. An easy way is to make note of the vobu_s_ptm (offset 0039 in nac pack) for 2 or 3 vobu preceeding the chapter and how many gop headers there were in each. The logic is not perfect, I have several theoretical and supposedly rare cases in my notes - now I need to know if theory is reality.

Also looks like I need to "grow" the database in larger steps.

[Sir Didymus]

Originally posted by mpucoder
...I need to know the lengths of the 4 gops preceeding the missed chapter. An easy way is to make note of the vobu_s_ptm (offset 0039 in nav pack) for 2 or 3 vobu preceeding the chapter ...

That's easy to do, if you think it may be useful; just need to use VobEdit; all the files are available to me, so it'll take very little time...

...and how many gop headers there were in each...
How many GOP headers in each VOBU ?
Am I missing something ?
That sounds less obvious to me...
The only way I see is to parse the VOBs with a specific program...
Maybe it is sufficient just to count the number of I frames in each VOBU [again, just using VobEdit] ?

Edit: Ok. Got it. Again with VobEdit, it is the "GOP start code...". I'll collect the info and report tomorrow...

[mpucoder]

In the left pane of VobEdit it shows [GOP] whenever there is a new gop.

Actually the pts information isn't the best to gather, it would be better to count frame headers in each gop - again VobEdit shows [I], [P], or [B] for each frame (sometimes multiple frames in one pack, they look like [BB] )

[Sir Didymus]

Following link point to an xls file useful as a reference:
http://webmail.libero.it/r.php?d=libero.it&wr=3zqcxucf&ws=3zqcxucf&e=libero.it&c=gW6ZnOnV7n6LHtTn5RaaThnopx3bw9OK103177

It is valid until 07.04.2005 09:06AM.

Well, I spent very little time to do coreographic improvements to the document; indeed hope collected info is still readable.

It clarifies (a little bit) what happened...
For example, in the chapter 84031, requested for 84019, the VOBU structures are as follow:


VOBU # VOBU Structure VOBU Size (pictures)
+1 [GOP]IBBPBBPBB[GOP]IBBPBB 15
0 [GOP]IBBPBBPBBPBB 12
-1 [GOP]IBBPPPBP[GOP]IPBPBBPBBPBB 20
-2 [GOP]IBBPBBPBBPBB 12
-3 [GOP]IBBPBBPBBPBB 12
-4 [GOP]IBBPBBPBBPBB 12


It seems the chapter request has not been accepted since the previous GOP, being just 8 pictures long, would produce (alone) a VOBU shorter than 0.4 s.
In this case maybe the proper strategy would be to check if this short GOP may be joined to the previous VOBU (the one at # -2)...

I see no visible drawbacks in this case...

The second example (chapter point 93472, requested for 93484) is even more interesting, since the first "available" VOBU is at # -3...

All the best,
SD

Edit: Hmmm. I have an update on this test (it's not a good news, I'd say): trying to replicate the problem on a shorter segment, I extracted the two cells from the title, across to the first disregarded chapter point (using VobEdit, it produced two vob files). Then joined (copy /B) the two cells, obtaining a single vob file. then demuxed ALL of the contained assets and remuxed with MuxMan a new title, using a single chapter point exactely matching the original one...

In this test the chapter point has been accepted, so it seems the GOP structure of the pictures across to the chapter point is not the (principal) factor causing the un-acceptance of the chapter points...

So apparently the condition/s causing this behaviour is/are not easily replicatable...

[mpucoder]

So vobu 0 is where the chapter was made? The strategy you describe (of joining the 8 frame gop to the previous 12 frame to align the chapter point) is exactly what Muxman is supposed to do. I don't understand why it did not. This is PAL, right?

[Sir Didymus]

So vobu 0 is where the chapter was made? --> yes...
This is PAL, right? --> yes... I double cheched the PTS values, in order to guarantee not to report mistakes about the GOP structures and picture nr... [there are some notes in the xls file reporting the values], each picture takes 40 ms...

[mpucoder]

I don't have any program to view xls :( (not really sure I want one either)

[Sir Didymus]

Oh, I see...

Well, no problem, here it is the code for the second delayed chapter point:


VOBU # VOBU Structure VOBU Size (pictures)
+1 [GOP]IBBPBBPBBPBB 12
0 [GOP]IBBPBBPBBPBB 12
-1 [GOP]IPBPB[GOP]IPBPBBPBBPBB 17
-2 [GOP]IBBPBBPBB[GOP]IBBPBBPBBPB 20
-3 [GOP]IBBPBBPBBPBB 12
-4 [GOP]IBBPBBPBBPBB 12


Just for the additional info, here it is the picture of the xls...
...best to save the image on the local PC and to look at it in its original resolution...

http://img191.exs.cx/img191/6613/xls9kw.th.gif (http://img191.exs.cx/my.php?loc=img191&image=xls9kw.gif)

[mpucoder]

Thanks for the gif. I can see what went wrong with the second one - at least enough to know what math to check. But the first one bothers me as it is a simple case that was tested. The logic for this case is "if the current vobu meets minimum and the next gop is short (<400ms) and the distance to the next chapter is short, incorporate the next gop into the current vobu" (this is not the only rule, just the one that applies to this case)
So when it is the vobu starting at 83998 the conditions are:
vobu length 12 frames (meets minimum)
next gop (which starts at 84010) is 9 frames (short)
next chapter is 9 frames later (short)
I should have joined the 9 frame gop and placed the chapter correctly.
But I'll double check the math.

I can synthesize an m2v with these gop lengths unless you happen to have the files already.

[mpucoder]

A new Muxman (0.13d) to fix subpicture attributes in VTSI_MAT is now available at the Muxman homepage (http://www.mpucoder.com/Muxman/)

[Sir Didymus]

Originally posted by mpucoder
...
I can synthesize an m2v with these gop lengths unless you happen to have the files already...


I keep the files, and of course I will not delete them, at least for a while, for testing purposes.

Funny thing is that I spent really a lot of time trying to reduce their size, in order to make possible to share some segment... but all my attempts to reproduce the problem are being frustrated...

I mean, the problem is replicatable (on the same huge 3GB m2v file), even remuxing it without audio and subpicures: giving to MuxMan 0.13d the m2v and the chapter list generates every time exactely the two glitches previously reported...

If I try to reduce in some way the m2v size, cutting out for example the first cell of the m2v, and adjusting in a suitable way the chapter list, the problem disappears... :confused:

Sorry, but in this condition I have no cues on the matter...

Very strange indeed; I'd say while being not able to replicate in a short segment the reported behaviour, my posts are almost un-useful...

So, nice w/e for the moment...

[mpucoder]

Here's what we can do then, since I cannot duplicate the problem either. Make a profile using Muxman 0.11c - it's the last version to have the "make profile" checkbox, and available in my forum archives in case you deleted it. Don't worry about what 0.11c makes for a DVD, profile information allows me to synthesize the entire m2v file.

[CoNS]

I have two bug reports and a request...

First bug report: I'm trying to mux a disc where I get this error every time I try it with MuxMan:

See this picture: http://home25.inet.tele.dk/dvdkat/muxman1.png

It happens at 99% in the muxing process. In the output folder, all files have been created by MuxMan except VIDEO_TS.IFO and .BUP. The created .vob files have the correct sizes, but are not playable.

IfoEdit does the job without any warnings or errors, and the output plays fine. I've used PgcDemux latest version to demux streams (only 1 video, 1 audio and 1 subtitle stream) and create celltimes.txt. MuxMan reads 13 chapters from the celltimes.txt file, but the original movie only shows 12 chapters in my software player (Media Player Classic). Same with the output created by IfoEdit.

Second bug report: It's possible to click [...] (browse) for audio 1, click "Cancel" in the browser window and then still get to the stream arrangement window. If I then click "Close" in this window, I return to the main MuxMan window, now with the browse button for audio 2 available. If I then select an audio file for the second slot (still leaving the first slot blank), and fill out all other information about the other streams etc. and hit "Start", Windows (Win2000) gives me a standard error message and closes MuxMan.

And then my request: I know I've asked this before, please forgive me for repeating it! :) But I'm not into Scenarist scripts and I think it would be extremely nice to have a function below the "Import Chapters" function in the File menu called "Import subtitle colours", which would bring up a browse window looking for an .ifo file and then let you specify a PGC within that titleset to copy subtitle colours from and use in the MuxMan process. Kinda like ReJig's authoring function combined with the PGC selection from PgcDemux... Please? Pretty please with sugar on the top?!! :D

[mpucoder]

The first one is not a bug, and was explained. In the past Muxman would ignore chapters that could not be created because they either were too close to the previous chapter (less than 400ms, 10 PAL or 12 NTSC frames) or beyond the end of the segment. It now considers these fatal errors as the condition makes it impossible to compile the ifo files.

The second one I'm aware of and once the project is a little futher on a as yet unwritten process of planning the entire DVD will fix this.

Muxman is an authoring program, and the project's goal is to achieve full authoring capability. While I can make a few concessions to re-authoring (such as .sup files or fixing SubRip .sst files), anything as major as extracting information from already authored DVDs is a side trip I'm not willing to make until the main goal has been reached.

Editing a palette is not that difficult. Create your project with the gui, save the project to a file, edit the file with notepad, and then load the file back in.

[CoNS]

Originally posted by mpucoder
The first one is not a bug, and was explained. In the past Muxman would ignore chapters that could not be created because they either were too close to the previous chapter (less than 400ms, 10 PAL or 12 NTSC frames) or beyond the end of the segment. It now considers these fatal errors as the condition makes it impossible to compile the ifo files.What do I do to fix it then?

[mpucoder]

If you are using scp or mxp the scene name tells you which one was not created.
If you are using a chapter list look at the scene name in the error message, it always ends with a number. The number is the chapter number that was not created. In your case the 13th chapter.

[CoNS]

So I just open my celltimes.txt file in notepad and delete the last chapter manually?

About the colour palette: Does the project file operate with YCrCB colour values or RGB?

[mpucoder]

Originally posted by CoNS
So I just open my celltimes.txt file in notepad and delete the last chapter manually?If that is the 13th chapter, yes.

About the colour palette: Does the project file operate with YCrCB colour values or RGB? RGB

[Sir Didymus]

Originally posted by mpucoder
Here's what we can do then, since I cannot duplicate the problem either. Make a profile using Muxman 0.11c - it's the last version to have the "make profile" checkbox, and available in my forum archives in case you deleted it. Don't worry about what 0.11c makes for a DVD, profile information allows me to synthesize the entire m2v file.

Excellent!!! Just done and sent to your e-mail the mxl file...

[mpucoder]

I found the problem, and there will be a new version soon. Just so you know why it changed when you modified the m2v, vobu planning uses random access to the video file, and the standard seek function uses a 32-bit signed integer for file position. Therefore it cannot be used to position beyond 2GB, and leaves the file at its current position. This means that the problems only happened beyond 2GB.

[mpucoder]

OK, version 0.13e is now available at the Muxman homepage (http://www.mpucoder.com/Muxman/)
Fixes two problems:
some bmp files not being decoded properly
chapter points beyond 2GB in the video file were not always at the correct frame.

[Sir Didymus]

Confirming in my test 0.13e solved the glitch on the chapter points...
Very subtile and difficult to catch, this one...

Compliments!!!
SD

[Trahald]

@mpucoder

yeah.. fseek bit me in the --- with some stuff i added to pulldown.exe.

_fseeki64 works alot better.

[DMagic1]

I have 4 seperate m2v files I'm adding in. All except one is accepted.
If I add that one first its accepted but all others after it are rejected. If I add the others first then that same one gets rejected. :confused:

[mpucoder]

All the files must have the same attributes like resolution, aspect ratio, framerate, pan/scan data, and CC. The log gives you a code for why the file was rejected. You can also open just one video file and look at the line under the filename on the main gui to see its attributes.