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.

 

Go Back   Doom9's Forum > (HD) DVD, Blu-ray & (S)VCD > DVD & BD Rebuilder

Reply
 
Thread Tools Search this Thread Display Modes
Old 27th July 2010, 04:02   #8921  |  Link
Capsbackup
Registered User
 
Join Date: Jul 2005
Posts: 1,995
I can report that a recent backup of Forgetting Sarah Marshall to BD-R with BD-RB 3404 for playback on my Sony S360 plays back perfectly. This title has the original theatrical release and the extended version, a seamless branching disc.
I watched the extended version completely, and there were no stutters, no freezes, no glitches of any kind!
It also has PiP with Dolby Digital Plus secondary audio, and it worked perfectly too!
Capsbackup is offline   Reply With Quote
Old 27th July 2010, 05:24   #8922  |  Link
RJNelson
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.
RJNelson is offline   Reply With Quote
Old 27th July 2010, 05:42   #8923  |  Link
setarip_old
Registered User
 
setarip_old's Avatar
 
Join Date: Aug 2005
Posts: 16,272
@Capsbackup

Hi!
Quote:
This title has the original theatrical release and the extended version, a seamless branching disc.
I watched the extended version completely, and there were no stutters, no freezes, no glitches of any kind!
Are you sure it didn't contain two separate and complete versions?
setarip_old is offline   Reply With Quote
Old 27th July 2010, 08:55   #8924  |  Link
chompy
Registered User
 
Join Date: Jul 2004
Posts: 196
Quote:
Originally Posted by jdobbs View Post
C'mon. You can't say "is one of the problem causes" if the issue goes away on a real player. It is the problem. It's because the player has to buffer the consecutive parts sufficiently -- and they may be some distance apart on the hard drive (resulting in delay due to the time it takes for head movement).

Also saying "this works" or "that works" isn't helpful either -- because they are doing completely different things in completely different ways.
Ok if you don't want to take a look at what I'm saying you're completely on your rights as the developer of this software...

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
chompy is offline   Reply With Quote
Old 27th July 2010, 11:21   #8925  |  Link
deank
Programmer (or just 教务长)
 
deank's Avatar
 
Join Date: Oct 2008
Location: Valencia, Spain
Posts: 4,248
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.
__________________
multiAVCHD - donate | popBD | uncropMKV | mkv2avi | easySUP
deank is offline   Reply With Quote
Old 27th July 2010, 13:59   #8926  |  Link
mpiper
Registered User
 
Join Date: Jan 2005
Posts: 90
TSMuxer is also crashing on me. Running Windows 7 64bit. I've tried setting tsmuxer to run in compatibility mode with Vista SP2, but still crashes. This has happened on several different BD discs.

Thoughts?
mpiper is offline   Reply With Quote
Old 27th July 2010, 15:07   #8927  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,398
Quote:
Originally Posted by deank View Post
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.
I think I do that too (check packet count). If I remember right some of the earlier TSMUXER versions used to set the packet count incorrectly. They also screwed up the EP tables, but I thought that was fixed. I'll go back and check that I haven't changed that.

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.
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net

Last edited by jdobbs; 27th July 2010 at 16:18.
jdobbs is offline   Reply With Quote
Old 27th July 2010, 16:16   #8928  |  Link
Capsbackup
Registered User
 
Join Date: Jul 2005
Posts: 1,995
Quote:
Originally Posted by setarip_old View Post
@Capsbackup

Hi! Are you sure it didn't contain two separate and complete versions?
If my understanding of seamless branching is correct, this one has it.
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.
Capsbackup is offline   Reply With Quote
Old 27th July 2010, 16:30   #8929  |  Link
deank
Programmer (or just 教务长)
 
deank's Avatar
 
Join Date: Oct 2008
Location: Valencia, Spain
Posts: 4,248
Quote:
Originally Posted by jdobbs View Post
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.
I don't remember problems with mpls, too, but just to be safe I do all the checks, because for example a Viera TV in AVCHD player mode will reject the authored structure with "Unsupported format" error message, just because of wrong IN_TIME in any playlist or clpiinfo file (or a mismatch between them and m2ts).
__________________
multiAVCHD - donate | popBD | uncropMKV | mkv2avi | easySUP
deank is offline   Reply With Quote
Old 27th July 2010, 16:34   #8930  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,398
Quote:
Originally Posted by chompy
...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
The value you are talking about is in the CLPI file, not the MPLS, so it isn't a value in the "playlist". It is a value associated with the clip. I can't "just copy the same values that were in the original playlist" -- because they are not the same after running them through TSMUXER, BD-RB changes all the IN/OUT values in the playlist. I think you may have your terms confused.

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).
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net
jdobbs is offline   Reply With Quote
Old 27th July 2010, 16:37   #8931  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,398
Quote:
Originally Posted by deank View Post
I don't remember problems with mpls, too, but just to be safe I do all the checks, because for example a Viera TV in AVCHD player mode will reject the authored structure with "Unsupported format" error message, just because of wrong IN_TIME in any playlist or clpiinfo file (or a mismatch between them and m2ts).
Ok, I see. I don't think that would be an issue with BD-RB, because I rewrite all the IN/OUT times.
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net
jdobbs is offline   Reply With Quote
Old 27th July 2010, 17:07   #8932  |  Link
chompy
Registered User
 
Join Date: Jul 2004
Posts: 196
Quote:
Originally Posted by jdobbs View Post
The value you are talking about is in the CLPI file, not the MPLS, so it isn't a value in the "playlist". It is a value associated with the clip. I can't "just copy the same values that were in the original playlist" -- because they are not the same after running them through TSMUXER, BD-RB changes all the IN/OUT values in the playlist. I think you may have your terms confused.

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).
Yes you're right, you change the IN/OUT times in the playlist, because tsMuxeR uses it own values, what I meant to say is that the difference between OUT and IN times (what BDEdit calls length) is the same as in the original, while deank counts m2ts length (packet count) and it’s a bit smaller than the original, so your IN time is the same as deank’s one (tsMuxeR default value), but his OUT time is a little smaller.

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
chompy is offline   Reply With Quote
Old 27th July 2010, 17:14   #8933  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,398
Quote:
Originally Posted by chompy View Post
Yes you're right, you change the IN/OUT times in the playlist, because tsMuxeR uses it own values, what I meant to say is that the difference between OUT and IN times (what BDEdit calls length) is the same as in the original, while deank counts m2ts length (packet count) and it’s a bit smaller than the original, so your IN time is the same as deank’s one (tsMuxeR default value), but his OUT time is a little smaller.

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
I don't think the OUT time would be set based on the packet length at all, as that could change dramatically depending upon what is or is not muxed -- while the length (in time) might stay the same.

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?
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net

Last edited by jdobbs; 27th July 2010 at 17:22.
jdobbs is offline   Reply With Quote
Old 27th July 2010, 17:35   #8934  |  Link
deank
Programmer (or just 教务长)
 
deank's Avatar
 
Join Date: Oct 2008
Location: Valencia, Spain
Posts: 4,248
Quote:
Originally Posted by jdobbs View Post
Ok, I see. I don't think that would be an issue with BD-RB, because I rewrite all the IN/OUT times.
Quote:
Originally Posted by chompy View Post
Yes you're right, you change the IN/OUT times in the playlist, because tsMuxeR uses it own values, what I meant to say is that the difference between OUT and IN times (what BDEdit calls length) is the same as in the original, while deank counts m2ts length (packet count) and it’s a bit smaller than the original, so your IN time is the same as deank’s one (tsMuxeR default value), but his OUT time is a little smaller.
@jdobbs: I just took a look again at the files chompy posted. You can take a look yourself:

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
__________________
multiAVCHD - donate | popBD | uncropMKV | mkv2avi | easySUP

Last edited by deank; 27th July 2010 at 17:44.
deank is offline   Reply With Quote
Old 27th July 2010, 17:52   #8935  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,398
Quote:
Originally Posted by deank View Post
@jdobbs: I just took a look again at the files chompy posted. You can take a look yourself:

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
Thanks, deanK, I'll take a look at it. Strange, though, that the value would change from the original. Sometimes in multi-part playlists you can have a repeated audio packet in two adjoining M2TS files when the connection_condition is right. Maybe it's possible that one of the removed audio streams had this condition and resulted in a very small shortening.

Interesting if nothing else.
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net

Last edited by jdobbs; 27th July 2010 at 18:02.
jdobbs is offline   Reply With Quote
Old 27th July 2010, 20:12   #8936  |  Link
chompy
Registered User
 
Join Date: Jul 2004
Posts: 196
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
chompy is offline   Reply With Quote
Old 28th July 2010, 04:32   #8937  |  Link
SquallMX
Special SeeD
 
Join Date: Nov 2002
Location: Mexico
Posts: 266
Video glitch when seeking (on a normal play everything looks fine):



Open-GOP bug?

Blu-ray players affected: TMT3 and PS3.
SquallMX is offline   Reply With Quote
Old 28th July 2010, 05:00   #8938  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,398
@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.
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net
jdobbs is offline   Reply With Quote
Old 28th July 2010, 05:31   #8939  |  Link
SquallMX
Special SeeD
 
Join Date: Nov 2002
Location: Mexico
Posts: 266
Quote:
Originally Posted by jdobbs View Post
@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.
1.-I am already doing a re-encode using OPEN_GOP=0, i will report the results ASAP.
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.
SquallMX is offline   Reply With Quote
Old 28th July 2010, 15:31   #8940  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,398
Quote:
Originally Posted by SquallMX View Post
1.-I am already doing a re-encode using OPEN_GOP=0, i will report the results ASAP.
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.
Great, thanks.
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net
jdobbs is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 09:45.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.