[Bug 651640] Qtdemux can't process fragments of ISO MP4 media file

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=651640
  GStreamer | gst-plugins-good | 0.10.29

--- Comment #4 from Christophe Dongieux <christophe.dongieux at gmail.com> 2011-06-04 10:41:07 UTC ---
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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.