GNOME Bugzilla – Bug 654278
aiffmux creates broken files if data larger 2GB
Last modified: 2011-08-16 22:37:20 UTC
aiffmux does not write files larger than 2GB properly. saving a file larger than 2GB with this pipeline gst-launch-0.10 pulsesrc ! queue ! audio/x-raw-int,rate=44100,channels=2,width=32,depth=32 ! aiffmux ! filesink location=test.aiff the resulting file will only play the first 1h40m in totem or audacity.
Then don't use formats with 32-bit limits. :) AIFF can support 4 GB, so I suppose this is really a bug. aiffmux could be helpful and generate an error after pushing 4 GB of data.
Oddly, it worked fine for me, though using a slightly different pipeline (to avoid waiting 1h40): gst-launch audiotestsrc is-live=0 blocksize=$((1024*1024)) num-buffers=3096 ! audioconvert ! audio/x-raw-int,rate=44100,channels=2,width=32,depth=32 ! aiffmux ! filesink location=test.aiff Audacity and Totem saw the whole file of about 3 GB. There was an integer overflow though, but which would have triggered at about half a GB's size, so probably not the cause. Not sure whether it's better to drop data after 4 GB or cause a pipeline flow error though. I've done the former. Patches to folllow...
Created attachment 193922 [details] [review] aiffmux: avoid integer overflow These values are 32 bits, and width is a multiple of 8.
Created attachment 193923 [details] [review] aiffmux: use guint32 for guint32 parameters This makes explicit that the range is limited.
Created attachment 193924 [details] [review] aiffmux: drop data after 4ish GB and moan
Maybe also return GST_FLOW_UNEXPECTED which could persuade upstream to conduct end-of-file stuff ?
That's what I meant by "caus[ing] a pipeline flow error". Thing is, I'm not sure if this could cause some data to be lost a bit below the 4 GB size (eg, waiting in a queue, or something), rather than just the data above 4 GB.
Comment on attachment 193924 [details] [review] aiffmux: drop data after 4ish GB and moan Rewrote this a little (didn't like the if over two lines with casts etc.), hope I didn't mess anything up.
Not sure returning GST_FLOW_UNEXPECTED is a good idea, this may cause unnecessary data loss in other parts of the pipeline. I'm almost wondering if it wouldn't be best to just continue pushing out the data (so it gets written into the output file if possible), but just make the data size in the header ~4GB.