[FFmpeg-devel] [PATCH 3/3] [RFC] mpegts: Support seeking based on stream timestamps.

[wm4]

On Sun, 21 Sep 2014 10:17:16 +0100
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> Should should fix seeking in some blurays in combination with
> e.g. MPlayer.
> Not yet tested due to no bluray at hand.
> 
> Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> ---
>  libavformat/mpegts.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index 3434341..c04e156 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -2659,6 +2659,12 @@ void ff_mpegts_parse_close(MpegTSContext *ts)
>      av_free(ts);
>  }
>  
> +static int mpegts_read_seek(AVFormatContext *s, int stream_index,
> +                            int64_t ts, int flags)
> +{
> +    return avio_seek_time(s->pb, stream_index, ts, flags);
> +}
> +
>  AVInputFormat ff_mpegts_demuxer = {
>      .name           = "mpegts",
>      .long_name      = NULL_IF_CONFIG_SMALL("MPEG-TS (MPEG-2 Transport Stream)"),
> @@ -2668,6 +2674,7 @@ AVInputFormat ff_mpegts_demuxer = {
>      .read_packet    = mpegts_read_packet,
>      .read_close     = mpegts_read_close,
>      .read_timestamp = mpegts_get_dts,
> +    .read_seek      = mpegts_read_seek,
>      .flags          = AVFMT_SHOW_IDS | AVFMT_TS_DISCONT,
>      .priv_class     = &mpegts_class,
>  };
> @@ -2680,6 +2687,7 @@ AVInputFormat ff_mpegtsraw_demuxer = {
>      .read_packet    = mpegts_raw_read_packet,
>      .read_close     = mpegts_read_close,
>      .read_timestamp = mpegts_get_dts,
> +    .read_seek      = mpegts_read_seek,
>      .flags          = AVFMT_SHOW_IDS | AVFMT_TS_DISCONT,
>      .priv_class     = &mpegtsraw_class,
>  };

IMO this is not a good idea. Seeking should seek the stream to a
timestamp; but the demuxer will output mismatching timestamps with a
different offset!

And in general, this seems useless: if you want to fix MPlayer, what
stops you from redirecting seeks to the stream layer if needed
directly in demux_lavf.c's seek function? In general, the application
can decide much better whether it wants to seek using the packet
timestamps or the stream layer's special seek function. Also, in the
context of MPlayer, your patch might actually trigger slow operations
when playing a .ts file with cache enabled: it will have to do a
synchronous call through the stream cache layer to call the seek
function.

If we want to fix FFmpeg's native libbluray support, I think we should
export it as demuxer, which opens a .ts demuxer as "slave", and
redirects the seek operations correctly to libbluray properly. It also
could rewrite the timestamps to reflect actual playback time, so that
seeking to a time actually works as expected. (Plus removes horrible
hacks from players to display the playback time correctly.)

In general, this avio_read_seek() thing seems to be a somewhat
misguided attempt to coerce high level streaming protocols into the low
level byte-oriented "protocol" layer. Apparently it's only used by
rtmp, which does scary thing like remuxing the received data to flv,
just to bypass the protocol/demuxer separation. Newer protocol
implementations like HLS don't do this anymore, and just put everything
into the demuxer.