[gstreamer-bugs] [Bug 556963] New: h264 playback choppy on most (but not all) files

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Sun Oct 19 08:59:10 PDT 2008


If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=556963

  GStreamer | don't know | Ver: 0.10.18
           Summary: h264 playback choppy on most (but not all) files
           Product: GStreamer
           Version: 0.10.18
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: don't know
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: bugs at mathrick.org
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


Playback is consistently choppy for about 80% of h264 streams. The exact
symptoms is that it plays a couple of frames, then pauses for 100-200ms or
thereabouts, then plays a couple of frames again. Sound playback is unaffected,
and both CPU cores on my machine are keeping cool (<35%, including a stray
flash process somewhere in the browser, eating up about 20%). Some h264
streams, however, play just fine, again with absolutely no CPU trouble. Mplayer
plays all of the files fine.

Below I include two samples, a jerky one and a smooth one, as video-only
matroska files, cut down to 1MB. Also attached are logs from the playback. One
interesting thing I noticed from the logs is this:

mathrick at hatsumi:/tmp$ cat jerky.log | grep "default
gsttypefindhelper.c:93:helper_find_peek" | wc -l
80985
mathrick at hatsumi:/tmp$ cat smooth.log | grep "default
gsttypefindhelper.c:93:helper_find_peek" | wc -l
4754

For some reason, the majority of _playback_ time in the jerky sample is spent
calling helper_find_peek; this continues and doesn't stop until the pipeline is
finally disassembled by EOS.

Filing under "don't know" initially, since I honestly don't know which
component is to blame.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=556963.




More information about the Gstreamer-bugs mailing list