GNOME Bugzilla – Bug 651640
Qtdemux can't process fragments of ISO MP4 media file
Last modified: 2011-06-04 10:41:07 UTC
Created attachment 188996 [details] 4 concatenated fragments of MP4 file, without file header Hello, I am currently working on a smooth streaming source plugin for Gstreamer. This plugin fetches mp4 fragments (a moof box + its mdat box) from a smooth streaming server and gives it to qtdemux. To verify it could be done this way, I asked on the #gstreamer IRC channel, and someone told me it should work. As an example, I downloaded 4 fragments, concatenated it to a single file, and tried to play it with gst-launch (with playbin2 or made the pipeline by hand: "gst-launch-0.10 -v filesrc location=movie.mp4 ! qtdemux ! queue ! ffdec_vc1 ! fakesink" With playbin2, decodebin2 thinks the source has "image/x-tga" as caps. With pipeline made by hand, it tries to parse the mp4 file header (ftyp, moov, ...) but doesn't find it, and complains it doesn't find any streams. You can find the 4 concatenated fragements to the single file movie.mp4 in attachment. Gstreamer version is 0.10.34, and gst-plugins-good is 0.10.29. Cheers, Christophe Dongieux.
Your file is missing the MP4 header. Could you try recreating the file with the header and see if it works?
Hello David, I recreated the file with a header and it works. You will find this file here: http://www.mediafire.com/?pfjtepo1r9jx2cs (be carefull, these 4 fragments are not the same as the ones I posted the first time) But I don't understand how qtdemux is supposed to work fine without this header, since it misses important information like the number of tracks, their type, the way they are encoded, etc. Is qtdemux supposed to work "as is" (e.g reading moof+mdat without the file header), or should we feed it with the missing information? Cheers, Christophe Dongieux.
(In reply to comment #2) > But I don't understand how qtdemux is supposed to work fine without this > header, since it misses important information like the number of tracks, their > type, the way they are encoded, etc. Nobody ever said it would work that way. No headers == broken file.
Ok, sorry then. Can you explain me how to solve my problem. I sum up: 1/ in a first place, I receive from the streaming server an XML document exposing the different tracks available (audio, video, ...), their encoding type (H264, AVC1, AAC) with the bitrate/resolution/codec_data/..., and the different chunks available with the corresponding timestamp. See an example here: http://smoothhd.code-shop.com/video/oceans.ssm/Manifest 2/ Then the client can start to ask for fragments (streamed fragments are ISO MP4 fragments) according to timestamps, and then play it. My problem is, as previously said, that the MP4 file header is not given by the streaming server. So what's the better way to deal with it? a) reconstruct the header (moov box) and put it in the gstbuffer for downstream processing (e.g. qtdemux feeding) ? b) feeding qtdemux with caps? Do you have an example for that? c) do like in a) but send it using caps and "streamheader"? (http://mediatools.cs.ucl.ac.uk/nets/newvideo/browser/gst-cvs/gstreamer/docs/random/streamheader) Also, the cool thing about smooth streaming is that the client can ask to change the resolution/bitrate of a given track, seamlessly, while playing (like "give my the chunk with timestamp n with the bitrate 2042000.", then plays it, and then "give my the chunk with timestamp n+1 with the bitrate 1340000"). So how to make aware downstream elements (at least the demuxer) that something changed without restarting the pipeline? Thanks in advance, Christophe Dongieux.