smartLabs tsMuxeR: Transport Stream muxer

[chompy]

Can this be cured by changing the .meta file to include

, timeshift=10ms

after the down-to-dts statement?

Thanks, but nope, it doesn't help at all, still DTS-HD StreamPlayer crashes and eac3to says that last DTS frame is incomplete.

I still hasn't been able to test Clown_BD BD Copier, but looking at the .bat and .meta files it creates I don't have little hope as the downconversion to DTS core is exactly the same I've done, but until I test it, I cannot assure it.

[mrr19121970]

I ran the original through eac3to:

eac3to v3.18
command line: "D:\TVIX\Clown_BD\eac3to_old\eac3to.exe" "M:\BDMV\STREAM\00052.m2ts" 3:"E:\HELIUM_D1_GBR\1_3_audio.dts" -progressnumbers
------------------------------------------------------------------------------
M2TS, 2 video tracks, 9 audio tracks, 7 subtitle tracks, 0:00:19, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: h264/AVC, 480p24 /1.001 (20:11)
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48khz
(core: DTS-ES, 5.1 channels, 24 bits, 1509kbps, 48khz)
4: AC3 Surround, English, 2.0 channels, 320kbps, 48khz
5: DTS-ES, French, 5.1 channels, 24 bits, 1509kbps, 48khz
6: DTS-ES, Dutch, 5.1 channels, 24 bits, 1509kbps, 48khz
7: AC3 EX, Hungarian, 5.1 channels, 640kbps, 48khz
8: AC3 EX, Dutch, 5.1 channels, 640kbps, 48khz
9: AC3 Surround, English, 2.0 channels, 192kbps, 48khz
10: AC3 Surround, French, 2.0 channels, 192kbps, 48khz
11: AC3 Surround, Dutch, 2.0 channels, 192kbps, 48khz
12: Subtitle (PGS), English
13: Subtitle (PGS), English
14: Subtitle (PGS), French
15: Subtitle (PGS), Dutch
16: Subtitle (PGS), Hungarian
17: Subtitle (PGS), Hungarian
18: Subtitle (PGS), English
[a03] Extracting audio track number 3...
[a03] Creating file "E:\HELIUM_D1_GBR\1_3_audio.dts"...
Video track 1 contains 456 frames.
Video track 2 contains 457 frames.
eac3to processing took 1 second.
Done.

and the tsMuxerR Core:

eac3to v3.18
command line: "D:\TVIX\Clown_BD\eac3to_old\eac3to.exe" "S:\BDMV\STREAM\00052.m2ts" 2:"E:\HELIUM_D1_GBR\1_2_audio.dts" -progressnumbers
------------------------------------------------------------------------------
M2TS, 1 video track, 9 audio tracks, 7 subtitle tracks, 0:00:19, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: DTS-ES, English, 5.1 channels, 24 bits, 1509kbps, 48khz
3: AC3, English, 2.0 channels, 96kbps, 48khz
4: AC3, French, 2.0 channels, 96kbps, 48khz
5: AC3, Dutch, 2.0 channels, 96kbps, 48khz
6: AC3, Hungarian, 2.0 channels, 96kbps, 48khz
7: AC3, Dutch, 2.0 channels, 96kbps, 48khz
8: AC3, English, 2.0 channels, 96kbps, 48khz
9: AC3, French, 2.0 channels, 96kbps, 48khz
10: AC3, Dutch, 2.0 channels, 96kbps, 48khz
11: Subtitle (PGS), English
12: Subtitle (PGS), English
13: Subtitle (PGS), French
14: Subtitle (PGS), Dutch
15: Subtitle (PGS), Hungarian
16: Subtitle (PGS), Hungarian
17: Subtitle (PGS), English
[a02] Extracting audio track number 2...
[a02] Creating file "E:\HELIUM_D1_GBR\1_2_audio.dts"...
[a02] The last DTS frame is incomplete and thus gets skipped. <WARNING>
Video track 1 contains 456 frames.
eac3to processing took 1 second.
Done.


So it is a tsMuxeR issue. On the UK version of UP there is no noticable gap.

[chompy]

In Spanish edition there isn't this warning:

eac3to v3.24
command line: e:\install\bluray\eac3to\eac3to 00052.m2ts 3: d:\dts_hd.dts -core
------------------------------------------------------------------------------
M2TS, 2 video tracks, 9 audio tracks, 12 subtitle tracks, 0:00:19, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: h264/AVC, 480p24 /1.001 (20:11)
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48kHz
(core: DTS-ES, 5.1 channels, 24 bits, 1509kbps, 48kHz)
4: DTS-ES, Spanish, 5.1 channels, 24 bits, 1509kbps, 48kHz
5: AC3 EX, Portuguese, 5.1 channels, 640kbps, 48kHz
6: AC3 EX, Hebrew, 5.1 channels, 640kbps, 48kHz
7: AC3 EX, Romanian, 5.1 channels, 640kbps, 48kHz
8: AC3 EX, Croatian, 5.1 channels, 640kbps, 48kHz
9: AC3 Surround, English, 2.0 channels, 192kbps, 48kHz
10: AC3 Surround, Spanish, 2.0 channels, 192kbps, 48kHz
11: AC3 Surround, Portuguese, 2.0 channels, 192kbps, 48kHz
12: Subtitle (PGS), English
13: Subtitle (PGS), English
14: Subtitle (PGS), Spanish
15: Subtitle (PGS), Portuguese
16: Subtitle (PGS), Hebrew
17: Subtitle (PGS), Romanian
18: Subtitle (PGS), Croatian
19: Subtitle (PGS), Portuguese
20: Subtitle (PGS), Hebrew
21: Subtitle (PGS), Romanian
22: Subtitle (PGS), Croatian
23: Subtitle (PGS), English
[a03] Extracting audio track number 3...
[a03] Extracting DTS core...
[a03] Creating file "d:\dts_hd.dts"...
Video track 1 contains 456 frames.
Video track 2 contains 457 frames.
eac3to processing took 1 second.
Done.

Could you compare the wavs from eac3to DTS core and tsMuxeR DTS core?

Greetings

EDIT: I see that your copy doesn't have English DTS-HD, it only has DTS core (it neither has PiP)... Is it the original source or has it been precessed with tsMuxeR (Clown_BD Copier, BD-Rebuilder, MultiAVCHD...)? If the original it's already only DTS, then there's no downconversion done.
In the spanish edition the audio gap is noticed between 00055.m2ts (or 00056.m2ts if selected the alternate playlist) and 00058.m2ts

[mrr19121970]

You're right I demuxed the wrong file. I've now corrected the original post.

The eac3to DTS Core is 3,595,444 bytes and the TSM core is 3,593,432 bytes the files are identical upto 0x36d408 where the TSM core ends. So the extra is only in the eac3to core.

[mrr19121970]

I'm now confused.

Demux original DTS core with tsMuxeR (3,597,896 bytes) is the identicle to the Demuxed down-to-dts version created with tsMuxeR in the 1st place.

Recapping

tsMuxeR CORE demuxed with eac3to = (3,593,432 bytes)
Original CORE demuxed with eac3to = (3,595,444 bytes)

Here are the 3 files http://clownbd.com/HELIUM_D1_GBR.zip

[chompy]

I think that original tsMuxerR Core is larger because TsMuxeR demuxes one frame more than eac3to: while eac3to uses the number of frames of the main video track (which is correctly related with the DTS track we are demuxing), tsMuxeR uses the larger number of frames that the PiP has (one more frame in UP) then I don't know what happens in this extra frame, but something wrong for sure as the resulting DTS core is corrupted.

[mrr19121970]

Same problem with down-to-ac3. This one does not have a PIP.

eac3to v3.24
command line: "D:\TVIX\Clown_BD\eac3to\eac3to.exe" "E:\SHREK_THE_THIRD_EN" 1) 4: "F:\SHREK\Audio_4_English.AC3" -progressnumbers -LOG="F:\SHREK\LOGS\eac3to_PASS3_LOG.LOG"
------------------------------------------------------------------------------
M2TS, 1 video track, 8 audio tracks, 10 subtitle tracks, 1:32:46, 24p /1.001
1: Chapters, 18 chapters
2: VC-1, 1080p24 /1.001 (16:9)
3: AC3, German, 2.0 channels, 96kbps, 48kHz
4: AC3, English, 5.1 channels, 640kbps, 48kHz
5: AC3, Spanish, 2.0 channels, 96kbps, 48kHz
6: AC3, French, 2.0 channels, 96kbps, 48kHz
7: AC3, Italian, 2.0 channels, 96kbps, 48kHz
8: AC3, Dutch, 2.0 channels, 96kbps, 48kHz
9: AC3, Portuguese, 2.0 channels, 96kbps, 48kHz
10: AC3, Turkish, 2.0 channels, 96kbps, 48kHz
11: Subtitle (PGS), German
12: Subtitle (PGS), English
13: Subtitle (PGS), English
14: Subtitle (PGS), Spanish
15: Subtitle (PGS), French
16: Subtitle (PGS), Italian
17: Subtitle (PGS), Dutch
18: Subtitle (PGS), Portuguese
19: Subtitle (PGS), Turkish
20: Subtitle (PGS), English
[a04] Extracting audio track number 4...
[a04] Creating file "F:\SHREK\Audio_4_English.AC3"...
[a04] The last (E-)AC3 frame is incomplete and thus gets skipped. <WARNING>
Video track 2 contains 133453 frames.
eac3to processing took 2 minutes, 20 seconds.
Done.

[mrr19121970]

Original UP demuxed with eac3to

eac3to v3.24
command line: "D:\TVIX\Clown_BD\eac3to\eac3to.exe" "M:\BDMV\STREAM\00052.m2ts" 1: "F:\UP\Video_1.*" 3: "F:\UP\Audio_3_English.DTS" -progressnumbers -LOG="F:\UP\LOGS\eac3to_PASS3_LOG.LOG"
------------------------------------------------------------------------------
M2TS, 2 video tracks, 9 audio tracks, 7 subtitle tracks, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: h264/AVC, 480p24 /1.001 (20:11)
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48kHz
(core: DTS-ES, 5.1 channels, 24 bits, 1509kbps, 48kHz)
4: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
5: DTS-ES, French, 5.1 channels, 24 bits, 1509kbps, 48kHz
6: DTS-ES, Dutch, 5.1 channels, 24 bits, 1509kbps, 48kHz
7: AC3 EX, Hungarian, 5.1 channels, 640kbps, 48kHz
8: AC3 EX, Dutch, 5.1 channels, 640kbps, 48kHz
9: AC3 Surround, English, 2.0 channels, 192kbps, 48kHz
10: AC3 Surround, French, 2.0 channels, 192kbps, 48kHz
11: AC3 Surround, Dutch, 2.0 channels, 192kbps, 48kHz
12: Subtitle (PGS), English
13: Subtitle (PGS), English
14: Subtitle (PGS), French
15: Subtitle (PGS), Dutch
16: Subtitle (PGS), Hungarian
17: Subtitle (PGS), Hungarian
18: Subtitle (PGS), English
[v01] Extracting video track number 1...
[a03] Extracting audio track number 3...
[v01] Creating file "F:\UP\Video_1.h264"...
[a03] Creating file "F:\UP\Audio_3_English.DTS"...
[a03] [0:00:19] The source file seems to be damaged (sync byte missing). <WARNING>
[v01] [0:00:19] The source file seems to be damaged (sync byte missing). <WARNING>
Video track 1 contains 456 frames.
Video track 2 contains 457 frames.
eac3to processing took 1 second.
Done.

[chompy]

Yes, Gladiator neither has PiP, and the number of frames are the same in eac3to and in tsMuxeR, but DTS core's last frame from tsMuxeR is corrupted while last from eac3to is OK.

[mrr19121970]

I mailled tsmuxer@smartlabs.tv, I've never got a reply from them in the past. Lets hope they consider the bug worthy of fixing.

[tebasuna51]

Also wav output from PCM tracks have bugs (repported to smartlabs) when extract with tsMuxeR.
Use tsMuxeR to mux and eac3to to extract.

[chompy]

Use tsMuxeR to mux and eac3to to extract.

Well, that's not true 100%... If I demux audio + video (H264) with eac3to, then I'll still have the gap in English audio stream, but now, I'll also have the gap in Spanish audio stream. :confused:

So what has finally worked (both audio streams without gaps) is:
1) Demux video + audio streams not downconverted with tsMuxeR.
2) Demux audio streams downconverted with eac3to.
3) Mux all files with tsMuxeR.
4) Enjoy my perfect seamless branching backup :)

I don't know why but it seams that video streams demuxed with eac3to have some problems: they are smaller than their tsMuxeR demuxed equivalents and cannot be opened with Adobe Premiere, while the same video demuxed by tsMuxeR is read prefectly.

Greetings

[IanD]

I'm having a peculiar issue with TsMuxer: to fit a 2:30:20 movie only onto a BD-R, I need to trim off some of the end credits to a total duration of 2:27:00, so I'm using ClownBD to extract the elementary streams, then TsMuxer manually in a later step to set the end cut point. However, if I set the cut point to 147 minutes or even 8840 seconds, I get the same duration of 2:22:59 which is a little too short as I lose the very last few seconds of the movie before the end credits start. There is no chapter point at the start of the end credits: the last one happens a few minutes before the cut point occurs.

I have tried using a split point, but it creates a structure with two m2ts and doesn't reduce it down, so cut seems to be the best option.

If I insert no cut point, I get the full movie, but it is about 300MB too large to fit on a BD-R.

Can anyone suggest why I'm getting a fixed cut point that differs from what I am entering in TsMuxer? Is TsMuxer implementing some automatic setting when cut is activated, that provides a conservative result for a 25GB BD-R and can this be overridden?

[laserfan]

Can anyone suggest why I'm getting a fixed cut point that differs from what I am entering in TsMuxer? Is TsMuxer implementing some automatic setting when cut is activated, that provides a conservative result for a 25GB BD-R and can this be overridden?I would guess/assume/expect? that tsMuxer can only use I-frames as cut points which could account for the problem.

If you had re-encoded the BD with x264 then you could look-in the .stats file to find an appropriate I- or i-frame and then calculate your seconds (actually, you want to use milliseconds) from that. I forget exactly but maybe you want to use as -cut-end= the ms of the last i-frame plus 42.

I'm not sure how you'd ID the i-frames if you've not re-encoded, tho someone here will know. If not, certainly a Pass 1-only with x264 oughta work.

[Capsbackup]

@IanD;
You could also try TSSplitter, but you might have the same issue described above.
http://www.ffprojects.net/tssplitter/tssplitter.htm
Also, you could try DGSplit.
http://neuron2.net/mine.html#tools

[laserfan]

I have used tsMuxer to trim its output both front-and-back, and it works spectacularly well; you just have to pick the perfect ms numbers for cut-start and cut-end. I dunno tssplitter but I think DGsplit cuts w/o concern for GOPs.

BTW cutting the front-off is tricky if you have chapter marks; you need to assert a new "first frame" since frame 0 gets cut. But if you do it right the resulting output works perfectly, Chapters, and of course Audio and Subtitles (in perfect sync).

[coolalibaba]

anyone updated PS3 to 3.50 firmware? Looks now PS3 doesn't refresh the area out of the actual content. So if you re-mux NC(such as 1920X800) video with srt subtitles to AVCHD, as subtitles is usually displayed out of the video conten area(at the bottom), you won't be able to see the subtitles now.

[deank]

Did you try with AVCHD which previously worked? If so - that's sad news, along with all the restrictions in this 3.50 firmware (like no more unlicensed USB devices/controllers). :mad:

[coolalibaba]

No, I didn't test others as I don't have other video sources currently. A work around is to adjust the position of subtitles to make it in the video content.

[setarip_old]

Sounds like the PS3 is gradually DEvolving into a game and "proper" video playback machine...

[titof]

Hi every body

I try the tsmuxer with High definition ts files (ok in VLC player). But impossible to mux them into a new ts file (no change)
The error is 10737414676

I'm using win7. Do you know this problem ?
Thanks

[LostChild1]

Hi,

I used to use TsMuxeR for everything, and it always went without a hitch. But ever since re-installing openSUSE 11.3, I get the following error on many files:

tsMuxeR: ../vodTransport/src/matroskaParser.cpp:134: virtual void vodcore::ParsedH264TrackData::extractData(vodcore::AVPacket*, uint8_t*, int): Assertion `curPos == end' failed.
Can't detect stream type.

Any idea what is causing this? I've tried installing any libraries I can think of, but it's not something I've ever had a problem with in the past. mkvmerge can tell me all the info about the files no problem, so I don't understand what tsMuxeR is complaining about.

Thanks for the help. :) Also of note: I run a 64-bit system, but I have, what I believe to be, the proper 32-bit libraries installed.

[arrgh]

Anybody an idea if it would be possible to remux 3D Blurays with tsmuxer?

[stevensf]

I have a movie with more than 32 subs and tsmuxer demux only 32 subs. anybody knows how I can demux the 48 subs of my movie ?

[shon3i]

Try with eac3to.

[stevensf]

Try with eac3to.

tx for the help but eac3to support only 32 subs as the others programs :(

[Midzuki]

^

What about xport ???

[chompy]

@ stevensf:

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

If I'm not wrong, the maximum subs per m2ts is 32, and if there are more, then they are in a different m2ts contining only those subtitles (use BDedit to know in which m2ts they are).

[stevensf]

@ stevensf:

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

If I'm not wrong, the maximum subs per m2ts is 32, and if there are more, then they are in a different m2ts contining only those subtitles (use BDedit to know in which m2ts they are).

ok tx :)

[GRKNGLR]

Hi,
Will there be a new version of TsMuxer?

Version: 1.10.6
Released: 20090511

[Lincoln Burrows]

I am confused, why is TsMuxer listed with versions 1.10.6 and 1.8.4?

[kaid]

Field testing report: Just checked out a self-encoded AVCHD and Bluray (with Big Buck Bunny! ;-) muxed with TSmuxer at the local electronics store on various BD players... They worked in every single player I tested (Pioneer, PS3, Sony, Philips, Samsung), only one would just play the AVCHD for some reason: The Sharp one (sorry, didn't write down the model, but it's the current one!). It simply refused to load the Verbatim BD-RE with the same Video (muxed to Bluray, not AVCHD though!)

The clerk said that this player is known to be very picky about the stuff it plays!...

[Ghitulescu]

Field testing report: Just checked out a self-encoded AVCHD and Bluray (with Big Buck Bunny! ;-) muxed with TSmuxer at the local electronics store on various BD players... They worked in every single player I tested (Pioneer, PS3, Sony, Philips, Samsung), only one would just play the AVCHD for some reason: The Sharp one (sorry, didn't write down the model, but it's the current one!). It simply refused to load the Verbatim BD-RE with the same Video (muxed to Bluray, not AVCHD though!)

The clerk said that this player is known to be very picky about the stuff it plays!...

He's false, the Sharps don't play anything that's not original. With the latest FW update, the Sharps were able to read BD-Rs.

[mikeathome]

Hi,
this is a huge thread so excuse me if I repeat something!

I backed up a Music BR (Rush - Beyond The Lighted Stage) the other day. It contains 1 playlist for the main title and another for the 'Making Of this Film'.

So I load the playlist into TSMuxer and deselect unwanted streams. So far so good works with both playlists.

I re-encode the video and mux back together with MKVmerger and the 'Making Of' starts in-sync and is of sync every time a different chapter/section (following the original playlist) is played. Strange, some are in sync but 90% are off by up-to 500ms.

I wonder if TSMuxer is correcting individual .m2ts audio delays during the join?

Has this been investigated before?
The seamless branching titles should link together w/o delays, shouldn't they? And indeed, the main title is perfectly in-sync although it was split over some 20 individual parts as well.

Will eac3to be able to fix this? If yes I'll re-run it but want to avoid because I probably have to re-encode (10+ hours).

mike

[mrr19121970]

I wonder if TSMuxer is correcting individual .m2ts audio delays during the join?

No, this is a well known issue.

Has this been investigated before?
The seamless branching titles should link together w/o delays, shouldn't they? And indeed, the main title is perfectly in-sync although it was split over some 20 individual parts as well.

tsMuxeR seems to be in a very long a deep dormant phase, and we should assume that the bugs will not be corrected.

Will eac3to be able to fix this? If yes I'll re-run it but want to avoid because I probably have to re-encode (10+ hours).

mike

Yes, eac3to will do this for you. I'm not sure why you need 10 hours though.

Check out Clown_BD (GUI for eac3to & tsMuxeR) it will probably help you in what you are trying to acheive.

[mikeathome]

Thank you mrr19121970!

That was very valuable information for me. I will change my procedure than and use eac3to.

The re-encode of the video on my CoreDuo would take long time. If I only have to correct the audio delays I might go along w/o the need to do this.

I'll check, I know I want an I7 but the old one just don't die ;)

mike

[rapscallion]

First time I ran into this. Demuxing an LPCM sound track, from Pearl Harbor, and the result was 3 separate wav tracks instead of 1.

2 @ 1 h 22m and 1 @ 17m (movie is 3h 3 m)

Any idea why this happened ?

[jdobbs]

First time I ran into this. Demuxing an LPCM sound track, from Pearl Harbor, and the result was 3 separate wav tracks instead of 1.

2 @ 1 h 22m and 1 @ 17m (movie is 3h 3 m)

Any idea why this happened ?You probably hit the size limit for the .WAV file. From the TSMUXER readme:

- PCM audio are saved as WAV files. Also automatically splitting into several files, if the size of WAV file exceeds 4Gb.

[rapscallion]

You probably hit the size limit for the .WAV file. From the TSMUXER readme:

- PCM audio are saved as WAV files. Also automatically splitting into several files, if the size of WAV file exceeds 4Gb.
Thanks jdobbs! wasn't aware of that limit. (my readme is in Russian and I never bothered to translate it)

I sure did go way over 4gb, more like 9gb total ! So, conversely, no way to remux back into 1 file along with the video ?

Just curious, not what I plan on doing. I'l save to 6 wavs, via eac3to, and then encode into DTS MA.

[mrr19121970]

You need to use eac3to to create a 64bit WAV (W64), and then you can remux.

From memory isn't Pearl Harbour in 2 .m2ts files? If so you're best off demuxing with eac3to anyway to fix any gaps or overlays that might result in an uplayable or out of sync title.

[coolalibaba]

what is the difference between the normal wav(.wav) and 64bit wav(w64)?

[mrr19121970]

what is the difference between the normal wav(.wav) and 64bit wav(w64)?

One has a 4gb limit due to 32bit addressing, the other doesn't.

[coolalibaba]

One has a 4gb limit due to 32bit addressing, the other doesn't.

thanks!

[jdobbs]

Thanks jdobbs! wasn't aware of that limit. (my readme is in Russian and I never bothered to translate it)

I sure did go way over 4gb, more like 9gb total ! So, conversely, no way to remux back into 1 file along with the video ?

Just curious, not what I plan on doing. I'l save to 6 wavs, via eac3to, and then encode into DTS MA. You should be able to remux them with the video into an M2TS using TSMUXER. Just an FYI: If you look in the stickys for this subforum you'll find an English translation of the TSMUXER readme.

[sylvain07]

hi
I have a problem with tsmuxer and the movie inception in bluray.
are the video and audio tracks cutting,
how to make?

[rapscallion]

Just an FYI: If you look in the stickys for this subforum you'll find an English translation of the TSMUXER readme.
I guess I didn't see the forest for the trees :thanks:

Question: For the first time, when demuxing *.mt2s stream, The DTS MA audio track (and the other 4 audio tracks) has Delay in ms automatically set to -8. (I demuxed the video/audio tracks separately)

Is that an info only display or does it do something?

I remuxed the exact same tracks without entering any delay and the display didn't show any delay.
Is it really gone/fixed or do I need to enter -8 ?

Edit : I entered -8 and the resulting file now displays as a +3 audio delay.

[Selur]

1. can anyone reproduce the following:
When muxing raw streams tsmuxer ignores the timeshift parameter, which results in asynch output.
When opening the muxed output, setting the timeshift again and saving, output is synch.
stumbled over this, here: http://forum.doom9.org/showthread.php?p=1467000#post1467000
2. is tsMuxeR still developed? and so is it worth to mail smartLabs or should I better look for an alternative?
(send an email to tsmuxer at smartlabs.tv hoping ... )

Cu Selur

[TEB]

hei. Not to derail this thread, but we will soon have an opensource TS muxer that will do most if not all and more that TSmuxer does:
http://forum.doom9.org/showthread.php?t=158765

[setarip_old]

@TEB

Is there a Windows executable version available now?

[coolalibaba]

hei. Not to derail this thread, but we will soon have an opensource TS muxer that will do most if not all and more that TSmuxer does:
http://forum.doom9.org/showthread.php?t=158765
uhoo, I've been expecting this for a long time as the developing of tsmuxer is actually dead.