since some weeks, I have problems with Transport Streams that I have recorded with my Kathrein SAT receiver.
It is not only linked to one program, so it had happened for at least two different german HD programs.
I tried Handbrake version 0.9.9 and the latest highly builds (not in the logs below).

I trimmed the transport stream to a 15s clip using Avidemux. The problem is the same as of the original file.
The original file is 720p/50. No matter what framerate I select, the encoded file will be around only 11-12 frames per second.
If I use Avidemux to export an MKV version of the problematic sample, Handbrake encodes everything fine, keeping the sample rate.

1. I'm using OS X, so Videoredo is no option.
2. I have already a workflow TS -->Avidemux--> MKV -->Handbrake--> M4V that works.
3. The purpose of this post is to provide an example file that does not work with Handbrake. Since other software (e.g. VLC) are able to play the file without problem, there might be a bug in the code that is responsible for parsing the TS stream.

Just FYI. I ran a quick test to see if it works to buffer some number of frames and manually re-order the timestamps in those frames after decoding. In order to catch all the backward jumping timestamps, I had to buffer 32 frames. Playback was smooth after this, so the timestamps are truely out of order and not just randomly jumbled.

We currently already have code that buffers 8 frames and re-orders timestamps for another known error condition (broken AVI files). In theory, I could use this same code to "fix" this problem, but increasing this value to 32 means we would be consuming an additional 60MB of memory (when encoding HD, I don't even want to think about the memory consumption of 4K). And there is no guarantee that you (or someone else) won't find a stream that requires more buffering. So I really don't want to do this.

Rodeo wrote:If it works fine in VLC, maybe we could look at what they're doing?

"Fine" is probably an overstatement. It also works "fine" in avplay. I already looked at what avplay does. When it sees pts errors it makes a "guess". It's "guess" is to use dts if the number of pts errors exceeds the number of dts errors. You can see a few stutters and the A/V sync is going to be off what whatever the separation is between dts and pts. But it looks mostly "fine".

Another option would be to just advance the pts by the frame duration whenever the pts goes backwards. I tried this and it also "fixes" this stream. But this would be prone to sync drift if you have a file where timestamps actually *do* jump backward (i.e. not just out of order) for one stream and do not jump backwards for other streams in the file. I.e. the frame dropping logic in sync.c might as well be removed because it would never be invoked. Buffering frames and reordering timestamps does not have this potential for sync drift.

The avplay "guess" is better than adding frame duration IMO because it also does not have this sync drift issue (it is just permanently out of sync by some small amount, about 30ms in this sample stream).

Forgot to mention, using the patch I posted, but changing the buffer depth back to 8 looks nearly as good as avplay to me, even though it is still dropping many frames in sync.c. So this would also be "fine" by some definition of the word.

The result of a buffer depth of 8 is that one frame out of 16 is dropped due to the timestamp going backwards. The lost time is made up by one frame in the group of 16 being 2 periods long. Without the patch, the pattern of drops is irregular with frequent sequences of 8 consecutive dropped frames.

Strangely, increasing the buffer depth to 16 isn't really better than 8. Different frames are dropped, but it is still 1 in 16. A depth of 17 makes the problem go away. So the period of the out of order sequences appears to always be 17 or less frames. My guess is that a depth of 8 is enough to resolve all out of order b-frames (b-pyramid), but not enough to resolve the out of order p frame which will have the largest descrepency. I.e. There is a sequence IPBBBBBBBBBBBBBBB. The I and the Bs always resolve in less than 8 frames, but the P (which belongs at the end in display sequence) requires a depth of 17.

JohnAStebbins,
Just to be clear, are the broken and backwards time stamps a result of stream errors from satellite broadcast, or from the processing that was done in AviDemux, or is that possible to tell?

I don't know if it was AviDemux or some problem with the the encoding of the stream *pre-broadcast*. But basically, there are frames that have timestamps that indicate the frame should be played *out* of order, but the bitstream is encoded with the frames *in* order.

One way I can imagine this happening is if the broadcast transcoder or avidemux did not properly associate the timestamps with the correct frames during decoding. The decoder doesn't really need timestamps to decode. It will spit out a sequence of frames without them. But due to P and B frames, the order of the output frames will not be the same as the order they were input to the decoder. So if the transcoding software is reading a packet, parsing the pts, decoding a frame, and assiging that pts to the decoded frame, it will be assiging the pts to the wrong frame. I think some variation of this must have happened in the creation of this TS file.

PaulF wrote:Stepped through a few frames and the PTS jumped, but the the DTS didn't. A clue?

DTS is the time the frame should be presented to the input of the decoder. It *must* always be in order by spec except at stream discontinuities (which are generally rare). If DTS jumped around, you would generally treat it as a discontinuity and adjust all subsequent timestamps by the amount that it jumped.

PTS jumping around is actually normal, but it is accompanied by a resequencing of the frames during decoding such that after decoding, the timestamps are back in order. This is what is not happening with this stream. After resequencing the frames and their associated PTS by the decoder, the PTS is still out of order (i.e. not monotonically increasing).

I can assure you, that the problem is exactly the same for the original 12GB file, which has not been touched by Avidemux.
I could produce the problem anywhere in the timeline of the original file in the 15s previews of Handbrake.

I was cutting off the end (not the beginning) to make it 15s long sample which does not blow up my dropbox space.

Some of the problematic files that I have (not the one that I provided), had been edited by the Kathrein SAT receiver. I had to cut them because the movies sometimes contain 5.1 audio, but not the advertisement at the beginning. And Handbrake then only sees the 2.0. I don't know what Kathrein uses to edit files.

What surprised me was, that Avidemux somehow repairs the file during export to MKV but not to TS. And the MKV is shrinked from 12GB to 7GB. So there seems to be a lot of other stuff in the file which maybe belongs to other programs of the the same transponder.

If things are too complicated or have bad side effects , I would have a workflow that I could live with (export to MKV first). I used this workflow to encode the move of the sample and everything is fine and in sync.

Vietwoojagig wrote:Hi guys,
thank a lot for the time you spend to check this issue.

I can assure you, that the problem is exactly the same for the original 12GB file, which has not been touched by Avidemux.
I could produce the problem anywhere in the timeline of the original file in the 15s previews of Handbrake.

FYI, you don't need to use avidemux to cut a TS file. You can hack a TS file pretty much anwhere. There are no global headers to worry about, so any tool such as dd on linux/osx that can cut a segment out of a file will work.

I was cutting off the end (not the beginning) to make it 15s long sample which does not blow up my dropbox space.

Some of the problematic files that I have (not the one that I provided), had been edited by the Kathrein SAT receiver. I had to cut them because the movies sometimes contain 5.1 audio, but not the advertisement at the beginning. And Handbrake then only sees the 2.0. I don't know what Kathrein uses to edit files.

What surprised me was, that Avidemux somehow repairs the file during export to MKV but not to TS. And the MKV is shrinked from 12GB to 7GB. So there seems to be a lot of other stuff in the file which maybe belongs to other programs of the the same transponder.

If things are too complicated or have bad side effects , I would have a workflow that I could live with (export to MKV first). I used this workflow to encode the move of the sample and everything is fine and in sync.

I'm thinking I should *at least* commit my patch that enables re-ordering with a buffer depth of 8. It improves the output *and* it provides log output that alerts us that the file has timestamp problems. The log will save a lot of debug time in the future if/when others have similar problems.

JohnAStebbins wrote:FYI, you don't need to use avidemux to cut a TS file. You can hack a TS file pretty much anwhere. There are no global headers to worry about, so any tool such as dd on linux/osx that can cut a segment out of a file will work.

The sample of the first 25MB of the original transport stream (Sample-ts-25mb.ts), created with unix command dd, now works great and produces no errors.
The sample of the first 15s of the edited transport stream (Sample-ts-15s.ts), edited with Avidemux still don't work.

it supports a lot of receivers and formats that are receiver specific versions of ts (ts4, rec, etc.)

you can fix and cut your stream with it and it brings along tools to remux your stream to mp4, mkv etc.
and a lot of other tools, like a raw cutter (cut off for example 25mb but take packets into consideration)

it works just fine and if there would be any errors in the source file like time jumps it would correct them for you

Like John I guess Avidemux produces the issue as it isn't handling transport streams correctly (somthing similar could be said for smart cutter, too)

EDIT:
@John if you ask the developer (cypheros) you could probably get some help in handling TS files with errors, as he has a lot of knowledge about them