[Bug 670080] New: Seeking problems on recorded mpegts streams

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=670080
  GStreamer | gst-plugins-bad | git

           Summary: Seeking problems on recorded mpegts streams
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: hk at getslash.de
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


We have problems when seeking on 'recorded' mpegts TV streams (DVB-S), that we
don't see on 'normal' mpegts video streams. When recorded DVD-S mpegts streams
(we use a Time-Shift-Server, but can be reproduced with any TV stream captured
via 'udpsrc ... ! filesink') are played back by a gstreamer-pipeline and a
seek_simple (with GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_KEY_UNIT) is issued we
see that the pipeline needs a long time to start playback again (depending on
the hardware up to a minute) and the process consumes lots of CPU and IO.

Tracing down the issue showed that after the seek LOTS of buffers are dropped
because they are too young relative to the NEW_SEGMENT that is defined after
the sseek:

mpegtsdemux
gstmpegtsdemux.c:2959:gst_mpegts_demux_sink_event:<mpegtsdemux1>ESC[00m pushing
time newsegment from 20:16:51.141321938 to 20:16:59.633147215 pos
0:00:21.224999716
...
mpeg2dec gstmpeg2dec.c:851:handle_slice:<mpeg2dec0>ESC[00m picture had pts
20:16:50.140433333, we had 20:16:50.1404333330:00:02.043965142 ESC[336m
4019ESC[00m  0x9d3a668 ESC[36mDEBUG  ESC[00m ESC[00m            
mpeg2dec gstmpeg2dec.c:1008:handle_slice:<mpeg2dec0>ESC[00m dropping buffer,
clipped
... ^^^ repeats ^^^ ....

The amount of dropped/clipped buffers seem to increase with bigger seek steps.
With longer streams and seek steps we saw > 1 minute of stream-time dropped
which means, that seeking is practically unusable.

No notable difference between souphttpsrc and filesrc.

We would like to find a solution to this problem, but don't know enough about
the internals to find out who to blame: mpegtsdemux's byte-to-time conversion?
wrong base_pts? the mpegts-stream? 

Please let us know if we can provide further information (debugging output,
ts-files, etc.)

Thanks, 
  Holger

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.