[vlc-devel] Smooth Streaming manifest, track IDs
martin at martin.st
Fri Feb 17 08:30:08 CET 2012
On Wed, 15 Feb 2012, Frederic YHUEL wrote:
> Why does the (client) manifest *not* contain the track IDs?
> I guess that what Microsoft had in mind, when they wrote the specs, is
> that the client can associate an arbitrary ID to each track. Since the
> client does know from which track belongs each chunk, all should go
I guess the reason is that it normally isn't required - each fragment only
contains data from one single track anyway. (And within one smooth
streaming presentation, the tracks might either reside in separate ismv
files and thus have overlapping track ids, or they might all be within the
same and have unique ids.)
> But the way VLC is done makes things tricky. Retrieving the "real"
> track IDs is compulsory, if we use avformat demux, and is very helpful
> otherwise (I'm working on VLC's MP4 demux).
Why do you need knowing the real track id if using the avformat demuxer?
If you use one separate demuxer for each fragment, there shouldn't be any
ambiguity, but does that have other drawbacks?
> Do you think my guess is correct? Or maybe there is a simple way to
> retrieve the track IDs after all? The only way I have in mind, is to
> pre-fetch the first (lowest quality) chunk of each track, and to parse
> the tfhd atom to finally get the track ID.
Also, a small note about prefetching (which might be informative but
probably not helpful): I guess you know that you can request
QualityLevels(...)/FragmentInfo(...) instead of Fragments. This gives you
only the moof atom, not the mdat part. This is used by the silverlight
player to fetch info about upcoming fragments (that are advertised within
the tfrf uuid tags) in live streams, without downloading the full
This is possible, since even if the client manifest explicitly contains
the spec actually mandates this to be almost literally this string,
there's not much variability. In particular, the "Fragments" string must
be exactly that, since apparently the silverlight players can swap it out
against FragmentInfo. The spec also mentions a few other similar things
that can be requested.
I'm not sure if all smooth streaming content providers actually answer to
requests for FragmentInfo though, it might have been omitted in some
implementations of static content I think, since the official silverlight
player only requests it for live streams.
More information about the vlc-devel