GNOME Bugzilla – Bug 652020
10MiB no_moov sanity check in qtdemux too small for valid 5D Mark II files
Last modified: 2011-06-14 10:00:39 UTC
I'm currently producing proxy versions of videos shot on a Canon 5D Mark II. On about half of the files, my transcoder is bombing out with this error: ERROR 12000 qtdemux.c(4330): gst_qtdemux_chain (): /GstPipeline:pipeline26/GstDecodeBin2:decodebin226/GstQTDemux:qtdemux26: no 'moov' atom within the first 10 MB One common theme among the 26 files I've found that cause this error is that they're all rather large. Smallest is around 1.2GB, largest around 4.2GB. I'll upload the smallest of these to the net somewhere to aid testing... would be awesome to get one of these files into the automated GStreamer tests (I spoke to Edward Hervey a bit about this at UDS/LDS in Budapest). All this video is CC-BY-SA licensed... or I could do CC-BY if that makes it easier to add to the tests. I also filed a bug about this in Launchpad: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/785748
Okay, with some friendly help from "ds" in #gstreamer, found out that this bug is being triggered because my transcode pipeline is using fdsrc instead of filesrc. (11:19:16 PM) ds: the fdsrc causes qtdemux to work in push mode, and that error is only triggered in push mode I personally still consider this a bug as there are times were dealing with file description is quite natural. Either way, here is the transcode pipeline: http://bazaar.launchpad.net/~dmedia/dmedia/trunk/view/head:/dmedia/transcoder.py
Please attach the output of running the mp4dump command on one of these files. The 10 MB sanity check kicks in after we have seen a 10 MB mdat atom while there is no moov atom in sight. Unless there is some corner case here that I'm missing (mp4dump will show), there is not much that can be done. You need to stop scanning at some point anyways, otherwise we would end up buffering e.g. such a 4.2 GB file in memory (if moov comes at the very end). The limit is quiet low with 10 MB because the intention was mainly to error out http streaming of such files on mobile devices in particular. But you say that it only happens for about half the files, so let's have a look.
Created attachment 189715 [details] gzipped output of mp4dump Okay, smallest file I have that triggers this is actually 2.25GB. If anyone is interested, you can download the full file here: http://uds-o.novacut.com/QWOAQNB2TPFLAKC5VU5UAZCXHPNVIVKU.mov I attached the gzipped output of mp4dump when run on this file. Please let me know if there is any additional information needed.
Jason, due to the fact fdsrc isn't seekable... there isn't much we can do about this. I'd strongly recommend using a seekable source instead (doesn't mean it has to be pull-based, an http source will also work fine (try opening that url in totem)). No player will be able to playback that file without seeking to the headers located at the end. You seem to have fixed that accordingly in your transcoder. Can we close this bug ?
Edward, Yeah, you can close this, thanks for taking a look at it! I got schooled on fdsrc :) Out of curiosity, would it be useful to have the output of mp4dump for a few hundred HDSLR videos? As far as editing, these cameras are the most important for Novacut. So if there is anything we can do as far as providing useful data or videos for the test suite, we're happy to help.
If that video stays up, I'll download it to add to the test suite.
Or feel free to send an old hard drive with samples on it, or bring one to the next GUADEC/Fosdem/whatever for one of us to copy them off :)
Edward: yup, that video will stay up where it is. Tim: ah, good idea! What are some confs you folks will be at in the next 6 months?
(In reply to comment #8) > Tim: ah, good idea! What are some confs you folks will be at in the next 6 > months? The GStreamer conference 2011 in October :) http://gstreamer.freedesktop.org/conference/