Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
27th July 2010, 04:24 | #8921 | Link |
Registered User
Join Date: Dec 2008
Posts: 7
|
I'm having a problem tsmuxer.exe crashing on me just as I start encoding the Director's Cut of Watchmen. I've tried disabling the subs as suggested earlier in the thread and that didn't work, but even if that were to have worked, I would rather not have to disable the subs, as I need them since my hearing is impaired.
|
27th July 2010, 04:42 | #8922 | Link | |
Registered User
Join Date: Aug 2005
Posts: 16,267
|
@Capsbackup
Hi! Quote:
|
|
27th July 2010, 07:55 | #8923 | Link | |
Registered User
Join Date: Jul 2004
Posts: 213
|
Quote:
All I say is that burned blu-ray still sttuters in TMT 3 (so no HDD distance involved), and that deank seems to count the "real" length of m2ts files after remuxing them and he corrects the playlist with these values (just few milliseconds, but enough to create stutters), while you just copy the same values there were on the original playlist, and then if I manually change the length of the m2ts files in your playlist with the values calculated by deank, the problem disappears. So as I stated in my previous post, "in my scenario" fixing the playlist created by BD-Rebuilder with deank's calculated m2ts files length solves "my" problem, so I don't know why you say it isn't helpful, because yes, if done exactly the same in both programs: just remux all the m2ts files (obviously not joining them, keeping all of them separately) in the playlist removing Pip and unwanted audio/subtitles, nothing more, nothing less. By the way, removing PROCESS_SECONDARY=0 doesn't help at all. Greetings |
|
27th July 2010, 10:21 | #8924 | Link |
Programmer (or just 教务长)
Join Date: Oct 2008
Location: Valencia, Spain
Posts: 4,251
|
I don't know if this is of any help, but since the early days when tsMuxeR needed fixclpi, multiAVCHD always checks each CLPI against the M2TS, sets proper packet count and verifies if in/out times match in all MPLS files, which refer to this m2ts, then puts the correct in/out values.
|
27th July 2010, 14:07 | #8926 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
Quote:
I don't think I remember an issue with the MPLS in/out times... was that something that often happens? I'll also go back and see if I make any adjustments there. [Edit] Actually I have to rewrite all the IN/OUT times because of the timing changes TSMUXER makes and the fact that I use the original MPLS files. Last edited by jdobbs; 27th July 2010 at 15:18. |
|
27th July 2010, 15:16 | #8927 | Link | |
Registered User
Join Date: Jul 2005
Posts: 1,995
|
Quote:
There is two mpls files, 01007.mpls, which is 1:57:46, that is made up of 29 seperate m2ts files. The second, 01006.mpls, is 1:51:00, and is made up of 28 seperate m2ts files. Several m2ts files are the same for each playlist, but several are different too. But they appear to "seamlessly" integrate to make each version of the movie. |
|
27th July 2010, 15:30 | #8928 | Link | |
Programmer (or just 教务长)
Join Date: Oct 2008
Location: Valencia, Spain
Posts: 4,251
|
Quote:
|
|
27th July 2010, 15:34 | #8929 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
Quote:
With that said, I did find that I only correct the packet count when "FIX_CLPI=1" was set. Just to be safe I've changed it so it always updates the packet count (just in case TSMUXER is wrong). |
|
27th July 2010, 15:37 | #8930 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
Quote:
|
|
27th July 2010, 16:07 | #8931 | Link | |
Registered User
Join Date: Jul 2004
Posts: 213
|
Quote:
I must admit that I don’t know nothing compared to you, and that maybe I hasn’t used the right words, so that together with my bad English doesn’t help at all. Thanks |
|
27th July 2010, 16:14 | #8932 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
Quote:
I'm a little confused. When you say "I manually change the length of the m2ts files" are you saying you are setting the packet length value in the CLPI, or you are changing the OUT time in the MPLS? If you're changing the OUT time -- how are you calculating what you believe to be the correct value? From the framecount/framrate? The reason I ask is, there shouldn't be any difference between the length (in time, adjusted for the new offset) of the original file and that of the newly reencoded one. If there is, that implies there is frame loss -- and that's a very bad thing. How big a difference do you make when you change it? Last edited by jdobbs; 27th July 2010 at 16:22. |
|
27th July 2010, 16:35 | #8933 | Link | ||
Programmer (or just 教务长)
Join Date: Oct 2008
Location: Valencia, Spain
Posts: 4,251
|
Quote:
Quote:
00102.mpls : refers to 00050.m2ts: IN: 019BFCC0, OUT: 01BA8B40. in multiAVCHD you have both CLPI and MPLS set to the same in/out times. in BD-RB you have correct info in the CLPI but not correct in the MPLS: 019BFCC0 / 01BA8B81. multiAVCHD always assumes that IN/OUT in the CLPI are the correct ones and overwrites what's in the mpls, that's why it works for chompy. You can see that the difference is just 0x41 which is close to nothing (0.001(4)s / less than 2 milliseconds) but still may cause troubles. I took a look at the other clpi files and it seems that all are referred with wrong OUT (by 0x40-0x43) in the playlist from BD-RB (00102.mpls). Dean Last edited by deank; 27th July 2010 at 16:44. |
||
27th July 2010, 16:52 | #8934 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
Quote:
Interesting if nothing else. Last edited by jdobbs; 27th July 2010 at 17:02. |
|
27th July 2010, 19:12 | #8935 | Link |
Registered User
Join Date: Jul 2004
Posts: 213
|
Thanks deank (and sorry jdobbs) for explaining what my poor knowledge hasn't been able to correctly tell... It seems that after remuxing those m2ts files, their OUT time is smaller than in the original and you correctly apply these values in CLPI, but not in MPLS.
Greetings |
28th July 2010, 04:00 | #8937 | Link |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
@SquallMX
Based on what you're describing I think that's the most probable cause. Can you try reencoding with Open-GOPs turned off and see if it corrects it? Also, does it correct itself within a second or so after seeking? Last, it doesn't do it with a chapter skip, does it? Starting with the last release that shouldn't happen. |
28th July 2010, 04:31 | #8938 | Link | |
Special SeeD
Join Date: Nov 2002
Location: Mexico
Posts: 333
|
Quote:
2.-Yes, it correct itself after a second. 3.-It does, the example screenshot is a chapter start but I was using beta 34.04, i will try again using beta 34.05. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|