Log in

View Full Version : tsMuxeR update for 3D blu-ray


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 [24] 25 26 27 28 29 30 31 32 33 34 35

ExSport
21st December 2013, 02:48
ExSportThis build has not new changes for SEI, but has 3-state choose instead. You can make next test:
- Found a file which already has SEI messages. You can detect such file if tsMuxeR doesn't show "insert SEI" message during remux.
- Ensure that source file has not problem
- Select value "always rebuild SEI" and remux in the tsMuxeR this file. So, tsMuxeR is going to recreate SEI even if they already exists. If problem appears after it I'll compare source file and file after tsMuxR.
If I understand well, your Scenarist samples have SEI? Will try these files which I already tested(not remuxed) and no problems when I played them. But if problem is variable framerate which your sample probably don't have, it will work I suppose
@HWK: thx for your tests and variable framerate hint, will continue tomorrow....

HWK
21st December 2013, 02:56
ExSport
OK

HWK
I don't understand exactly why do you conclude that file has variable framerate? And yes, tsMuxeR doesn't support it and doesn't take it into account during generation SEI messages.

I use mediainfo on original file and this is what I get. If I encode file and set frame rate mode to constant then media info shows 23.976 fps. Also times stamp then matches to original file after muxing with tsmuxer, where variable shows 5:51:27 instead of 23 sec.

It doesn't matter if you demux first or not, it still the same. Only way out of this I can think off is use constant frame rate instead of variable.

BTW: I am referring to sample of Sony pictures

physic
21st December 2013, 02:58
ExSport
No, my sample has b-pyramid (I suspect b-pyramid cause problem but it is not confirmed), but has no SEI messages. And this file has fixed framerate for sure. So, if you got problem after remuxing this file, variable framerate can't explain it.

HWK
21st December 2013, 03:05
ExSport
No, my sample has b-pyramid (I suspect b-pyramid cause problem but it is not confirmed), but has no SEI messages. And this file has fixed framerate for sure. So, if you got problem after remuxing this file, variable framerate can't explain it.

Is that from preview of Disney plane movie or sample.

minhjirachi
21st December 2013, 04:11
In fact tsmuxer is blessing which was needed the most and i had seen that all of my multiplexing for 3d's are playing smoothly without any glitches even avataar.

Can you tell me the name of your 3D Player? Because I have test it on HTPC (nothing happed) but if I play it on 3D Player (IMAX-i18D, IMAX NX-3000, Dune Base 3D, Popcorn Hour A400, Himedia910B, Mede8er MED1000X3D), all of them were glitch.

Avatar was glitch at the scene 21. You can see pixel glitch (when Neytiri hit Jake Sully) and freezing (when Jake Sully explain his purpose to Navi People).

So please check it.

Sharc
21st December 2013, 08:46
Sharc
I have not idea yet how to fix it. I tried a lot of files (include your sample) and can't reproduce this problem. May be you can give me TeamViewer access to your PC?
Finally I found the solution to my .iso problem:
I have to activate "Use async I/O" in the 'General' Tab.
Does this make sense? Should it be set by Default?
I noticed that in 2.4.1(b) all the 'General' items are ticked by Default:
- Use async I/O
- Play sound at end (this is self explaining, LOL)
- Blu-ray audio PES


Added:
The muxing (whichever O/P format) introduces Glitches near the picture borders which are not present in the source file (combinedMVC in my uploaded sample). Did you see these glitches as well in your tests?

physic
21st December 2013, 13:45
Sharc
Great. So, new version save UI changes and this check box was always unselected on startup. The problem because of I did not implemented ISO writing correctly without this setting.
Actually it is depracated setting and no longer makes sense. I'll just remove it to next version. It is going to be always checked in core.

Sharc
21st December 2013, 14:27
Sharc
Great. So, new version save UI changes and this check box was always unselected on startup. The problem because of I did not implemented ISO writing correctly without this setting.
Actually it is depracated setting and no longer makes sense. I'll just remove it to next version. It is going to be always checked in core.
Excellent! One more issue nailed down. Thanks!

tebasuna51
21st December 2013, 14:59
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


Seems last version v2.6.7 (and not v2.6.6) solve the channel mapping problem with 7.1 PCM.

Still there are a little problem with PCM extraction, use always eac3to to extract audio from m2ts.

ExSport
21st December 2013, 16:11
ExSport
No, my sample has b-pyramid (I suspect b-pyramid cause problem but it is not confirmed), but has no SEI messages. And this file has fixed framerate for sure. So, if you got problem after remuxing this file, variable framerate can't explain it.
Ok, my fault. Anyway I tested these samples remuxed and no problems with playback as expected.
I was able to find only one sample with SEI, unfortunately it is with variable framerate (similar to my sample). If you have any sample with SEI and constant framerate, please send me a link for tests.
Back to the sample which I found here:
https://trac.ffmpeg.org/ticket/424
It is sample with SEI and variable framerate. Original file captured with some camcorder is 16MB in size and unplayable with PS3.
When I remuxed it with latest v2.6.7, it created valid file for PS3 with size under 10MB! I created two samples, one with original SEI and one with SEI rebuilt.
Sample with original SEI was replayed without glitch on PS3 but when tsMuxeR recreated own SEI, file is not so smooth. There are some judder/pauses/back frames or how to say that.
I recorded test progress so you can see the described behavior.
First file played is with original SEI, second one is with reconstructed SEI:
https://www.copy.com/s/GoqLaZ6kKKEt/Test_Samples (Browse to Recording folder for file: "Original and rebuilt SEI for variable framerate sample.mp4")
Second file there named "Behavior of every tsMuxeR version.mp4" is from previous test posted yesterday which I accidentally removed.
Test samples can be also found here (browse to Tests/SEI folder):
https://www.copy.com/s/GoqLaZ6kKKEt/Test_Samples/Tests/SEI
If original SEI is used also with sample using variable framerate, output seems correct. If tsMuxeR does own SEI, output is not smooth. It can be due to variable framerate as HWK mentioned and you agreed it is not supported but I don't have any SEI sample with constant framerate to make sure problem is only for variable framerate. Anyway if it is true, is it possible to add its support or if not, make tsMuxeR aware of that kind of files and disable SEI usage for variable framerate?
Many thanks!

minhjirachi
21st December 2013, 16:35
I want to ask how to check does tsmuxer calculate the TSRecordingRate number right or not? And how to calculate that number? Because when I mux same movie in Scenarist. I fill in the TSRecordingRate field the number, which generate by tsmuxer. And the Scenarist get to error: "Buffer Underflow" or "SSIF Allocation Failed at condition 5". So that I think tsmuxer has problem with that number and that why I always get glitch with movies remuxed by tsmuxer.

Sharc
21st December 2013, 19:48
Sharc
Great. So, new version save UI changes and this check box was always unselected on startup. The problem because of I did not implemented ISO writing correctly without this setting.
Actually it is depracated setting and no longer makes sense. I'll just remove it to next version. It is going to be always checked in core.
Did you have a chance to test my uploaded sample after remuxing it to .m2ts or .iso? I get Glitches near the picture borders which IMO are not present in the source (combinedMVC).
I am just asking in case it is a bug, or whether something is special with the source, or wrong with my playback.

physic
21st December 2013, 21:49
tebasuna51
Yes, I fixed 7.1 channels and I'll fix 7.0 as well to final tomorrow release. Which problem with extraction do you mean? I checked extracted via tsMuxeR wav file and it byte identical to eac3to extracted wav except of wav header.

minhjirachi
tsMuxeR calculate it just as avarage bitrate throughout a file. I know that this is not entirely correct. I am going to change this value to maximum allowed value 48Mbit in tomorrow release. I suppose it is better than avarage bitrate because of maximum bitrate value allow to use extents of 1312 sectors for dependend view (instead of 1056 sectors in the current version). More long extent is better for reading from BD disk in case of high bitrate. Also, I am going to improve bitrate control in tsMuxeR according to BD specs. in a future versions.

Sharc
I don't see any Glitches in TMT5. If you mean some vertical Glitches near the left or right border, try to change option "use base video stream for right eye".

Sharc
21st December 2013, 23:35
tebasuna51
Sharc
I don't see any Glitches in TMT5. If you mean some vertical Glitches near the left or right border, try to change option "use base video stream for right eye".
ok. Thanks for checking. I guess it could be Stereoscopic Player using CoreAVC which introduces these glitches.
Never mind.

HWK
22nd December 2013, 00:00
ok. Thanks for checking. I guess it could be Stereoscopic Player using CoreAVC which introduces these glitches.
Never mind.

Which movie is giving this problem. I recently ran into few movies where coreavc was having trouble decoding dependent view. The Croods is one of them.

Sharc
22nd December 2013, 00:27
Which movie is giving this problem. I recently ran into few movies where coreavc was having trouble decoding dependent view. The Croods is one of them.
No movie, just the sample which I uploaded for investigating the .iso failure.

rodm
22nd December 2013, 01:52
rodm
I checked iso disk built on OS X 10.8 and havn't found problem. Of course, your report OS X 10.9, but I havn't it yet. Could you check your disk once more on version 2.5.7 and if problem still exists create short 1-2min long iso file and send it to me?

Just to close this one off - I now have it all working (but ONLY under Windows). TsMuxer just doesn’t work under OSX 9 for all of the (many) files I have processed.

I have spent hours experimenting with TsMuxer under OSX 9 and haven’t been able to produce a single good BR disk (with a BDMV folder burnt to it) even though the same source files worked under OSX 8.
I have tried many different source video files and many different settings.

When I copied my .ts files to a Windows 7 machine, that had been produced on my OSX 9 iMac, and used the Windows version of TsMuxer to produce the BDMV folder it all worked fine.

So, the same source .ts files always work with the Windows version of TsMuxer, but never with the OSX 9 version.
So, be warned, when you eventually move to OSX 9 you may have some problems??? I don’t think it is a bug in TsMuxer per se - I suspect it’s some funny interaction with OSX 9?

Anyway I’m under way again, and TsMuxer is great (on Windows and OSX 8). Many thanks for all the good work Roman.

I will donate some money!

Cheers, Rod.

minhjirachi
22nd December 2013, 09:54
Fixed!

physic
22nd December 2013, 11:12
minhjirachi
Parameter 3D-offset is written to meta for BD muxing only. You used TS muxing instead.

Emulgator
22nd December 2013, 12:14
tsMuxeR calculate it just as avarage bitrate throughout a file.
I know that this is not entirely correct. I am going to change this value to maximum allowed value 48Mbit in tomorrow release.
I suppose it is better than avarage bitrate because of maximum bitrate value allow to use extents of 1312 sectors for dependend view
(instead of 1056 sectors in the current version).
More long extent is better for reading from BD disk in case of high bitrate.
Also, I am going to improve bitrate control in tsMuxeR according to BD specs. in a future versions.

Good to hear !
The Blu-ray TS muxers I had to work with (SONY DVD-A Pro 5.0, 5.2, 6.0, Adobe Encore -> Sonic, DVDitProHD -> Sonic)
have to perform stream checks before and while muxing.
Each stream to be muxed has to be checked according to VBV model.
Streams leading to violations have to be rejected, in best case issuing a detailed report.

minhjirachi
22nd December 2013, 15:17
minhjirachi
Parameter 3D-offset is written to meta for BD muxing only. You used TS muxing instead.

So sorry about my mistake. Waiting for your release.

Good to hear !
The Blu-ray TS muxers I had to work with (SONY DVD-A Pro 5.0, 5.2, 6.0, Adobe Encore -> Sonic, DVDitProHD -> Sonic)
have to perform stream checks before and while muxing.
Each stream to be muxed has to be checked according to VBV model.
Streams leading to violations have to be rejected, in best case issuing a detailed report.

Yeah. You will like this. :D

physic
22nd December 2013, 17:44
Emulgator
Two pass muxing is not required in any way. Any VBV control can be done on the fly. I already has plan how to add this VBV code (actually tsMuxeR has such code, you can see it on the General tab, but current abilities is not enough for 3D and this mux mode is not used for BD disks). It is going to increase CPU usage a little bit abount 5-10% during a muxing. But that's all.

physic
22nd December 2013, 18:38
ExSport
I have good news for you. I've got PS3 today and investigated your problem. I've found solution.
The problem because of your sample doesn't has flag "fixed frame rate" inside VUI parameters (HWK mentioned it). As soon as SEI data appears, PS3 goes crazy because of invalid flag value. I tried to correct this flag manually and sample start work correctly with SEI messages. So, I'll introduce this flag correction during rebuilding VUI/SEI parameters. It is going to be incuded to today release.

ExSport
22nd December 2013, 19:47
ExSport
I have good news for you. I've got PS3 today and investigated your problem. I've found solution.
The problem because of your sample doesn't has flag "fixed frame rate" inside VUI parameters (HWK mentioned it). As soon as SEI data appears, PS3 goes crazy because of invalid flag value. I tried to correct this flag manually and sample start work correctly with SEI messages. So, I'll introduce this flag correction during rebuilding VUI/SEI parameters. It is going to be incuded to today release.
Great! Thanks Roman!
Btw. I made same tests on Panasonic TV and samples remuxed with older versions than v2.5.7 were unplayable, with newer versions samples played but my feeling was it was not so smooth.
Also it seems PS3 is more sensitive because remuxed sample from camcorder "variable-ts720p_i_fr_rebuildSEI_2.6.7.ts" which stuttered (sample with fox and bird) but on Panasonic TV I didn't spotted it:confused:
So many thanks for finding the root cause (also HWK thx for your tests and hints) and final fix.:thanks:

physic
22nd December 2013, 20:02
Stable version is ready: tsMuxeR 2.6.9

windows 32 bit: tsMuxeR_2.6.9.zip (https://drive.google.com/file/d/0B0VmPcEZTp8NcnB0TU9MOEhEQ3c/edit?usp=sharing)
linux 32 bit: tsMuxeR_2.6.9.tar.gz (https://drive.google.com/file/d/0B0VmPcEZTp8NdjJ2NWR1aHg3Ylk/edit?usp=sharing)
MacOS 10.8 (64 bit): tsMuxeR_2.6.9.dmg (https://drive.google.com/file/d/0B0VmPcEZTp8NamN4dkNjOElxRlk/edit?usp=sharing)

There is no new functions since previous build 2.6.x, only bug fixes.

xledentaldj
22nd December 2013, 20:54
Great!! Awesome!!! Posted over at the Networkedmediatank.com forum:
http://www.networkedmediatank.com/showthread.php?tid=68815&pid=638033#pid638033

HWK
22nd December 2013, 21:03
So many thanks for finding the root cause (also HWK thx for your tests and hints) and final fix.:thanks:

No problem at all. Glad I could help you and Roman.

Gegette
22nd December 2013, 22:08
Stable version is ready: tsMuxeR 2.6.9

windows 32 bit: tsMuxeR_2.6.9.zip (https://drive.google.com/file/d/0B0VmPcEZTp8NcnB0TU9MOEhEQ3c/edit?usp=sharing)
linux 32 bit: tsMuxeR_2.6.9.tar.gz (https://drive.google.com/file/d/0B0VmPcEZTp8NdjJ2NWR1aHg3Ylk/edit?usp=sharing)
MacOS 10.8 (64 bit): tsMuxeR_2.6.9.dmg (https://drive.google.com/file/d/0B0VmPcEZTp8NamN4dkNjOElxRlk/edit?usp=sharing)

There is no new functions since previous build 2.6.x, only bug fixes.
Great work !

It's time to donate :cool:

Merry Christmas !

Necrologyst
23rd December 2013, 03:16
physic

thanks for the update of software, I haven't made any test yet but wanted to ask something.

As I'm new to this I've been reading and reading, it seems that years ago (found 2009 boards) people where having problem when remuxing a blu ray, the final result when burned and tested on retail players had problems with chapter skipping and ff and rwd buttons.

I'm having that kind of issues when remuxing 3DBD (want to replace and audio and keep menus, as i mentioned earlier). It's a BD where you can choose 2D or 3D. Playback in 2D has no problems, but in 3D becomes pixelated and jerky when next chapter o ff buttons are pressed. Maybe tsmuxer is not handling right this matter with 3D discs (maybe because of dependent view?)

Another thing I noted is that, when loaded a mpls file, tsmuxer shows the movie with 1 less milisecond and some chapter points also 1 less milisecond, I thought that it may be a rounding numbers thing, but wanted to mention.

So... Any idea on what may be happening?

Thanks in advance.

Chumbo
23rd December 2013, 05:06
Congrats on a stable build. :) I just grabbed i to check it out and noticed that the output file name now defaults to the C:\Users\username folder and doesn't change to the location from where files are added. This happens when using the Add as well as drag-and-drop. Not sure if this was a change due to some other request, but it would be nice if it worked the way it did before, i.e., use the source folder of added file(s) (first file for multiples). Thanks.

filler56789
23rd December 2013, 05:39
I just grabbed i to check it out and noticed that the output file name now defaults to the C:\Users\username folder and doesn't change to the location from where files are added. This happens when using the Add as well as drag-and-drop.

+1. Many people install the OS to a small partition of the HDD, and in these cases there is not much room for huge remuxes.

HWK
23rd December 2013, 06:33
+1. Many people install the OS to a small partition of the HDD, and in these cases there is not much room for huge remuxes.

Count my vote as well, although i have 400 GB + on SSD. But I like ability to choose and have program save location for future. Also since my drive is read only mode, last thing I want to loose everything.

tebasuna51
23rd December 2013, 10:52
tebasuna51
Yes, I fixed 7.1 channels and I'll fix 7.0 as well to final tomorrow release. Which problem with extraction do you mean? I checked extracted via tsMuxeR wav file and it byte identical to eac3to extracted wav except of wav header.
The wav's aren't byte identical, the extracted by tsMuxeR have 4 bytes more and for that the headers are different.

A hex dump:
Position -------------------------- Extracted by tsMuxeR --------------------------
000000000 52 49 46 46 00 08 7D 06 57 41 56 45 66 6D 74 20 28 00 00 00 FE FF 08 00
-----
000000024 80 BB 00 00 00 94 11 00 18 00 18 00 16 00 18 00 3F 06 00 00 01 00 00 00
000000048 00 00 10 00 80 00 00 AA 00 38 9B 71 64 61 74 61 C4 07 7D 06 00 00 00 00
... --
108852528 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 16 80 B1 C0
... -----------
108857328 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

------------------------------------- Extracted by eac3to ---------------------------
000000000 52 49 46 46 FC 07 7D 06 57 41 56 45 66 6D 74 20 28 00 00 00 FE FF 08 00
-----
000000024 80 BB 00 00 00 94 11 00 18 00 18 00 16 00 18 00 3F 06 00 00 01 00 00 00
000000048 00 00 10 00 80 00 00 AA 00 38 9B 71 64 61 74 61 C0 07 7D 06 00 00 00 00
... --
108852528 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
... -----------
108857328 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-------------------------------------------------------------------------------------

There are 2 problems:

1) The Data Length 108857284 (hex C4 07 7D 06) is not multiple of Sample Length 24 (3 bytes, 24 bits, for each 8 channels).
Some soft can reject this wav as invalid.

2) The 4 extra bytes 16 80 B1 C0 make a audible click (-4 dB) at end of Front Left channel.

These 4 bytes are the PCM header of last PCM block than is incorrectly transfered to the wav output.

physic
23rd December 2013, 14:13
HWK
tsMuxeR save last output dir. Home folder is used for first run only.

tebasuna51
ok. I'll check it

Chumbo
23rd December 2013, 15:40
HWK
tsMuxeR save last output dir. Home folder is used for first run only....
Any chance of adding a "use source folder for output" or have it work the way it did, i.e., when we load a file, it then uses the source file's folder? The saving the last folder seems to only work while it's running. Once it's closed and reopened, it goes back to the home folder. Right now it's just more work to have to constantly change the output folder.

One thing I tried was to remove the folder altogether but the file was not saved in the home folder nor the source folder. Where does it save the file if the folder is not provided? It would be nice if it saved the file to the source file's folder if no path is provided. Thank you.

hndts
23rd December 2013, 17:44
Every movie with the length more than 2 hours, glitch & pixelated, I think

physic
23rd December 2013, 21:28
Chumbo
Saving last output folder works for sure. May be tsMuxeR doesn't has right on your PC to write settings to the registry. It create settings at:
HKEY_CURRENT_USER\Software\Network Optix\tsMuxeR
Or you has problem under other OS?

pistacho
23rd December 2013, 21:40
In my system Output dir is created in:
HKEY_CURRENT_USER\Software\Network Optix\tsMuxeR\general\general\outputDir

But is (not) read from:
HKEY_CURRENT_USER\Software\Network Optix\tsMuxeR\general\outputDir because not exist

Seems a bug :eek:

physic
23rd December 2013, 22:43
pistacho
very weird. I just rechecked it - my PC has not this problem. May be some QT bug. I'll investigate it.

filler56789
23rd December 2013, 23:06
My suggestion: drop the Registry and use a .ini file.

Nico8583
24th December 2013, 02:30
I have several questions when demux BD :
- Is timeshift used ?
- Are insertSEI and constSPS necessary ?
- Are no-pcr-on-video-pid, new-audio-pes, vbr, vbv-len and start-time necessary ?

And when do you plan to integrate 3D subtitles informations from MVC stream ? :) It's just for my info.

Thanks !!

HWK
24th December 2013, 03:28
And when do you plan to integrate 3D subtitles informations from MVC stream ? :) It's just for my info.

Thanks !!

Physic, integrated into tsmuxer, is there title you are having problem with.

Chumbo
24th December 2013, 03:43
Chumbo
Saving last output folder works for sure. May be tsMuxeR doesn't has right on your PC to write settings to the registry. It create settings at:
HKEY_CURRENT_USER\Software\Network Optix\tsMuxeR
Or you has problem under other OS?
I'm running under Windows 8.1 Pro 64bit in this case. I found outputDir under:
HKEY_CURRENT_USER\Software\Network Optix\tsMuxeR\general\general
However, the value is NOT using the correct Windows/DOS slashes, i.e., using foward (/) instead of backslashes (\), e.g., C:/Users/username. Not sure if the path slash is an issue. I did launch tsMuxer as Administrator and it still loaded the path as C:\Users\CHUMBO\default.ts. Launching with Administrator should resolve any rights issues...you would think. ;)

My suggestion: drop the Registry and use a .ini file.
I'd recommend staying away from the registry too. So +1 for .ini file.

[EDIT] I just manually created outputDir under HKEY_CURRENT_USER\Software\Network Optix\tsMuxeR\general and launched tsMuxer and it did properly read outputDir. So it does look like it's the location that's getting mucked up between write/read.

Nico8583
24th December 2013, 10:07
Physic, integrated into tsmuxer, is there title you are having problem with.
If is already integrated, I don't find it :D
Where are extracted informations ? Or what can I do to extract them ?

Cedvano
24th December 2013, 10:11
Physic, integrated into tsmuxer, is there title you are having problem with.

Subtitles are in 2D, but not in 3D.

SubJunk
24th December 2013, 11:08
There seems to have been a regression between 2.6.4b and 2.6.9. I've uploaded a sample to show the bug here (http://www.spirton.com/uploads/Unsorted/20131224-sample.mkv). The output from 2.6.4b plays with VLC Media Player (tested with 2.0.7) but the output from 2.6.9 doesn't.
It's the same when playing via PS3.

r0lZ
24th December 2013, 11:41
Subtitles are in 2D, but not in 3D.Correct, but there are SEI messages in the MVC stream that contain the offsets to use to display the subtitles in 3D: the so called "3d-planes". I have asked Roman to add a function to retrieve these values, so that they can easily be used to convert the PGS subtitles to 3D side-by-side or top&bottom IDX/SUB files. Roman has promised to add that feature soon. I suppose it's on his (long) list of things to do for the next stable release...

Cedvano
24th December 2013, 11:56
Correct, but there are SEI messages in the MVC stream that contain the offsets to use to display the subtitles in 3D: the so called "3d-planes". I have asked Roman to add a function to retrieve these values, so that they can easily be used to convert the PGC subtitles to 3D side-by-side or top&bottom IDX/SUB files. Roman has promised to add that feature soon. I suppose it's on his (long) list of things to do for the next stable release...

Ok, thanks for information. Let Physic enjoy the holiday season.

nunub
24th December 2013, 13:02
At last the beta period is over and a stable era has started, there is no glitches and i hope some new features concerning 3d might be added by physic.

godu
24th December 2013, 13:05
Any problem detected with Windows 8 64Bit or is the tsmuxer compatible?