TSPE 0.700 Public Beta out now! [Archive] - Page 5

View Full Version : TSPE 0.700 Public Beta out now!

Pages : 1 2 3 4 [5]

Ventolin

22nd November 2009, 17:42

Hi Dave,

Thank you very much for your post and for your kind words!

You'll be pleased to know that development has been continuing and a new release is just days away!

If you check the download page of the website you can see that 0.80 is in final testing. Some full licence holders are in a closed beta test for 0.80 and the final bugs are being sorted out as we speak.

I have just 1 big but minor bug to fix before I can release the next version, but I hope to have that fixed in the next few days. Barring any other "show stoppers" (there's been one already) the release should go ahead.

Regarding 0.755, (and for 0.80) it sounds like you may have a directshow filter issue. To quickly see if this is the case, just turn off the Video checkbox and try and edit your file. Just go through the motions and see if TSPE crashes. If it doesn't then the directshow filter setup is the cause.

As you may have read, best results are obtained with Haali and CoreAVC or FFDShow. Make sure these filters are in use by checking your system tray icons and right clicking the video window. You can force CoreAVC or FFDShow to be the h264 decoder by enabling DirectShow control and selecting the filter in the filter selection dialog window.

I hope that fixes your issues and answers your questions for now, no doubt you will have more when the new version is released! I'll make an announcement here when it's ready, though you can also check the website.

If you have any specific questions feel free to PM me.

Regards,

Vent

medp7060

13th December 2009, 09:30

I tried 0.755, it is not attractive at all. I hope the coming 0.8 will be "frame acurate", otherwise, it cannot stand out among other similar unitlities.

BTW, a commercial one is Videoredo, which is in a alpha test now. It may be the one everyone is expecting.

joerg

13th December 2009, 13:03

I bought the software in May, when it looked like development was really progressing. I had some reservations about buying a beta at the price that was asked and about the hardware lock, but was convinced by the fast and helpful forum replys from Ventolin.
I hoped to be able to cut my HDTV caps properly during summer time with that new version which was initially announced to be available around the 2nd week of june. It never came.
Always if someone asks the new version "will be out soon" - the last answer stated the last bugs should be fixed "in a few days" - and again it's been three weeks. This is starting to feel like a "Duke Nukem Whenever" which is quite frustrating. I am starting to wonder if I made a mistake buying the beta so early.
In the meantime I have tried TSDoctor (which is free in it's beta stage) which allows to clean, convert to ts and cut my m2ts files in one go. It has had lots of updates during the last few months. Unfortunately it also doesn't really support accurate cutting.
@medp7060: Thanks for the hint about VideoRedo. I'll have a look at it once it's released with h264 support.

Ventolin

14th December 2009, 20:19

Hi Guys,

@medp7060
Sorry, 0.80 isn't frame accurate. The current plan is to have frame accurate by version 1.00. 0.90 will have a new muxing engine which is a prerequisite for frame accurate editing.

I am unaware of any other applications that are similar to TSPE offering editing and analysis of any transport stream regardless of content inside! If there is do let me know!

@joerg
I have what I hope to be the public release version of TSPE 0.80 ready to go. I'm in the process of updating the website as we speak. If you can't wait then send me an email and I'll send you the pre-release version.

My apologies for the continued delay but hope to release 0.80 today or tomorrow.

Regards,

Vent

Ventolin

15th December 2009, 06:54

Hi folks,

Well, after days and days of "almost ready" (more like months ahem!), the next version,

TSPE 0.810 Professional is finally out!

You can download it here:

http://www.bitstreamtools.com/download

This version is fresh out of the closed beta test so I've labeled it as "Unstable Development Alpha Release" mostly because there are probably bugs which haven't been caught yet and need to be fixed. Updates will be added as and when bugs are fixed and new features added.

If you have a full licence you will need to regenerate your new licence details with the new version. A temp licence is inlcuded with the TSPE setup program which is used if no existing licence is found in the installation folder. The temp licence gives 30 days unrestricted evaluation.

A list of new features are given if you follow the "What's New" link, but here's a brief summary:

Windows 7 support
GUI Update
Timelines - PIDLine, PESLine, Timeline
Comskip / ShowAnalyser import
Application Setup and Uninstall
Update checking
Enhancements and Bug Fixes!

So, what's next?
0.90 - New Muxing engine, independant PID editing
1.00 - Frame accurate

No timeframes for the above I'm afraid, but I'll try and keep a stable beta and unstable alpha available so you can try out the newest versions.

Thanks to all for your support and feedback, of course you are always welcome to give some more!

Regards,

Vent

joerg

15th December 2009, 08:26

Great to see the new version is finally out! I have just downloaded and installed it but will probably not be able to really test it before the weekend.
You write "If you have a full licence you will need to regenerate your new licence details with the new version.". After installing and starting TSPE 0.810 it tells me it is "Licensed to Joerg" - so to me everything seems fine with regard to the license. Do I still need to re-generate and mail in my activation key?

canTsTop

15th December 2009, 17:45

medp7060

15th December 2009, 22:15

select 2min, but only output 2.4 s.

Ventolin

16th December 2009, 01:54

i did some tests with new version. here is sample http://www.mediafire.com/?mjm55izyaww and edl http://pastebin.com/f785da6b5

i open video in tspe, scan for errors, its clean. when cut some parts of video and save it. open edited video in tspe, scan for errors and there is:
Continuity Errors: 0, Transport Error Indicator Errors: 0
Timestamp gaps: 0, PCR gaps: 3
Total number of separate discontinuous regions: 3

edited video plays until first cut in vlc and mpc-hc with internal dxva decoder. mpc-hc with internal ffmpeg decoder plays all video, but there is some corruption in video near cuts. vlc version is 1.0.3, mpc-hc 1.3.1400.0

Hi canTsTop,

Thanks for your sample and edl.

Looks like there might be a bug in the PCR fixup code. I tested it on 0.755 and it was ok so will hopefully be able to fix it.

@medp7060
Can you please give some more information? A sample and edl as canTsTop did would be very helpful.

Thanks guys.

Regards,

Vent

prenz

23rd December 2009, 16:32

Hi Ventolino,

I have by accident found a sure way to crash TSPE (0.810):
- import any sufficiently large .ts
- scan it
- while scanning, move the time slider
- now TSPE will log a whole bunch of bogus inconsistencies, until it finally crashes after a minute or so.

Ventolin

23rd December 2009, 17:16

joerg

23rd December 2009, 19:39

Hi Ventolin,

did you overlook my posting?:
You write "If you have a full licence you will need to regenerate your new licence details with the new version.". After installing and starting TSPE 0.810 it tells me it is "Licensed to Joerg" - so to me everything seems fine with regard to the license. Do I still need to re-generate and mail in my activation key?

I would still like to know if there's any reason for me to re-generate and mail in the activation key. Would be great to get a short answer.

Regards
Joerg

Ventolin

23rd December 2009, 23:26

Hi joerg,

Sorry I didn't reply earlier, but I was expecting you to find that the old licence stopped working. I'm a bit surprised it is still working though!

No need to regenerate it if it's working fine, if it does fail then just resend your activation details as before.

Regards,

Vent

joerg

23rd December 2009, 23:43

The audio streams (in the original m2ts stream as well as in the remuxed and fixed stream) are displayed as being 64 kbit and 44100Hz:
PID: 0x184D: MPEG1 Audio Layer 2, 64Kbit/s @ 44100Hz
PID: 0x184E: MPEG1 Audio Layer 2, 64Kbit/s @ 44100Hz
In fact the streams are 256 Kbit/s @ 48000Hz.
So it looks like they are being mis-detected (doesn't look like this has any negative effect as far as I can tell, but I thought I'd mention it).

Yes, this does look like a minor bug, it will only affect the display side of things and will not affect the output. Hopefully will have this fixed soon.

It seems like this bug is still present in version 0.810.

Also I noticed that the new PES Line mode does not affect the way the "Jump back a frame" and "Junp forward a frame" buttons work - i.e. they always seem to work in the physical order of the frames, even while I'm viewing the PES line. Is this expected?

And I have a suggestion: would it be possible to allow advancing through the video frame by frame in the TSPE Internal Viewer? Currenty I can just press play. Such a feature would make it easier to really properly test edit points.

joerg

23rd December 2009, 23:45

Sorry I didn't reply earlier, but I was expecting you to find that the old licence stopped working. I'm a bit surprised it is still working though!

No need to regenerate it if it's working fine, if it does fail then just resend your activation details as before.

:thanks: That's what I wanted to know: will it fail visibly and let me know that it stopped working or can there be some side-effects that I won't notice. I guess your reply answers that question and I will get a clear message if it fails.

btw: I even exchanged my main harddisk in the meantime (my "old" WD Raptor broke (in the middle of the day while I was working with the PC) so I had to get a new disk and restore the system from a (much too old) backup) and the license kept working fine.

joerg

24th December 2009, 00:23

Hi Joerg,
1. With this sample you do need a preview offset of +3. The preview offset is dependant on the stream though which is why it is not remembered when you restart TSPE. I will have a look at ways to improve this situation.

Have you been able to make any changes for this with the new version? I tested this again and I am still not seeing the correct frame. I am using the latest CoreAVC (2.0.0) and Haali (1.9.355.21). For me this is a huge issue since I need to be able to see the correct frame in order to make proper cuts. Using the "test cut" feature is a workaround, but it is rather clunky. If the offset is dependent on the stream (as you said), I cannot even figure out the correct offset once and be done with it. :( Is there anything that can be done to resolve this or will we have to live with this?

2. When you set an end point, what you are actually setting the exact point at which to stop the edit. So if you are setting an I frame then everything upto that I frame is inlcuded but not the I frame itself. You would need to set the end point to the next frame in the PTS order.

This I agree is a bit confusing so I will have a look at changing this so the current frame you are looking at is also included.

It seems like this has not changed in the new version. This is a bit unfortunate since it makes making proper cuts very difficult - you never know where exactly to set the cut point if you want a specific frame included (due to the added difficulty of frame ordering within the stream).

[still 2.]However, if you do move past the I frame to the next B frame in PTS order, the resulting output is missing the last B frame before the target I frame (in PTS order) which is incorrect. This needs fixing.

It seems that this bug is still present, which is quite unfortunate since it makes clean cuts more or less impossible. After doing a cut I had a look at the resulting stream and found the following:

[...]
52:19.98 (I)
52:19.94 (I,P,B)
52:19.96 (I,P,B)
52:20.04 (I)
52:20.00 (I,P,B)
[end of stream]

Obviously the frame for 52:20:02 (probably an I,P,B frame) is missing.

3. M2TS vs TS - the sample has shown a few bugs which I need to fix before I can do any further analysis. Thanks for the sample again!

Also for this issue I would like to know if it has been fixed with the latest beta and clean edit now works with m2ts or if I need to convert the m2ts to ts first before doing my cut (I would obviously like to avoid that step). My first tests seem to suggest that this is fixed.

5. Jump time inaccuracy - this is a bug that I've known about but haven't got around to fixing yet.

This also seems to be unfixed.

I also found another bug, I believe. Move somewhere close to the end of the stream. Click the +10 seconds button (where no 10 seconds are left). The stream will jump to the last frame, which is fine. Click the "move back a frame" button one or more times. Now click the "move forward a frame" button. TSPE will tell you "No More Frames Found." and will refuse to move forward again.

The most important of these issues (at least for me) are the issue 1.) and the two issues listed at 2.) since they are essential for making proper cuts. I do not necessarily need true frame accurate editing (with re-encoding small parts (e.g. when I,P or I,P,B-frames are set as cut-in) of the video) - if I know I can set the cut-in at an I-frame and the cut-out at I or I,P frame that's good enough. But if I can't properly identify (see) the frames I actually cut at, this makes editing really difficult.

Ventolin

24th December 2009, 05:49

Hi Joerg,

Thank you for your excellent feedback! There's quite a bit, so I'll try and answer what I can now and look into the others later. Easy post first...

[Audio identification bug]
It seems like this bug is still present in version 0.810.
Yes, it's still there, I haven't fixed that bug yet, thanks for the reminder :)

Also I noticed that the new PES Line mode does not affect the way the "Jump back a frame" and "Junp forward a frame" buttons work - i.e. they always seem to work in the physical order of the frames, even while I'm viewing the PES line. Is this expected?
Try clicking the frames in the PES line! (Have a look at the What's New page on the website).

And I have a suggestion: would it be possible to allow advancing through the video frame by frame in the TSPE Internal Viewer? Currenty I can just press play. Such a feature would make it easier to really properly test edit points.
Try the mouse wheel after pausing! (This is listed in the Keyboard Shortcuts under the Help menu)

More in next post...

Regards,

Vent

Ventolin

24th December 2009, 06:45

Have you been able to make any changes for this with the new version? I tested this again and I am still not seeing the correct frame. I am using the latest CoreAVC (2.0.0) and Haali (1.9.355.21). For me this is a huge issue since I need to be able to see the correct frame in order to make proper cuts. Using the "test cut" feature is a workaround, but it is rather clunky. If the offset is dependent on the stream (as you said), I cannot even figure out the correct offset once and be done with it. :( Is there anything that can be done to resolve this or will we have to live with this?
For the samples you sent me, the offset is +3. I don't know why this is the case, but you are the only person to have reported issues with the accuracy - in all other streams it's frame accurate. This seems to be an issue with either Haali or CoreAVC but fixing this in TSPE will probably need internal filters to be written which might come in for version 2. It might be all your streams require the same offset - let me know if this is the case and I'll make the offset setting persistant.

2. When you set an end point, what you are actually setting the exact point at which to stop the edit. So if you are setting an I frame then everything upto that I frame is inlcuded but not the I frame itself. You would need to set the end point to the next frame in the PTS order.

This I agree is a bit confusing so I will have a look at changing this so the current frame you are looking at is also included.
It seems that this bug is still present, which is quite unfortunate since it makes clean cuts more or less impossible.
This isn't really a bug, as it performs as intended. Just remember that the end frame should be the first frame that you don't want. As I mentioned before it is a little confusing, but certainly possible. If the end point is going to be joined by another segment, then the end frame will be the last I or P frame if Clean Edits is on, so the actual end frame is determined by the stream frame order in this case.

After doing a cut I had a look at the resulting stream and found the following:

[...]
52:19.98 (I)
52:19.94 (I,P,B)
52:19.96 (I,P,B)
52:20.04 (I)
52:20.00 (I,P,B)
[end of stream]

Obviously the frame for 52:20:02 (probably an I,P,B frame) is missing.
In this sequence, the last displayable frame looks like 52:19.98(I) as the 2nd I frame (52:20.04) might not be complete. It's not as clean as it should be though, the last I and B frame shouldn't be there. I will probably have a go at cleaning this up for the next version, 0.90.

3. M2TS vs TS - the sample has shown a few bugs which I need to fix before I can do any further analysis. Thanks for the sample again!Also for this issue I would like to know if it has been fixed with the latest beta and clean edit now works with m2ts or if I need to convert the m2ts to ts first before doing my cut (I would obviously like to avoid that step). My first tests seem to suggest that this is fixed.
Yup, I hope I fixed that!

5. Jump time inaccuracy - this is a bug that I've known about but haven't got around to fixing yet.
This also seems to be unfixed.
Yeah, not quite fixed but alot better than it used to be. It gets it right mostly, but sometimes it's slightly out. Not too big an issue though as it's just for rough positioning anyway, but it can be fixed.

I also found another bug, I believe. Move somewhere close to the end of the stream. Click the +10 seconds button (where no 10 seconds are left). The stream will jump to the last frame, which is fine. Click the "move back a frame" button one or more times. Now click the "move forward a frame" button. TSPE will tell you "No More Frames Found." and will refuse to move forward again.
Nice bug! Looks like the +10 seconds goes over the end of the file, so seeking back frames fails - look at the byte position and compare it to the end byte position!

The most important of these issues (at least for me) are the issue 1.) and the two issues listed at 2.) since they are essential for making proper cuts. I do not necessarily need true frame accurate editing (with re-encoding small parts (e.g. when I,P or I,P,B-frames are set as cut-in) of the video) - if I know I can set the cut-in at an I-frame and the cut-out at I or I,P frame that's good enough. But if I can't properly identify (see) the frames I actually cut at, this makes editing really difficult.
Yeah, I agree it's sometimes hard to get the exact start / end frames matching with the actual frames in the edit, but for most streams this is the case. However, some streams such as yours are a bit more troublesome. That's why the Test edit point functions and Test Start / End point buttons are there along with fine tuning the frame displayed in the video window. They are compromises because getting it frame accurate for every transport stream with any content is pretty hard and using 3rd party directshow filters means some of that accuracy is out of my control.

However, I hope with the Timeline view and overlap detection finding the right edit points is alot easier with the new version.

To recap, to fine tune the edit point between two segments A and B:

First get 2 segments set:

Set the start & end point of segment A.
Click + to add to the timeline.
Set the start * end point of segment B.
Click + to add to the timeline.
Double click inbetween segment A and segment B to make a "Test Edit Point".

To fine tune:

Double click segment A or segment B to load that segment into the main viewer.
Change the start / end point.
Click + to add to the timeline. TSPE will auto detect if there's an overlap and change the relevant segment automatically.
Double click inbetween segment A and B to test again.

Remember you can leave the preview window open along side the main TSPE gui so it's doesn't take too long to fine tune the edit point.

Hope that helps, thanks again for your excellent feedback. I'll drop you an email about this also.

Regards,

Vent

joerg

24th December 2009, 12:46

This isn't really a bug, as it performs as intended. Just remember that the end frame should be the first frame that you don't want. As I mentioned before it is a little confusing, but certainly possible. If the end point is going to be joined by another segment, then the end frame will be the last I or P frame if Clean Edits is on, so the actual end frame is determined by the stream frame order in this case.

OK, to help me understand, let's assume I have the following:

01. 57:53.38 (I)
02. 57:53.34 (I,P,B)
03. 57:53.36 (I,P,B)
04. 57:53.44 (I)
05. 57:53.40 (I,P,B)
06. 57:53.42 (I,P,B)
07. 57:53.50 (I,P) <-- last visible frame that I want included
08. 57:53.46 (I,P,B)
09. 57:53.48 (I,P,B) <-- last frame that should be in the resulting stream according to the timecodes
10. 57:53.56 (I,P)
11. 57:53.52 (I,P,B)
12. 57:53.54 (I,P,B)
13. 57:53.62 (I,P)
14. 57:53.58 (I,P,B)
15. 57:53.60 (I,P,B)
16. 57:53.68 (I)
17. 57:53.64 (I,P,B)
18. 57:53.66 (I,P,B)

Where would I need to set the cut-out point if I want 07. to be the last visible frame in the resulting stream?

a) From a user standpoint (using physical frame order) considering what you said I'd go (from 07.) to the next frame (08.) using the next frame button and set that as cut-out (which is probably incorrect.)
b) From a user standpoint (using PTS frame order) considering what you said I'd go (from 07.) to the next frame in time order (11.) using the PES line feature (which is probably incorrect.)
c) From a logical standpoint I'd guess I have to select 10. as the cut-out-frame.

As you can see it is quite confusing if it works the way it is currently implemented.

In this sequence, the last displayable frame looks like 52:19.98(I) as the 2nd I frame (52:20.04) might not be complete. It's not as clean as it should be though, the last I and B frame shouldn't be there. I will probably have a go at cleaning this up for the next version, 0.90.

Actually from what I set as cut-out the 2nd I-frame SHOULD be there. If you look at the example I gave above, 07. is the frame I selected as cut-out. So considering what you said 06. should be the last (physical) frame included in the resulting stream. In my case 05. is the last frame included. Now you say 04. and 05. shouldn't be in the resulting stream while actually they should and 06. (which is missing) ahould be added!

Nice bug! Looks like the +10 seconds goes over the end of the file, so seeking back frames fails - look at the byte position and compare it to the end byte position!

Indeed it seems to go over the end of the file. Interestingly enough seeking back still works (still showing incorrect current byte position, but moving the picture and "Time" value). Only seeking forward frames again fails.

To recap, to fine tune the edit point between two segments A and B:

In my use case I (fortunately) have to cut only at the beginning and end so there is only one segment in the resulting list as there are no ads that I need to cut out. I just want these cuts at the beginning and end to be as exact as possible (call me pedantic if you want ;) )

satnews

24th December 2009, 18:51

Stable Release
Please note this version does not support Windows 7 for full licences and will not edit .m2ts files for temp licences.
Download both the beta version and trial Licence file.

1. TSPE 0.755 Main Application
2. TSPE 0.755 (17/03/09) 30 Day Trial Licence File

I'm using TSPE 0.755. Thank for great trial testing...
But i get big problem ;(
cant save my cuts, when i press [Edit] - nothing to do, just an error on log-window

Error:
Index was outside the bounds of the array.
PID: 0, iPii: 0, ProgIndex: 0
Error: Edit failed, only 376 bytes written.

I do not have that error on 0.810 with same ts-files at same time.

Like TSPE 0.755 cause it works more accurately for my side.

thank

p/s Windows XP Pro x64

dylmaster

29th December 2009, 13:04

Very quick test of 0.81 on ITV HD, which previously didn't work. It now successfully makes cuts that hold lip sync (which is a BIG improvement for me since previous problems were a deal buster), but there is an apparent faulty GOP generated around the cut resulting in a still frame or glitch for about half a second on replay. This is after setting both in and out points AFTER pressing the previous/next I frame button. At least these buttons now appear to work correctly (previously they didn't go to the same frames).
In general, the preview (using the latest version of CoreAVC) seems to be more touchy - yanking the slider to a different part of the file results in severe blockiness that clears after a few seconds of play or 'jogging'. I wish it was possible to lock the preview display to half size and thus avoid all the interlace artifacts. It should also be easy to force it to the correct aspect ratio. I hope these points can be considered for future versions but at least I can now consider using it again and finding some of the bugs!
Thanks for your effors Vent - however late!

Cela

2nd January 2010, 13:42

Hi Vent,
since New Year 2010 (Y2k10) TSPE 0.755 gets lost after entering 'Preview' via 'Set Test' with error messages in the log pane:
Error: Quick-parsing packet header
Der Index war außerhalb des Arraybereichs.
"... Index outside array..."

This error occurs since Jan 1, 2010 with all my newly recorded TS files on my Windows XP machine. I just confirmed this also to happen with old TS files by testing an ArteHD TS file recorded in Nov 2009 and succussfully processed (trimmed) with TSPE 0.755 in Dec 2009.

On my secod computer (Vista) I get the following error message with a recording from Servus TV HD from Dec 27, 2009
Error:
Der Index war außerhalb des Arraybereichs.
PID: 0, iPii: 0, ProgIndex: 0
Error: Edit failed, only 376 bytes written.

In addition there may also be a data problem with recordings from newly launched german language DVB-S2 services at Astra 19.2° E:
ORF1 HD, ORF2 HD, Servus TV HD, Das Erste HD, ZDF HD, etc.

Edit:
****
I guess it may be a license problem although the TSPE main window starts with correct "...Licensed to:..."
info.

I just found that there are the following 5 positions (^) changed in the Activation Key when I rerunTSPE Activation:
-----------------^-------------------^^
-------------------------------------^^
(no hardware or operating system change in the last few months!)

What should be done?
Renewing the TSPE 0.755 license and/or upgrade to TSPE 0.8 or both?

Thanks

joerg

2nd January 2010, 14:29

Cela

2nd January 2010, 16:25

Now with TSPE Pro 0.810 Licensed to Beta Test:
+ All older TS work
- Problem with TS from new ORF2 HD:
Set Start and End Point works.
Add to EDL works.
Preview Start/End point does NOT work.
Edit the item in the EDL does NOT work.

Error messages:
Error: Calculating Timestamp Framerate
StartIndex darf nicht kleiner als Null sein. [~ startindex < 0 not allowed]
Parametername: startIndex
...
Testing Start Point
Error: Testing Start Point
Ein leerer Pfad ist unzulässig. [~ empty path not allowed]
...
Changing search PID to match Frame Search Type
Changing search PID to match Frame Search Type
Copying Data...
Processing EDL Item: 1 of 1
Warning: No PCRPID Found, Please update the PMT with the PCR PID in the Table Editor <<<how to do the update?>>>
Error: PID tree failed validation checks

First 26 seconds (40 MB) cut with DVBViewer's TSPLayer from a 2+hours DVBViewer capture from ORF2 HD from Jan 1, 2010 can be found in
http://rapidshare.com/files/329270384/ORF2HD_test.ts

Hope you can fix this.

Regards

P.S.
ProjectX reports
-> Filetype is TS (generic PES Container)
-> demux
-> Service ID 0x1330
-> PMT 0x6C refers to these usable streams:
Video:
PID: 0xB68(#3)(H.264)
Audio:
PID: 0xB69(ger)(#4)
PID: 0xB6B(AC-3)(ger)(#7)[PD]
PID: 0xB6A(ENG)(#6)
Teletext:
n/a
Subpict.:
n/a
and demuxes the audio streams 'adjusting audio at its own timeline'.

tsMuxeR GUI 1.10.6 only recognizes the h.264 stream but none of the audio streams (maybe a problem related to the same cause?). Thus does not report the audio delay values which would apply to the audio streams demuxed by ProjectX. Thus no workaround until TSPE gets fixed.

rebkell

2nd January 2010, 17:21

I am seeing exactly the same problem. 0.810 works, but since clean cut doesn't work properly with 0.810 anymore I don't want to use that version.
Is there any workaround other that re-setting the clock to 2009 (I confirmed that this resolved the problem)?

I hope so, I'm currently using .755, haven't even downloaded the newer version. .755 has been doing everything I need and I have no need for anything else. I have my routine down pat and it's been working without a hitch for many many months.

The key problem is really the only problem I've had with TSPE since way way back.

HD65

3rd January 2010, 12:12

I have another issue, not Y2K10 related. I just bought an AVCHD camcorder and a HD Mediaplayer. I needed an AVCHD editor, and TSPE seems one of the few editing the PGS stream as well. This will keep the correct timestamp in the video, which is important to me. Most other editors ignore the PGS stream and don't include it in the output at all.

But I think there is a bug in TSPE's PGS output stream when there are two (or more) edits. It looks as if the "gap" which is fixed for video (see output below) is not applied to the PGS stream. As a result, the last subtitle of the first cut stays on the screen for the duration of the gap between the two cuts. You can also see this problem when you demux the output file and process the SUP stream in SupRip.

Processing EDL Item: 1 of 2
New PAT Created.
New PMT Created.
Processing EDL Item: 2 of 2
New PAT Created.
New PMT Created.
Video PTS gap of 10,5 seconds fixed at 00:00:10 in output file, 0x92E7100.
Section duration is 00:00:20 (555 video frames)
Average bitrate is 16,96 Mbps
Total time taken 2,36 seconds, write speed 19,3 MB/s
Edit complete: successfully written file with 43929984 bytes.
Creating Custom Filter Graph...
Video Loaded.

If I create two separate files of the same edits and then join them with tsmuxer there is no problem.

Ventolin

5th January 2010, 20:54

Hi Guys,

Sorry for the Y2K10 issue and for the delay in replying, I hope you can understand sometimes I am not able to respond immediately.

I have put a fix up on the website, TSPE 0.760. I hope that version works as 0.755 did.

I took the opportunity to update it to support Windows 7 and it has an online version check.

I haven't had time to test this version thoroughly though, so please let me know if there are any issues.

HD65 - please bear with me, this issue will need to be addressed in 0.810+ and might take a while to fix. Can you please provide a sample and short explanation on how to reproduce the error?

Cela, I will try and have a look at why your streams are failing but might take a while also.

Regards,

Vent

kirkusinnc

6th January 2010, 14:02

Getting a zero byte file in Firefox and an error in IE when I attempt to download the new version...

Kirk

Ventolin

6th January 2010, 14:34

Getting a zero byte file in Firefox and an error in IE when I attempt to download the new version...

Kirk
Hi Kirk,

I just tested it with IE, Opera and Firefox and could download it fine. What error message did you get with IE?

Regards,

Vent

HD65

6th January 2010, 20:08

...

HD65 - please bear with me, this issue will need to be addressed in 0.810+ and might take a while to fix. Can you please provide a sample and short explanation on how to reproduce the error?

...

Thanks Vent. I'll work on a small sample. Here's how to reproduce the issue:

- Take a film clip with three streams: video, audio and subtitle (e.g. from a HD camcorder). Say the duration is 4 seconds, with one subtitle per second.
- Use TSPE and place two edits in the EDL. Say the first and last second.
- Hit the edit button (v 0.810) so a new clip is created. The duration of this new clip is 2 seconds.

If you demux this new clip and use SupRip to make an srt file of the PGS stream, you'll see that SupRip thinks that the first subtitle lasts three seconds. When you play this clip in a player supporting subtitles, you'll never see the second subtitle.

Cela

10th January 2010, 20:17

I just found a couple of posts (in German language, let Google translate to English) which claim that in the context of certain DVB-S2 CBR services (ORF1 HD, ORF2 HD, arte HD, etc.) VBR material is blown up to CBR by NALU padding and that repacking the TS to MKV may reduce filesize down to 50 percent of the original.
See:
http://forum.digitalfernsehen.de/forum/hd-tv-die-zeitschrift/238797-das-maerchen-von-der-hohen-hd-bitrate.html
http://forum.digitalfernsehen.de/forum/hd-tv-die-zeitschrift/190891-orf-hd-vorschau-143.html#post375732
http://forum.digitalfernsehen.de/forum/hd-tv-die-zeitschrift/190891-orf-hd-vorschau-143.html#post3757702

In these posts it is adviced to
>1. demux the recorded.TS by tsMuxeR (~ 6 min) and then to
>2. mux to MKV by mkvmerge GUI from MKVtoolnix (and enter the respective fps attribute for the MPEG-4 par 10 ES video stream) (~6 min)

After
>3. demuxing the MKV with MKVextractGUI from MKVtoolnix (~7 min)
>4. and finally muxing back to TS by tsMuxeR (~6 min).
my tests yield TS-size reductions to 50%-70% of the original recording size.

Mkvmerge from MKVtoolnix (with its AVC/h.264 ES-Demultiplexer and its MPEG-4 part 10 ES-Video-output modul) seems to do the magic!

-> Feature request for TSPE_0.810:
Couldn't TSPE's Edit take care of removing the superfluous NALU padding on the fly?
It would save the time, effort and temporary disk space of the 4-step workaround! That would be a real cool, useful and efficient feature.

Regards

P.S.
TSPE_0.760 cured the Y2k10 and works with the license files from TSPE_0.755. Thanks!

P.P.S-
MarcN explains in
http://forum.digitalfernsehen.de/forum/hd-tv-die-zeitschrift/190891-orf-hd-vorschau-144.html#post3762895
"Nalu type 12 are so-called "filler data", large packages composed almost entirely of zero bytes. They are for example required if one requests the encoder to produce a fixed, high bitrate, but the picture does not provide enough information to fill the stream with it."

rebkell

10th January 2010, 22:51

Getting a zero byte file in Firefox and an error in IE when I attempt to download the new version...

Kirk

I just tried it with Firefox and it downloaded just fine, I'd already downloaded before on another machine and had no problems.

Ventolin

23rd January 2010, 05:42

@Cela,

Thanks for that info, I'll have a look into it. It will have to come after 0.90 though or even 1.0 but certainly a feature worth having!

Regards,

Vent

Lennen

30th January 2010, 18:52

Hi Everybody,

in the need for an appropriate H.264 capable cutting program, I came across this promising software and highly consider it for a purchase, but for now I have some trouble with my HDTV recordings from the German Astra channels (Das Erste HD, ZDF HD, Arte HD, Einsfestival HD).

Although the recordings seem to be fine and playback well with either DVBViewer or VLC player, I get endless PTS gap errors of 0,0 seconds when performing the file scan in TSPE. The gaps are written to the marker list and when I am scanning a large file, e.g. 2 hours Castaway movie, the application will crash after a while. I have tried TSPE 0.76 and TSPE 0.81 with different directshow codecs (ffdshow, PowerDVD, CoreAVC) on two different machines (XP 32bit and Vista 64bit), but without success.

I played with the scan options and it seems with the three options: >suppress related errors<, >suppress nearby errors< and >disable M2TS header checking< enabled, the application at least does not crash and finishes the scan after approximately half an hour, creating a 1.4 MB Log file with 25000 PTS gap errors!!!

The problem only occurs to 1280x720, 50fps material from the above mentioned channels. 1920x1080, 25fps, H.264 material and 720x576, 25fps, MPEG2 recordings, recorded with the same DVB hardware, passes the scan without any error. I am a newbe to HDTV and unaware if it is a problem with my PC configuration, with the recordings itself or with TSPE, so i have uploaded a very short sample. Maybe some helpful soul here can test the file with his working configuration.

You can download the sample here:
http://rapidshare.com/files/340484379/Einsfestival_HD_test.zip.html
The ZIP archive includes the .ts file, the .log file and the marker list.

The log looks like this:
PTS gap of 0,0 seconds in PID 0x0641 at offset 0x766B0
PTS gap of 0,0 seconds in PID 0x0641 at offset 0xCE448
PTS gap of 0,0 seconds in PID 0x0641 at offset 0x10E054
....
....
PTS gap of 0,3 seconds in PID 0x0641 at offset 0x8C5AC4
PTS gap of 0,0 seconds in PID 0x0641 at offset 0x925BD0

PID Tree:
PAT PID: 0x0000 Ver: 0 TS ID: 0x04B1
0x0640: PMT Ver: 1 Program : 28396
0x0641: H.264/AVC Video (as defined in ITU-T Rec. H.264 | ISO/IEC 14496-10 Video)
0x0642: MPEG1 Audio (ISO/IEC 11172-3 Audio)
0x0646: AC-3 Audio (DVB) Stream

PID List:
PID: 0641: H.264/AVC Video (as defined in ITU-T Rec. H.264 | ISO/IEC 14496-10 Video)
H.264 1280x720 (1280x720) @ 50,000 fps
PID: 0642: MPEG1 Audio (ISO/IEC 11172-3 Audio)
MPEG1 Audio Layer 2, 64Kbit/s @ 44100Hz
PID: 0640: PMT
PID: 0000: PAT PID: 0x0000 Ver: 0 TS ID: 0x04B1
PID: 0646: AC-3 Audio (DVB) Stream
AC3: 2/0: L,R 48KHz 256Kbit/s

Using the new timeline feature in TSPE 0.810, it seems that the gaps are detected on every single I and P Frame. I also noticed that the 256Kbit/s, 48kHz MPEG1 Audio is reported false as being 64Kbit/s, 44kHz and the Approximate System Bitrate is obviously not correct.

Thanks for your support!

onitoo

1st February 2010, 05:24

I came across an issue with TSPE 0.810. I used TSPE to cut out the commericals from a HDTV recording with 3 streams: video, audio and subtitles. I trimmed out only 1 commericals (65 seconds) in the middle of the film clip. When I played back the trimmed film clip, the first portion before the cut point is ok for video, audio and subtitles. But in the second portion after the cut point, the subtitles are delayed by the length of time of the commericals (65 seconds in this case).

In a second trial, I unchecked the "fix timecodes" box. This time the subtitles are in sync with the video and audio after the cut point. But of course the total time length of the film shown in the player is incorrect.

Is there a way to use the "fix timecodes" feature and without the subtitles out of sync problem? In fact I noticed that this issue also exists in earlier versions.

Regards,

pausefisk

1st February 2010, 12:38

Ventolin

9th February 2010, 04:32

Hi Lennen,

Sorry for not replying earlier.

Thanks for your sample and your bug report. It's quite an interesting stream you have there! Will add this to the bug list and figure out how to deal with it.

The audio is indeed reported incorrectly (a known bug which needs to be fixed!)

I think the approx system bitrate is correct though unless the duration is calculated incorrectly by both TSPE and the codec.

av. system bitrate = total number of bits / seconds

total number of bits = size of file in MegaBytes * 8

Regards,

Vent

Ventolin

9th February 2010, 04:34

Ventolin

9th February 2010, 04:37

It seems that there is an issue staring/running TSPE when bitdefender antivirus 2010 is installed and running.

I've been using TSPE for months in my vista 32bit, with bitdefender antivirus 2009, running fine, but now i switched to windows 7 64bit, running bitdefender anitivirus 2010.

If i set antivirus in game mode, TSPE starts fine, but crash when i load .ts file (HD), or if it loads fine, it crashed when playing.

I'm not sure if this is because of the antivirus or another thing... i got both ffdshow and haali installed. Any suggestion?

Hi pausefisk,

Sorry for the delay in replying.

I actually am running Windows 7 64bit on my development machine so will test with bitdefender 2010 and see if I can replicate the behaviour.

Does this happen with TSPE 0.760 and/or 0.810?

Regards,

Vent

Lennen

10th February 2010, 18:56

Hi Ventolin,

Thanks for your answer. I now can at least stop to search for the right configuration… Sad to hear that there is no simple solution so far.

Is there an understandable explanation, what exactly is different with this stream to cause such strange behavior? As I mentioned before the problem occurs exclusively to recordings in 1280x720, 50p format, which has become the new standard for all public German HD channels. I also noticed that different recordings from the same channel show completely identical average bitrates, so I think the streams will most likely be affected by the NALU padding issue, Cela mentioned above. When I apply the described procedure to my recordings, the file size indeed shrinks by about 3 percent, but in contrast to my slight hope, it has no effect on the zero seconds PTS gap issue.

To the average system bitrate question: File size was 9.698.920 bytes. Divided by 1024^2 and multiplied with 8 gives 73,997 Mbits. Divided by 9,3 seconds I come to 7,95665454 Mbits/s. TSPE on the contrary reports 795.665.453.839.046,00 Mbits/s. The digits are the same but the decimal point has shifted rightwards.

Regards,

Lennen

pausefisk

12th February 2010, 19:02

Hi pausefisk,

Sorry for the delay in replying.

I actually am running Windows 7 64bit on my development machine so will test with bitdefender 2010 and see if I can replicate the behaviour.

Does this happen with TSPE 0.760 and/or 0.810?

Regards,

Vent

Hi.

TSPE 0.755 = OK!
TSPE 0.760 = NOT LOADING
TSPE 0.810 = NOT LOADING

As for the crashing, it was my interal directoshow filters that caused it, i got that solved now. However i remember i had some issues with some .ts recordins in 0.755 wich worked fine in TSPE 0.810, so i hope you find a way to fix this ;)

PS!! I would be NICE to be able to change witch audio that should be played when cutting the video. Some times my recordings have several languages, and i have to listen to the "wrong" audio when cutting, wich can make it a bit hard to find the correct spots.

TheFrenchDumb

24th August 2011, 07:22

stable version crashed on my seven 64 bit

beta seems to work (just launching)

jmac698

8th September 2011, 02:13

Hello,
I have a good test case for you to work on. This stream isn't working in your latest beta
http://www.mediafire.com/?97306hu22241bhr
since your program can't find it, I'll give you a hint - the streams are 0x980 and 0x981, 1080p mpg2 and 5.1 ac3.
Though I don't know much about using it, however I was hoping your program would let me fix this stream.
thanks.

jmac698

8th September 2011, 05:54

The problem has been found - does your program support Transport Sync Error? And it was probably cut with mp2cut2.

xport Transport Stream Demuxer 0.96
program = 1, video channel = 1, audio channel = 1
Program Number = 1 (0x0001), Program Map PID = 55 (0x0037)
Transport Sync Error, skipped 73 bytes, at 44 <------------------------------ kills my PID detection!
program descriptor = 0x88, 0x04, 0x0f, 0xff, 0xc4, 0xfc
Video PID = 2432 <0x0980>, type = 0x02
Audio PID = 2433 <0x0981>, type = 0x81
ES descriptor for stream type 0x81 = 0x0a, 0x04, 0x65, 0x6e, 0x67, 0x00
Audio Bitrate = 384000, Audio Sampling Rate = 48000
Audio Mode = 2/0, bsid = 6, bsmod = 0
Sequence Header found
26 frames before first Sequence Header
Horizontal size = 1920
Vertical size = 1080
Aspect ratio = 16:9
Frame rate = 29.97
Sequence header bitrate = 25000000 bps
Progressive Sequence = 0
First Video PTS = 0xa89e0530
First Audio PTS = 0xa89dfd3b, -2037
ts rate = 450760, video rate = 3479986
packets for pid 0 <0x0000> = 197, first = 1, last = 48047
packets for pid 55 <0x0037> = 154, first = 1012, last = 48048
packets for pid 2432 <0x0980> = 42407, first = 50, last = 48178
packets for pid 2433 <0x0981> = 5424, first = 45, last = 48183
packets for pid 5269 <0x1495> = 1, first = 44, last = 44
coded frames = 454, video fields = 1135

patja

22nd November 2011, 05:21

TSPE is proving invaluable for repairing H.264 ts files from my Hauppauge Colossus HDMI source.

But I really need to be able to script it from the command line. All I need is the ability to load a source file and hit the edit button's method.

Is there an undocumented feature that would enable me to accomplish the above repair-only scenario in the current release?

If not, what are the plans for a command line-enabled version?

xara

30th May 2012, 21:54

A new alpha version is available (0.815 26/05/2012) but the free unrestricted license dont work.
Anyone sucessfully tested this version?

Nevermind... I got it. Upgrade my full license and works fine.
The new version seems to be very stable.
The previous one, 0.813, crashes all the time in my machine. But this performe like a rock.