smartLabs tsMuxeR: Transport Stream muxer [Archive] - Page 67

deank

13th April 2009, 19:36

I never stopped auto-fixing clip information about mt2s blocks, despite it was said long ago it was fixed in tsmuxer.

I didn't know it is still wrong, but now I know - thanks, rapscallion.

mrr19121970

13th April 2009, 19:56

On a short test muxe, ~30 min it's fine/matches, but on a full movie, I get the discrepancy

Do you folks click on "Fix length" to correct this, ignore it, or don't bother checking ?
Am I just being overly picky here?

i've seen a discrepancy on original BDs, so I guess if it's not causing you a visible problem on playback i'd say it's a small worry

deank

13th April 2009, 20:05

i've seen a discrepancy on original BDs, so I guess if it's not causing you a visible problem on playback i'd say it's a small worry

It is noticeable in PS3... Offset $38-$3B in .clpi files should usually have the corresponding m2ts filesize % 192 rounded up (or otherwise said number_of_source_packets in ClipInfo() segment).

rapscallion

13th April 2009, 20:47

i've seen a discrepancy on original BDs, so I guess if it's not causing you a visible problem on playback i'd say it's a small worry
Well, that's the thing, I haven't burned any full movie discs yet, other than the tests I've done on the short clips (dvd-rw).

That's why I thought I'd ask first, because you did experience a problem on the PS3.
Thank you for that program, BTW !

roman76r

13th April 2009, 22:54

New version of tsMuxeR is available:
www.smlabs.net/tsMuxer/tsMuxeR_1.9.8(b).zip

Change list:
- added option "--insertBlankPL" which allows to add short black video (near 0.5 second) before main video. It is sovles the problem of "green bar" for cropped video on some players such PS3.
- Added options --mplsOffset and --m2tsOffset for changing M2TS and MPLS files enumeration.
- video_format field in MPLS file now always filled, including cropped video.

idbirch2

13th April 2009, 22:58

I haven't been fixing the M2TS packet size in my TSMuxer output since the bug was fixed and it's not been incorrect since - are you sure this app is performing the check properly? All my recent muxes (full movies split every 4GB) check out fine using my own clpi checking code and Dean's. I also watched one of my new muxes today and it was fine (as you say, the issue when present causes horrible pauses at each .m2ts split).

Maybe it only occurs on single-m2ts muxes (I don't do those) in which case, it wouldn't really matter as you'd just get a pause right at the very end of the movie?

rack04

14th April 2009, 00:18

Retaining mkv custom chapters does not work in 1.9.8. They work fine in 1.9.7.

roman76r

14th April 2009, 11:20

rack04
You are right. I'll fix it at evening.

mrr19121970

14th April 2009, 13:11

@roman76r

I'm wondering why you don't keep page 1 up-to-date (especially concerning version numbers).

Thanks.

rapscallion

14th April 2009, 14:36

deank

14th April 2009, 14:43

I believe this one (http://www.deanbg.com/fixclipinf.rar). It is command line utility.

idbirch2

14th April 2009, 14:44

You can still get FixClipInf here (http://mkv2avi.deanbg.com/fixclipinf.rar). Run it from a command line simply giving it the path to your root BD/AVCHD folder e.g. fixclipinf D:\Stuff\FilmA
Edit, ha, Dean beat me to it! :)

rapscallion

14th April 2009, 14:58

Thank you both...I'll give it a try and see if the results differ.

Edit : Well, I guess it'll remain a bit of a mystery. File patched w/dean's app and Clipinf Editor still shows a mismatch in the packets. Patched again with the same results. One could assume from this that there was no mismatch to start with.

deank

14th April 2009, 16:16

@mrr19121970: I just tried clipinf editor 0.02b.

1) I see "Frame rate" above the resolutions drop-down.
2) CLIPINF Header shows HDMV0100 to be AVCHD and HDMV0200 to be Blu-ray, which is incorrect (as previously discussed in this thread)

AVCHD clpi file will have CLEX segment and its extended data should contain ID1+ID2 for AVCHD (0x1000 0x01000). Read more here. (http://forum.doom9.org/showthread.php?p=1272188#post1272188)

http://multiavchd.deanbg.com/cledit.jpg

rapscallion

14th April 2009, 18:29

@dean....did you see the edit in my post above yours ?

deank

14th April 2009, 18:57

Yes, but I didn't have the chance to try direct tsmuxer output and check if packets match.

Your post was the reason to download clipinf editor and check some things.

All of my files showed a match, but I'll try later with pure tsmuxer 1.9.6 output.

rapscallion

14th April 2009, 19:08

I think that it might be size related. Every movie clip (5) that I test muxed ~30 min (less than 4gb) does not indicate an error in Clipinf.

Every full length movie (6 so far) ~2 hrs (~8.4 gb) has displayed the error , ver 1.8.3 through 1.9.7. (originally outputted Blu-ray and now Blu-ray and AVCHD)

deank

14th April 2009, 19:10

I just tried a file and split it to 20 m2ts+clpi and all showed correct values in clipinfeditor. I'll check later with a full-time movie.

edit:

Ok, I tried with 2hrs source (nine .clpi files) and tsmuxer 1.9.7 created proper m2ts block sizes in clip files. It may be something else in your case.

---

edit2: ...if you have only one m2ts/clpi pair and there are differences it shouldn't affect playback in any way, as idbirch said - so you need not to worry if final result will be broken. You wouldn't notice it I believe.

BlackJack1

14th April 2009, 21:44

what is the best = most compatible for standalone players version of TsMuxer?

deank

14th April 2009, 21:52

what is the best = most compatible for standalone players version of TsMuxer?

Take a look here. (http://forum.doom9.org/showthread.php?t=146339)

rapscallion

14th April 2009, 21:55

Iedit:

Ok, I tried with 2hrs source (nine .clpi files) and tsmuxer 1.9.7 created proper m2ts block sizes in clip files. It may be something else in your case.
OOps, deleted my last post by mistake.

1.9.7
Here are the screen shots again. The first, the full 8.4gb movie with a single stream. Packet error and duplicate PID's
The second, same movie cut @ 3.4 gb, single stream. No packet error and single PID's.

Yes, I realize that it will most likely won't be a problem in playback. Just curious why the discrepancies.:thanks:

deank

14th April 2009, 21:56

We shall wait for attachment approval (I edited my post in the previous page).

About PID's - I'll need to see the screen shots... But before trusting to one application - verify with another (like mediainfo or tsmuxer itself) to check if wysiwyg. If you get about 5-10 blocks difference and you're using only one segment (1 m2ts/clpi) it wouldn't matter - not that it is okay...

onesloth

14th April 2009, 23:04

roman,

Most of the blu-ray structures that I've looked at have IN times of 00:00:11.650, instead of tsMuxer's default 00:10:00.000. It would be very useful to me if tsMuxer used a 00:00:11.650 IN time for blu-ray output instead or, even better, had an option for specifying the desired IN time.

laserfan

14th April 2009, 23:07

Can someone please briefly explain what IN time is, especially why it isn't just 00:00:00.000??? :confused:

onesloth

14th April 2009, 23:42

Can someone please briefly explain what IN time is, especially why it isn't just 00:00:00.000??? :confused:
http://www.blu-raydisc.com/Assets/Downloadablefile/2b_bdrom_audiovisualapplication_0305-12955-15269.pdf
Page 12 looks like it's the relevant specification.

I'm no expert, but my understanding is that a playlist item can start and stop at arbitrary points on a stream's timeline. IN times mark the point on the stream that a given playlist item starts at. Somebody else would have to explain why IN times are not zero when the playlist item plays (nearly) the whole stream.

For my purposes, after reencoding a seamless branching disc's m2ts's, being able to set tsMuxer's output's IN times the same as the original structure *should* (I assume) greatly simplify reconstructing the branching disc.

laserfan

15th April 2009, 00:56

...my understanding is that a playlist item can start and stop at arbitrary points on a stream's timeline. IN times mark the point on the stream that a given playlist item starts at.Very helpful post thanks. I will have to study the white paper (looks interesting but I just glanced at it); maybe this will be clearer to me, but the IN point implies that there should be a 10sec delay before the stream starts, and I don't *think* that's something that always happens on playback...is it?

onesloth

15th April 2009, 01:16

but the IN point implies that there should be a 10sec delay before the stream starts, and I don't *think* that's something that always happens on playback...is it?
It isn't specifying a ten second delay. Its saying that playback of that playitem (part or possibly all of a movie playlist) begins at 10 minutes into the timeline of the clip (m2ts). I believe the reason playback doesn't start 10 minutes into the stream is because the stream that needs to be played doesn't actually start until 10 minutes into its clip's timeline. That is to say, the timeline is perhaps 10 minutes longer than the actual stream.

mrr19121970

15th April 2009, 06:30

Packet error and duplicate PID's
The second, same movie cut @ 3.4 gb, single stream. No packet error and single PID's.

this is a known bug in my program. the 1st time you run, you'll get duplicated info. 2nd time it's gone. i only noticed myself a few weeks ago, and thought i'd got away with it as nobody had reported it. quite difficult to debug, as it requires a reboot every time. it's probably just an intialization issue though.

i'll have another look at this and the 2 other display bugs deank reported.

mrr19121970

15th April 2009, 08:50

@mrr19121970: I just tried clipinf editor 0.02b.

1) I see "Frame rate" above the resolutions drop-down.
2) CLIPINF Header shows HDMV0100 to be AVCHD and HDMV0200 to be Blu-ray, which is incorrect (as previously discussed in this thread)

2) original Blu-Ray disks have HDMV0200. please also see this thread http://forum.doom9.org/showthread.php?p=1191107#post1191107

I've uploaded V0.03b now. please feel frr to download.

vcarter

15th April 2009, 10:09

added option "--insertBlankPL" which allows to add short black video (near 0.5 second) before main video. It is sovles the problem of "green bar" for cropped video on some players such PS3

i know doom9 is full of dev with big QI,but for others like me,can someone tell us if with this option we don't need to add black borders.
and what about necessarry compliant resolution for ps3?
so no more green bars on ps3 with bd9 (avchd on dvd dl) with reso=1920*816 ?

@+

herrde

15th April 2009, 10:21

so no more green bars on ps3 with bd9 (avchd on dvd dl) with reso=1920*816 ?

In short: yes. This is the method that is being used in other programs like multiAVCHD or mkv2vob. deank (the programmer of multiAVCHD) invented it. It changes the big green bar of non-compliant resolution AVCHD movies to black.

Note that it DOES NOT center the movie, the movie will still be at the top of the screen. If you want the movie to be centered, you still have to add black borders to a movie with a non-compliant resolution for the time being.

Also, you will have to play your movie from the start. If your movie starts somewhere from the middle (e.g. if you continue to watch a movie after a break), the bar will turn green again. You would have to go to its beginning first and then jump back to the position you want to continue watching from.

Best,

Gero

deank

15th April 2009, 10:32

Also, you will have to play your movie from the start. If your movie starts somewhere from the middle (e.g. if you continue to watch a movie after a break), the bar will turn green again. You would have to go to its beginning first and then jump back to the position you want to continue watching from.

It is true only if your player goes directly to playback mode (from XMB to movie). If you're using a menu, initiate playback and then stop the movie and re-launch it from the menu it will continue and the green bar will be removed.

The trick with the green bar was first used in multiAVCHD build 159 ~ January 8th. (http://forum.doom9.org/showthread.php?p=1234195#post1234195)

ACrowley

15th April 2009, 11:59

what is the best = most compatible for standalone players version of TsMuxer?

latest Version works perfect on Pocornhour .
All Audio Formates are working fine now, including DTS HRA which was broken before.

Works also fine on Sony BDP S350

rapscallion

15th April 2009, 13:31

this is a known bug in my program. the 1st time you run, you'll get duplicated info. 2nd time it's gone. i only noticed myself a few weeks ago, and thought i'd got away with it as nobody had reported it. quite difficult to debug, as it requires a reboot every time. it's probably just an intialization issue though.

I'll have another look at this and the 2 other display bugs deank reported.
Thanks mrr19121970, I hadn't tried running it twice and you're right , no duplicates. (new ver the same)

I am curious about the packet length errors for longer length outputs and also why the error remains after applying dean's clpi fix/patch ? (your fix in the editor works, of course)

mrr19121970

15th April 2009, 15:15

I am curious about the packet length errors for longer length outputs and also why the error remains after applying dean's clpi fix/patch ?

I rounded down, not up. You can now try 0.04b. Thanks.

rapscallion

15th April 2009, 18:08

I rounded down, not up. You can now try 0.04b. Thanks.
Excellent ! new ver shows no error now in movies I restored the original clipinf files, from the backup folder.

So it appears that Tsmuxer output and your editor are in sync.:thanks:

Thanks for your efforts on this and hope that I didn't cause too much confusion for everyone else by bringing this up.:o

belcampo

15th April 2009, 18:42

latest Version works perfect on Pocornhour .
All Audio Formates are working fine now, including DTS HRA which was broken before.

Works also fine on Sony BDP S350

SInce 1.9.1 -1.9.9 I can't produce files that my PopCornHour accepts, with h.264 and aac. The older tsMuxeR_1.8.18(b).zip although works fine.

ACrowley

15th April 2009, 19:03

SInce 1.9.1 -1.9.9 I can't produce files that my PopCornHour accepts, with h.264 and aac. The older tsMuxeR_1.8.18(b).zip although works fine.

Mh... i can only speak about H264/VC1/Mpeg2 + DTS (HD,HRA,ES) AC3(EX6.1)and TrueHD (with AC3 core)

AAC in M2TS works with Popcornhour ? Didnt kow that.
I thought onlAAC in MP4/MOV only
I dont know ,maybe AAC+H264 is better in MP4 generally ?

vcarter

16th April 2009, 08:14

hi

i use 1.9.8 and on final avchd disc ,there's no more certificate,and in bdmv,there are no more AUXDATA,BDJO,JAR,META.
and a big problem appeared:video and audio are no more synchro

@+

ps:sorry i did not read the tsmuxer readme about empty folder

turbojet

16th April 2009, 08:23

Discoboy

16th April 2009, 10:38

TiVoMad

16th April 2009, 17:12

I am about to convert my HD-DVD collection to m2ts (so I can play on a Popcorn Hour). I would like to keep the hi-def audio if possible. When I use eac3to to de-mux the truehd track in its native form, TSMuxer will not accept it as input. Is this because it has no AC3 core in there? Is there a way round this or do I need to convert to lpcm to keep the quality ?

Sorry if this was already answered, it's a long thread.

TiVo.

SomeJoe

16th April 2009, 17:20

I am about to convert my HD-DVD collection to m2ts (so I can play on a Popcorn Hour). I would like to keep the hi-def audio if possible. When I use eac3to to de-mux the truehd track in its native form, TSMuxer will not accept it as input. Is this because it has no AC3 core in there? Is there a way round this or do I need to convert to lpcm to keep the quality ?

eac3to.exe can add the interleaved .ac3 track for BD compatibility. (The following assumes that the input HD-DVD structure contains a TrueHD track).

eac3to.exe "<input>" <title>) <track>: "<output path>.thd+ac3"

TiVoMad

17th April 2009, 10:06

eac3to.exe can add the interleaved .ac3 track for BD compatibility. (The following assumes that the input HD-DVD structure contains a TrueHD track).

eac3to.exe "<input>" <title>) <track>: "<output path>.thd+ac3"

Works a treat, thank you very much. I did not realise you could do that :)

shon3i

17th April 2009, 12:03

Is anyone else seeing the muxing stop in TSMuxerGUI 1.9.9 when minimizing/restoring the program?
I'm using vista x64 and it happens with m2ts/mkv inputs and all possible outputs.

roman76r: Is there a possibility for this command line option so open with works correctly: tsmuxergui.exe <input file>
same here on win xp sp3

ACrowley

17th April 2009, 12:25

Octo-puss

17th April 2009, 12:44

Please update the first post with the latest version, it is getting a bit messy :) Thank you.

idbirch2

17th April 2009, 18:23

Strange, no problems with minimizing the GUI on Windows 7 x64.

deank

17th April 2009, 18:41

A possible bug report:

m2ts/ts files sometimes cannot report framerate (at all).

When tsMuxeR cannot detect fps and it is explicitly set (or detected) in .meta - file is created properly but mediainfo (not tsMuxeR itself) can detect the original FPS from the resulting m2ts/ts file.

Dean

edit: Please add a --log=filename.txt option.

Furiousflea

17th April 2009, 19:04

QUOTE=turbojet;1274548]Is anyone else seeing the muxing stop in TSMuxerGUI 1.9.9 when minimizing/restoring the program?
I'm using vista x64 and it happens with m2ts/mkv inputs and all possible outputs.

I can confirm same behaviour here using the gui. (vista x64\tsmuxer 1.9.9)