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 142962 - Error converting wav file to ogg/vorbis
Error converting wav file to ogg/vorbis
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
git master
Other All
: Normal normal
: 0.8.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-05-22 14:46 UTC by Jan Schmidt
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jan Schmidt 2004-05-22 14:46:20 UTC
I'm using the following script to read a wav file and encode to ogg/vorbis:

INFILE=$1
shift
OUTFILE=$1
shift
                                                                               
                                                                       
gst-launch filesrc location="$INFILE" ! typefind ! spider ! \
audioconvert ! rawvorbisenc managed=true quality=0.85 ! { queue ! oggmux !
filesink location="$OUTFILE" } $@

The file output has 4096 null (\0) bytes at the start before the Ogg header. It
seems to be cause by a DISCONT event to new offset 4096 feeding down the
pipeline before any buffers are pushed from oggmux. rawvorbisenc and oggmux just
pass it on, resulting in filesink seeking to 4096 bytes in before data output.

My reasoning for it looks like: 
 * spider instantiates wavparse to read the file
 * wavparse does some seek in the filesrc to a different offset, resulting in a
DISCONT downstream
 * the DISCONT is passed downstream.

Since they're encoders, either oggmux or rawvorbisenc should handle this
discont, shouldn't they?
Comment 1 Ronald Bultje 2004-05-22 16:07:14 UTC
filesink should ignore the discont. Why does it handle that? Who implemented
that? This is the exact reason that downstream seeking happens via a SEEK event
and not via a DISCONT event.
Comment 2 Jan Schmidt 2004-05-22 23:40:02 UTC
Added by wim in 2002, apparently.
revision 1.3
date: 2002/06/08 15:00:30;  author: wtay;  state: Exp;  lines: +10 -0
A discont event is the right way to handle seeking on filesink IMO

Wim, do you remember your reasoning? :)

I also think that filesink should ignore the discont offset, however it is also
a problem that the offset in the event still seems to be relative to the
original file, it hasn't been transformed to match the data coming out of each
element. Shouldn't that happen the same as it would for a seek event?


Comment 3 Ronald Bultje 2004-05-27 12:06:13 UTC
oggmux now discards disconts. It's a workaround until we know if anything uses
disconts in filesink. I still think it should ignore them...

It doesn't work for me yet, however:

Starting program:
/media/gnome/src/gstreamer/gstreamer/tools/.libs/lt-gst-launch-0.8 filesrc
location=/tmp/af.wav ! spider ! rawvorbisenc managed=true quality=0.85 ! { queue
! oggmux ! filesink location=/tmp/af.ogg }
[New Thread 16384 (LWP 15294)]
RUNNING pipeline ...
[New Thread 32769 (LWP 15295)]
[New Thread 16386 (LWP 15296)]
 
(process:15294): GStreamer-CRITICAL **: file gstcaps.c: line 413
(gst_caps_get_structure): assertion `GST_IS_CAPS (caps)' failed
 
(process:15294): GStreamer-CRITICAL **: file gstcaps.c: line 576
(gst_caps_is_fixed): assertion `GST_IS_CAPS (caps)' failed
 
** (process:15294): CRITICAL **: file gstaudioconvert.c: line 329
(gst_audio_convert_parse_caps): assertion `gst_caps_is_fixed (gst_caps)' failed
 
** (process:15294): CRITICAL **: internal negotiation error
 
Program received signal SIGSEGV, Segmentation fault.

Thread 16384 (LWP 15294)

  • #0 gst_opt_scheduler_get_wrapper
    at gstoptimalscheduler.c line 1321
  • #1 gst_pad_pull
    at gstpad.c line 3241
  • #2 gst_spider_identity_dumb_loop
    at gstspideridentity.c line 435
  • #3 loop_group_schedule_function
    at gstoptimalscheduler.c line 1227
  • #4 schedule_group
    at gstoptimalscheduler.c line 1063
  • #5 gst_opt_scheduler_schedule_run_queue
    at gstoptimalscheduler.c line 1106
  • #6 schedule_chain
    at gstoptimalscheduler.c line 1154
  • #7 gst_opt_scheduler_iterate
    at gstoptimalscheduler.c line 2310
  • #8 gst_scheduler_iterate
    at gstscheduler.c line 695
  • #9 gst_bin_iterate_func
    at gstbin.c line 1121
  • #10 gst_marshal_BOOLEAN__VOID
    at gstmarshal.c line 433
  • #11 g_type_class_meta_marshal
    at gclosure.c line 514

Comment 4 Ronald Bultje 2004-05-27 12:29:39 UTC
Nevermind, works after wim's latest opt fixes.