GNOME Bugzilla – Bug 603093
mp4 playback is jerky after being paused
Last modified: 2012-06-11 13:25:19 UTC
using totem 2.28.4-1 gstreamer0.10 0.10.25-1 gstreamer0.10-bad 0.10.17-2 gstreamer0.10-bad-plugins 0.10.17-2 gstreamer0.10-base 0.10.25-1 gstreamer0.10-base-plugins 0.10.25-1 gstreamer0.10-ffmpeg 0.10.9-1 gstreamer0.10-good 0.10.17-1 gstreamer0.10-good-plugins 0.10.17-1 gstreamer0.10-pitfdll 0.9.1.1-2 gstreamer0.10-python 0.10.17-1 gstreamer0.10-ugly 0.10.13-1 gstreamer0.10-ugly-plugins 0.10.13-1 gstreamermm 0.10.5-1 when i play a mp4 (x264 i guess), it's fine. but as soon as i hit pause, and restart the playback of the file, the playback is slighty jerky. and it's visually annoying. i guess it's a gstreamer bug ?
Seems likely. Please post a debug log as per: http://projects.gnome.org/totem/#bugs
Created attachment 148578 [details] ouput of GST_DEBUG_NO_COLOR=1 GST_DEBUG=*:2 totem 2> log i go and check if there is bug for gstreamer and fill one if none, or you do that ? i guess you can close this one
https://bugzilla.gnome.org/show_bug.cgi?id=603120
*** Bug 603120 has been marked as a duplicate of this bug. ***
Don't create new bugs for the sake of it.
That says timestamping problems: 0:00:16.057222736 25011 0x81d6080 WARN totem bacon-video-widget-gst-0.10.c:1819:bvw_bus_message_cb: Warning message: warning message from element 'autovideosink0-actual-sink-xvimage': GstMessageWarning, gerror=(GstGError)NULL, debug=(string)"gstbasesink.c\(2572\):\ gst_base_sink_is_too_late\ \(\):\ /GstPlayBin2:play/GstPlaySink:playsink0/GstBin:vbin/GstGConfVideoSink:video-sink/GstBin:bin0/GstAutoVideoSink:autovideosink0/GstXvImageSink:autovideosink0-actual-sink-xvimage:\012There\ may\ be\ a\ timestamping\ problem\,\ or\ this\ computer\ is\ too\ slow."; Whereas this says you have problems getting an audio output: 0:00:00.564856537 25011 0x81d6080 WARN jackclient gstjackaudioclient.c:290:gst_jack_audio_get_connection: could not create connection 0:00:00.566159498 25011 0x81d6080 WARN jacksink gstjackaudiosink.c:371:gst_jack_ring_buffer_open_device:<autoaudiosink0-actual-sink-jackaudio> error: Cannot connect to the Jack server (status 17) 0:00:00.577528259 25011 0x81d6080 WARN alsa gstalsa.c:124:gst_alsa_detect_formats:<autoaudiosink0-actual-sink-alsa> skipping non-int format 0:00:00.578713979 25011 0x81d6080 WARN alsa pcm_hw.c:1325:snd_pcm_hw_open: alsalib error: open /dev/snd/pcmC0D1p failed: No such file or directory 0:00:00.632561587 25011 0x81d6080 WARN jackclient gstjackaudioclient.c:290:gst_jack_audio_get_connection: could not create connection 0:00:00.632817548 25011 0x81d6080 WARN jacksink gstjackaudiosink.c:371:gst_jack_ring_buffer_open_device:<autoaudiosink1-actual-sink-jackaudio> error: Cannot connect to the Jack server (status 17) 0:00:00.636702908 25011 0x81d6080 WARN alsa gstalsa.c:124:gst_alsa_detect_formats:<autoaudiosink1-actual-sink-alsa> skipping non-int format 0:00:00.637816308 25011 0x81d6080 WARN alsa pcm_hw.c:1325:snd_pcm_hw_open: alsalib error: open /dev/snd/pcmC0D1p failed: No such file or directory What audio output are you using? What audio output is actually selected in gstreamer-properties?
i have no audio problem. I use alsa and it's what is selected in gstreamer-properties. i reverted to auto-detect now. some time ago i tried oss, so after that try, i switched back to alsa and selected it explicitly to avoid problem with old installation of OSS. i don't know why gstreamer insist on trying to use /dev/snd/pcmC0D1p which does not exists here. what i have is $ l -1 /dev/snd/* /dev/snd/controlC0 /dev/snd/hwC0D0 /dev/snd/pcmC0D0c /dev/snd/pcmC0D0p /dev/snd/pcmC0D2c /dev/snd/seq /dev/snd/timer /dev/snd/by-path: pci-0000:00:05.0@ i thought it would be better to open a bug for gstreamer if it is related to gstreamer. but if you prefer to let it for totem. let's go for it.
note the audio warning happens when i open totem. but the "timestamping problem" happen at 00:00:16 after i hit pause and play. it does happen 75% of the time when i press pause and then play. if not 90%. i must say this does not happen with avis ...
Reopening as I think the requested information has been provided.
Does this still happen in modern versions?
it does not seem to happen anymore