Risk of explosion with .dds files
See #95 (closed) for the background to this issue. Issue #95 (closed) is very general, but one data point is that sometimes Tracker is causing desktop lockups for people when trying to process
.dds is an image format used mainly in video games and video game mods. The MIME type is detected as
image/x-dds, and due to our
90-gstreamer-image-generic.rule extract rule we end up sending the file to GStreamer.
There is no GStreamer plugin that could decode .dds files. Running tracker-extract on a random .dds file with GST_DEBUG=*:3 produced many warnings like this:
0:00:00.057568078 12862 0x7f23f80e86d0 WARN mpegaudioparse gstmpegaudioparse.c:475:gst_mpeg_audio_parse_head_check:<mpegaudioparse0> invalid bitrate: 0xf
A different file produced this:
0:00:00.058564737 12892 0x55fb9e837700 WARN discoverer gstdiscoverer.c:1584:handle_message:<mpegvparse0> Got an error [debug:gstbaseparse.c(3625): gst_base_parse_loop (): /GstPipeline:Discoverer/GstURIDecodeBin:discoverer-uri/GstDecodeBin:decodebin1/GstMpegvParse:mpegvparse0], [message:No valid frames found before end of stream]
Another produced a long stream of these warnings, and several seconds of high CPU usage:
0:00:05.267261435 2926 0x7f76780e76d0 WARN libav gstavauddec.c:756:gst_ffmpegauddec_handle_frame:<avdec_mp1float0> decoding error
Obviously the GstDiscover object is doing something wrong here.
We should do a fix on the stable branch for this. First we should specifically blacklist
image/x-dds files in
90-gstreamer-image-generic.rule. And, perhaps we could see if GstDiscoverer could be improved to avoid parsing image file formats with an MP3 decoder.