View Full Version : s3tots: DEVELOPMENT related information

10-23-2007, 08:53 PM
I've released a utility, s3tots to unpack mpeg2 from series 3 TY files. Please see the support thread here: http://www.dealdatabase.com/forum/showthread.php?t=57574 for more information including source&binary.

This thread is for development related information concerning s3tots. I think it'd make sense to start this off with a bit of a comparison between old TY format and s3 (version 3) TY format. This basically means a comparison between mpeg2 transport stream vs program stream:

Series 1/2 conversion or playback solutions all required converting TY streams to mpeg2 program streams. This was the logical approach as series 1/2 TY streams most closely resembled program streams, furthermore media players as well as mpeg2 authoring programs work best with program streams.

Series 3 TY streams are structured much differently. More simply actually. Series 3 TY streams most closely resemble mpeg2 transport streams. In fact they are little more than a container format around transport streams. That container format assists PVR operations such as trick-play. Gone is any need to re-mux the streams as was necessary for series 1/2 (at least for those conversion methods that cared about generating spec compliant mpeg2).

What is an mpeg2 transport stream? It is a standard mpeg2 format, most suitable for transport of recordings across lossy media (such as your cable or satellite or antenna). mpeg2 transport stream files most commonly are denoted with the ".ts" file extension. Some archaic equipment such as the MyHD tuner instead use ".trp" to mean the same thing but that's an exception not the norm.

One of the chronic problems with series 1/2 mpeg files has been transmission errors. Most media players and authoring programs do not expect transmission errors from program streams. Many programs fail horribly when they hit such an error. Especially DVD authoring software. Some TY conversion tools have tried to fix up such errors with limited success. For problem cases, a separate fix up pass with a program such as videoredo has always been in order.

For transport streams, transmission errors are considered routine and so utilities that can read transport streams will likely better handle such errors.

10-23-2007, 08:53 PM
s3tots adds standard PAT and PMT tables to the transport stream per the iso spec. These tables are missing from the transport stream found in the TY data. s3tots normally determines the PID assignments for the audio and video streams from out-of-band information stored in the TY stream directly. Failing this, s3tots can still normally auto-detect the stream PID assignments, and does a better job at it than media players IMO.

When s3tots detects the PID assignments from the TY stream directly, you'll see a diagnostic of the form:
TY set video,audio pid: 7c0,7c1. Audio is AC3
Otherwise, when s3tots determines the PID assignments from the streams
themselves (or when they change) you'll see a diagnostic of the form:
Packet 76, audio pid now 22 (vid pid 21)
Audio is now MPEG

s3tots tracks and reports on continuity errors, discontinuity flags, and warped PCR timestamps. The continuity errors and discontinuity flags are detected per the transport stream standard, not in some ad hoc fashion. This detection allows you to see when your recording has some sort of transmission glitch that may or may not result in playback/conversion problems. Basically you are getting transport stream error checking ala tsreader built in to s3tots for free.

PCR timestamps are stored as 33 bit values which wrap every ~26 hours. In practice the PCR may wrap in any TY recording as the timestamp is allowed to start off as a large number for some broadcasts. I have not seen this happen often; I think it's common for the PCR to be reset between shows at least. s3tots is careful to allow the PCR to wrap cleanly, and to preserve the timestamps provided by the source. Nonetheless, many media players hiccup when they see the PCR timestamp wrap. I have experimental code (see WARP_PCR in s3tots.c) if you wish to have s3tots renumber the PCR timestamps to avoid this issue.