After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 556963 - h264 playback choppy on most (but not all) files
h264 playback choppy on most (but not all) files
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-libav
0.10.18
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-10-19 15:59 UTC by Maciej Katafiasz
Modified: 2010-11-23 05:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gst-lanuch dvb-t output (15.69 KB, text/plain)
2010-02-05 10:25 UTC, Karol Sobczak
Details

Description Maciej Katafiasz 2008-10-19 15:59:08 UTC
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@hatsumi:/tmp$ cat jerky.log | grep "default gsttypefindhelper.c:93:helper_find_peek" | wc -l
80985
mathrick@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.
Comment 1 Maciej Katafiasz 2008-10-19 16:07:19 UTC
Bah, Bugzilla is yelling at me for attaching large files. Here's a link instead:

http://sei.meidokon.net/files/gst/

You may notice that there is slight jumpiness in the smooth sample, that is actually bad telecine removal on framerate conversion and is the fault of the original encoder. The actual playback is fine.
Comment 2 Edward Hervey 2009-06-24 17:20:09 UTC
Maciej, could you try again with the latest gst-ffmpeg pre-release ?
Comment 3 Tobias Mueller 2010-01-05 16:34:12 UTC
Maciej: Ping
Comment 4 Karol Sobczak 2010-02-05 10:24:27 UTC
I am seeing the same behaviour with latest gst-ffmpeg (from git) release too. I am playing some raw mpeg stream and after few minutes video becomes jerky (sound is still playing good). Also I have been trying to use ffdec_h264 to decode dvb-t live stream. I have spotted that when I am playing such stream and do something that lags PC, then after a while I begin too see sideshow (one frame every second). The video never catches up again.

For playing saved raw mpegts stream I have been using this pipeline:

gst-launch-0.10 -m filesrc location=17.01.1100.ts ! mpegtsdemux name=demux0 demux0. ! queue max-size-bytes=0 max-size-buffers=0 max-sizeime=0 ! ffdec_h264 ! xvimagesink demux0. ! queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 ! flump3dec ! pulsesink

For playing dvb-t stream I have been using this pipeline:

gst-launch-0.10 -m dvbsrc pids=201:202:204 adapter=0 ! mpegtsdemux name=demux0 demux0. ! queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 ! ffdec_h264 ! xvimagesink sync=false demux0. ! queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 ! flump3dec ! pulsesink

I am attaching gst-lanuch output for dvb-t playback.
Comment 5 Karol Sobczak 2010-02-05 10:25:25 UTC
Created attachment 153069 [details]
gst-lanuch dvb-t output
Comment 6 Karol Sobczak 2010-02-05 10:57:38 UTC
(In reply to comment #4)
> I am seeing the same behaviour with latest gst-ffmpeg (from git) release too. I
> am playing some raw mpeg stream and after few minutes video becomes jerky
> (sound is still playing good). Also I have been trying to use ffdec_h264 to
> decode dvb-t live stream. I have spotted that when I am playing such stream and
> do something that lags PC, then after a while I begin too see sideshow (one
> frame every second). The video never catches up again.
> 
> For playing saved raw mpegts stream I have been using this pipeline:
> 
> gst-launch-0.10 -m filesrc location=17.01.1100.ts ! mpegtsdemux name=demux0
> demux0. ! queue max-size-bytes=0 max-size-buffers=0 max-sizeime=0 ! ffdec_h264
> ! xvimagesink demux0. ! queue max-size-bytes=0 max-size-buffers=0
> max-size-time=0 ! flump3dec ! pulsesink
> 
> For playing dvb-t stream I have been using this pipeline:
> 
> gst-launch-0.10 -m dvbsrc pids=201:202:204 adapter=0 ! mpegtsdemux name=demux0
> demux0. ! queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 !
> ffdec_h264 ! xvimagesink sync=false demux0. ! queue max-size-bytes=0
> max-size-buffers=0 max-size-time=0 ! flump3dec ! pulsesink
> 
> I am attaching gst-lanuch output for dvb-t playback.

(In reply to comment #4)
> I am seeing the same behaviour with latest gst-ffmpeg (from git) release too. I
> am playing some raw mpeg stream and after few minutes video becomes jerky
> (sound is still playing good). Also I have been trying to use ffdec_h264 to
> decode dvb-t live stream. I have spotted that when I am playing such stream and
> do something that lags PC, then after a while I begin too see sideshow (one
> frame every second). The video never catches up again.
> 
> For playing saved raw mpegts stream I have been using this pipeline:
> 
> gst-launch-0.10 -m filesrc location=17.01.1100.ts ! mpegtsdemux name=demux0
> demux0. ! queue max-size-bytes=0 max-size-buffers=0 max-sizeime=0 ! ffdec_h264
> ! xvimagesink demux0. ! queue max-size-bytes=0 max-size-buffers=0
> max-size-time=0 ! flump3dec ! pulsesink
> 
> For playing dvb-t stream I have been using this pipeline:
> 
> gst-launch-0.10 -m dvbsrc pids=201:202:204 adapter=0 ! mpegtsdemux name=demux0
> demux0. ! queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 !
> ffdec_h264 ! xvimagesink sync=false demux0. ! queue max-size-bytes=0
> max-size-buffers=0 max-size-time=0 ! flump3dec ! pulsesink
> 
> I am attaching gst-lanuch output for dvb-t playback.

Sorry, for dvb-t I have used:

gst-launch-0.10 -m dvbsrc pids=201:202:204 adapter=0 ! mpegtsdemux name=demux0
demux0. ! queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 !
ffdec_h264 ! xvimagesink demux0. ! queue max-size-bytes=0
max-size-buffers=0 max-size-time=0 ! flump3dec ! pulsesink

"sync=true"
Comment 7 Wim Taymans 2010-10-07 10:30:50 UTC
More timestamp fixes are in git now. Is this still a problem?
Comment 8 Fabio Durán Verdugo 2010-11-23 05:26:40 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!