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 155126 - scheduling problems while dvd ripping
scheduling problems while dvd ripping
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-10-11 19:49 UTC by Tim-Philipp Müller
Modified: 2005-08-25 23:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tim-Philipp Müller 2004-10-11 19:49:15 UTC
I've got what I believe are scheduling problems when ripping a CD via 
dvdreadsrc and re-encoding it to theora/vorbis-in-ogg and writing it to file. 
Using CVS HEAD of both core and plugins. 
 
I've got 3 threads, which are embedded into the top-level thread  
 
Thread 'audio-reencode' (ar): 
 { dvddemux.audio_XX ! queue ! a52dec/mad ! audioscale ! audioconvert ! 
rawvorbisenc ! queue ! oggmux.sink_XX } 
 
Thread 'video-reencode' (vr): 
 { dvddemux.video_XX ! queue ! mpeg2dec ! deinterlace ! videoscale ! 
video/x-raw-yuv,width=xxx,height=xxx ! ffmpegcolorspace! theoraenc ! queue ! 
oggmux.sink_XX } 
 
Thread 'mux-output' (mo): 
 { oggmux ! identity ! filesink location=foo.ogg } 
 
 
Thread 'pipeline' (top-level): 
 { dvdreadsrc ! dvddemux  { audio-reencode } { video-reencode } 
{ mux-output } } 
 
 
The gst-debug=*:5 log can be found here: 
 
 http://scentric.net/tmp/log-dvd-rip-scheduling.bz2  (1.9 MB) 
 
I get this with titles from two out of five DVDs, and it always stops at 
exactly the same spot for the same title. Other titles/DVDs work fine, not 
sure why. 
 
Possibly this is also an oggmux problem, no idea. 
 
Cheers  
 -Tim
Comment 1 Tim-Philipp Müller 2004-10-12 10:31:58 UTC
Closing this as 'invalid'. I made it work using idle handlers etc. and assume 
the problem was due to changing state from within a thread's context. I still 
think this is a bug and there is a scheduling problem, but it's probably not 
of the sort that's fixable in 0.8. 
 
Cheers  
-Tim