View Full Version : tsMuxeR update for 3D blu-ray
jdobbs
16th December 2013, 22:40
I got a crash for this file. It is occured not every time and occured at the end of the work when output file already ready and muxer start to exit.Good to know it isn't only me.
Thanks.
HWK
16th December 2013, 22:44
I got a crash for this file. It is occured not every time and occured at the end of the work when output file already ready and muxer start to exit.
I tired again, however mine doesn't crash but give error message instead. Also it takes while for error message to appear, but no crash.
http://s30.postimg.org/u3ugnjlgh/Capture.jpg
Video Dude
16th December 2013, 22:49
Good to know it isn't only me.
Thanks.
jdobbs, I tried your video and it does mux on my system without error or crash, but the output file does not play.
ExSport
16th December 2013, 22:52
Yes, I can confirm that as well. Media info report says variable framerate for all the samples. Open in total code and it recognize stream not to be valid, it opens it but needs encoding to make it compatible. (GOP and dimension are two big ones which seems messed up) I will do more testing to be sure and see what I can come with.
More info on file, which I got after scanning and inspecting it...
Damn. This file is output generated with UniversalMediaServer (DLNA/UPnP server) so I never passed it via MediaInfo because file itself is compatible in HW players. It is tsMuxeR which makes it invalid (with SEI settings). FFmpeg itself has corrupt DTS output on hw players so tsMuxeR muxes video+DTS together.
Thanks guys for troubleshooting! Hopefully we will find the root cause why this file is so problematic for tsMuxeR so it can be fixed.
HWK were you able to reproduce it? Thx!
HWK
16th December 2013, 22:52
jdobbs, I tried your video and it does mux on my system without error or crash, but the output file does not play.
How many time did you try it out?
jdobbs
16th December 2013, 22:53
jdobbs, I tried your video and it does mux on my system without error or crash, but the output file does not play.Now try it with TSMUXER v1.10.6. It's a two second video of some trees outside my house.
HWK
16th December 2013, 22:53
Damn. This file is output generated with UniversalMediaServer (DLNA/UPnP server) so I never passed it via MediaInfo because file itself is compatible in HW players. It is tsMuxeR which makes it invalid (with SEI settings). FFmpeg itself has corrupt DTS output on hw players so tsMuxeR muxes video+DTS together.
Thanks guys for troubleshooting! Hopefully we will find the root cause why this file is so problematic for tsMuxeR so it can be fixed.
HWK were you able to reproduce it? Thx!
I am working on it.
HWK
16th December 2013, 22:57
Now try it with TSMUXER v1.10.6. It's a two second video of some trees outside my house.
Know that you mention it. Mux file created on my side has no video and furthermore elementary one is fine, so something is really messed up.
[update1]
tsmuxer 1.10.6 mux shows about 9 trees in zigzag shape and partially snow covered, which is not visible with 2.6.4.
Video Dude
16th December 2013, 23:01
Now try it with TSMUXER v1.10.6. It's a two second video of some trees outside my house.
TSMUXER v1.10.6 works. I see a tree with some snow on the ground.
How many time did you try it out?
Twice with v2.6.4, once with .ts mux and once with .m2ts mux.
HWK
16th December 2013, 23:16
Damn. This file is output generated with UniversalMediaServer (DLNA/UPnP server) so I never passed it via MediaInfo because file itself is compatible in HW players. It is tsMuxeR which makes it invalid (with SEI settings). FFmpeg itself has corrupt DTS output on hw players so tsMuxeR muxes video+DTS together.
Thanks guys for troubleshooting! Hopefully we will find the root cause why this file is so problematic for tsMuxeR so it can be fixed.
HWK were you able to reproduce it? Thx!
I did some more testing and it seems when SEI message are added GOP structure of a file is changed which can create problem with playback and giving appearance if jumping back and forth.
First one original, second processed through tsmuxer.
Look at M and N values, time stamp, number of frames and first PTS and many more all of them are different from original (don't worry about pid) even though they are same files.
http://s28.postimg.org/dhoue70wd/Comparsion.jpg
Explain why there is no smooth playback. I will continue to do more testing.
Take out SEI message and picture timing info, then GOP and total running time match, but first PTS time code doesn't match.
http://s30.postimg.org/8rocbzgbl/Comparsion.jpg
Alanick
16th December 2013, 23:19
Right click on the EXE and then select "Properties". At the bottom of the dialog there is an "Unblock" button. Click it, and then click on "Ok".
that I do know, I meant something permanent, cause no matter how many times you update, its back to same unblocking procedure, it must be done during the build of the app itself, to be signed or something, not to be considered harmful, I'm sure something can be done, maybe its not a priority, but worth fixing it.
ExSport
16th December 2013, 23:33
I did some more testing and it seems when SEI message are added GOP structure of a file is changed which can create problem with playback and giving appearance if jumping back and forth.
First one original, second processed through tsmuxer.
Look at M and N values, time stamp, number of frames and first PTS and many more all of them are different from original (don't worry about pid) even though they are same files.
...
Explain why there is no smooth playback. I will continue to do more testing.
Take out SEI message and picture timing info, then GOP and total running time match, but first PTS time code doesn't match.
...
Thank you! Don't understand to anything but hopefully it will help to Physic (if it is tsMuxeR bug but it seems it is because SEI settings will make this mess here-maybe unusual file but who knows if it can mess also other more general files...)
ExSport
16th December 2013, 23:35
that I do know, I meant something permanent, cause no matter how many times you update, its back to same unblocking procedure, it must be done during the build of the app itself, to be signed or something, not to be considered harmful, I'm sure something can be done, maybe its not a priority, but worth fixing it.
If you read my post you should understand there is nothing to fix. You can circumvent this behavior by changing local policy on your PC but highly not recommended!
HWK
16th December 2013, 23:36
Thank you! Don't understand to anything but hopefully it will help to Physic (if it is tsMuxeR bug but it seems it is because SEI settings will make this mess here-maybe unusual file but who knows if it can mess also other more general files...)
No problem, but if you noticed running time is increased by a sec for same file and information about how picture are stored within video when processed through tsmuxer. There are many more things for simplicity I will just list main ones.
SeeMoreDigital
16th December 2013, 23:40
Bloody iPhone files... What will they think of next to make saving our data easier?
jdobbs,
Does the iPhones original .mov (or .mp4) file work okay with MKVmerge GUI?
physic
17th December 2013, 00:08
jdobbs
I found the issue. Problem with inserting SEI messages for this file.
- tsMuxeR 1.10.6 can't do it, but just do nothing (inspite of message in log "inserting sei" appears, but it is lies).
- New version do inserting SEI and do it wrong. Stream became totally broken
Technically tsMuxeR can't insert NAL_HDR_PARAMETERS data, required for timing SEI, because of this stream doesn't contains VUI parameters at all. So, addition inserting step must be done.
I'll fix it today.
Sharc
17th December 2013, 00:13
Hi Roman,
I think there is some regression bug in version 2.6.4(b).
I'm trying to multiplex combined AVC+MVC stream and I'm getting error: "SPS picture order 3 not supported." (and nothing is muxed)
Muxing of combined AVC+MVC works here with 2.6.4(b) (muxing to .m2ts and .iso) .....
[Added:]
Hmmm... with another sample the muxing introduces glitches.
physic
17th December 2013, 02:23
jdobbs
I postpone this update to tomorrow.
HWK
Different in a first PTS value is not a problem at all. It is relative value and first value may be any (parameter "start mux time" on the BD tab is changed this value).
ExSport
I suggest to check one more short sample on a PS3. It is a stream with SEI messages and b-pyramid (like your ffmpeg_sample stream), but made by Scenarist:
https://drive.google.com/file/d/0B0VmPcEZTp8NUjRuUjdYRU9Dcms/edit?usp=sharing
Disk contains two one minute movies with different type of b-pyramid. They are played sequentially. Please, check their both.
HWK
17th December 2013, 02:25
jdobbs
I postpone this update to tomorrow.
HWK
Different in a first PTS value is not a problem at all. It is relative value and first value may be any (parameter "start mux time" on the BD tab is changed this value).
ExSport
I suggest to check one more short sample on a PS3. It is a stream with SEI messages and b-pyramid (like your ffmpeg_sample stream), but made by Scenarist:
https://drive.google.com/file/d/0B0VmPcEZTp8NUjRuUjdYRU9Dcms/edit?usp=sharing
Disk contains two one minute movies with different type of b-pyramid. They are played sequentially. Please, check their both.
You are right, PTS is not trivial. Don't know what was going through my head that time.
jdobbs
17th December 2013, 05:10
jdobbs
I found the issue. Problem with inserting SEI messages for this file.
- tsMuxeR 1.10.6 can't do it, but just do nothing (inspite of message in log "inserting sei" appears, but it is lies).
- New version do inserting SEI and do it wrong. Stream became totally broken
Technically tsMuxeR can't insert NAL_HDR_PARAMETERS data, required for timing SEI, because of this stream doesn't contains VUI parameters at all. So, addition inserting step must be done.
I'll fix it today.Great. Thanks!
jdobbs
17th December 2013, 05:10
Bloody iPhone files... What will they think of next to make saving our data easier?
jdobbs,
Does the iPhones original .mov (or .mp4) file work okay with MKVmerge GUI?I haven't tried the GUI, but MKVMERGE has no problem with it.
ExSport
17th December 2013, 05:24
ExSport
I suggest to check one more short sample on a PS3. It is a stream with SEI messages and b-pyramid (like your ffmpeg_sample stream), but made by Scenarist:
https://drive.google.com/file/d/0B0VmPcEZTp8NUjRuUjdYRU9Dcms/edit?usp=sharing
Disk contains two one minute movies with different type of b-pyramid. They are played sequentially. Please, check their both.
During the weekend I will be at home so I can test it (PS3+PanTV).
If anyone want to test it sooner, it will be much appreciated:)
I exctracted two m2ts files from provided IMG file:
https://www.copy.com/s/GoqLaZ6kKKEt/Test_Samples/Physic
@Physic: I expect these files will play ok as other my mkv files (remuxed with tsMuxeR).
But this ffmpeg sample is somehow specific from my other mkv files (not created with ffmpeg) so not sure what we can expect:cool:
Thx!
Cedvano
17th December 2013, 06:52
With the new version, I have "Not enought buffer for parse video stream" error.
And he check DTS when I have only AC3 !!!
The 2.4.1(b) work fine with the same meta.
Pecosbil
17th December 2013, 13:28
New version 2.6.4(b) is ready:
windows 32 bit: tsMuxeR_2.6.4(b).zip (https://drive.google.com/file/d/0B0VmPcEZTp8NVWxJNDFtbFdWbG8/edit?usp=sharing)
linux 32 bit: tsMuxeR_2.6.4(b).tar.gz (https://drive.google.com/file/d/0B0VmPcEZTp8NTGFFNDZnNlZMdTg/edit?usp=sharing)
MacOS 10.8 (64 bit): tsMuxeR_2.6.4(b).dmg (https://drive.google.com/file/d/0B0VmPcEZTp8NcDVrdVBUbzBxUjQ/edit?usp=sharing)
- Add secondary video support (PIP)
- fixed mp4 files with MPEG-DASH (HLS stream)
- fixed SEI again
- fixed DTS-ES recognition
- fixed font renderer (a little bit wrong text position)
- several minor improvments and bug fixes
The subtitle alignment problem is still there, line spacing is now fixed and it stays constant no matter what characters you're using.
I'm quessing that baseline isn't used for offset calculations, take a look at these pictures that I made: (First (http://personal.inet.fi/cool/pecosbil/first.png), Second (http://personal.inet.fi/cool/pecosbil/second.png)). As you can see, if a subtitle line contains characters like 'y' or 'g', the offset is calculated from the lowest point (i.e., in this case the 'y' character) and not from the baseline. Line spacing used to suffer from this same issue, but that was fixed with the latest update.
These are my settings (http://personal.inet.fi/cool/pecosbil/settings.png) for the subtitle renderer.
jdobbs
17th December 2013, 14:24
@physic
I've noticed that if I create output to a .SSIF file, and then compare it to a .SSIF that was generated within an ISO they do not match. Is that how it is supposed to work?
physic
17th December 2013, 14:26
Pecosbil
Ok. I'll check it using your settings. Since 1.6.4 I calculate base line offset as font descending value. Is it not correct?
physic
17th December 2013, 14:28
jdobbs
Should be same. I'll check it at evening. Are you sure that you use same PTS offset value for both files?
jdobbs
17th December 2013, 15:31
jdobbs
Should be same. I'll check it at evening. Are you sure that you use same PTS offset value for both files?Yes. They both use the same meta, except for the removal of the "--blu-ray" parameter when creating the SSIF.
Pecosbil
17th December 2013, 16:37
Pecosbil
Ok. I'll check it using your settings. Since 1.6.4 I calculate base line offset as font descending value. Is it not correct?
No, if you calculate the baseline from descending characters (like 'y' or 'g' for example) it will fluctuate depending on what characters the line is made of - as can be seen from the pictures.
The first image has two lines that doesn't contain any descending characters and the second one has them in both lines. The subtitles in the second picture are drawn 12 pixels higher (because of the 'y' character in the lower line) and they should be at the same vertical position. Previously this affected the line spacing as well but now it only affects the offset.
Sharc
17th December 2013, 19:45
@physic
The problem with glitches reported here (http://forum.doom9.org/showpost.php?p=1658093&postcount=1067)started with version 2.5.5(b) onwards.
No glitches with earlier versions.
Sample here (http://www.mediafire.com/download/gk8zdkibvbc6l3n/glitches.zip)
Cedvano
17th December 2013, 20:30
@physic
These glitches (http://forum.doom9.org/showpost.php?p=1658093&postcount=1067)started with version 2.5.5(b) onwards.
No glitches with earlier versions.
Samples here:
http://www.mediafire.com/download/gk8zdkibvbc6l3n/glitches.zip
I confirm for glitches and somes errors.
I have already mentioned but it went unnoticed.
videofan3d
17th December 2013, 21:01
videofan3d
I just remuxed two Combined H.264 source without error. Could you upload a sample?
Hi,
here is example of problematic Combined H.264 file:
Vysehrad (Prague) (http://www.uloz.to/xFcksLwJ/vysehrad-3d-cely-zip)
Version 2.4.1(b) muxes it without problems, while 2.6.4(b) fails.
Remark: it is about 5 minutes of HD-3D video - a bit bigger file. But as reward you can see nice part of Prague city ;)
Chetwood
18th December 2013, 06:35
If you read my post you should understand there is nothing to fix. You can circumvent this behavior by changing local policy on your PC but highly not recommended!
Or by saving your downloads to a FAT32 drive. Cause the info that a file has been downloaded from the Internet is stored in the alternate data streams that come with the NTFS filesystem.
idbirch2
18th December 2013, 10:08
The SysInternals tool 'streams' can also be used to remove the 'Downloaded from internet' flag: http://technet.microsoft.com/en-gb/sysinternals/bb897440.aspx
But there's no way for physic to fix this his end as the flag is set by Windows when you download the file and its written to disk.
r0lZ
18th December 2013, 10:58
There is a simple way to fix it! Simply distribute the exe in a ZIP archive. The exe file, once extracted, will not have the flag set. But is it really more convenient to have to extract the file from an archive instead of just clearing the flag? In the case of tsMuxeR, since there are two exes and one text file to download at each update, I think that distributing an archive could be more convenient.
alfixdvd
18th December 2013, 14:07
I mux a mkv file that contains video (AVC high@3.1, 1280x720) and audio (AC3 256Kb) and a srt file that contains subtitles.
Output is TS Muxing, the process not generate errors of muxing, but when I display the movie the subtitles are not shown: Media Player Home Cinema, Arcsoft TotalMedia Theatre, VLC, MPC-BE.
jdobbs
18th December 2013, 14:30
There is a simple way to fix it! Simply distribute the exe in a ZIP archive. The exe file, once extracted, will not have the flag set. But is it really more convenient to have to extract the file from an archive instead of just clearing the flag? In the case of tsMuxeR, since there are two exes and one text file to download at each update, I think that distributing an archive could be more convenient.The flag is still there when extracted from an archive on my system. TSMUXER can be downloaded as a zip. To get the zip instead of the individual files, just click on "File" at the top of the screen and select "Download". It will download a zip file.
laserfan
18th December 2013, 15:08
Or by saving your downloads to a FAT32 drive. Cause the info that a file has been downloaded from the Internet is stored in the alternate data streams that come with the NTFS filesystem.
I have never heard of this before and am having trouble surfing on it.
Is this the reason Windows sometimes says "the file you are attempting to run comes from an untrusted source r u sure you want to run it" or some such for downloaded exes?
r0lZ
18th December 2013, 16:33
The flag is still there when extracted from an archive on my system. TSMUXER can be downloaded as a zip. To get the zip instead of the individual files, just click on "File" at the top of the screen and select "Download". It will download a zip file.Oh, I haven't noticed that File menu before. Just tried it, and my Win8 doesn't show the warning when the exes are opened. I use 7-Zip to extract the exes. Maybe it's different with the Windows Compressed Folder. Anyway, that warning can be safely ignored when the source is trusted. It is obviously made for the newbies that do not know the risk.
co
18th December 2013, 16:37
@physic
I tryed to demux using the 2.6.4(b) this *.vob file
http://www.share-online.biz/dl/6I32D0YM7N6
which has a audio PCM stream embedded. The right channel is very noisy - unusable.
Could you please do something?
co
Cedvano
18th December 2013, 16:56
@physic
I tryed to demux using the 2.6.4(b) this *.vob file
http://www.share-online.biz/dl/6I32D0YM7N6
which has a audio PCM stream embedded. The right channel is very noisy - unusable.
Could you please do something?
co
I have noisy too with TsMuxeR, but with MeGui, I can extract this audio and remux with TsMuxeR.
All is good. Here the file (https://drive.google.com/file/d/0BxjaFf3cdexVRGF2cl8yWWhpYjg/edit?usp=sharing)
physic
18th December 2013, 17:47
Cedvano
I think glitches may be appeared because of I changed SEI messages. Is glitches exists if unselect "insert SEI" checkbox?
Cedvano
18th December 2013, 18:34
Cedvano
I think glitches may be appeared because of I changed SEI messages. Is glitches exists if unselect "insert SEI" checkbox?
Yes, glitches exists with "insert SEI" uncecked.
Here the two output info :
Network Optix tsMuxeR. Version 2.6.4(b). www.networkoptix.com
Decoding H264 stream (track 1): H.264/MVC Views: 2 Profile: High@4.1 Resolution: 1280:720p Frame rate: 23.976
MVC muxing fps is not set. Get fps from stream. Value: 23.976
B-pyramid level 2 detected. Shift DTS to 3 frames
Decoding H264 stream (track 2): Profile: High@4.1 Resolution: 1280:720p Frame rate: 23.976
H.264 muxing fps is not set. Get fps from stream. Value: 23.976
B-pyramid level 2 detected. Shift DTS to 3 frames
H264 bitstream changed: insert nal unit delimiters
Processed 999 video frames
Processed 1000 video frames
Flushing write buffer
Mux successful complete
Muxing time: 1 sec
Network Optix tsMuxeR. Version 2.4.1(b). www.networkoptix.com
Decoding H264 stream (track 1): H.264/MVC Views: 2 Profile: High@4.1 Resolution: 1280:720p Frame rate: 23.976
MVC muxing fps is not set. Get fps from stream. Value: 23.976
Decoding H264 stream (track 2): Profile: High@4.1 Resolution: 1280:720p Frame rate: 23.976
H.264 muxing fps is not set. Get fps from stream. Value: 23.976
H264 bitstream changed: insert nal unit delimiters
Processed 1000 video frames
Processed 1000 video frames
Flushing write buffer
Mux successful complete
Muxing time: 2 sec
As you can see, the last version lost 1 frame. And "B-pyramid level 2 detected. Shift DTS to 3 frames", there is only AC3.
Sharc
18th December 2013, 20:22
physic:
The glitches and missing frame happens with versions 2.5.5(b) / 2.5.7(b) / 2.6.4(b).
Unselecting "insert SEI" (for 'Base' and 'Dependent' stream) does not help.
physic
18th December 2013, 23:33
I working on reported problem. I'll release hotfix today or tomorrow.
spawnbsd
19th December 2013, 00:02
Any chance of fixing LPCM 5.1 and 7.1 muxing into an MPEG2 TS. Anytime I try doing this in the new releases, I get "The parameter is incorrect". If I use the 1.10.6 release it works fine.
Also (and less important), it would be nice if 7.1 LPCM channel order could be fixed, as far as I know TSmuxer has always messed up the channel order for 7.1 LPCM. I have to fix with eac3to:
http://forum.doom9.org/showthread.php?p=1261328#post1261328
Sharc
19th December 2013, 00:06
I working on reported problem. I'll release hotfix today or tomorrow.
Thank you. Take your time, no rush.
HWK
19th December 2013, 00:08
@Roman, may I suggest to include some validation to be done on source files if output is selected to be blu-ray iso or folder from muxer.
physic
19th December 2013, 00:15
spawnbsd
Could you upload a sample?
spawnbsd
19th December 2013, 00:25
spawnbsd
Could you upload a sample?
Here is a Dolby TrueHD 7.1 channel test file I've been using.
http://www.mediafire.com/download/5go3f4zwf2tj7t3/hd_dolby_truehd_channel_check_lossless.m2ts
Using eac3to, I have to remap using these parameters in order to get proper playback on my PS3. 5.1 LPCM content seems to be fine, I haven't tested 6.1 though, but I would expect it'll have issues like 7.1 (as we'll need to use eac3to to duplicate the back-center to back-left and back-right).
Finally, I have to use the old release of TSmuxer to mux it, any of your newer releases gives "The parameter is incorrect.".
E:\Projects\LPCM_7.1_Testing>c:\Vidstuff\Eac3to\eac3to.exe hd_dolby_truehd_chann
el_check_lossless.m2ts audio.w64 -0,2,1,6,7,4,5,3
M2TS, 1 video track, 1 audio track, 0:01:34, 60i /1.001
1: h264/AVC, 1080i60 /1.001 (16:9)
2: TrueHD/AC3, 7.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
Track 2 is used for destination file "audio.w64".
a02 Extracting audio track number 2...
a02 Extracting TrueHD stream...
a02 Decoding with libav/ffmpeg...
a02 Remapping channels...
a02 Writing W64...
a02 Creating file "audio.w64"...
a02 The original audio track has a constant bit depth of 24 bits.
Video track 1 contains 2832 frames.
eac3to processing took 2 seconds.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.