GNOME Bugzilla – Bug 116597
wavenc doesn't rewrite header at EOS
Last modified: 2011-08-27 15:47:32 UTC
wavenc should seek to the beginning of the file and rewrite the header with the proper lengths. Does filesrc even handle this correctly?
file*sink* handles seeks, because avimux has been using it for more than a year. And avimux works for uncompressed audio. ;).
Reassigning to Iain as this is his plugin.
Should be fixed in HEAD
This bug is still present for me. I'm running Fedora Core 2 with GStreamer 0.8.1, using Sound Juicer to create the wave files. Also, when looking through the code for wavenc, I noticed that in gst_wavenc_stop_file(), there's no code to update the data at position 40, that's supposed to be the size of the data block.
Yes there is. static void gst_wavenc_stop_file (GstWavEnc * wavenc) { GstEvent *event; GstBuffer *outbuf; event = gst_event_new_seek (GST_FORMAT_BYTES | GST_SEEK_METHOD_SET, 0); gst_pad_send_event (GST_PAD_PEER (wavenc->srcpad), event); outbuf = gst_buffer_new_and_alloc (WAV_HEADER_LEN); WRITE_U32 (wavenc->header + 4, wavenc->length); memcpy (GST_BUFFER_DATA (outbuf), wavenc->header, WAV_HEADER_LEN); gst_pad_push (wavenc->srcpad, GST_DATA (outbuf)); } It first does a seek to the start of the file and then generates a new header, and sets the length. Now, whether this is working or not is a different matter, but the code is there.
OK, please correct me if I'm wrong, but shouldn't it also update the size of the data block, at position _40_, so that the bogus size set in gst_wavenc_setup() doesn't stay?
oh, I get you now... Yeah, I'll reopen this then.
it seems that its been fixed in CVS HEAD. "GST_WRITE_UINT32_LE (wavenc->header + 40, wavenc->length);"
Still seeing this as an issue. # produce 10s WAV using arecord $ arecord -d 10 -f cd -t wav arecord.wav # extract the file size from the header $ od -t d4 -j4 -N4 arecord.wav 0000004 1764036 0000010 # indeed, this is only 8 bytes less than the actual file size (what is to be expected) $ ls -l arecord.wav -rw-r----- 1 linuxluser users 1764044 Aug 27 11:03 arecord.wav #GREAT! # now the same for gstreamer whos source is a static file... $ gst-launch-0.10 filesrc location=arecord.wav ! audio/x-raw-int,rate=44100,channels=2,endianness=1234,width=16,depth=16,signed=true ! wavenc ! filesink location=gst.wav # extract what gstreamer put in the header $ od -t d4 -j4 -N4 gst.wav 0000004 1764080 0000010 # we see this is as expected, 8 bytes less than file size $ ls -l gst.wav -rw-r----- 1 linuxluser users 1764088 Aug 27 11:13 gst.wav #GREAT AGAIN! # now record from a live stream (I hit ctrl-C after 2.2 seconds)... $ gst-launch-0.10 alsasrc ! audio/x-raw-int,rate=44100,channels=2,endianness=1234,width=16,depth=16,signed=true ! wavenc ! filesink location=gst_stream.wav Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstAudioSrcClock ^CCaught interrupt -- handling interrupt. Interrupt: Stopping pipeline ... Execution ended after 2245740102 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... # sadly, we get a bogus number (almost equals 2^31) $ od -t d4 -j4 -N4 gst_stream.wav 0000004 2147418148 0000010 # which is not even close to the actual file size $ ls -l gst_stream.wav -rw-r----- 1 linuxluser users 395180 Aug 27 11:20 gst_stream.wav
More testing reveals that adding "-e" option to gst-launch allows it to send an EOS internally upon receiving a SIGINT. So I suppose it is doing the right thing. Sorry.