Sync with TS timestamps and subs

[alex22]

All,
I'm heavily recording MPEG2 transport streams with my DreamBox, and I AutoGK them afterwards. In parallel, I'm also extracting the (teletext-borne) subtitles with Dave Chapman's dvbtextsubs.
All this is fine, except the sub timestamps seem to have a slight drift, correlated to spots of TS corruption.
Hence I'm wondering: what is the policy regarding the original timestamps ? Indeed, the sub timestamps are relative to the rigid, original timeline of the program (they are consistent with the timestamps in the video substream). But if frames are corrupted and dropped by the encoding process, the output timeline has gaps, which explain the drift. Is there any hope ? A flag somewhere, -rigid_timeline, which would replace dropped frames by a mere repetition of the last frame ?

TIA,

-Alex

[len0x]

Not sure I understand all this, but my suggestion is: always rebuild TS with ProjectX before feeding to AutoGK. This will ensure that stream is repaired and there will be no lost frames during encoding (as well as no a/v synch issues).

P.S. DGIndex that is used for decoding/demuxing is not that robust when dealing with broken streams (AutoGK is not really involved in this process).

[alex22]

> my suggestion is: always rebuild TS with ProjectX before feeding to
> AutoGK. This will ensure that stream is repaired and there will be
> no lost frames during encoding (as well as no a/v synch issues).

Well, in addition to extending the size of the toolchain, I can't understand how ProjectX is supposed to be smart about sub timestamps, whil it doesn't even know (AFAIK) what (teletext) subtitle is...

Again, the problem is not about the damaged TS packets themselves, but about the fact that removing them introduces discontinuities in the temporal mapping from initial stream to final AVI, while the teletext timestamps are relative to the initial stream timing.

> DGIndex that is used for decoding/demuxing is not that robust when
> dealing with broken streams

It's not that bad. I happen to use it also outside AutoGK (mainly to "GOPchop" my TS before encoding), and provided you use the 'Raw PID' detection instead of the one based on PAT/PMT, the tool is very robust.

-Alex

[len0x]

I don't understand what do you require from AutoGK then...

[alex22]

What I'm asking is: what is the end user of AutoGK supposed to do if he wants correctly timed subs ?

Maybe you could help by just identifying the tool in the chain which is at the best position to solve the problem. Perhaps it's DGIndex, perhaps it's VirtualDubMod, I don't know, you're the expert ;-) Then I'll start bugging this tool's author...

TIA,

-Alex

[len0x]

Decoding of the video is done via DGIndex/DGDecode combo. So if frames are dropped then they are dropped there only. If you want to ask specific handling of those cases you can do that in DGIndex forum.

[alex22]

Thanks, I'll start from there.
Best regards,
-Alex

[haubrija]

Originally posted by len0x
but my suggestion is: always rebuild TS with ProjectX before feeding to AutoGK. This will ensure that stream is repaired and there will be no lost frames during encoding (as well as no a/v synch issues).

Hi lenOx,

Can u let me know what settings you use in ProjectX before sending the .ts stream to AutoGK. I have thus far been unable to use ProjectX with my .ts streams as AutoGK won't encode the resulting file (I beleive due to the remapping of PIDs). I've looked for a setting to disable that but have been unsuccesful.

John

[len0x]

Sorry I missed this. I'm not dealing with TS that often. Can you please provide a sample TS file produced by ProjectX that cannot be processed by current version of AutoGK?

[len0x]

Oh, I found the problem - TS parsing was completely disabled in some cases. Fixed now (will be available in 1.90b)