Re: subtitle and transport stream patches

Hello,

su, 2020-07-12 kello 14:54 +1000, [email protected] kirjoitti:
> > > This patch corrects the very poor synchronization between
> > > transport
> > > streams and external subtitles. It is all very well using bit
> > > rate to
> > > estimate a seek amount but it is not a good idea to feed such a
> > > coarse
> > > estimate into a subtitle stream which is trying to synchronize
> > > its output
> > > when there already exists a highly accurate pts.
> > 
> > Not applied because it breaks many TV streams that jump midway
> > through.
> > This is the reason for that bitrate estimation thing.
> > Made some compromise patch instead, try that one.
> > 
> 
> Not sure what you mean by "... jump midway though".
> My patch works ok when seeking to 10%, 20%, etc positions.
> 
> Do you mean streams where PTS has discontinuities? I have never
> seen an example of that.

Yes, discontinuities are allowed in .ts stream, there are even packet-
level markers for that.

Examples would be recorded TV broadcasts, with or without commercials
cutted out. Or BluRay streams. It is easy to create such file by just
concatenating multiple .ts clips.

BluRay menu background videos are usually just short .ts fragments
repeated and sliced together. Also in-movie discontinuities are
possible at clip boundaries. Ex. when the movie has two versions:
"normal" cut and extended version. Extended version would typically be
implemented by injecting additional clips to the playlist in middle of
"normal" version (to save space). This means either normal version or
extended version will have discontinuities.

But BluRay is not a problem, we can always use input layer timestamps
derived from playlist and clip metadata. The problem are raw .ts /
.m2ts files without any additional metadata.

> Or maybe when PTS wraps? But that can be detected automatically.

We already detect discontinuities and wraps, but the problem is with
forward seeks: one doesn't know if seek jumped over discontinuity.
Maybe this could be estimated by comparing byte offsets and timestamps
(?).

Backwards seeks should be OK (until first forward seek), as we already
know if there were discontinuities.

> :JW
> 
> 
> 
> _______________________________________________
> xine-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xine-devel