GNOME Bugzilla – Bug 659798
Segfault when you convert with audioconvert from audio file mkv to audio file avi
Last modified: 2011-09-28 11:14:39 UTC
Created attachment 197217 [details] stacktraces Utilisation: ======================== Comment: --------- Gstreamer can generate audio raw and convert for file avi, but it can't put audio raw in mkv file and after convert for file avi. I hope, you have enough information Test with audiotestsrc : ----------------------- gst-launch audiotestsrc ! "audio/x-raw-int, width=(int)32, depth=(int)32, signed=(boolean)true, endianness=(int)1234, channels=(int)2, rate=(int)48000" ! audioconvert ! avimux ! filesink location=test.avi -v Generate audio file mkv with the same audio caps : -------------------------------------------------- gst-launch audiotestsrc ! "audio/x-raw-int, width=(int)32, depth=(int)32, signed=(boolean)true, endianness=(int)1234, channels=(int)2, rate=(int)48000" ! audioconvert ! matroskamux ! filesink location=test.mkv -e Convertion from audio file mkv to audio file avi: -------------------------------------------------- gst-launch-0.10 filesrc location=test.mkv ! matroskademux name=demux ! queue ! audioconvert ! queue ! avimux bigfile=True name=mux ! progressreport update-freq=1 silent=true ! filesink location=test.avi -v Log : /GstPipeline:pipeline0/GstQueue:queue0.GstPad:sink: caps = audio/x-raw-int, width=(int)32, depth=(int)32, signed=(boolean)true, endianness=(int)1234, channels=(int)2, rate=(int)48000 /GstPipeline:pipeline0/GstQueue:queue0.GstPad:src: caps = audio/x-raw-int, width=(int)32, depth=(int)32, signed=(boolean)true, endianness=(int)1234, channels=(int)2, rate=(int)48000 /GstPipeline:pipeline0/GstAudioConvert:audioconvert0.GstPad:src: caps = audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)16, depth=(int)16, rate=(int)48000, channels=(int)2 /GstPipeline:pipeline0/GstAudioConvert:audioconvert0.GstPad:sink: caps = audio/x-raw-int, width=(int)32, depth=(int)32, signed=(boolean)true, endianness=(int)1234, channels=(int)2, rate=(int)48000 Caught SIGSEGV accessing address (nil) Processus arrêté With GDB : {{{
+ Trace 228536
Solution for the moment to convert audio file mkv to audio file avi: --------------------------------------------------------------------- gst-launch-0.10 filesrc location=test.mkv ! matroskademux name=demux ! queue ! audioconvert ! "audio/x-raw-float, width=(int)64, rate=(int)48000, channels=(int)2, endianness=(int)1234" ! audioconvert ! queue ! avimux bigfile=True name=mux ! progressreport update-freq=1 silent=true ! filesink location=test.avi -v
Segfault, so marking as NEW.
This only happens with orc, it seems to be on audioconvert. In this function: (AudioConvertPack) MAKE_PACK_FUNC_NAME (s16_le)
The input buffer's data is not aligned. If I copy the input data into an aligned buffer in matroskademux, just before sending it, it works fine. matroskademux uses a subbuffer to point to wherever in its bytestream the actual data starts. I guess it's fine most of the time, when data is some byte stream, but here it is interpreted directly as 32 bit samples without decoding, so it's not fine. I'm not totally sure at which point it makes the most sense to ensure aligned0 buffers. I'd say matroskademux, when it detects raw samples or raw video, but I'm not totally certain that's best, as it'd need redoing for every other container that might do that kind of thing.
IMHO it's audioconvert / orc's problem to handle alignment.
For raw audio we should assume an alignment of the underlying data type, e.g. 4 byte aligned for 32 bit integers/floats. Otherwise things will break for some audio sinks too for example and you don't really want to care for alignment in every single audio element. matroskademux should handle this
FWIW, orc assumes alignment of the data type too and only handles additional alignment constraints internally (which depend on the target)
Right, matroskademux it will be for 2/4 alignment, then, makes the most sense.
Created attachment 197575 [details] [review] matroskademux: ensure minimal alignment for audio/x-raw-* buffers Since matroskademux will attempt to push unaligned buffers, downstream might have trouble with those, especially if downstream uses ORC, such as audioconvert. Ensure we push buffers aligned to the basic type at least for those raw buffers.
I think that's all the caps we need this for, easy to add add for more. I don't make any attempt to support large alignments, I don't think it's really worth the trouble.
Review of attachment 197575 [details] [review]: ::: gst/matroska/matroska-demux.c @@ +3537,3 @@ + GST_BUFFER_DATA (sub) = copy; + /* Sub buffers don't have their own memory to free */ + GST_BUFFER_MALLOCDATA (sub) = copy; Better create a new buffer here, the subbuffer will still point at the parent buffer and this might confuse some code. On the new buffer use something like gst_buffer_copy_metadata() to copy all the stuff. Also better use guchar instead of unsigned char for consistency ;)
Traditionally we prefer guint8 * instead of guchar * for data. Also, for what it's worth, there's also g_memdup() which does malloc + copy in one go. (Apologies for the nitpicking.)
Created attachment 197642 [details] [review] matroskademux: ensure minimal alignment for audio/x-raw-* buffers Since matroskademux will attempt to push unaligned buffers, downstream might have trouble with those, especially if downstream uses ORC, such as audioconvert. Ensure we push buffers aligned to the basic type at least for those raw buffers.
commit 671b56f9da6ce3e337307eeba5d25b2e29645560 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Tue Sep 27 15:59:24 2011 +0100 matroskademux: ensure minimal alignment for audio/x-raw-* buffers Since matroskademux will attempt to push unaligned buffers, downstream might have trouble with those, especially if downstream uses ORC, such as audioconvert. Ensure we push buffers aligned to the basic type at least for those raw buffers. https://bugzilla.gnome.org/show_bug.cgi?id=659798