 Transport Stream Packet Editor - updates |
Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
 |
|
| Transport Stream Packet Editor - updates |
     |
Das einzige Tool was ich gefunden habe mit dem man H.264 Streams editieren kann:
| Zitat: |
Copy and Paste_1: GUIDE TO TS PACKET EDITOR (TSPE)
What is TS Packet Editor?
===================
It is a tool which allows you to trim (edit) and perform error scans on Transport Stream files (.ts) containing either MPEG2 video data or h.264 video data. The data can be standard definition or high definition (tested with SD MPEG2, HD MPEG2, and 720p and 1080i h.264). TSPE can analyse the stream and scan (quickly!) for the most common types of capture errors, that is 'continuity errors' and 'TEI errors'. Additional features (e.g. PID stripping) are planned for possible future versions.
Think of it as combining some of the most convenient features of HDTVtoMPEG2, MPEG2Repair, GSpot and TSReader Pro in a single fast, efficient package. And did I mention it handles h.264?
TSPE is an extremely precise tool, with sub-frame accuracy, even down to actual Transport Stream packets if you like. But note, unlike VideoRedo, it cannot re-encode the video if making an edit between keyframes. That's to say, you can make edits between keyframes, but if you play back the result it will have a few frames of stationary video before it picks up full motion video from the first keyframe found in the edit (you might still want to do an edit like that to get a good audio edit position). On the other hand, an edit can end with any frame, the end point does not have to be a keyframe.
Summary: edit Start points should be at video keyframes (the edit points can be between keyframes, but the additional frames will not be displayed in playback); edit End points should be at video frames. It is also possible for advanced users to edit by reference to audio frames, not video frames.
Limitations:
* Understanding all the features of TSPE requires basic knowledge of transport stream structure and PIDs (see Detailed Guide below)
* When editing, the accuracy of the video preview depends on the quality of your Directshow codec setup for your input file (see Setup section 3 below)
* When editing, TSPE 0.301 keeps all PIDs, it does not discard null packets or other unwanted PIDs
* TSPE's error scan and analysis functions work with transport streams, not with the underlying elemental streams - while TSPE will detect most types of capping errors, it will not detect video encoding errors in the underlying video, as for example MPEG2Repair can do
* TSPE cannot repair errors, although some of its features may help you to do that 'manually' (e.g. make a 'Frankencap')
* TSPE cannot repair timestamp or timecode errors (PTS or PCR) although that may be coming some time in the future
* TSPE is still at early stages of development. It has been tested with most types of material available and it seems stable. But it may be untested or incompatible with your type of input file. The tool may still contain bugs and it may introduce errors or other damage in its output files: if using on precious material you are advised to retain the input file as well, at least until you have (1) verified the TSPE output using another error-scanning tool; and (2) watched the output all the way through to check for glitches: if you don't do that it is at your own risk!
* TSPE is written for Windows XP, not Vista or other OS. If you have it working in Vista by all means let people know, but don't be surprised if it doesn't work exactly the same way.
Setup
=====
1. Install .NET Framework 2.0 from Microsoft
(If you don't want to install that full package then you could try the lite Framework runtime library from http://www.nliteos.com/ - TSPE has not yet been tested with this: please report if you have success!)
2. Download and extract TSPE to a folder, for example C:\Program Files\TSPE
The package consists of 3 files:
Code:
TS Packet Editor.exe
Interop.QuartzTypeLib.dll
Interop.Scripting.dll
3. IMPORTANT: Check that you have good Directshow playback of your input file on your PC: this means that your input file can be played correctly in Windows Media Player (or using "Render File" in GraphEdit).
For best results, a file should be played using the following filters:
+ either Gabest MPEG Splitter (mpegsplitter.ax) version 1.0.0.3 or later (recommended - also known as MPC internal splitter) or Haali Media Splitter version 1.6.193.1 or later
+ video codec (for h.264, choice of CoreAVC Pro (recommended) or Cyberlink H264/AVC decoder**)
+ AC3 Filter
**Elecard AVC/H264 decoder can also be used if these others are unavailable, although navigation in TSPE will be slower with Elecard, that's to say it will take a little while to update the video preview window each time the video position changes.
Note: TSPE does not require that you are able to play h.264 stutter-free on your hardware: as the video image is usually static TSPE can be used even on quite a low-end system.
Here is an example filtergraph for h.264 in GraphEdit.
Having working Directshow playback is important for two reasons
* The video preview window in TSPE uses Directshow to show the video
* The video bitrate assumed by the editor is (currently) based on media duration provided by the Directshow media splitter
To repeat the point: for accurate operation of TSPE, it is IMPORTANT that your playback filtergraph returns the correct duration of the media. Gabest MPEG Splitter does this. Haali usually does this, except for a small minority of files containing a PTS rollover / wraparound: that is a bug in Haali. If in doubt, check first by playing the input file in your usual media player and see if the correct duration is shown.
TIP: If you do not have good Directshow playback, perhaps for an individual problem file, TSPE can be used with the video preview window disabled. In that situation if you need accurate timings to guide your edits you will have to set the bitrate manually.
4. (Optional) In Windows you can set file type .ts (or .tp, or any other type of transport stream file) to "Open With ..." TSPE.
Simply right-click on a .ts file, select "Open With..." in the context menu, and Browse to TSPE. (You can also do this in Explorer using Tools/Folder Options/File Types.)
Quickstart for scanning
==================
Hit the 'Scan' button towards the bottom of the main window, and let TSPE do its stuff. The output of the scan will also be written in a log file. For more information, see section headed TSPE's error detection features in the Detailed Guide below.
Quickstart for editing
==================
TSPE main window. The numbered areas in this screenshot match steps 1-4 below.
1. Set the source and output files
Click "Open" to browse to the file to edit.
When the file is opened, a default name (the same filename with .edit suffixed)
will be shown in the text box next to the "Save As" button. Use the "Save As"
button to select a different output name, or just edit the name directly in the text box.
It is also possible here to enter a different drive letter in the "Save As" text box so that for example the output file will be
on drive K: where the input file is on drive J: (when editing, it is recommended that input and output file
are on two different physical drives, for speedy operation).
Note: the source file would usually have file extension .ts but it does not have to be that. In the above screenshot,
the file extension of the (fictional) input file is .tp and the output file has the same extension.
HINT: at this stage you may also want to check the configuration options are correct for your input file to avoid problems later: see the two Important notes at the start of the Detailed Guide (part 1) below.
2. Set up a Start point and End point for your edit
Use the navigation controls under the video preview window to navigate to
the Start point and the End point for your edit. The video preview window
helps you to see where your edits will be made. When you have the good Start point,
press "Set" to set it. When you have the good End point, press the other "Set" to set it.
You can navigate the video using the slider and the 'Play' button (hit the button again to Pause playback)
Alternatively use the navigation keys (see below).
HINT: usually the video preview window is accurate, but for some files it can be a few seconds out. You can use the 'Test' buttons to preview your Start point and your End point (always use "Set" button to set the Start point or End point first). Each "Test" button will create a small output file (in the same folder as the input file, and with a similar name with suffix ".test") so you can preview the edit point. For the Start point, the test file lasts for 3 seconds starting at the Start point which has been set. For the End point, the test file lasts for 3 seconds ending at the End point which has been set. It should be possible to preview the .test file while TSPE is running, just by Alt-Tabbing out of TSPE and browsing to the .test file in Windows and playing it using your normal playback software: note that some playback solutions may play the test file slightly differently (for example, with reduced resolution) while TSPE is running since both TSPE and the player are clashing for the use of the same codecs for playback.
Recommended: for new users, always set your Start point and End point at keyframes, using the IF+ and IF- buttons.
3. Store your Start point and End point in the edit decision list
The edit decision list is bottom right. Press the "Add" button to add the Start point and End point
which you have set. This will create a new line in the edit decision list, showing your Start point and End point in seconds and in bytes.
If you have multiple edits in the list and you want only one of them in the output file, either delete the others from the list or select the one you want by highlighting its row using the mouse.
4. Make your edit
Press the "Edit" button to create the output file, according to the edit decision list. (For more information, see section Using the Edit Decision List in the Detailed Guide.)
Detailed Guide (part 1)
=================
Important: For editing and navigation, set the radio buttons (bottom left) according to the type of video your file contains - h.264 (the default) or MPEG2. (This is not necessary if you only want to do an error scan.)
IMPORTANT: For editing and navigation of NTSC input files, ensure the 'Frame Rate' configuration option is correct for your file - this may need to be set manually for some NTSC sources (see Configuration Options in Part 2 below). If you notice that the video preview window does not match your 'Test' edits, or if your 'Test' edits have duration more than 3 seconds, the Frame Rate is the first thing to check.
h.264 or MPEG2 video data consists of a series of frames, which are either keyframes (sometimes called I-Frames) or non-keyframes (sometimes called B-Frames or P-Frames). Usually around one frame in every ten is a keyframe - and there are 24, 25, 30, 50 or 60 frames in total per second - so typically you will see two or three I-Frames per second. With both MPEG2 and h.264 video, the playback software can only draw the non-keyframes if it has the keyframe which comes before. If you start an edit at a point which is not the first packet in a keyframe, then in playback you may see frozen video for a few frames until the first keyframe is reached and full motion video playback begins.
Navigation buttons
+10 moves forward 10 seconds
+1 moves forward 1 second
IF+ moves forward to the next keyframe (h.264 or MPEG2: note, needs the video type radio button to be correctly set)
F+ moves forward to the next frame (h.264 or MPEG2: note, needs the video type radio button to be correctly set)
p+ moves forward by one packet
Play starts the video playing (press again to Pause)
p- moves back by one packet
F- moves back to the previous video frame (I-Frame, B-Frame or P-Frame: see note above)
IF- moves back to the previous video keyframe (I-Frame: see note above)
-1 moves back 1 second
-10 moves back 10 seconds
You can also navigate by dragging the slider in the timeline seen below the video preview window. Clicking with the mouse to the left or right of the slider moves backward or forward by 60 seconds.
To navigate to the very start of the input file (packet 0), drag the video slider all the way to the left.
To navigate to the very end of the input file (to include the final packet), drag the video slider all the way to the right and then click the "+10" button a few times to be sure it has reached the very end.
Finally, another way to navigate is to use the "Jump" button for the Start point or the End point: that will change the current location to the Start point or End point already set. (If none has yet been set this takes you to the start or end of the input file.)
Bytes, packets and time
An MPEG2 Transport Stream is a series of packets. Each packet is exactly 188 bytes long and must always start with byte (hex) 0x47. (In some streams the packets are 204 bytes including error correction code but that is unusual.)
TSPE works with these packets: edits will always be at a packet boundary. The smallest navigation step is one packet. The current packet (packet number, bytes, and seconds) is shown in the 'Current' column in the Start point / End point table:
The time in seconds is obtained by using the bitrate as provided from the same playback filters used by the video preview window. Usually (using MPEG Splitter or Haali splitter) the time is accurate but if it is not, you can set a bitrate manually: see section Bitrate Override below.
A hex dump of the current packet is shown in the large hex dump panel in the left column.
Additional information about the current packet is shown in the 'Packet Decode' information panel below the hex dump: in particular, table packets and frame headers are parsed, and timestamps (PTS or PCR) shown where present.
Packet Decode information panel showing PID, continuity counter, and PTS for the current packet
Rough guide to PIDs
Each packet has an identifier (Packet IDentifier or PID). This tells the decoding hardware what type of content the packet contains. Some common PIDs (in hex) are:
0 = PAT (Program Association Table)
1 = conditional access table
10 or FE = PMT (Program Map Table)
11 = MPEG2 video data
14 = audio data (usually AC3)
258 = MPEG2 video (standard definition)
259 = PCM stereo audio
5DE = h.264 video (BBC HDTV)
5E1 = AC3 audio (BBC HDTV)
7FF = filler, no data
Packets of several different types are muxed together to make the .ts file, for example a typical BBC h.264 mux will have mostly 5DE packets (for the video) with about 3% of the packets being 5E1 (for the audio). There will also be PIDs 00, FE and FF (tables) appearing occasionally in the mux.
Information about the packets present in the mux is shown by TSPE in the form of a PID tree. Note that this will not always include all packets in the file, for example null packets, unless a full PID scan is done. TSPE does a quick PID scan when loading the file (see Configuration Options in Part 2 below). TSPE does a full PID scan if the 'Find PIDs' button is pressed or when using the 'Scan' button.
PID tree information panel showing PIDs 0 (PAT), 1 (PMT), 5DE (h.264 video) and 5E1 (AC3 audio)
The tables (principally PAT and PMT) contain timing information and information about the other PIDs. The tables are included regularly throughout the transport stream. Most PC playback solutions will in fact work even if the tables are not present or incorrect.
Each packet also has a 4 bit continuity counter to help with detecting broadcast errors. The counter typically runs from 0 to F and then restarts at 0 again. The next packet in the stream having the same PID will have the continuity counter incremented by one. In this way the continuity counter runs in a continuous sequence within all packets of the same PID - but the continuity sequence for packets with a different PID will be different.
You can see which PIDs are in your file from the PID tree. You can also step through the different PIDs by repeatedly pressing the NPID (next PID) button: this will scan forward through the file until a new PID (different from the current packet) is found. Because video and audio PIDs are the most common, this will usually show you the video and audio PIDs; to reach the tables and other rarer PIDs you may need to press NPID many times.
You can search to see if your file contains a particular PID by entering the PID number (in hex) into the textbox and then pressing PID+ (or PID-) to look for the next packet of that PID number. This feature can be useful if your input file contains, for example, a switch from SD to HD part way through the file (assuming that the HD video has different PIDs from the SD video).
TSPE's error detection features
A major feature in TSPE 0.301 is the combined error scan - press the 'Scan' button to scan the whole input file for errors.
This scans for continuity errors (simultaneous scan in all the different PIDs) and TEI errors. It will scan the whole input file without stopping, giving you a full log of results at the end of the scan. The scan output will be displayed in the logging window and (optionally) copied to the EDL. It can also (optionally) be written in text format in an MPEG2Repair-style .log file (automatically saved in the same folder as the input file, and with a similar name).
(If you have used TSReader then you may have seen it scanning an input file for the number of continuity errors and TEI errors: apart from the nicer user interface, the main difference is that TSPE reports exactly where the errors are ... and lets you edit around them.)
A continuity error is a break in the continuity counter which is supposed to run continuously (see Rough Guide to PIDs, above). It indicates that there are likely some missing packets immediately before the reported position of the error - often referred to as a "glitch".
A TEI error means that when the capturing software captured the packet it failed a basic integrity check and was flagged as containing an error. This type of error is rarer than a continuity error. It means that the captured data is wrong - there may also be missing packets. If you often get TEI errors then you need to look at your capping hardware, as there is some kind of problem.
You can also check the particular parts of the input file using the CCS or TEI
buttons - these two buttons perform continuity scans or TEI scans.
When TSPE is doing a CCS scan, it scans only one PID at a time. The PID currently being scanned is shown in the PID textbox: a PID there can be entered manually, or a PID can be reached by pressing the NPID button until the required PID is shown - or by navigating to a packet of the required type (e.g. an I-Frame would be a video packet).
In contrast, the 'Scan' button scans all PIDs simultaneously (so that it would usually pick up at least two continuity errors at a glitch, i.e. an error in the video PID and an error in the audio PID).
You can manually step through a sequence of all packets of the same PID (skipping over packets with different PID) by setting the PID in the textbox manually (or a PID can be reached by pressing the NPID button until the required PID is shown - or by navigating to a packet of the required type (e.g. an I-Frame would be a video packet)) and then pressing the PID+ and PID- buttons. For example, this can be used to examine the hex dump around the location of a continuity error that has been found.
If an error scan is taking a long time to run, you can stop it by hitting the "Abort" button.
Note: there is a 6% chance (one in sixteen) that a loss of packets will be undetected if TSPE is scanning only a single PID using the 'CCS' button. This chance is reduced by scanning more than one PID, for example scanning both video and audio using the 'Scan' button reduces the chance of it missing a glitch to 0.4% or less.
How serious is a continuity error?
A continuity error in the first few seconds of a cap is quite normal, for example as hard-drives spin up or capping software stabilises itself. Usually when you edit you will discard the first few seconds anyhow, so this does not matter.
Most continuity errors indicate a loss of data packets in the capture (it is also possibly a fault at the transmitter).
A continuity error in audio data may cause a dropout or some other type of minor glitch.
A continuity error in MPEG2 video data will most likely cause a brief "blocky" type of video error within a frame.
A continuity error in h.264 video data will most likely cause framedrops which will look like a small (sub 1 second) freeze in the video; in a bad case the freeze can last two or three seconds. But sometimes it can be worse, with on-screen artifacting, or, (if nVidia hardware acceleration is being used) an nVidia driver crash giving a BSOD or hard reboot. The Elecard software decoder is the most robust for handling an h.264 video stream with a glitch.
Including tables in your output file
By default, when making an edit, TSPE includes two additional packets at the start of the edit which are the PAT and PMT tables. These tables are needed to make a strictly compliant MPEG2 Transport Stream file: you will see that most input files made by capping software will likewise have these two tables present (sometimes additional tables are present). TSPE finds the appropriate tables in the input file from around the location of your edit start, and creates copies of those tables as the first two packets in the output file. (The way TSPE finds these tables is fairly complex. These initial tables will not have continuity counter 0, they will have a continuity counter set to ensure no continuity error with the other PAT and PMT packets that will follow in the output file. In contrast, some pro tools will force the continuity counter of all PIDs to zero at the start of a file: TSPE does not do this.)
If the inclusion of tables causes you problems in the output file (for example, if tables were wrong in the input file, or if the input file contains multiple PIDs in different programs muxed together), then you can also try setting TSPE to include no tables in its edit. Although a file with no tables at the start is not strictly compliant, most PC playback solutions will happily play such a file (for example, a raw .ts capture from a DVB-T or satellite source will not necessarily commence with tables).
Note: unchecking 'include tables' does not cause TSPE to strip tables from the edited Transport Stream: all PIDs in the edited section are retained, including table PIDs. The 'include tables' setting only affects whether TSPE will build new tables to form the initial packets of the output file.
Of course, if the input file starts with tables, and the edit is done from the very start of the input file (packet 0) then the existing tables will be used and TSPE's "Include Tables" feature will do nothing whether enabled or disabled.
Detailed Guide (Part 2)
=================
Using the Edit Decision List
TSPE's Edit button creates an output file according to the edit points contained in the Edit Decision List (the panel at bottom right of the main screen). The Edit Decision List is also referred to as the EDL.
As noted in the Quickstart guide, step 3, you need to use the Add button when you are ready to add the Start and End points of an edit to the list. Do this before using the 'Edit' button to create your output file. If there is only one edit in the list then the 'Edit' button will use that. If there are several edits in the list then the "Edit" button will use all the selected ones. (If you do not select any then TSPE will concatenate all of them as if all were selected.)
Here there are two very similar edits in the Edit Decision List. The user now needs to highlight just one of them, before pressing the "Edit" button to create the output file
One use for the edit list is as a kind of log, if you are trying out several different Start points and End points (the Test button is also handy here, see the Hint in Quickstart step 3). If you have previously been using it as a log, make sure to select only one table row for your final output Edit - or you can of course delete all the unwanted rows using the 'Del' button.
It is also possible to include multiple different input files in the Edit Decision List (for example, you can drag and drop multiple .ts parts onto the TSPE window, and drop them onto the edit list table). This will allow you to concatenate or 'join' files. I have not yet tested this feature myself but it should work fine (please report any problems). Another major potential use for multiple input files in the Edit Decision List is to fix errors in a cap by joining chunks from two different sources: see section Introduction to fixing glitches with TSPE below.
You can navigate to the start/end point of existing entries in the Edit Decision List, by double-clicking with your left mouse button on the required row in the table: that will recover an entry from the edit table back into TSPE's Start/End point table (main window, top right). You can then use the 'Jump' buttons to navigate to the Start point or the End point.
TSPE can save the edit decision list (see the 'Save' and 'Load' buttons below the list table) and the filetype of the saved list file is .edl.
TSPE can also load a log file generated by itself or by MPEG2Repair into its EDL (use the 'Load' function to open the .log file). This will create a TSPE edit decision list based on the offsets of the errors reported in the log file, so that you can use TSPE to visually inspect the error locations and/or create a small edited chunk containing the errors.
Note that TSPE's editing function works according to byte offsets (which should be packet offsets) in the edit list: the timecodes shown in the edit list are only for information. For advanced users, it would be possible to manually edit the .edl file (or an MPEG2Repair logfile) to set the byte offsets to something different. Warning: if you edit the .edl file manually and set the byte offsets to positions which are not correct transport stream packet boundaries then TSPE's behaviour will be undefined.
Setting the bitrate manually
TSPE works on packet numbers and bytes. These are fairly meaningless numbers for most users, so to help the user it also displays the file position in seconds. TSPE calculates the time in seconds from the file position using a bitrate assumed to be constant for the file. TSPE tries to obtain bitrate data from the Directshow video graph used to preview the video and this usually works. Sometimes this time data is wrong, either because of:
(a) a timestamp (PTS) gap in the input file
(b) a PTS rollover/wraparound in the input file (the PTS rolls over to 0 approximately every 25 hours: this confuses Haali)
(c) the input file contains two types of video joined together (e.g. low bitrate channel testcard, followed by high bitrate h.264 video)
(d) other weirdness in the input file which is confusing the Directshow filtergraph.
An error in the time shown by TSPE will not cause any fault in the edit output file, but it will mean that the video preview window becomes useless: in this situation, the "Test" buttons should be used to test that edit positions are accurate.
In more detail, TSPE displays video in the video preview window according to the time calculated according to the bitrate and the current packet byte offset. So video preview seeking is by time. If TSPE has the times wrong (for any of the reasons suggested) then TSPE's video preview window will not match the actual position of the edits being made. To avoid any problems with the video preview window, the user should always use the "Test" function to test and preview edit points (alternatively, playback the final output file to ensure edits are correct). For a small problem (e.g five second PTS gap) the video preview will be almost correct but will seem to 'drift' slightly throughout the file; edits can still be made accurately by using the video preview to find the approximate position and then using the "Test" buttons iteratively until the precisely correct position is found. For a large problem, it is recommended to use TSPE's bitrate override feature, or to split your input file into two chunks with each chunk having a constant bitrate.
If there is a problem with the time display in seconds, you can override it by setting the bitrate manually in the textbox there (note: in Mbps). Note that you always have to re-open the input file before bitrate override will work.
PTS timestamps and PCR
TSPE recognises and decodes the PTS (Presentation Time Stamp) within the video stream. The PTS is a precise timecodes (in milliseconds) used by playback software to synchronise audio and video packets. The PTS is included in every video frame and audio frame packet header.
Video packets also include another timecode called the PCR. The PTS and PCR are related although the exact relationship depends on the framerate. There are 3600 PCR "ticks" per frame. Because the PCR count per second is variable depending on the framerate, the PTS is a more reliable guide to actual timings.
TSPE displays the PTS and PCR in the Packet Decode information panel if a PTS or PCR is found in the current packet. TSPE has two buttons ('PTS' and 'PCR') to scan forward through the file for the next packet containing a PTS or PCR.
The PTS is not used to calculate the times shown by TSPE for the current position nor in the edit decision list. Nor is the PTS used to control seeking in the video preview window: both of those timings depend on the bitrate assumed, as explained above.
Future versions of TSPE may make greater use of the PTS to avoid some of the problems when the assumed bitrate is incorrect. Future versions of TSPE may be able to scan for and locate PTS gaps.
Configuration Options
Video mode: MPEG2 or h.264 (default h.264) - this duplicates the radio buttons at bottom left of main window
Audio mode: AC3 or MPEG Audio (default AC3) - must be correctly set when navigating by audio frames instead of video frames
Frame +/-AV: Video mode or Audio mode (default Video mode) - switch to Audio mode for the "F+" and "F-" buttons to navigate by audio frames
Frame rate: 60/50/30/25/23.97 (normally set correctly according to input file parameters, but may need manual adjustment by the user especially for NTSC input files) - the frame rate is used for some navigation controls in conjunction with the bitrate; it may need manual adjustment especially for NTSC files which report as 29.97fps but are actually 23.97fps after 3:2 pulldown (or vice versa)
Include Packet At End Point? (default enabled) - Testing shows that the header of the video frame following the end point (i.e. the packet at the End Point) needs to be included in the output file in order for the final frame in the edit to be terminated correctly.
Auto Find PIDs? (default enabled) - When opening an input file, TSPE will perform a quick scan of the file in order to build the PID tree information. This means that it can take a couple of seconds to open a file. Files will open faster with this option switched off, in which case the PID tree can be built using the 'Find PIDs' button.
The final three options concern the logging output of the 'Scan' function:
Include PID Tree in Scan? (default enabled) - The scan log (onscreen and in the log file) will also include PID tree information.
Scan to EDL? (default enabled) - The positions of any errors found will also be copied into the edit list as edit point boundaries - the errors can then easily be "inspected" by making short edits to include the error positions (HINT: doubleclick the edit list to copy row information back up to the Start / End Point table, and then use the 'Jump' and -10 and +10 buttons to create a 20s video segment)
Scan to log? (default enabled) - When a Scan is completed, TSPE will write the output into a .log file in the same folder as the input file and with a similar name.
Introduction to fixing glitches with TSPE
One simple approach to fixing a severe glitch with TSPE is to perform two edits, one of the file up to (but not including) the bad glitch position, and one is from the glitch position onwards. If both edits are selected in the edit decision list then the output will combine both of the edits, skipping the glitch position in the middle. It is envisaged the user will set the edit points at keyframes either side of the glitch. The output file will almost certainly then contain a video freeze at the glitch position, as it moves from one keyframe to the next without the intermediate video frames, but for many people a frame drop like this is preferable to visible errors onscreen within the frame.
To reduce the effect of the glitch on audio, a more advanced approach would be to include all the good video frames up to just before the glitch position, and also include all the audio frames possible. This can be done, basically, by scanning to the glitch position (using CCS), then manually entering the audio PID, and using PID- to scan back to the last audio packet preceding the glitch. It is usually safe to use that as an end point for the edit, and you may even pick up some additional good video frames as well. Then after the glitch, include all audio packets (find ranges of audio packets using PID+) by repetitively adding audio-packet-only edits to the edit list, until you reach the next video keyframe when you can start to include the full video again.
It is also of course possible to repair glitches perfectly, if you happen to have access to two caps of the same broadcast made from the same source. If that is your situation it should be fairly simple to identify matching keyframes in the two sources using TSPE (use the hex preview to make sure, or make use of the PTS shown in the Packet Decode panel), and then to build up an edit decision list which will have the result of editing sections from both sources together to make a clean output. This could be called a "Frankencap". HINT: if doing this, you probably want to disable the option Include Packet at End Point?, so that the two sources will join together exactly correctly at the splice points.
Note: if the two sources are not derived from exactly the same broadcast, they cannot easily be joined together, both because the PTS and all other timecodes will be wrong, and because the video and audio will be encoded differently. This is because video and audio are normally encoded in realtime by the broadcaster using single-pass encoding: so (unless you are very lucky) keyframes etc in two different encodes will not match. In a bad case you might even find that PIDs, framerates or resolutions do not match.
Current limitations of TSPE
* As noted, TSPE for full functionality requires establishing a good quality Directshow playback graph for each input file in question. TSPE can be used without that but the video preview window will not work or at least it may not reflect the true edit positions.
* TSPE will be partly confused by an input file which contains PTS gaps or an input file with two or more significantly different bitrates within the same file. In that scenario the 'Test' button is useful to ensure edit start and end points are accurate, because the video preview display may not be an accurate guide: in a bad case you may also want to switch off video decoding altogether. Alternatively split the input file into two or more portions each having a constant bitrate and no PTS gaps.
* Behaviour with an input file containing multiple video streams (e.g. three different channels sharing the same mux) is undefined: although all the PIDs will be recognised and a full error scan may be done, the video preview window will not work correctly, for example it does not know which of the video streams you want to see, and also edits may be incorrect
* If using TSPE's editing functions to edit out sections in the middle of an input file (e.g. to edit commercials), the resulting output will, at minimum, contain timestamp gaps which may cause video freezes and/or seeking issues during playback. As a workaround, you may be able to fix this by demuxing and/or remuxing (for example, h.264 can be demuxed into an MKV).
Finally, we stress once again the importance of having good stable playback of your input file in WMP or a similar player, before starting trying to edit it using TSPE. Please do not ask in this thread about how to play h.264 files in WMP, there are plenty of threads in this forum about how to get h.264 playback working on your PC, and there are also details in part 3 of the Setup guide above (mods are requested please to delete such questions if this thread starts to go too far off topic). |
Quelle: http://lijg2.spaces.live.com/Blog/cns!43...6E8A7!138.entry
Aktuell scheint die 0.301 zu sein, die man bei http://www.techpowerup.com/downloads/435 runterladen kann.
Cu Selur
__________________
Hybrid
|
|
30.12.2006 16:26 |
|
|
Cela
Grünschnabel
Dabei seit: 27.01.2007
Beiträge: 2
|
|
Habe vor einigen Tagen anderswo zufällig TSPE und diese Beschreibung entdeckt und TSPE sofort an einer aktuellen Anixe HD Aufnahme (TS-Datei mit 28,8 GB, aufgenommen mit DVBViewer) ausprobiert.
Aus meiner Sicht zeigt TSPE gute Ansätze, hat aber für den praktischen Gebrauch bei größeren Dateien noch gravierende Nachteile. Vielleich liegt das aber daran, dass ich es noch nicht vernünftig bediene.
Eine detaillierte Beschreibung meiner Versuche und wie ich mit TSPE trotzdem GOP-genau schneide, findet sich in der "Beobachtungen..."-Datei.
Wäre interessant eure Erfahrungen im Umgang mit größeren H.264 Dateien zu erfahren.
Mein Nahziel wäre es, das sehr gute Bildmaterial eines H.264 TS in eine bestmögliche DVD zu konvertieren (z.B. mit DVD2SVCD oder mit Nero oder sonstwie). Mit DVD2SVCD würde ich wohl einen Avisynth-Script für H.264 benötigen. Gibt es sowas? (Ist für diese Frage vielleicht nicht das richtige Forum, aber Celur könnte es trotzdem wissen 
)
Habe auch hier ( http://www.dvbviewer.com/forum/index.php...pic=15032&st=15 ) nachgefragt.
Besten Dank
|
|
|
27.01.2007 18:49 |
|
|
Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
Themenstarter 
|
|
| Zitat: |
| Die beste Verbesserung wäre, wenn PjX und Mpeg2Schnitt H.264 direkt verarbeiten würden. |
Denke nicht das einer der beiden Authoren in absehbarer Zeit cutting support für h.264 Streams liefert.
Wegen dem schneiden einfach öfter mal die Test Funktion angucken, da mit IF+/i zwar zwischen mit I-Frames gesprungen wird, aber h264 auch IDR Frames benutzt kann es leicht zu 'Unklarheiten' beim Schnitt kommen Augenzwinkern
-> mit Test wird testweise die aktuelle GOP extrahiert, die dann einfach angucken und gut ist 
Zum Playback nutz ich Haalis Splitter (für den Container) + CoreAVC pro (für den h264 Stream) + ffdshow (für den Sound).
Cu Selur
Ps.: Falls deine Englischkenntniss brauchbar sind: http://forum.doom9.org/showthread.php?t=114361
__________________
Hybrid
|
|
|
28.01.2007 10:08 |
|
|
Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
Themenstarter
|
|
| Zitat: |
| Mein Nahziel wäre es, das sehr gute Bildmaterial eines H.264 TS in eine bestmögliche DVD zu konvertieren |
Sicher kein bestmöglicher Weg aber brauchbar gehts mit Nero Vision:
1. Haalis Splitter installieren (um den Transportstream öffnen zu können)
2. Nero Vision starten
3. DVD erstellen -> DVD Video
4. Videodatei hinzufügen (hier den Transportstream auswählen) und warten bis Nero das Material eingelesen hat
5. jetzt immer schön 'Weiter drücken' bzw. das Menü für die zusammenstellen und am Ende auf 'schreiben' drücken.
Cu Selur
__________________
Hybrid
|
|
|
30.01.2007 14:10 |
|
|
Cela
Grünschnabel
Dabei seit: 27.01.2007
Beiträge: 2
|
|
@Selur
Vielen Dank für deine Tipps. So hats geklappt.
Ohne deine Hinweise hätte ich es nicht geschafft.
Ciao Cela
|
|
|
30.01.2007 17:05 |
|
|
Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
Themenstarter
|
|
|
|
11.03.2007 08:58 |
|
|
|
