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 154744 - Time slider does not work with avi videos from Cannon SD100
Time slider does not work with avi videos from Cannon SD100
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal minor
: 0.10.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-10-07 01:25 UTC by Dennis Cranston
Modified: 2006-03-15 09:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Short sample avi for testing. (793.51 KB, application/octet-stream)
2004-10-07 19:55 UTC, Dennis Cranston
Details
Screenshot. (21.68 KB, image/png)
2004-10-09 16:31 UTC, Dennis Cranston
Details

Description Dennis Cranston 2004-10-07 01:25:54 UTC
I updated to today's latest CVS gstreamer, gst-plugins, and totem.  

When I play an AVI file recorded by my ditigal camera, totem's time slider will
jump to about the 25-50% position when the video starts.  As the avi plays the
slider slowly increments to the 100% position (as expected), but hits the 100%
position about 4-7 seconds before the video is finished playing.  Let me know if
you need a sample avi to reproduce the bug.
Comment 1 Ronald Bultje 2004-10-07 07:59:28 UTC
Yeah, a sample movie would be appreciated.
Comment 2 Dennis Cranston 2004-10-07 19:55:49 UTC
Created attachment 32365 [details]
Short sample avi for testing.

This avi is only 3 seconds.  When totem plays the clip the time slider will
begin at the 100% position.
Comment 3 Dennis Cranston 2004-10-09 16:30:19 UTC
Also if I drag the time slider, the video does not seek to the new position.  I
am attaching an odd screenshot.  Look at the 'Playing' parameters in the status
bar.  This happened afer adjusting the time slider while the avi was playing, 
Comment 4 Dennis Cranston 2004-10-09 16:31:09 UTC
Created attachment 32430 [details]
Screenshot.
Comment 5 Ronald Bultje 2004-11-22 15:29:36 UTC
I think I fixed that 'starts at 4-7s' bug, can you please check? I'm not sure
about the other bug.
Comment 6 Dennis Cranston 2004-11-22 21:18:02 UTC
Actually, I don't know if it's fixed.  The CVS head version of totem, gstreamer,
and gst-plugins results in Totem crashing when I try to play avi files.

Here is the stack trace.

Backtrace was generated from '/gnome/install/bin/totem'

Using host libthread_db library "/lib/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -161507648 (LWP 6105)]
[New Thread -169612368 (LWP 6108)]
[Thread debugging using libthread_db enabled]
[New Thread -161507648 (LWP 6105)]
[New Thread -169612368 (LWP 6108)]
[Thread debugging using libthread_db enabled]
[New Thread -161507648 (LWP 6105)]
[New Thread -169612368 (LWP 6108)]
[New Thread -167388240 (LWP 6107)]
[New Thread -164631632 (LWP 6106)]
0x00b887a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2

Thread 1 (Thread -161507648 (LWP 6105))

  • #0 _dl_sysinfo_int80
    from /lib/ld-linux.so.2
  • #1 __waitpid_nocancel
    from /lib/tls/libpthread.so.0
  • #2 libgnomeui_segv_handle
    at gnome-ui-init.c line 741
  • #3 <signal handler called>
  • #4 IA__g_logv
  • #5 IA__g_log
  • #6 IA__g_assert_warning
    at gmessages.c line 542
  • #7 bacon_video_widget_get_metadata
    at bacon-video-widget-gst.c line 2025
  • #8 bacon_video_widget_properties_update
    at bacon-video-widget-properties.c line 140
  • #9 on_got_metadata_event
    at totem.c line 1267
  • #10 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #11 IA__g_closure_invoke
    at gclosure.c line 437
  • #12 signal_emit_unlocked_R
    at gsignal.c line 2442
  • #13 IA__g_signal_emit_valist
    at gsignal.c line 2201
  • #14 IA__g_signal_emit
    at gsignal.c line 2245
  • #15 bacon_video_widget_signal_idler
    at bacon-video-widget-gst.c line 560
  • #16 g_idle_dispatch
    at gmain.c line 3821
  • #17 IA__g_main_context_dispatch
    at gmain.c line 1947
  • #18 g_main_context_iterate
    at gmain.c line 2578
  • #19 IA__g_main_loop_run
    at gmain.c line 2782
  • #20 IA__gtk_main
    at gtkmain.c line 963
  • #21 main
    at totem.c line 3997
 
Comment 7 Bastien Nocera 2004-11-22 21:55:44 UTC
Dennis, update your CVS, it's bug #158910
Comment 8 Dennis Cranston 2004-11-23 01:57:13 UTC
Bastien, 
Thanks for the quick fix.

Ronald,
No, the 'starts at 4-7s' bug has not been fixed.  Here is a link to one of my
avi files,
http://us.f1.yahoofs.com/bc/12c9ac06/bc/avi/mvi_0535.avi?BCFppoBBToCMeYah 
Sorry about the funny looking url, the file is stored in a yahoo briefcase.  The
file starts playing at the 4-5 second mark.
Comment 9 Ronald Bultje 2004-11-23 08:50:27 UTC
Core 0.8.7 or CVS? :).
Comment 10 Dennis Cranston 2004-11-23 17:14:13 UTC
Did you test with the avi file I provided you in the link above?

I am using CVS head.

$ gst-register --gst-version
GStreamer Core Library version 0.8.7.1
Comment 11 Ronald Bultje 2004-11-23 17:35:19 UTC
No, not yet, sorry. Just trying to be sure... :). I'll look.
Comment 12 Dennis Cranston 2004-11-23 20:37:35 UTC
Just in case that link doesn't work, here is a url to the briefcase webpage a
link to the file.
http://f1.pg.briefcase.yahoo.com/bc/dennis_cranston/vwp2?.tok=bcHspbUBsSKGvl5V&.dir=/avi&.dnm=mvi_0535.avi&.src=bc
Comment 13 Ronald Bultje 2004-12-03 13:56:29 UTC
I tried, and cannot reproduce it. It plays exactly as one would expect...
Comment 14 Dennis Cranston 2004-12-03 20:08:51 UTC
Well, you are luckier than me.  ;-)

What could the difference be between your test environment and mine?  Is there a
library that gstreamer depends on for avi playback?  If yes, maybe I am using a
different version of the library?  

On my test system, if I open totem and drag the avi file to it.  The video plays
fine, but the play time displayed at the bottom of totem's window starts at 4
seconds.  If I click pause the video takes about 4 seconds to actually pause,
and dragging the time slider while playing remains broken.
Comment 15 Ronald Bultje 2004-12-03 21:32:12 UTC
...

Can you try osssink and see if the 4-second-start is fixed then? Yes, I'm asking
that for a very good reason. :).
Comment 16 Dennis Cranston 2004-12-03 22:37:56 UTC
Actually I was using osssink, so I started trying the other sinks. 

The good news is that using the alsasink appears to fix the four second start
problem.  Of course, pauses are still delayed and using the time slider to seek
while the video is playing remains broken.  But it's a start. ;-)
Comment 17 Ronald Bultje 2004-12-03 23:17:23 UTC
Seeking in very short AVI files indeed appears to be problematic. I intend to
fix that at some point. ;).
Comment 18 Ronald Bultje 2005-01-03 14:35:49 UTC
seeking in very short avi files is fixed now. I still can't reproduce the
time-slider-is-wrong issue with osssink...
Comment 19 Dennis Cranston 2005-01-09 06:00:37 UTC
Ronald,  Thank you for all the hard work you are putting into gstreamer.   Your
work is much appreciated!  Using the latest version from CVS, seeking is fixed
for the avi files created by my Cannon camera.  The time-slider-is-wrong only
happens if I use the osssink (Fedora Core 3).
Comment 20 Ronald Bultje 2005-06-08 12:13:22 UTC
I had a closer look today, and can indeed reproduce it. I've seen this before,
the scheduler caches the samples internally. I don't know how to fix that, since
I cannot touch the scheduler when getting the position.
Comment 21 Andy Wingo 2005-07-15 15:37:17 UTC
Strange stuff with this file on HEAD with totem+gst 0.9. I get a total time of 2
seconds, but the slider never moves from 1 second. Frames come every second or
so. Wierd. Probably just 0.9 issues here.
Comment 22 Andy Wingo 2005-11-14 10:27:30 UTC
OK at this point the slider bar works fine in totem with 0.9, but the video's
stride is broken. I uploaded the file to
http://gstreamer.freedesktop.org/media/incoming/mvi_0535.avi
Comment 23 Dennis Cranston 2005-11-17 06:40:39 UTC
I tried totem using gstreamer 0.9.5 (CVS HEAD from 2005-11-16).  The above video
plays great and the slider works pretty well.  But, when I drag the slider
handle close to the end of the video I get the following critical message in the
terminal.

(lt-totem:12327): GStreamer-CRITICAL **: gst_event_new_newsegment: assertion
`start_value <= stop_value' failed
Comment 24 Dennis Cranston 2006-01-11 06:48:49 UTC
I retested again with gstreamer 0.10.1.  The good news is the video plays.  The bad news is now the slider does not work at all.  Once I drag the time slider to change the playing position, the video stops playing and I have to restart totem to get the video to play again.
Comment 25 Jan Schmidt 2006-02-11 23:52:06 UTC
Updating based on my testing tonight:

Using 0.10.3 of GStreamer core and gst-plugins-base, and 0.10.2 of gst-plugins-good the video plays, and I can seek around nicely. 

There is a section or several seconds about 1/3 of the way through that if I seek in that area playback doesn't resume, for some reason. Elsewhere, it finishes the seek fine.

Also, seeking to the end of the video causes criticals on the console:
** (totem:387): WARNING **: Internal data flow problem. [gstbasesink.c(1238): gst_base_sink_chain_unlocked (): /play/vbin/video-sink/bin8/xvimagesink1:
Received buffer without a new-segment. Cannot sync to clock.]

(totem:387): GStreamer-CRITICAL **: gst_event_new_new_segment: assertion `start <= stop' failed
Comment 26 Dennis Cranston 2006-02-14 02:02:17 UTC
I retested with 0.10.3 and seeking doesn't work very well.  After a seek the video will pause, but if I nudge the time slider back or forward a small amount it will begin to play again.  Kind of strange. 
Comment 27 Wim Taymans 2006-02-14 16:49:43 UTC
This is a plugins thing.
Comment 28 Dennis Cranston 2006-03-15 06:16:34 UTC
Seeking is fixed in CVS!  It looks like the following commit did the trick.  
Thanks!

2006-03-14  Tim-Philipp Müller  <tim at centricular dot net>

        * gst/avi/gstavidemux.c: (gst_avi_demux_process_next_entry):
          Catch short reads, like they might happen with truncated
          files (see #305279); remove unnecessary indentation.